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.
This is a semi-internal option. The end-user may want to change it.
Though in reality this is aimed toward device integrators that integrate
a device with a small boot partition.
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.
This quirk touches the `blank` file of the framebuffer /sys nodes, which
ends up unsuspending things that start suspended until the *right thing*
is happening to not be suspended.
X11, among others, do the right things. It seems other framebuffer
interfaces are not.
This can likely be fixed in other ways, but this is the more
approachable way to me right now.
