| 10 Mar 2023 |
 @elvishjerricco:matrix.org | It's possible that issue only existed back when I was trying to reuse the openssh module verbatim in stage 1, rather than doing the dead simple thing like the PR does now | 21:08:14 |
 @lily:lily.flowers | In reply to @elvishjerricco:matrix.org
It's possible that issue only existed back when I was trying to reuse the openssh module verbatim in stage 1, rather than doing the dead simple thing like the PR does now Yeah as a problem that sounds suspicious. I can probably test with it added back if you need to see how it behaves now | 21:24:38 |
| @elvishjerricco:matrix.org | Lily Foster: Feel free. Though fwiw I kinda doubt tmpfiles would be useful for us in stage 1. | 21:26:02 |
| @lily:lily.flowers | In reply to @elvishjerricco:matrix.org
Lily Foster: Feel free. Though fwiw I kinda doubt tmpfiles would be useful for us in stage 1. Yeah, me too. Which is why I wasn't gonna PR it unless someone expressed an interest to have tmpfiles in initrd | 21:26:32 |
| @lily:lily.flowers | (it's a small patch but it also really doesn't do much good -- though I feel we probably should leave it available to work, even if we don't actually add it to any targets or emit tmpfiles.d stuff by default) | 21:27:13 |
| @lily:lily.flowers | (so to clarify my stance -- I'd rather not remove the unit if we don't have to, but I also don't care to implement stuff in the tmpfiles/initrd modules for it) | 21:28:42 |
| @elvishjerricco:matrix.org | I'd say let's leave it out. It's just an unnecessary thing that can still cause stuff to break for no reason | 21:29:15 |
| @lily:lily.flowers | The unit existing really should cause anything to break (which is why that sounds suspicious that it did -- It's rarely pulled in by anything as far as I remember). But the amount I care is not much, so whichever you're more comfortable with is fine | 21:30:48 |
| @elvishjerricco:matrix.org | Well the existing unit also doesn't do anything :P If we're going to keep it, we should have an implementation. And if we have an implementation, that's logic we have to maintain even if no one's using it | 21:32:29 |
| 11 Mar 2023 |
 jaen | Hi, I've asked previously for help with getting systemd-stage1 to work with my LUKS setup, but didn't get any responses, so I've put it aside for a while. I'm trying again now and I think the only issue I have is getting my unit dependencies wrong, as doing the same steps manually on a running system properly shows Plymouth password prompt and decrypts what it should decrypt. | 11:52:42 |
| jaen | Is there any way to show all the units and their dependencies for the stage1 systemd before booting into it? Maybe that will make it easier for me to figure out where to put my units. | 11:52:44 |
| jaen | If it helps, what I'm trying to do at a high-level is taking advantage of the fact that if you put a domain socket as keyfile source, systemd will try to get keyfile contents from that socket. As such, I have added a keyfile.socket to the stage1 units and it spawns a unit with a simple bash script using systemd-ask-password --no-tty and cryptsetup to read the keyfile. I can provide relevant parts of config if you would need more details. | 11:58:18 |
| jaen | * If it helps, what I'm trying to do at a high-level is taking advantage of the fact that if you put a domain socket as keyfile source in crypttab, systemd will try to get keyfile contents from that socket. As such, I have added a keyfile.socket to the stage1 units and it spawns a unit with a simple bash script using systemd-ask-password --no-tty and cryptsetup to read the keyfile. I can provide relevant parts of config if you would need more details. | 11:58:33 |
| jaen | I think that's everything relevant – https://gist.github.com/jaen/f1e32d2d7810b20ba97159a19f8374db | 12:06:49 |
| 13 Mar 2023 |
 @hexa:lossy.network | Redacted or Malformed Event | 15:00:26 |
| 14 Mar 2023 |
|  ckie (they/them) changed their display name from ckie (they/them) to ckie (they/them; heavily limited keyboard usage, dictation or voice only). | 01:09:13 |
| 22 Mar 2023 |
 @linus:schreibt.jetzt | ElvishJerricco: re zfs mount generator, I wonder if in the future (when we have multiple initramfs support) we could even make the generator work in the systemd initramfs, by updating an initramfs which contains the cache in the zedlet | 13:25:55 |
| @linus:schreibt.jetzt | and thus make non-legacy mounts for /var/lib and stuff work too | 13:26:22 |
| @elvishjerricco:matrix.org | I have thought about doing that already. But it's not clear where to source that cache from. If the point is to keep the mountpoint details out of the nix config, then it has to be acquired when the generation is added to /boot, which doesn't seem ideal | 13:29:02 |
| @elvishjerricco:matrix.org | oh, I misread | 13:29:16 |
| @elvishjerricco:matrix.org | have the zedlet do it. | 13:29:21 |
| @elvishjerricco:matrix.org | huh | 13:29:22 |
| @elvishjerricco:matrix.org | that seems... risky | 13:29:28 |
| @elvishjerricco:matrix.org | and also not helpful for nixos-install | 13:29:40 |
| @linus:schreibt.jetzt | hm yeah | 13:30:36 |
| @elvishjerricco:matrix.org | btw I do use non-legacy mountpoints for initrd FSes, I just also have them in fileSystems with the zfsutil option :P | 13:30:38 |
| @linus:schreibt.jetzt | right | 13:30:50 |
| @elvishjerricco:matrix.org | it's just nice to have mount.zfs handle turning properties into mount options, and to have the fs hierarchy so you can just make new datasets and have the mountpoints be inferred | 13:31:27 |
| @linus:schreibt.jetzt | yeah | 13:31:49 |
| @linus:schreibt.jetzt | [root@sol:~]# zfs list -Ho name | wc -l
277
| 13:32:12 |
