stage-0: Add ability to boot in generation kernel+initrd #262
Conversation
samueldr
added
3. topic: stage-1
Which means there is no device-specific kernel/initrd on them.
Used to undo some of the close-knit integration work NixOS does, so we can cheat an make a more generic rootfs.
samueldr
force-pushed
the
feature/stage-0
branch
from
0c6bd45
to
7f7105a
Compare
Not great to outright disable, but we're not always using compatible kernels :/.
`#quit` would leave the `@pid` variable around, which in turn meant that calling `#kill` after would fail since the process was already gone.
This is partly complete; we need to handle the situation where **only** stage-0 should kexec into the next system. This is yet to be implemented, but will be done through a configuration that transforms the current bootloader-launched stage-1 into a stage-0, while keeping the on-disk stage-1 stage-1.
AArch64 Linux (arm64) didnd't support kexec up until 4.8
This is to use the value in the documentation.
The support is according to the default device configuration. For now this means the kernel version, but a device can also configure it as needed.
samueldr
force-pushed
the
feature/stage-0
branch
from
7f7105a
to
d5127c2
Compare
If stage-0 is not supported, default to not bundling a kernel into the derivation. This way, no useless builds of the kernels only to rebuild.
samueldr
force-pushed
the
feature/stage-0
branch
from
358883e
to
e88ace2
Compare
What's the current status? Now that #643 was merged, which devices other than the PinePhone and the PinePhone Pro support kexec? |
|
The unclearly and unstated goal is now to remove It is confusing, YMMV on all of the exactly two platforms that could do it. The YMMV-ness of it also exists on mainline and mainline-adjacent devices. And it's confusing, as the first boot through The whole concept behind this could be moved to an external project that builds more focused "Linux-kexec-as-a-bootloader-but-actually-good-and-working-with-DTs" optimized systems. |
|
Thanks for the explanation. |
This adds the ability for the boot to be split in "stage-1" and "stage-0".
Stage-1 is what was previously implemented, the system will continue and boot into the generation. With Stage-1, the initial kernel that is being booted into ends up being the only available kernel. Even if the user selects another kernel version to build into a generation, it will have no effect.
Stage-0 implements a more "classical" flow to Mobile NixOS boot, where booting into a generation uses that generation's kernel and stage-1 initrd.
All platforms that can support stage-0 have been enabled.
For now, all android devices cannot, as the kernel version used either does not have the feature for
arm64OR the vendor broke the functionality in different manners.asus-dumocan reboot using kexec, but the issue with its display suspend/resume ends up "chainloading" into a system with the display broken. Not at all useful here!QEMU could realistically boot using stage-0, BUT it's being deleted in #253. This PR enables stage-0 for the new UEFI device and system. With the new UEFI system type, this makes Mobile NixOS' stage-0 basically act as a bloated GRUB, which is amazing as this bloated GRUB has all the capabilities a Linux kernel has, which includes touchscreen support for entering passphrases for encrypted filesystems, among other features.
Fixes #4, fixes #82
TODO
The user selected a system to boot into. Right now it's completely forgotten once stage-1 starts, and it defaults to the current generation again. To fix this, add a kernel cmdline parameter giving a path to boot into, rather than the default. This can still be changed during boot by entering into the boot GUI. It is possible that the boot GUI is what's being tested in this new generation!
TODO later
Use generation's .dtb asSee stage-0: Use generation's .dtb askexec --dtbparameterkexec --dtbparameter #264.Self-explanatory. If we're going to boot into a system, we should boot using everything that it expects, including the FDT.To test, it would be appropriate to apply a device tree overlay on top of the pinephone's stage-0 .dtb file, where the default triggers are different for the LEDs, leading to a blue (aqua would be fine) LED in stage-0, and a green LED for stage-1.Add "Keep stage-0 kernel" option to generation selection GUISee stage-0: Add "Keep stage-0 kernel" option to generation selection GUI #266It might be that the built generation's kernel is broken, and it's easier for the user to just keep booting with the existing stage-0 kernel.Too much work creeping up with that feature.
scheme to manage "initial stage" installationSee "Bootloader" installation equivalent #265.Initial stage being the kernel+initramfs that is initially loaded, stage-0 or stage-1, depending on the device's capabilities.Either (both) automatically when the generation is being switched into, or manually calling a utility.The user might not want to automatically update the installed initial kernel, as the platform might be annoying to fix on breakage.This will need a kind of "PAL" (platform abstraction layer) to be implemented that will manage what to do with a given build to install the bootloader.