<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]
<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
<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.
<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
<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?
<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
<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
<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
<{^_^}>
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…]