| 23 Sep 2022 |
 @elvishjerricco:matrix.org | In reply to @janne.hess:helsinki-systems.de
We're about to rebuild the activation script from stage 2 here (as a brief aside, arguably stage 1 and stage 2 should actually be almost the same infrastructure, and it should simply be possible to make a NixOS config that's as stripped down as stage 1 needs to be) | 08:17:56 |
| @elvishjerricco:matrix.org | In reply to @janne.hess:helsinki-systems.de
We're about to rebuild the activation script from stage 2 here * (as a brief aside, arguably stage 1 and stage 2 should actually be almost the same infrastructure, and it should simply be possible to make a NixOS config that's as stripped down as stage 1 needs to be; main difference between the two being make-initrd-ng closures instead of nix closures) | 08:18:30 |
 K900 | Now that I think about it, I wonder if we could do a crime on WSL | 08:20:06 |
| K900 | And basically have initrd-as-root | 08:20:14 |
| K900 | And reuse all the systemd-in-stage1 stuff | 08:20:30 |
| K900 | For context, the latest WSL update added native systemd-as-PID1 support | 08:20:56 |
| K900 | But it doesn't have a good way to run the activation scripts | 08:21:09 |
 @janne.hess:helsinki-systems.de | Maybe a question for #wsl:nixos.org ? | 08:21:42 |
| @elvishjerricco:matrix.org | I believe I've mentioned before that my zeroth attempt at systemd in stage 1 was literally just doing a nested nixos eval with lots of hacks stripping things out and then putting that in an initrd :P | 08:21:47 |
 Arian | Happy to commit crimes on WSL | 08:21:54 |
| K900 | In reply to @janne.hess:helsinki-systems.de
Maybe a question for #wsl:nixos.org ? I've been posting there about my experiments with wrapping systemd | 08:22:50 |
| K900 | So far kinda feels like the wrapper route is still easier | 08:27:16 |
| K900 | Even though it makes things kinda awkwaed | 08:27:27 |
| K900 | * Even though it makes things kinda awkward | 08:27:31 |
 flokli | Arian: will you bring your windows laptop? | 19:12:37 |
 Zhaofeng Li | In reply to @elvishjerricco:matrix.org
Zhaofeng Li: While I'm largely OK with https://github.com/NixOS/nixpkgs/pull/189676/ I had another thought about the patch. Couldn't we just change that hard coded absolute path to something in /etc and configure said directory in NixOS with environment.etc rather than taking on the risk that we could be wrong about relative paths being safe? Just looked at it, and it seems that adding a new /run/cryptsetup-libraries seems unappealing to people and /run/opengl-drivers doesn't look like a good place either. We can do /run/current-system/cryptsetup-libraries but then ABI breakages may occur (discussion). | 20:49:59 |
| Zhaofeng Li | We can also stick with the patch in cryptsetup, and also patchelf'ing systemd-cryptsetup (in systemd) to add the hardcoded paths to rpath | 20:51:34 |
| Zhaofeng Li | * We can also stick with the patch in `cryptsetup`, _and_ patchelf'ing `systemd-cryptsetup` (in systemd) to add the hardcoded paths to rpath | 21:17:16 |
| @elvishjerricco:matrix.org | Alright, that makes sense. PR looks good to me as is, it's not enough of an initrd size increase to really bother me, even if 2-3 MB is kind of unfortunate. | 21:18:33 |
| @elvishjerricco:matrix.org | * Alright, that makes sense. PR looks good to me as is; it's not enough of an initrd size increase to really bother me, even if 2-3 MB is kind of unfortunate. | 21:18:40 |
| Zhaofeng Li | * We can also stick with the patch in cryptsetup, and patchelf'ing systemd-cryptsetup (in systemd) to add the hardcoded paths to rpath Actually doesn't affect dlopen from libraries | 21:35:32 |
| 27 Sep 2022 |
| @elvishjerricco:matrix.org | Janne Heß: So I think if we can get #189676 and #169116 both finished and merged, we can probably unhide the documentation for the systemd initrd options in 22.11, since I believe those are the last unimplemented features. And if we manage that, I think we could potentially even campaign for it to be the default in 23.05. What do you think of that? | 20:07:15 |
| 28 Sep 2022 |
| @janne.hess:helsinki-systems.de | does iso booting work? that's the only major thing apart from networking I'm aware of | 09:00:13 |
| @elvishjerricco:matrix.org | I wasn't aware that wasn't working, though that does appear to be the case | 21:49:25 |
| @elvishjerricco:matrix.org | ah, well problem number one is that we have root=LABEL=nixos-minimal-22.11-x86_64 in cmdline, which isn't what we have for the / mountpoint in fstab. So systemd-fstab-generator is preferring the cmdline one, which doesn't actually work | 22:51:40 |
| @elvishjerricco:matrix.org | though interestingly it probably would work (and just be wrong) if systemd-fstab-generator didn't automatically add ro to the mount unit it makes from the cmdline | 22:53:00 |
| @elvishjerricco:matrix.org | But really I don't understand how the ISO works at all with the scripted initrd considering the way its file systems are set up
"/nix/store" = mkImageMediaOverride
{ fsType = "overlay";
device = "overlay";
options = [
"lowerdir=/nix/.ro-store"
"upperdir=/nix/.rw-store/store"
"workdir=/nix/.rw-store/work"
];
depends = [
"/nix/.ro-store"
"/nix/.rw-store/store"
"/nix/.rw-store/work"
];
};
Those options should have to use /mnt-root/nix/... shouldn't they?
| 22:56:58 |
| 3 Oct 2022 |
| Arian | do we want to make public availability of systemd-initrd a blocker for the feature freeze? | 11:02:34 |
| Arian | i think it's in good enough state for a documented opt-in at the moment | 11:02:45 |
 @oxalica:matrix.org | I'm still waiting for https://github.com/NixOS/nixpkgs/pull/189676 for non-password LUKS unlocking | 13:45:46 |
