| 19 Mar 2022 |
 @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 |
| bobvanderlinden |
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
Same here 😅 Haven't done any research, would be useful to do so, but at the very least it didn't pull in man pages 😄
| 10:04:51 |
| @elvishjerricco:matrix.org | Arian: Yea, it's definitely a labor intensive thing to get initramfs exactly right. I think there's no way around this | 10:05:18 |
| @elvishjerricco:matrix.org | It's why we have the escape hatch of manually specifying paths to include | 10:05:40 |
| Arian | I dont really recall anymore how large my systemd initrd was without any optimisations but it wasn't too bad | 10:05:45 |
| @elvishjerricco:matrix.org | And I also intend to have a manual exclusion list | 10:05:52 |
| Arian | do we have some target we want to optimise for? I supposed 1/2 the amount of minimal RAM we recommend? | 10:06:03 |
| @elvishjerricco:matrix.org | Arian: The best I've gotten is about 20M and that's still too much | 10:06:07 |
| Arian | why is 20M too much? | 10:06:14 |
| @elvishjerricco:matrix.org | Because I don't want the new initramfs to be twice as big as the old one | 10:06:27 |
| Arian | why not? | 10:06:32 |
| @elvishjerricco:matrix.org | And a lot of people have small /boot partitions | 10:06:34 |
| Arian | ah yeh that's a good argument | 10:06:42 |
| @elvishjerricco:matrix.org | it's already a problem for plenty of users to see /boot filling up | 10:06:44 |
| bobvanderlinden | Hmm, at the moment, mine is 18M (/boot/kernels/9cvnrh9wh6r707klrv7aawl8zm8w22rs-initrd-linux-5.15.27-initrd) | 10:07:08 |
