orivej has quit [Ping timeout: 246 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 256 seconds]
h0m1 has quit [Ping timeout: 260 seconds]
h0m1 has joined #nixos-aarch64
ryantrinkle has quit [Ping timeout: 260 seconds]
cole-h has quit [Quit: Goodbye]
cole-h has joined #nixos-aarch64
<samueldr> dan_b`: might interest you, I looked into getting my motorola-addison booting again, hopefully we will be able to see how closely matched they are this way
<samueldr> at the very least, I'm curious how it'll go for wcnss wifi
<samueldr> though, I'm bringing this up because I'm curious about your device: how big is its boot partition?
<samueldr> one of the main issue with addison is how boot is 16MiB large, and images build just shy over 16MiB
<ashkitten> samueldr: what do we use udev for?
<samueldr> somehow poking the hardware or kernel so hardware shows up right
<samueldr> main culprit: storage
<ashkitten> i feel like we should be able to do without udev for that? do you have examples?
<samueldr> I don't grok what udev does, tbf, and I wouldn't mind alternatives
<samueldr> though I don't have an example of how to make things work without it
<ashkitten> ky0ko knows all about embedded, she said mdev is a good alternative but we shouldn't need any of that in an initramfs as root
<samueldr> I don't even have a clear example of a thing not working in mind, I'd have to tear things down and look at what breaks
<ashkitten> i'll try to take a look, but i'm afraid i don't have a very good device to test with due to lack of a serial cable
<samueldr> ky0ko: is mdev the busybox mdev or another one?
<ky0ko> the embedded arm systems i build (and sometimes my desktop systems) never even have an equivalent to udev in the initramfs, let alone full systemd-udevd
<ky0ko> samueldr: busybox mdev is generally fine yes
<ky0ko> there is also hotplugd
<ky0ko> neither is compatible with the .rules format of udev but provide similar functionality
<samueldr> like, I'm also not 100% positive what udev *does* that is needed here
<ky0ko> i cannot think of why it would possibly be necessary
<samueldr> hmm, I *think* I ended up needing some of the .rules from udev
<samueldr> or at least, rules fixed things (that surely can be fixed in another way)
<ky0ko> those .rules files were likely a quick solution, but certainly not the only - or even best - way to make things work if they weren't
<samueldr> note that I don't want to make the stage-1 a bizarro world where things are wildly different from nixos proper, so that makes udev (and compatible) the better options
<samueldr> ky0ko: is hotplogd the openwrt one, or is there another one?
<ashkitten> but it's unnecessarily large and there's no reason to set up devices like that until you get to stage-2
<samueldr> (openwrt seemingly is replacing it with procd which does more)
<ky0ko> yes, the openwrt one
<samueldr> thanks, I like knowing of options
<samueldr> another thing to keep in mind, I *think* phones are less embedded-ey than hardware designed to be "embedded", and it's possible that the kernels and configs from them do weird things
<samueldr> which is why we need something to react on those events and do whatever udev does
<ky0ko> i should note that where i work, we work with android platforms regularly
<ky0ko> they're as embedded as anything else i work with
<samueldr> alright
* colemickens looks over, haskell building, probably for cachix. -_-
<samueldr> though, one thing that stays true, I have zero non-public knowledge, and no mentoring, no one to ask for info, no OEM, so it's also entirely plausible I'm off base for things
<ky0ko> i think it's worth saying - and i'd love to be proven wrong - that generally, if you're being constrained to a size of 16mb for an operable system image to use as a "stage1", you're pretty much on the edge of *having* to go make the early boot stage a bizarro world where everything is different
<samueldr> yeah, though I'm trying my best not to
<ky0ko> even if it barely is over now, and you scrape it down enough to fit - in the future, functionality will be added, and it will push it back over if you don't have the space. even if you change nothing.
<samueldr> yep
<samueldr> oh, one major thing: "proper" touchscreen support without rewriting the world has dependencies on udev
<samueldr> (just remembered)
lopsided98 has quit [Remote host closed the connection]
lopsided98 has joined #nixos-aarch64
cole-h has quit [Quit: Goodbye]
cole-h has joined #nixos-aarch64
alp has joined #nixos-aarch64
cole-h has quit [Ping timeout: 256 seconds]
alp has quit [Ping timeout: 272 seconds]
pat_h has joined #nixos-aarch64
pat_h has quit [Quit: Connection closed]
wavirc22_ has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
wavirc22 has joined #nixos-aarch64
<fps> btw: i once looked into using e.g. ipfs as a way to distribute binaries for guix[sd back then]
<fps> has someone done something similar for nix?
<fps> ah ok
<Raito_Bezarius> fps: yes
<fps> looks like it
<Raito_Bezarius> there is a big issue somewhere on the nix repository
<Raito_Bezarius> nixos/nix iirc
<Raito_Bezarius> where the author of the repository you mentioned explain that ipfs seems not to be able to overcome the performance issues which you meet at nix-scale
<Raito_Bezarius> nixpkgs-scale * rather
<fps> yeah, when i tested it back then especially publishing an updated list of binaries on ipfs/ipns sucked big time
<fps> dammit. this would be such a posterchild application for functional package managers like nix and guix :
<fps> :)
<fps> if only one could lift the requirement to have a list of nars published somewhere.. hmmm..
<fps> just mentioning it in this channel because of the apparent lack of binary substitutes for aarch64 packages ;)
<srk> I was mentioning p2p and bittorrent regarding this few months before ^^ trust issues of course
<srk> managed to bootstrap most of the stuff since then so it's not that bad now but I've had to use t|hefloweringashes cache. now I have better desktop and can crosscompile most things
<srk> if only crosscompiling would produce identical binaries as native, that would be epic
<fps> srk: yeah, the trust issue is a longstanding one. i guess with selectively compiling some builds one can gain some probabilistic notion of trust in the provided binaries
<fps> but hold on. about the need for publishing a list of nars:
<Raito_Bezarius> i just use packet.com to bootstrap stuff sometimes
<srk> fps: exactly my idea but simpson quickly pointed out few other attacks :)
<Raito_Bezarius> with spot instances
<srk> intesional store could make things much easier but there's reproducibility needed on top of that as well
<fps> what's an "intentional store"?
<fps> or "intensional"?
<Raito_Bezarius> content addressed stores for example
<{^_^}> rfcs#17 (by wmertens, 2 years ago, open): [RFC 0017] Intensional Store
<{^_^}> rfcs#62 (by regnat, 23 weeks ago, open): [RFC 0062] Content-addressed paths
<srk> ,thesis
<fps> hehe, i was just thinking of "why not use the hash of the output instead of the inputs as store path"?
<Raito_Bezarius> and then you stumble into a whole part of Eelco's thesis
<fps> yeah
<fps> it has been some time since i read that ;)
<fps> ok, the intensional model is probably hard to achieve due to the not _complete_ purity of builds
<fps> bbiab
<angerman> Are there any aarch64 Amazon ec2 ami images? I can’t seem to find any?!
<angerman> There is only one, but that fails with invalid parameters.
nschoe has joined #nixos-aarch64
orivej has joined #nixos-aarch64
orivej has quit [Read error: Connection reset by peer]
orivej_ has joined #nixos-aarch64
<thefloweringash> angerman: hydra builds amazon images, and you can register them with nixos/maintainers/scripts/ec2/create-amis.sh
<sphalerite> Does anybody by any chance know if and how I can make this patch https://gitlab.freedesktop.org/tomeu/linux/-/commit/854a9ee2a93fd716e57eaf98f3b9daae2100565e into a device tree overlay?
<thefloweringash> sphalerite: at a guess: yes*. I don't think you can delete nodes, so you probably have to define an entirely separate opp table and change the pointer in `&gpu { operating-points-v2 = <...>; }`
<thefloweringash> from a skim of the driver it looks like the operating-points-v2 dt entry is skipped in the driver, so having extras around shouldn't matter
orivej_ has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 260 seconds]
orivej has joined #nixos-aarch64
orivej_ has joined #nixos-aarch64
orivej has quit [Ping timeout: 260 seconds]
<angerman> thefloweringash: hmm... I tried to import the latest one: "ClientError: EFI partition detected. UEFI booting is not supported in EC2."
<thefloweringash> Did the system value somehow get lost? IIRC uefi is required for the aarch64 machines. At least for the a1.* type.
orivej_ has quit [Ping timeout: 265 seconds]
orivej has joined #nixos-aarch64
<thefloweringash> angerman: there’s related discussion here: https://github.com/NixOS/nixpkgs/pull/62042#issuecomment-546370351
<angerman> thefloweringash: fair enough thanks!
zupo has joined #nixos-aarch64
tilpner_ has joined #nixos-aarch64
tilpner has quit [Ping timeout: 256 seconds]
tilpner_ is now known as tilpner
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Thra11 has quit [Ping timeout: 246 seconds]
<angerman> thefloweringash: what's the recommended way to run the latest create-amis.sh script? Or let's say the one in <nixpkgs>?
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-aarch64
Thra11 has joined #nixos-aarch64
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-aarch64
Darkmatter66_ has joined #nixos-aarch64
Darkmatter66 has quit [Ping timeout: 256 seconds]
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-aarch64
orivej_ has joined #nixos-aarch64
orivej has quit [Ping timeout: 246 seconds]
ryantrinkle has joined #nixos-aarch64
orivej has joined #nixos-aarch64
orivej_ has quit [Ping timeout: 272 seconds]
orivej has quit [Ping timeout: 265 seconds]
orivej_ has joined #nixos-aarch64
t184256 has left #nixos-aarch64 ["Disconnected: Replaced by new connection"]
t184256 has joined #nixos-aarch64
<adisbladis> samueldr: Why is 19.09 pinned in build.sh for the pinebook?
<adisbladis> gchristensen: How/when are keys for the community builder updated?
t184256 has left #nixos-aarch64 [#nixos-aarch64]
cole-h has joined #nixos-aarch64
<gchristensen> keys?
<clever> gchristensen: maybe ssh authorized_keys ?
<gchristensen> user's keys are updated whenever a PR is sent, and then usually teh following monday it automatically goes out, and it can go out manually sooner if needed
<adisbladis> gchristensen: Ok, could you update please? :)
<gchristensen> keys don't update automatically, you hav eto update the repo
<adisbladis> I did already
<gchristensen> oh
<gchristensen> you did? :)
<gchristensen> rip ed25519
<gchristensen> adisbladis: should be done already https://buildkite.com/grahamc/nix-community-aarch64-build-box/builds/150
<clever> gchristensen: you free to help with some gpg problems?
<gchristensen> oh god lol
<adisbladis> gchristensen: I can't log with the new key
<gchristensen> adisbladis: hm. why not I wonder
<clever> adisbladis: if you ssh -v, it should say what keys its offering
<adisbladis> I know, it's offering up the correct key
<gchristensen> 15:18:05 up 3 days 10:40, 2 users, load average: 0.01, 0.02, 0.30
<gchristensen> 3 days is not the same as 2 hours
<clever> gchristensen: pinentry used to work fine, but now that ive configured the yubikey, pinentry stuff is a total mess
<clever> either not prompting at all, or prompting in the same tty as a shell, then they take turns eating characters of the pin
<gchristensen> adisbladis: just redefine 3d to be 2h and we'll befine
<adisbladis> :D
<kloenk> clever: are you using nixos with the nixos gpg-agent module? I had no luck using it so far. The home-manager gpg-agent works better (at least on my side)
<clever> kloenk: i was starting gpg from .xsession, but something has changed with the addition of the yubikey
<clever> the nixos module rebinds the curses pinentry to each newly created tty, often leading to pw prompts over ssh to another box
<kloenk> Ok, im starting gpg-agent via systemd user service. Do you have the pcscd service enabled?
<adisbladis> clever: programs.gnupg.pinentryFlavor
<clever> kloenk: yep
<clever> adisbladis: i'll give that a try...
<adisbladis> programs.gnupg.agent.pinentryFlavor is the correct one
<adisbladis> fwiw i use the qt one
<adisbladis> gchristensen: Odd
<adisbladis> What's the contents of /etc/ssh/authorized_keys.d/adisbladis on the box ?
<gchristensen> adisbladis: the issue is likely the BMC being unhappy
<gchristensen> adisbladis: can you SSH at all?
<clever> [root@amd-nixos:~]# nixos-rebuild switch --option repeat 0
<clever> warning: ignoring the user-specified setting 'repeat', because it is a restricted setting and you are not a trusted user
<clever> building Nix...
<clever> since when is root not trusted? heh
<adisbladis> gchristensen: Yes, works just fine to other boxes
<kloenk> clever: i Think only @wheel is trusted by default, and root seems to not be in the wheel group
<kloenk> oh, sorry. The other way around. root is only trusted by default
<clever> [root@amd-nixos:~]# nix show-config | grep trusted-users
<clever> trusted-users = builder clever
<clever> kloenk: oh, maybe root isnt trusted, lol
<clever> kloenk: that fixed it
<clever> adisbladis: i think its working, i had to start the user .socket services, before i started the gpg agent .service, now the ssh agent and pinentry work...
<adisbladis> GPG agent </3
<gchristensen> adisbladis: I kicked the bmc
<clever> adisbladis: and pinentry prompts me to insert the yibikey!!
<clever> now that just leaves one minor issue, its not aware of the fact that i have 2 yubikeys with the same secrets
<adisbladis> gchristensen: Thanks :) I can't access the machine quite yet but I guess that's just a matter of a bit of time
<gchristensen> try now
<adisbladis> Yay <3
<gchristensen> ipmitool bmc reset cold ftwi
<adisbladis> Thanks ={
<adisbladis> =)
<clever> gchristensen: have you seen my haskell-init project?
<gchristensen> nope
<gchristensen> what's that?
<clever> gchristensen: a single haskell binary, compiled to a static /init, and packaged into an initrd
<gchristensen> oh cool
<gchristensen> nice
<clever> sadly, you cant keep it a single ELF binary if you want kernel modules
<clever> modprobe does some of the dynamic linking work now i believe, so getting that reproduced in haskell wouldnt be fun
<clever> and it just feels like giving up if you have to include a c binary in your pure haskell initrd :P
<gchristensen> hehehe
<clever> kexec is similar, the syscall is a lot dumber then you think
<clever> the userland tools provide some assembly stubs, to aid in the transition from one kernel to the next, sort of like a bootloader
<clever> and gcc hardening broke those stubs at once point
<gchristensen> I want a faster initrd builder
<kloenk> clever: I think there is no way to use 2 yubikeys with the same key on one device, because gpg just has one stub entry per secret
<clever> kloenk: the script i saw, would just `rm -v ~/.gnupg/private-keys-v1.d/$stuff` every time udev detects a new yubikey
<clever> kloenk: but i want to adjust that, to not destroy other keys
<kloenk> clever: sounds like a good way, just delet/move the file of the secret on that key? and the match thes keys to the yubkey serial number to move that file back?
<clever> kloenk: i think the script was using `gpg --card-status` to re-import the keys on insertion, i'll need to experiment to see what each step does and what i need
<gchristensen> I think our tool to make initrds could be MUCH faster with recursive nix
<kloenk> clever: yep `gpg --card-status` imports the key from the yubikey and creates a stub entry in the database. I belive this could have the downside of the need to be online if you change the key
<clever> gchristensen: yeah, i can see how sub-steps might be cached
<gchristensen> (cd root && find * -print0 | sort -z | cpio -o -H newc -R +0:+0 --reproducible --null | $compressor >> $out/initrd)
<gchristensen> ^ split this out in to one cpio build fper store path
<gchristensen> and then just cat them all together
<kloenk> clever: I think I have to learn haskell now. this initrd seems funny
<clever> gchristensen: though, the initrd builder tries to combine nearly everything into one storepath first
<gchristensen> the squashfs thing?
<clever> gchristensen: extra-utils
<gchristensen> link?
<gchristensen> eh?
<clever> gchristensen: this combines most of the things in the initrd into a single extra-utils path
<gchristensen> ah
<clever> even without recursive nix, you could cpio that first
<clever> and then cat it onto the other stuff
<gchristensen> ehhh I'm thinking more for netboot
<gchristensen> where almost nothing, relatively speaking, is in the extra utils :R
<gchristensen> :)
<kloenk> what is this recursive nix?
<clever> gchristensen: one sec
<gchristensen> oh neat
<clever> gchristensen: i'm not entirely sure how it works, but line 26 is fetching root.squashfs naked, then ipxe dynamically wraps it in cpio and appends to the initrd
<gchristensen> neat!
<clever> so linux thinks it was always /root.squashfs in the initrd
<gchristensen> wait, can I ipxe fetch any number of cpios
<clever> kloenk: running nix-build in nix derivations
<clever> gchristensen: this shows an example of specifying 2 initrd cmds
<kloenk> clever: ah, tried that this moring, but it doesn't work if I just do it. What do I have to do to make it work?
<clever> kloenk: do you have a version of nix beyond this pr? https://github.com/NixOS/nix/issues/13
<{^_^}> nix#13 (by edolstra, 8 years ago, open): Recursive Nix
<kloenk> clever: I use flakes, I have pinned my nix to use nix#nix
<gchristensen> clever: this is AMAZING
<clever> gchristensen: i think the magic part, is that if you specify a 2nd param to the initrd cmd, it will wrap the file in a cpio archive, rather then appending
<gchristensen> I can generate a very large netboot.ipxe file, with tons of: initrd store/8n10gaxixlm8rg6w7q8xj2nw00nqslby /nix/store/8n10gaxixlm8rg6w7q8xj2nw00nqslby-bash-interactive-4.4-p23
<clever> gchristensen: but also, the latency of having to start up a tcp connection...
<clever> does ipxe support http pipelining and keep alive?
<gchristensen> no idea
<clever> and the same problem as docker layers, you cant generate one derivation per storepath dynamically
<clever> you have to re-make all of them in one
<gchristensen> nope! recursive nix!
<clever> IFD would be needed, to know the runtime closure of the initrd, and generate the drv's for each cpio
<clever> yeah, that could also work
<clever> i also recently found an explosive memory usage problem in haskell.nix
<clever> basically, if an executable needed profiling, it would map `lib: lib.override { profiling = true; }` over all of its dependencies
<clever> and those deps, would then do the same on their deps
<clever> can you see the problem?
<gchristensen> oww yes
<clever> that was causing hydra to consume over 40gig of ram, and OOM at eval time
<kloenk> because of misconfig in my flake I got my hydra to consume 170gig of ram and then be killed by the OOM xD
<gchristensen> kloenk: nice!
<kloenk> There is defenetly better documentation needed
alp has joined #nixos-aarch64
<kloenk> clever: you can find out witch files are belonging to wich keys with this command: `gpg --list-secret-keys --with-keygrip` then you just have to move then away from the gnupg folder
<gchristensen> bah, recursive nix isn't released enough for my machine to have it yet
<clever> kloenk: the current script is using this to find the keys to nuke: [clever@amd-nixos:~]$ gpg-connect-agent 'keyinfo --list' /bye 2>/dev/null | grep -v OK | awk '{if ($4 == "T") { print $3 ".key" }}'
<kloenk> clever: ok, but do you have to be online to use that key again?
<clever> kloenk: i'm not sure which ones it listed, because they dont match `gpg -K`
<clever> kloenk: dont know
<kloenk> clever: do you have a public key url set in you yubikey?
<clever> kloenk: nope
<kloenk> clever: ok, then I guess you don't have to be online for this to work. but not sure
alp has quit [Quit: Leaving]
<gchristensen> nice.
<samueldr> adisbladis: because at the point unstable (future 20.03) didn't work right, I don't remember how
orivej_ has quit [Ping timeout: 258 seconds]
orivej has joined #nixos-aarch64
<samueldr> that repo's not being kept up-to-date well :(
orivej_ has joined #nixos-aarch64
orivej has quit [Ping timeout: 265 seconds]
orivej_ has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-aarch64
<adisbladis> samueldr: Have you done any more work on the pinebook after that ?
<adisbladis> I'm helping a friend to set it up nixos on his pinebook
<samueldr> not enough, updated the kernel, which is the last update, and that latest update makes modesetting things slow
<samueldr> I *think* because of DRM or mesa or something along the line not being at the tip of development
<samueldr> didn't dig further as time escaped me
<adisbladis> Ok
pat_h has joined #nixos-aarch64
<adisbladis> samueldr: fwiw I just built it with unstable and it boots up fine, haven't gotten to setting up X yet
<samueldr> I think it should now work fine, as I was using unstable with that latest kernel update to see if it helped
<samueldr> (with the speed issue)
<samueldr> I guess the pin can be updated, I kinda forgot it even was pinned
<samueldr> though at the same time it's good to start from a known working point, it should do it with actually pinned kernel and such too
<samueldr> or I should at least test it anew
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 272 seconds]
orivej has joined #nixos-aarch64
wavirc22 has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
wavirc22 has joined #nixos-aarch64
zupo has joined #nixos-aarch64
pat_h has quit [Ping timeout: 256 seconds]
orivej_ has joined #nixos-aarch64
orivej has quit [Ping timeout: 272 seconds]
orivej_ has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
pat_h has joined #nixos-aarch64
pat_h has quit [Ping timeout: 265 seconds]
cole-h has quit [Quit: Goodbye]
cole-h has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Thra11 has quit [Quit: WeeChat 2.8]