In #327506, we stopped using `/sbin` in the `pathsToLink` of `initrdBinEnv`. This inadvertantly stopped including the `sbin` directory of the `initrdBin` packages, which meant that things like `mdadm`'s udev rules, which referred to binaries by their `sbin` paths, stopped working.
The purpose of #327506 was to fix the fact that `mount` was not calling mount helpers like `mount.ext4` unless they happened to be in `/sbin`. But this raised some questions for me, because I thought we set `managerEnvironment.PATH` to help util-linux find helpers for both `mount` and `fsck`. So I decided to look at how this works in stage 2 to figure it out, and it's a little cursed.
---
What I already knew is that we have [this](696a4e3758/nixos/modules/system/boot/systemd.nix (L624-L625))
```
# util-linux is needed for the main fsck utility wrapping the fs-specific ones
PATH = lib.makeBinPath (config.system.fsPackages ++ [cfg.package.util-linux]);
```
And I thought this was how `mount` finds the mount helpers. But if that were true, then `mount` should be finding helpers in stage 1 because of [this](696a4e3758/nixos/modules/system/boot/systemd/initrd.nix (L411))
```
managerEnvironment.PATH = "/bin";
```
Turns out, `mount` _actually_ finds helpers with [this configure flag](696a4e3758/pkgs/os-specific/linux/util-linux/default.nix (L59))
```
"--enable-fs-paths-default=/run/wrappers/bin:/run/current-system/sw/bin:/sbin"
```
Ok... so then why do we need the PATH? Because `fsck` has [this](a75c7a102e/disk-utils/fsck.c (L1659))
```
fsck_path = xstrdup(path && *path ? path : FSCK_DEFAULT_PATH);
```
(`path` is `getenv("PATH")`)
So, tl;dr, `mount` and `fsck` have completely unrelated search paths for their helper programs
For `mount`, we have to use a configure flag to point to `/run/current-system`, and for `fsck` we can just set PATH
---
So, for systemd stage 1, we *do* want to include packages' `sbin` paths, because of the `mdadm` problem. But for `mount`, we need helpers to be on the search path, and right now that means putting it somewhere in `/run/wrappers/bin:/run/current-system/sw/bin:/sbin`.
Windows with BitLocker and TPM enabled doesn't support boot chaining.
This option activates a special experimental mode in systemd-boot that
tries to detect such systems and, if detected and selected by the user
at the boot menu, set the BootNext EFI variable to it before resetting.
The [Boot Loader Specification](https://uapi-group.org/specifications/specs/boot_loader_specification/)
allows for using a key called "devicetree" for specifying which
devicetree the bootloader should use during boot. With regards to
systemd-boot, this key is used to specify which file should be picked up
from the ESP to install to the EFI DTB Configuration Table. Linux then uses
this Configuration Table to setup the machine. This change is similar to
the one done in https://github.com/NixOS/nixpkgs/pull/295096, where that
change was for adding DTB support to systemd-stub, and this is for
systemd-boot.
Regardless of mutable or immutable users, systemd-sysupdate never
updates existing user records and thus will for example never change
passwords for you.
It only support initial passwords and now actively asserts agains other
paswords.
On Linux we cannot feasbibly generate users statically because we need
to take care to not change or re-use UIDs over the lifetime of a machine
(i.e. over multiple generations). This means we need the context of the
running machine.
Thus, stop creating users statically and instead generate them at
runtime irrespective of mutableUsers.
When /etc is immutable, the password files (e.g. /etc/passwd etc.) are
created in a separate directory (/var/lib/nixos/etc). /etc will be
pre-populated with symlinks to this separate directory.
Immutable users are now implemented by bind-mounting the password files
read-only onto themselves and only briefly re-mounting them writable to
re-execute sysusers. The biggest limitation of this design is that you
now need to manually unmount this bind mount to change passwords because
sysusers cannot change passwords for you. This shouldn't be too much of
an issue because system users should only rarely need to change their
passwords.
systemd-sysusers cannot create normal users (i.e. with a UID > 1000).
Thus we stop trying an explitily only use systemd-sysusers when there
are no normal users on the system (e.g. appliances).
The activation script that remounts the /etc overlay now handles other
mount points on top of /etc by bind mounting them to the new temporary
/etc overlay and then atomically revealing it.
Fix regular expression used to get bootloader versions from bootctl status.
This avoids problems that occur in minor environments like mine.
References: #296563
we have a zoo of ways to call subprocesses.
Let's just replace this with one function that has reasonable defaults.
i.e. I catched instances where commands where run in a shell.
