2018-06-17 update
Now with more declarative device configuration.
I have been working since last Wednesday (it’s now Sunday) on (ab)using the declarative configuration system from <nixkpkgs/nixos>
. I really like how I believe it will allow device configurations and descriptions to be smaller by extending and merging configurations. Right now it’s a bit overkill since there is one device, an android-system based one, but once other devices are added this will show its true potential.
This is not to be confused with the NixOS system configuration! What has been implemented is using the configuration system to build (for now) a basic stage-1 including kernel. There are no current plans for integration with NixOS configuration (as I don’t really know how to handle it). Every configurations have been prefixed mobile.*
, so adding those configurations to an NixOS system later on should be possible, assuming implementation can work.
Next steps
These are not ordered chronologically.
More targets
Both x86_64 and AArch64 qemu targets should be added, this may allow some work to have a better turnaround, but will especially force the declarative configuration to be tested using a non-android system.
Additionally, I have an armv7l device (Nexus 7 2013, flo) to which I can port mobile-nixos. I’ll first need to re-install my armv7l SBC as SD card corrupted on a forced shutdown. I’m hoping the qemu-user-arm shenanigans will allow a full build of everything needed. (on rare occasions it fails due to qemu emulation discrepancies or bugs)
Framebuffer agent / menu / lib
Complete framebuffer + inputs use will be needed for the over-arching goal of using a full NixOS system including rollbacks. This means that either a NIHnot-in-house new implementation of something, or look into existing work (e.g. android recoveries).
Implement switching roots
To continue booting, switching roots (stage-2) is necessary! This shouldn’t be much of an issue, but as of right now nothing has been implemented.
Explore kexec
options
This will need more documentation elsewhere. In #1 I described how mobile-nixos could be built like a tertiary bootloader, where it would be used to kexec
into another kernel+initrd, allowing the NixOS system to have a full control on the kernel without touching the boot.img partition. The non-kexec method (simpler stage-1 to stage-2 switch root) wouldn’t allow either safe stage-1 changes nor safe kernel changes (without a host system to recover).
NixOS configuration and “bringup”
I expect a bit of work will be needed to get a NixOS system working. First, I’ll need a way to generate a virgin or pre-configured image, like the sd-image
, but in a way that’s installable on the target device. As some devices won’t have a VT terminal (e.g. my asus-z00t), a solution will have to be found, either pre-configure an ssh or adb service, or find out if fbterm
or a similar tool can be used.
Then, as part of the configuration, some common configurations should be explored. Will it be possible to merge system
and userdata
together using LVM so a bit more space can be used by NixOS?
Finally, what kind of issues will happen once I try getting stage-2
running?
Evening update
Well, I added qemu-x86_64 support. This isn’t as useful as it could be as networking fails to work properly, but once figured out, this will help with some stuff.
Do note that qemu has an horizontal framebuffer, this will actually help in ensuring nothing is badly hardcoded to work only on portrait devices; not all devices are portrait!