| 19 Mar 2022 |
 bobvanderlinden | the tool doesn't write to files/directories anymore | 09:33:06 |
 @elvishjerricco:matrix.org | bobvanderlinden: Sure, but that's not what I meant | 09:34:19 |
| @elvishjerricco:matrix.org | it's just searching for any /nix/store/XXXXXXX... path in any file and adding that to the list, right? | 09:34:34 |
| bobvanderlinden | ah, yes, if it is not an ELF file, it will do that. I gathered it can be optimized a bit by detecting a text-file for instance | 09:35:20 |
| bobvanderlinden | * ah, yes, if it is not an ELF file, it will do that. I gathered it can be optimized a bit by detecting a text-file for instance, but I haven't implemented that yet. | 09:35:38 |
| @elvishjerricco:matrix.org | Hmm... I dunno whether or not that's a good idea | 09:35:39 |
| @elvishjerricco:matrix.org | It could definitely lead to excessive inclusions | 09:35:51 |
| @elvishjerricco:matrix.org | and initramfs really needs to be lean | 09:36:03 |
| @elvishjerricco:matrix.org | Not even close to as bad as copying whole nix closure of course, but I'd be curious to know if it tends to make the initramfs noticeably bigger | 09:36:55 |
| bobvanderlinden | Well, the idea was that if you refer to files in initramfs.systemd.services (directly or indirectly), it'll copy those automatically. You only need to add things to initramfs.contents if those files were missed. That shouldn't happen that often. | 09:37:32 |
| @elvishjerricco:matrix.org | yea, I was going to add stuff specifically for parsing Exec* options in service files to make sure it was as minimal as possible, rather than just any referenced path | 09:38:14 |
| bobvanderlinden | I see that as an optimization ;) it's good to do so. My solution is crude indeed, but it does get the job done, also for things like initramfs.systemd.services.myservice.script = "... ${somePackage}/bin/something ..."; where ExecStart refers to a bash script, that refers to a bin file. It can go deep I guess 😅 | 09:40:43 |
| @elvishjerricco:matrix.org | we'll have to play with it and see the size consequences | 09:41:35 |
| bobvanderlinden | The initramfs of mine was 30M last time I ran it | 09:41:56 |
| @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 |
