| 4 Apr 2022 |
 bobvanderlinden | https://github.com/bobvanderlinden/nixpkgs/tree/pr-systemd-initrd-luks-lvm | 16:07:05 |
| bobvanderlinden | Luks:
https://github.com/bobvanderlinden/nixpkgs/blob/pr-systemd-initrd-luks-lvm/nixos/modules/system/boot/initrd-systemd-luks.nix | 16:07:47 |
| bobvanderlinden | Udev and initial work on lvm2 are in the same directory under similar path | 16:09:11 |
 @janne.hess:helsinki-systems.de | ah great, I did it in the current luksroot module which is a bit more messy than your approach | 16:09:23 |
| bobvanderlinden | Yea we do need to find a nice way to structure the modules with all the different combinations. It would be nice if there was a initrd-systemd directory that can include them all | 16:11:02 |
| bobvanderlinden | But didn't want to conflict with other work 😅 | 16:11:28 |
| bobvanderlinden | For lvm2 I think using the ueventd variant as the package could already be a good step in the right direction. | 16:13:25 |
| @janne.hess:helsinki-systems.de | This will probably break your cryptsetup again :/ https://github.com/NixOS/nixpkgs/pull/167167 | 16:20:41 |
| @janne.hess:helsinki-systems.de | but I think it might be one of the last breakages I create 🤞 | 16:21:16 |
| bobvanderlinden | Haha I liked that pr. It does make things a bit more insightful from nix code. Though I am still interested in gathering the files using /nix/store references, as that would in theory avoid problems like not including a binary by accident or including too much without it being used. Theory is different from practice though, so it probably needs tweaking nonetheless. | 16:30:21 |
| @janne.hess:helsinki-systems.de | roberth suggested a second option that deeply traces the closure dependencies with exportReferencesGraph or something like this | 16:31:17 |
| bobvanderlinden | Ah that would satisfy my need as well 👍 good solution | 16:36:17 |
| @janne.hess:helsinki-systems.de | yeah I think doing that by default for all store paths would bloat the initrd too much | 16:36:43 |
 @arianvp:matrix.org | Janne Heß: we can probably pick flokli 's brain about the init=/systemConfig= dillemma | 16:40:22 |
| @janne.hess:helsinki-systems.de | 🧠⛏️ | 16:41:00 |
 flokli | Stop picking my brain | 16:51:46 |
| flokli | 
Download tenor_gif2894795343590525608.gif | 16:52:15 |
| @janne.hess:helsinki-systems.de | Is this enough context to understand what our discussion is? https://github.com/NixOS/nixpkgs/pull/167168#discussion_r841894434 | 17:15:56 |
| bobvanderlinden | I focused on the luks changes and updated those to the new changes on master (objects -> contents). It includes udev and luks. Draft PR: https://github.com/NixOS/nixpkgs/pull/167231 | 20:35:09 |
| @janne.hess:helsinki-systems.de | In reply to @bobvanderlinden_:matrix.org
I focused on the luks changes and updated those to the new changes on master (objects -> contents). It includes udev and luks. Draft PR: https://github.com/NixOS/nixpkgs/pull/167231 would you be okay with me potentially taking your code tomorrow and reworking it into a larger PR? | 20:55:29 |
| bobvanderlinden | yea totally. Not sure if a larger PR will be merged sooner, but it's totally fine to reuse the code/commits. | 20:56:29 |
| @janne.hess:helsinki-systems.de | I have enough mergers here 😏 | 20:56:51 |
| bobvanderlinden | haha nice :D awesome to see the collaboration here! | 20:57:11 |
| bobvanderlinden | I'm cleaning up the previous changes from make-initrd-ng, but now that there are more 'flags' for the contents file entries I think it might be better to just use a proper stdin input format (JSON?) and output a cpio file directly from the make-initrd-ng executable while we're at it (instead of piping paths from make-initrd-ng to cpio). | 20:59:51 |
| bobvanderlinden | Currently stdin expects 2 lines per file entry (1 for symlink, 1 for object). With exportReferencesGraph it would need 3 lines per file entry. It becomes a bit messy. | 21:01:33 |
| bobvanderlinden | Not sure of JSON is the right way to go, but something more structured made sense | 21:01:57 |
| @janne.hess:helsinki-systems.de | I think something as simple as a csv would be good enough. Although nix can easily serialize JSON so JSON is probably cleaner in the end | 21:03:37 |
| @janne.hess:helsinki-systems.de | ohh but this has the downside that we now need cargo dependencies (for serde) which we didn't need before | 21:03:58 |
| bobvanderlinden | indeed, same if we are using a cpio library (or libarchive binding?) | 21:04:39 |
| bobvanderlinden | not that much of a problem right? | 21:05:13 |
