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.
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.
This ends up saving ~100KiB. Not much, but we're already 1MiB over the
~7-8 MiB budget.
Though, in reality, it's not for the space saving, but because
dlopen/dlsym will be needed for ffi-based bindings.
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??
From https://hydra.nixos.org/eval/15817511580f35dfb accidentally introduced udisks
in the build.
A local test build of the default "dummy" system disk image wasn't done,
thus the failure not found.