| 19 Mar 2022 |
 @elvishjerricco:matrix.org | Oof. Last time I was making progress on this stuff I wasn't happy that it was up to 20M | 09:42:17 |
| @elvishjerricco:matrix.org | Old is like 10M | 09:42:25 |
 bobvanderlinden | I thought first get everything working with the reusable initramfs.systemd.services. See what else needs to go in contents (hopefully only the /etc and /bin symlinks). Once that works, see whether the find-dependencies can be optimized more without missing any dependencies | 09:42:50 |
| @elvishjerricco:matrix.org | I think size takes priority over find-dependencies finding everything | 09:43:24 |
| @elvishjerricco:matrix.org | it's not such a big deal if we have to add some manual paths | 09:43:31 |
| bobvanderlinden | Ah! I compared with the original initrd, it seemed those were similar. | 09:43:42 |
| bobvanderlinden | agreed 👍️ | 09:43:51 |
| bobvanderlinden | it's fine to remove the dependency finding in arbitrary files | 09:44:44 |
| @elvishjerricco:matrix.org | We should definitely be getting rid of all the stuff like extraUnits and stuff that I did in favor of reusing the systemd modules though. | 09:46:17 |
| bobvanderlinden | it get a bit messy anyway when we want to support boot.initrd.extraUtilsCommands | 09:46:18 |
| @elvishjerricco:matrix.org | We do not want to support stuff like boot.initrd.*Commands I'm pretty sure | 09:46:37 |
| @elvishjerricco:matrix.org | That's going to be a road that leads only to madness | 09:46:45 |
| @elvishjerricco:matrix.org | Given that this should be an opt-in optional initrd, it should be clean slate | 09:46:56 |
| bobvanderlinden | I think it eases the migration from initrd to initramfs.systemd. Helps keep the PR smallish and easier to merge | 09:47:54 |
| @elvishjerricco:matrix.org | Well | 09:48:01 |
| @elvishjerricco:matrix.org | It should come in stages. | 09:48:10 |
| @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 |
