| 25 Apr 2023 |
 @elvishjerricco:matrix.org | * So, to me it kinda looks like once you bring in either luks or networkd, you might as well bring in full, as long as you don't pull in tpm2 by default | 00:36:01 |
 @janne.hess:helsinki-systems.de | In reply to @mlyx:matrix.org
https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/tasks/lvm.nix
Can we disable lvm by default? For those who don't use lvm, it adds lots of unnecessary stuff in initrd. I didn't to keep some backwards compat | 08:16:24 |
| @elvishjerricco:matrix.org | Yea we're hoping to maintain compat via stateVersion. | 08:17:04 |
| @elvishjerricco:matrix.org | If your stateVersion is old, then default to on like the old days | 08:17:19 |
| @elvishjerricco:matrix.org | otherwise, expect it to be explicitly set, and do so in nixos-generate-config | 08:17:38 |
| @janne.hess:helsinki-systems.de | Oh no my first state version bump in years :D | 08:17:40 |
| 26 Apr 2023 |
| @elvishjerricco:matrix.org | So I just realized that we're always pulling in all of systemd's udev rules in initrd. Is that right? | 06:48:42 |
| @elvishjerricco:matrix.org | * So I just realized that we're always pulling in all of systemd's udev rules in initrd. Is that a good idea? | 06:53:50 |
| @janne.hess:helsinki-systems.de | In reply to @elvishjerricco:matrix.org
So I just realized that we're always pulling in all of systemd's udev rules in initrd. Is that a good idea? That may be why I have to reconnect my webcam after booting with it plugged in 👀 | 07:55:23 |
 @aktaboot:tchncs.de | In reply to @elvishjerricco:matrix.org
So I just realized that we're always pulling in all of systemd's udev rules in initrd. Is that a good idea? do they take too much space for it to be a concern ? | 11:43:40 |
|  dadada changed their profile picture. | 12:49:17 |
| @elvishjerricco:matrix.org | aktaboot: I don't think so, but they might just do a bunch of Things(TM) that don't need to be done in stage 1 | 14:18:09 |
 flokli | It's not an easy yes/no question. Some stuff might need funky udev rules to get initialized. But then breaking if you then transition to another systemd/udev is a bug you'd also hit when switching to a new generation | 18:12:49 |
| flokli | It makes sense to, let's say, initialize hardware as much as possible. It usually takes a while for it to power up, and the earlier it happens the better | 18:13:30 |
| flokli | It gets tricky when you also need to load some firmware, which isn't present at that time. | 18:13:49 |
| flokli | It should just try again loading that firmware later once available? | 18:14:17 |
| flokli | Janne Heß: try checking your logs to see what kind of init your webcam does, im curious | 18:14:47 |
| @janne.hess:helsinki-systems.de | In reply to @flokli:matrix.org
Janne Heß: try checking your logs to see what kind of init your webcam does, im curious nothing special in the journal. just regular usb connection stuff | 21:34:28 |
| 27 Apr 2023 |
| @elvishjerricco:matrix.org | In reply to @janne.hess:helsinki-systems.de
I didn't to keep some backwards compat So apparently it's a little more than that. All /dev/mapper/* symlinks come from LVM's rules, and that rules file does a couple things with the dmsetup command. So maybe we can't make it optional? Without that rules file, e.g. LUKS devices wouldn't show up in /dev/mapper/ like everyone expects | 01:33:32 |
| @elvishjerricco:matrix.org | I'm not sure what happens without the dmsetup commands; I don't know if udev bails when a command fails, or if the results of that command are critical | 01:34:39 |
| 28 Apr 2023 |
| @elvishjerricco:matrix.org | My initrd is now maximally complicated. Two different LUKS volume, one TPM2 unlocked, both on ZFS zvols, one ZFS encryptionroot, custom ZFS import service, and networking with SSH and tailscale.
I can't imagine the nightmare that would have been without systemd-initrd. | 04:12:38 |
| @aktaboot:tchncs.de | In reply to @elvishjerricco:matrix.org
My initrd is now maximally complicated. Two different LUKS volume, one TPM2 unlocked, both on ZFS zvols, one ZFS encryptionroot, custom ZFS import service, and networking with SSH and tailscale.
I can't imagine the nightmare that would have been without systemd-initrd. may I ask whats your usecase for the networking part ? | 07:14:55 |
| @elvishjerricco:matrix.org | To unlock the the encrypted file system remotely over tailscale | 07:15:41 |
 @uep:matrix.org | I assume the LUKS-on-zvol are relatively small? basically key or config containers with relatively static filesystems, as a way of bootstrapping to the final zfs load-key? | 22:23:32 |
| @uep:matrix.org | (for example, to run the ssh service out of) | 22:24:35 |
| @elvishjerricco:matrix.org | uep: Exactly. The first volume, the tpm2 locked one, contains my ssh host keys and tailscale state directory. That way I can log in remotely, and the presence of correct host keys informs me that the tpm is happy with the boot measurements. The second volume is unlocked manually and contains the zfs key file | 22:24:41 |
| @uep:matrix.org | yup | 22:25:05 |
| @uep:matrix.org | why a second volume with file, rather than a passphrase directly, since you're logging in manually regardless? | 22:25:34 |
| @uep:matrix.org | (would make perfect sense as a multi-factor case, but you can't currently mix them without even more customisation) | 22:26:18 |
| @elvishjerricco:matrix.org | to get all the other nice luks-y things. Like I want to have the second volume unlocked with tpm2+pin (currently having a bug with that one), with a recovery key backup slot. | 22:26:37 |
