| 20 Mar 2022 |
 @arianvp:matrix.org | I see. | 10:48:23 |
 @janne.hess:helsinki-systems.de | #164943 doesn't add a way for me to use the initrd-ng stuff without systemd, right? ElvishJerricco | 13:35:55 |
| @janne.hess:helsinki-systems.de | ah kinda. I can just call makeInitrdNG with my contents and mkForce that into system.build | 13:37:24 |
| @janne.hess:helsinki-systems.de | I was just wondering about that because it provides future proofing (maybe we want to use another init system in 10 years for stage 1, who knows) and also adds flexibility for very, very obscure things (I may or may not be doing with the current stage 1 👀) | 13:38:15 |
| @janne.hess:helsinki-systems.de | also while we're touching everything, it might be wise to fixup the type of the contents passed to make-initrd(-ng). It's currently List of { object = path_or_derivation; symlink = "/path"; } which is horrible imo because it doesn't allow for overriding. I think something like { path_or_derivation = { symlink = "/path"; } would be nicer for that and would still provide a way to add more attributes in the future. | 13:40:58 |
| @janne.hess:helsinki-systems.de | * also while we're touching everything, it might be wise to fixup the type of the contents passed to make-initrd(-ng). It's currently List of { object = path_or_derivation; symlink = "/path"; } which is horrible imo because it doesn't allow for overriding. I think something like { path_or_derivation = { symlink = "/path"; }; } would be nicer for that and would still provide a way to add more attributes in the future. | 13:41:15 |
 @elvishjerricco:matrix.org | Janne Heß: you can't have a derivation as a key of an attrset | 13:53:06 |
| @janne.hess:helsinki-systems.de | ah right, damn it | 13:53:33 |
| @elvishjerricco:matrix.org | I thought about finding something like that and honestly this just really isn't ever going to need to be overridden like that | 13:53:43 |
| @janne.hess:helsinki-systems.de | hah I have the perfect idea. Just do objects = map lib.mkBefore [, that should make it as overridable as system.build was in 21.11 | 13:54:52 |
| @janne.hess:helsinki-systems.de | also, yes. I know how incredibly ugly that is | 13:55:28 |
| @elvishjerricco:matrix.org | The thing is that object is always going to be copied to its original path, so there's nothing to override there, and you can always specify the same object more than once to have more than one symlink. So the only overriding we can't do is removing a symlink | 13:56:32 |
| @janne.hess:helsinki-systems.de | Hm you are probably right and my desire to have the ability to remove files is too much me holding on to the things I had previously but that I didn't really need | 13:57:46 |
| @arianvp:matrix.org | I just realized that systemd does some wacky stuff where stage-2 systemd binary inherits state from the stage-1 systemd binary. E.g. to show stage-1 boot times in systemd-analyze blame
I think this currently doesn't work in Nixos as our stage 2 is a shell script execing into systemd instead of systemd that also calls a shellscript | 14:15:00 |
| @arianvp:matrix.org | This might also be something we want to change. Have the first executable in stage-2 be systemd proper | 14:15:16 |
 bobvanderlinden | ElvishJerricco: just looked at your PR. Looks good 👍️ I do think it'll help to at least split off the changes to systemd-lib.nix and utils.nix to a separate PR to ease the review process. | 15:33:06 |
| bobvanderlinden | Hopefully https://github.com/NixOS/nixpkgs/pull/164016 can be merged soonish, so the changes your PR introduced will be clearer in the diff. | 15:34:17 |
| bobvanderlinden | I do think it might help to have an executable like make-initramfs-ng/find-dependencies that doesn't copy everything first to a root dir and afterwards package those files up using cpio. A slight optimization, but I think that can be a separate PR with a separate discission. I won't mention it in the PR to avoid nitty-gritty discussions. | 15:36:43 |
| @janne.hess:helsinki-systems.de | In reply to @arianvp:matrix.org
I just realized that systemd does some wacky stuff where stage-2 systemd binary inherits state from the stage-1 systemd binary. E.g. to show stage-1 boot times in systemd-analyze blame
I think this currently doesn't work in Nixos as our stage 2 is a shell script execing into systemd instead of systemd that also calls a shellscript That's the --deserialize flag, I had a pr for that | 15:37:01 |
| @janne.hess:helsinki-systems.de | https://github.com/NixOS/nixpkgs/pull/137122/files | 15:38:27 |
| @janne.hess:helsinki-systems.de | this one, the commit is still good to go | 15:38:34 |
| @janne.hess:helsinki-systems.de | In reply to @arianvp:matrix.org
This might also be something we want to change. Have the first executable in stage-2 be systemd proper I don't think that's remotely possible | 15:38:46 |
| @janne.hess:helsinki-systems.de | To be more precise, initrd systemd calls real systemd with some arguments. On my CentOS 7, PID 1 is /usr/lib/systemd/systemd --switched-root --system --deserialize 22. My PR should properly forward all flags from the shell script so that should work. The 22 (in this case) is the file descriptor that holds the initrd systemd state that is deserialized into the new systemd. stage-2-init.sh already uses the exec bash call which inherits all FDs so as long as stage-2-init.sh doesn't touch these FDs, it should work properly | 15:44:10 |
| @janne.hess:helsinki-systems.de | also ElvishJerricco I found this to improve things because I can set env vars:
diff --git a/nixos/lib/systemd-lib.nix b/nixos/lib/systemd-lib.nix
index 3129fbe7bdb..716128a49ac 100644
--- a/nixos/lib/systemd-lib.nix
+++ b/nixos/lib/systemd-lib.nix
@@ -396,6 +396,13 @@ in rec {
text = commonUnitText def +
''
[Service]
+ ${let env = cfg.globalEnvironment // def.environment;
+ in concatMapStrings (n:
+ let s = optionalString (env.${n} != null)
+ "Environment=${builtins.toJSON "${n}=${env.${n}}"}\n";
+ # systemd max line length is now 1MiB
+ # https://github.com/systemd/systemd/commit/e6dde451a51dc5aaa7f4d98d39b8fe735f73d2af
+ in if stringLength s >= 1048576 then throw "The value of the environment variable ‘${n}’ in systemd service ‘${name}.service’ is too long." else s) (attrNames env)}
${attrsToSection def.serviceConfig}
'';
};
| 16:32:52 |
| @janne.hess:helsinki-systems.de | (on top of your PR). I wonder if we should use cfg.globalEnvironment here. It sets LOCALE_ARCHIVE and TZDIR | 16:33:31 |
| bobvanderlinden | In reply to @janne.hess:helsinki-systems.de
(on top of your PR). I wonder if we should use cfg.globalEnvironment here. It sets LOCALE_ARCHIVE and TZDIR I'd rather see a boot.inird.systemd.globalEnvironment instead. Just to avoid unintended changes to initrd.
That said, I'm not sure if it's needed if we can set envvars to specific values boot.initrd.systemd.services.emergency.environment.SOME_VAR = "3";.
Are things like LOCALE_ARCHIVE and TZDIR needed in initrd? | 17:00:48 |
| bobvanderlinden | In reply to @janne.hess:helsinki-systems.de
(on top of your PR). I wonder if we should use cfg.globalEnvironment here. It sets LOCALE_ARCHIVE and TZDIR * I'd rather see a boot.inird.systemd.globalEnvironment instead. Just to avoid unintended changes to initrd.
That said, I'm not sure if it's needed if we can set envvars to specific values boot.initrd.systemd.services.emergency.environment.SOME_VAR = "3";.
Are things like LOCALE_ARCHIVE and TZDIR needed (or even usable) in initrd? | 17:00:58 |
| @janne.hess:helsinki-systems.de | LOCALE_ARCHIVE and TZDIR are probably more optional. Adding a global option and not populating it by default would be a good way imo. For me, I needed the environment for boot.initrd.systemd.services.emergency.environment.SYSTEMD_SULOGIN_FORCE = "1"; | 17:02:00 |
| @janne.hess:helsinki-systems.de | also, you mentioned something about /proc/sys/kernel/modprobe. How did you set it in your attempt? Because it looks like it's not set at all in the PR | 17:02:46 |
| @elvishjerricco:matrix.org | In reply to @arianvp:matrix.org
This might also be something we want to change. Have the first executable in stage-2 be systemd proper Yep. I mentioned this in the PR. We can either do activation in stage one with nixos-enter, or maybe do something clever with systemd generators | 17:05:26 |
