Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

stage-0: Add ability to boot in generation kernel+initrd #262

merged 36 commits into from Dec 29, 2020


Copy link

@samueldr samueldr commented Dec 27, 2020

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 arm64 OR the vendor broke the functionality in different manners.

asus-dumo can 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


  • "Chainloaded" stage-1 should continue with its own generation

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

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.

It 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.

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.

@samueldr samueldr added topic: stage-1 stage-1, boot, init type: enhancement New feature or request labels Dec 27, 2020
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
@samueldr samueldr merged commit 32f58ad into NixOS:master Dec 29, 2020
@samueldr samueldr deleted the feature/stage-0 branch December 29, 2020 23:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
topic: stage-1 stage-1, boot, init type: enhancement New feature or request
None yet

Successfully merging this pull request may close these issues.

Kexec into another kernel+stage-1 with boot selection GUI Explore kexec.
1 participant