| 15 Jun 2023 |
 @lily:lily.flowers | I would be down for something new though | 14:24:16 |
| @lily:lily.flowers | In reply to @elvishjerricco:matrix.org
It'd probably be easier to replace plymouth altogether with a totally new thing tbh Also I'm gonna have the builtins.storeDir stuff pushed in a bit. Waiting on something and then going to test it against my flake matrix of VMs for testing plymouth across several common configs | 14:24:59 |
 @elvishjerricco:matrix.org |
my flake matrix of VMs for testing plymouth across several common configs
Well that sounds fancy
| 14:25:36 |
| @lily:lily.flowers | It's not as fancy as it sounds. It's pretty hacky and I threw it together way too fast. But it does let me cycle through a bunch of VMs for systemd-initrd, stage-1-initrd, luks, different themes that depend or don't depend on bgrt, etc | 14:26:22 |
| @elvishjerricco:matrix.org | that's pretty cool | 14:26:49 |
| @lily:lily.flowers | I'll share if you want. Just don't look at the crimes I did to make LUKS work... | 14:27:12 |
| @elvishjerricco:matrix.org | lol yea it'd probably be helpful for testing it | 14:28:42 |
| @lily:lily.flowers | Okay, I'll clean up the LUKS a little and post it | 14:29:05 |
 K900 (deprecated) | Time to RIIR Plymouth? | 14:36:10 |
| @elvishjerricco:matrix.org | In reply to @k900:conduit.0upti.me
Time to RIIR Plymouth? I do legitimately wonder how hard that would be. Like it'd be cool to scope out just how much stuff plymouth actually does. I'm sure samueldr has actually done most of this for his mobile NixOS stage 1 boot splash / osk | 14:38:59 |
 @uep:matrix.org | Hm. Helping someone with an install, they did:
fileSystems."/boot" =
{
device = "/dev/disk/by-uuid/7CBF-1A69";
fsType = "zfs";
};
(wrong fstype)
| 16:12:37 |
| @uep:matrix.org | but the result is that it inferred a pool name of "" | 16:12:54 |
| @uep:matrix.org | and added a job to import that pool, which is of course failing. | 16:13:13 |
| @uep:matrix.org | seems like there's room for an assertion that the pool name isn't blank | 16:13:28 |
| @elvishjerricco:matrix.org | Oh that's... interesting | 16:13:34 |
| @elvishjerricco:matrix.org | Yea for sure | 16:13:37 |
| @uep:matrix.org | somewhere in here:
datasetToPool = x: elemAt (splitString "/" x) 0;
fsToPool = fs: datasetToPool fs.device;
zfsFilesystems = filter (x: x.fsType == "zfs") config.system.build.fileSystems;
allPools = unique ((map fsToPool zfsFilesystems) ++ cfgZfs.extraPools);
rootPools = unique (map fsToPool (filter fsNeededForBoot zfsFilesystems));
| 16:22:40 |
| @uep:matrix.org | or, misplaced in the thing that creates the import service, I guess | 16:23:00 |
| @uep:matrix.org | * or, misplaced in the thing that creates the import service, just below, I guess | 16:23:08 |
| @elvishjerricco:matrix.org | I'd just add a NixOS style assertion like assertions = [{ assertion = !(elem "" allPools); message = "pls no"; }] | 16:24:53 |
| @uep:matrix.org | well, that will fail but not helpfully? | 16:26:15 |
| @elvishjerricco:matrix.org | I mean failure is the only useful outcome | 16:26:31 |
| @uep:matrix.org | but yes, it does fit there | 16:26:33 |
| @elvishjerricco:matrix.org | So the message just needs to be helpful | 16:26:37 |
| @elvishjerricco:matrix.org | I just didn't bother to write one because I'm on my phone :P | 16:26:50 |
| @uep:matrix.org | yeah but it cant point to the dataset | 16:27:05 |
| @elvishjerricco:matrix.org | Sure it can | 16:27:12 |
| @elvishjerricco:matrix.org | Oh | 16:27:16 |
| @elvishjerricco:matrix.org | Wait I see what you mean | 16:27:20 |
| @elvishjerricco:matrix.org | It can name the mountpoint though | 16:27:28 |
