| 19 Mar 2022 |
 @elvishjerricco:matrix.org | One PR that just adds bare bones functionality | 09:48:18 |
| @elvishjerricco:matrix.org | and one PR after another restoring old features | 09:48:25 |
| @elvishjerricco:matrix.org | The *Commands things are really really antithetical to the systemd approach in the first place | 09:48:44 |
| @elvishjerricco:matrix.org | and it's just going to make things harder anyway | 09:48:49 |
 bobvanderlinden |
Given that this should be an opt-in optional initrd, it should be clean slate
Ah like that. Merge a clean slate and start adding initramfs.systemd configs to modules that currently use extraUtilsCommands?
| 09:48:52 |
| bobvanderlinden | *
Given that this should be an opt-in optional initrd, it should be clean slate
Ah like that. Merge a clean slate and start adding initramfs.systemd configs to modules that currently use extraUtilsCommands?
| 09:49:04 |
| bobvanderlinden | indeed, alright, that also sounds like a good idea | 09:49:17 |
| @elvishjerricco:matrix.org | It shouldn't be too bad either; initrd doesn't really support that much right now | 09:49:37 |
| @elvishjerricco:matrix.org | The excessive number of LUKS features will probably be the hardest part :P | 09:49:51 |
| bobvanderlinden | at some point deprecate everything from boot.initrd | 09:49:52 |
| @elvishjerricco:matrix.org | Yea that's the hope | 09:49:58 |
| bobvanderlinden |
The excessive number of LUKS features will probably be the hardest part :P
haha indeed xD I was hoping there would be existing solutions for things like LUKS based on systemd. Haven't looked into this yet.
| 09:51:08 |
| @elvishjerricco:matrix.org | In reply to @bobvanderlinden_:matrix.org
at some point deprecate everything from boot.initrd Er, well, I guess the existing boot.initrd options will remain in place; we'll just implement them with systemd, with the exception of the *Commands ones, which would be deprecated along with the old initrd and eventually removed | 09:52:07 |
| bobvanderlinden | yes, might be good to document this plan/idea/goal in the PR. There were other people also working on initramfs+systemd, keep everyone focused on the same goal might help | 09:53:39 |
| @elvishjerricco:matrix.org | I'm likely to close it and open a new one with a clean branch and clean conversation. I'm not a fan of these commits and conversations going back and forth on the plans/goals | 09:54:43 |
| @elvishjerricco:matrix.org | But what you've done is definitely very useful | 09:55:15 |
| bobvanderlinden | Ah good, yes, I was considering doing that as well, but thought if you were working on the same things it helped having your work in my history as well. | 09:56:26 |
 Arian | Honestly I like the automatic closure copying and working around it is fragile... | 09:56:44 |
| Arian | (one of the things I don't like about the current initramfs setup) | 09:56:56 |
| @elvishjerricco:matrix.org | Arian: Unfortunately it's just not feasible for initramfs. If you just copy whole closures you get hundreds of megabytes in size. Even with the trimming on the automated stuff that I've done to get closer to that, it's still too big | 09:59:09 |
| @elvishjerricco:matrix.org | (Fun fact: My very first attempt at this task was literally creating a NixOS configuration and putting it in an initramfs; somehow this worked) | 10:00:13 |
| @elvishjerricco:matrix.org | (but it was massive) | 10:00:19 |
 colemickens | I'm increasingly curious what sorts of things get pulled in automatically that you know can be culled out. I've seen it in other places myself but curious all the same | 10:01:02 |
| bobvanderlinden | (just a small thing: the work i did with looking for /nix/store/XXXX* paths doesn't output full closures, but only individual files within closures. but, like @ElvishJerricco says, his can still lead to undesiredly large initramfs) | 10:01:07 |
| @elvishjerricco:matrix.org | yea, I know :) | 10:01:23 |
| @elvishjerricco:matrix.org | colemickens: The worst thing is crap like man pages, if you use full closures | 10:01:38 |
| @elvishjerricco:matrix.org | If you just copy the exact paths, it can still lead to stuff like full directories with too much stuff in it; like if a binary refers to its bin directory but you only need like one other binary from there | 10:02:15 |
| @elvishjerricco:matrix.org | I think systemd units sometimes put full paths in comments for like, documentation purpose? I guess? | 10:03:03 |
| colemickens | makes sense, thanks :) and thanks to y'all working on this :D | 10:03:09 |
| Arian | Problem is it's hard to prove the pruning is correct | 10:04:48 |
