| 15 Nov 2022 |
 @elvishjerricco:matrix.org | we're currently just adding all fsPackages to initrd | 19:22:48 |
| @elvishjerricco:matrix.org | well, their bins anyway | 19:23:01 |
 K900 | I'm just guessing we have one already | 19:23:04 |
| K900 | And we're adding another one | 19:23:08 |
| K900 | And it blows up | 19:23:09 |
| K900 | Or something | 19:23:14 |
| @elvishjerricco:matrix.org | well we already have mount explicitly added | 19:23:15 |
| K900 | Oh | 19:23:19 |
| K900 | Yeah that would do it too | 19:23:26 |
| K900 | So I guess we can just remove that? | 19:23:41 |
| K900 | Or revert that and specifically add mount and fsck | 19:23:55 |
| @elvishjerricco:matrix.org | I added all fsPackages because it was the only sane way to get mkfs.xyz, fsck.xyz, and mount.xyz available in initrd for systemd | 19:24:02 |
| @elvishjerricco:matrix.org | * I added all fsPackages because it was the only sane way to get mkfs.xyz, fsck.xyz, and mount.xyz available in initrd for systemd | 19:24:19 |
| K900 | I'm not disagreeing with that | 19:24:29 |
| K900 | I'm disagreeing with adding all of util-linux there if anything | 19:24:43 |
| @elvishjerricco:matrix.org | my point being that putting util-linux in fsPackages seems very wrong to me | 19:24:44 |
| @elvishjerricco:matrix.org | right | 19:24:47 |
| @elvishjerricco:matrix.org | we should probably revert that commit altogether and then try to find a better way to handle whatever it was fixing | 19:25:15 |
| K900 | The commit message says it just needs fsck | 19:25:39 |
| @elvishjerricco:matrix.org | yea, and it probably should have used config.systemd.package.util-linux, since systemd can be built with other util-linux'es | 19:26:04 |
| @elvishjerricco:matrix.org | K900: though maybe we should have an initrd.fsPackages option instead | 19:27:47 |
| @elvishjerricco:matrix.org | because, as I can see if that commit's diff, we have dosftools in system.fsPackages, which almost certainly no one needs in initrd | 19:28:18 |
| @elvishjerricco:matrix.org | not sure how best to properly populate such an initrd.fsPackages option though | 19:29:18 |
| @elvishjerricco:matrix.org | really fsPackages should have been an attrset rather than a list, so we could do config.system.fsPackages.${fsType} to get the package for a given fs. Then we could have just pulled them that way for initrd for only the FSes needed by it. | 19:35:33 |
| @elvishjerricco:matrix.org | Maybe we could still do a refactor to that effect though. Something like system.fsPackageByName.${fsType}, and then have the modules that add to system.fsPackages do so like [config.system.fsPackageByName.${fsType}]; | 19:38:15 |
| @elvishjerricco:matrix.org | then we just always have fsPackageByName set for any FS supported, regardless of if it's in use | 19:39:01 |
| @elvishjerricco:matrix.org | But barring a big ole refactor like that, I think we can do it by available kernel modules. Like boot.initrd.fsPackages = map fsPackageForMod config.boot.initrd.availableKernelModules; | 19:43:04 |
 @andreas.schraegle:helsinki-systems.de | In reply to @elvishjerricco:matrix.org
because, as I can see if that commit's diff, we have dosftools in system.fsPackages, which almost certainly no one needs in initrd people with ESPs might need it | 22:19:57 |
| @elvishjerricco:matrix.org | Andreas Schrägle: I can't think of a scenario where initrd even needs to mount the ESP, let alone do anything you would do with dosfstools to it | 22:20:34 |
| @elvishjerricco:matrix.org | dosfstools would be for like... messing with the ESP somehow | 22:20:56 |
