This update is the twelfth in a series of regular updates on the state of the project.
Only changes that have been accepted and merged in Mobile NixOS are chronicled here. There’s always more work currently in-progress.
Notable changes
During the month 13 pull requests were merged.
Some major improvements landed, let’s take a peek.
Progress in stage-1
The boot splash utility now shows the progress of the boot. This is done with a simple progress bar shows how much of the tasks have been handled. Long-running tasks can provide a message to show so the user knows things aren’t necessarily hung.
Speaking of hung tasks. Our init
now detects when no tasks resolved in a given amount of time. When this
happens, the boot is being failed with, hopefully enough context in the error
message to help the user.
Speaking of error messages. Error messages are now less of a dead-end for our users. The interface has been reviewed to put the text message front and center. Previously we were showing a big image because we didn’t even have text rendering at this state. Now that we do, let’s use it.
In addition to that, the error applet is now somewhat interactive. There is now a cancellable countdown; when the time is elapsed the kernel is crashed, which allows the platform to do its default action (generally reboot). When canceled, the user can select different options, either through the touch screen, using a mouse, a keyboard or using volume-keys navigation.
The user can select to power off their device, which default action (so mashing the power key will power off the device). Depending on whether the platform supports it, the usual different reboot options are given.
Encrypted root filesystem support
Thought we were done with stage-1 updates? No! What if it was now able to decrypt LUKS encrypted filesystems? Well it can! For now, this is mainly the plumbing to make it all work. Getting a LUKS encrypted filesystem on your device is left as an exercise to the reader.
Our stage-1 can now ask for a passphrase during the early boot process phases. This is done through an on-screen keyboard. For the time being the keyboard is hard-coded to be the US QWERTY layout, and this is bad. Further improvements are planned, but out of scope for releasing the feature. The on-screen keyboard will be necessary for other upcoming planned features.
While using an on-screen keyboard is useful when you don’t have a physical keyboard, physical keyboards also can be used with that interface. Similarly to the previous note, it is hardcoded to be the US QWERTY keyboard, but the tooling chosen to drive the keyboard mapping (libxkbcommon) will give us the ability to configure both the on-screen and physical keyboard.
Ports
No new ports were made in November. There is still a total of 15 devices you can build for.