Mainly, this aims to reduce the impedance mismatch between path
as-seen-in-stage-1 and paths-according-to-stage-2.
Now, two helpers, one using the other, are used to properly telegraph
the intent when using a file path.
With this, reading `nixos-version` was also fixed.
... this way, the framebuffer content is not evicted by a needless mode
change.
AFAIK none of our targets will be affected by this change. The
framebuffer should already be setup with the correct mode. This was
holdover from early early cargo-culting about the framebuffer.
I have verified on a few devices, it does not worsen their behaviour.
A NixOS change for systemd-stage-1 added an `x-` mount option, which is
not handled well by busybox mount.
- 1b39491326
The same option was not an issue for the shell-script stage-1 as it
already stripped `x-` mount options
- 8be838254b/nixos/modules/system/boot/stage-1-init.sh (L365-L366)
Thus it's assumed safe to strip the options the same way.
This is useful for devices with USB, where input devices may take a
short while before showing up.
With this, external USB keyboard passphrase input is reliable in the
limited testing I did.
Better than doing the wildly weird thing of mounting/unmounting to peek,
and it doesn't leave a stray mountpoint after switch_root.
Why not depend on `/proc` or keep it mounted? Mainly because of the
mount options. I don't want to deal with it when it is being handled
through the mount tasks.
These will be provided by proprietary bootloader (e.g. google-blueline),
and cannot be removed.
Thus we'll ignore any bogus parameter.
(cherry picked from commit c961ca142650fead3c3b565cfc59f8ae0662d771)
In #300 I "fixed" stage-0 by adding a switch to toggle between it being
enabled and disabled in the recovery menu. *That* works as expected.
In 2a46962d76 one can observe that the
`#will_kexec?` method will use data that will only come from the
`choice` made from the recovery interface. The `@use_generation_kernel`
member is not set at any other point.
With ruby semantics, this means that the `if` is false, so *unless* you
choose to boot using the recovery menu, it will never trigger `kexec`.
Why has this gone through this way? Most likely because my main testing
target was configured so it *always* went to the recovery menu at the
time, meaning that I never saw the default behaviour.
In some instances, e.g. really slow CPU, udev might not have run, and
libinput will not be able to work appropriately.
That is because uevent files will be missing.
