| 20 Mar 2022 |
@elvishjerricco:matrix.org | But given we should be caching this tool, users should never end up downloading a rust tool chain to build their systems | 08:25:51 |
Arian | oh yeh polkit... great =) | 08:26:44 |
@janne.hess:helsinki-systems.de | In reply to @arianvp:matrix.org But given we were eager to add it to nix as well I think that ship has sailed. And rust bootstrapping is in sorta-ok shape It got removed iirc and is now only used for the docs | 09:44:35 |
@janne.hess:helsinki-systems.de | In reply to @elvishjerricco:matrix.org Arian: Rust has been in the bootstrap path for quite a while now because it's needed for spidermonkey which is needed for... polkit(?) or something Andy is in the process of replacing that for duktape though | 09:44:58 |
@janne.hess:helsinki-systems.de | (not saying I don't like the language but I don't think it's part of bootstrap rn) | 09:49:17 |
ius | In reply to @arianvp:matrix.org oh yeh polkit... great =) Note that polkit master includes support for duktape instead of spidermonkey, which is a reasonably small C++ JS implementation. That's how I avoid having to build llvm/spidermonkey on (terribly slow) RISC-V | 10:45:42 |
ius | oh doh, that's what Janne Heß mentioned as well | 10:48:08 |
Arian | 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 |
Arian | 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 |
Arian | 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 |