Stage 1 systemd | 83 Members | |
| systemd in NixOs's stage 1, replacing the current bash tooling https://github.com/NixOS/nixpkgs/projects/51 | 26 Servers |
| Sender | Message | Time |
|---|---|---|
| 20 Mar 2022 | ||
| this one, the commit is still good to go | 15:38:34 | |
In reply to @arianvp:matrix.orgI don't think that's remotely possible | 15:38:46 | |
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 | |
| also ElvishJerricco I found this to improve things because I can set env vars:
| 16:32:52 | |
(on top of your PR). I wonder if we should use cfg.globalEnvironment here. It sets LOCALE_ARCHIVE and TZDIR | 16:33:31 | |
In reply to @janne.hess:helsinki-systems.deI'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 | |
In reply to @janne.hess:helsinki-systems.de* 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 | |
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 | |
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 | |
In reply to @arianvp:matrix.orgYep. 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 | |
In reply to @bobvanderlinden_:matrix.orgI think that's a good point. I'd like to make that change but just didn't bother last night. I wouldn't be opposed to a patch to change that in this PR | 17:06:41 | |
| Janne Heß: I did not realize it was possible to do the serialization thing without switch-root'ing to exactly the systemd binary. Cool, I'll take a look | 17:09:25 | |
| Janne Heß: Yea we might want a globalEnvironment thing, I just didn't see a need, since initrd is really supposed to just launch and die as quickly as possible | 17:11:33 | |
yeah people will probably not get mad if it's missing. It's something that can be added later. A working systemd.services.<?>.environment is more useful though ;) | 17:13:02 | |
Janne Heß: Is there a reason boot.initrd.systemd.services.emergency.environtment doesn't work on its own though? | 17:13:27 | |
Also, for the modprobe thing, it's in the object that gets symlinked to /etc/sysctl.d/nixos.conf | 17:13:45 | |
In reply to @elvishjerricco:matrix.org Yeah you are missing:
| 17:14:04 | |
| (but without the globalEnvironment, just def.environment) | 17:14:12 | |
Ohhh, def.environment doesn't just get assigned to serviceConfig.Environment like e.g. path gets set to environment.PATH | 17:15:13 | |
| Ok, yea that needs a fixing | 17:15:23 | |
| yeah | 17:15:29 | |
ElvishJerricco no worries. I was thinking these kinds of optimizations can also happen after the PR. I'd rather be in a state where the PR is merged and multiple people can create PRs to improve the various parts of initrd-systemd, rather than everyone commenting/attempting to make changes to the PR itself, leaving you to be the central person that needs to do things: a situation I'd like to avoid with the time it takes for some PRs | 17:16:14 | |
| bobvanderlinden: Yea, I agree that delaying the PR with endless discussion would be unfortunate. But delaying for actual completed patches to be included is reasonable | 17:17:09 | |
| So long as they don't escape the scope of "core functionality" | 17:17:33 | |
| And I think that would be in scope | 17:18:00 | |
| I wish it was easier to make it clear that this section of nixos is experimental and people should not use it. That would make it easier to merge the PR in its current state. There are tons of ideas and suggestions to come up for the PR regarding its core functionality, but imo it doesn't really help to make you apply all of those suggestions rather than people making small PRs on top to improve things. Things like formatting, naming, file-placement are really popular to comment on, but do not contribute that much to moving forward imo. | 17:22:53 | |
| Something that I really think would contribute to the initial PR would be a simple nixos test that just boots a simple VM without anything fancy. I'm currently working on that and struggling with ext4 atm :/ For some reason the kernel and mount hate me | 17:24:15 | |
I should probably hide these options from the nixos manual for the time being (I forget how to do that; something about visible or internal?) | 17:24:24 | |
| Janne Heß: I'm working on a test ;D | 17:24:38 | |
In reply to @bobvanderlinden_:matrix.orgoh that's great. Have you made it load ext4? | 17:24:56 | |