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!
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.
This didn't end up being something that's being worked on. It probably
was entirely confusing for everyone as it wasn't documented, and didn't
actually do anything useful most of the time.
Rather than polluting the build with some one-off special cases like
this, we'll implement an "installer" as an example system, if we even
want an installer.
It's not planned yet *how* users should install, it may not even be an
installer type system.
This also rewords the "successful default build failure" message.
Instead of borrowing some of its system.build products, rely instead on
a full system.build for the recovery.img.
This allows us to better make use of the implicit declarativeness of the
system configuration. At some point the recovery "system" will be moved
out of that file and things will continue to work.
In addition, put the implementation of the build side-by-side with the
system type definition. It made no sense to keep those where they were,
as it was baggage from the earlier implementation of the project.
It didn't make sense to stuff that into systems anyway, it's baggage
from the first steps of making Mobile NixOS.
This is a *part* of depthcharge system type, so why stuff it into `system`
at the root??
It didn't make sense to stuff that into systems anyway, it's baggage
from the first steps of making Mobile NixOS.
This is a *part* of android system types, so why stuff it into `system`
at the root??
