This way on kexec the device is in a better state, and the kernel that
boots next is able to use the controller.
This was verified to fix an issue with kexec+gadget on the Chuwi Hi10
Pro HQ64 tablet.
The update from 29a10085f3 caused the
uncompressed kernel to not be installed anymore into the kernel output.
This meant that building the top-level argument failed as a file assumed
to exist wasn't there anymore.
We now provide the appropriate filename when we know it.
It's being replaced by the generic uefi-x86_64 device.
Basically, replace the QEMU-specific system type by the totally standard
UEFI system type. This way we're dogfooding it way better!
Closes#252.
This uses the `lib.systems.elaborate` function which builds the
complete attrset as preferred by Nixpkgs by using
`lib.systems.elaborate`, rather than building a partial equivalent.
@noneucat originally implemented it the simplest way possible, re-using
parts of the now unneeded custom functions. We can, instead, simply
pass a system name to `elaborate`, which ends up doing the right thing.
Co-authored-by: Andy Chun <andy@lolc.at>
Co-authored-by: Samuel Dionne-Riel <samuel@dionne-riel.com>
First, right now we're putting the full error message front and center,
rather than the sad phone.
We're keeping the sad face though, but only as an accent icon.
Finally, not part of this PR, we'll add actions to abort a total crash.
The applet is specifically written to show what we call the "recovery
menu". Yes, it's also the boot selection, but it will get confusing with
the upcoming boot tracking splash UI that's upcoming.
This will be used by the boot GUI to only show relevant reboot options.
We might add other HAL-ish things in there.
Note that this is all internal stuff :)
Ugh... The whole `''${devtype} ''${devnum}:''${bootpart}` thing was
cargo-culted from other u-boot scripts as "the way to go" to re-use the
information set by the generic distro boot...
EXCEPT that it doesn't work since 2018.
13dd6665ed
They are not environment variables since that change. So any of those
scripts end up working *by sheer luck* since it would end up booting
from the first device's first partition.
Ugh ugh ugh...
There is one **major** difference with the choice: We are now selecting
on a partition's label, rather than booting whatever is deemed bootable.
This assumes the upcoming change where we are using GPT rather than MBR.
But still, this is compatible with the default expectation from U-Boot
by falling back to the "bootable" attribute.
