stage-0: Add ability to boot in generation kernel+initrd #262
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
samueldr
added
topic: stage-1
1 task
samueldr
commented
Dec 27, 2020
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
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.