# Mobile NixOS January 2020 Round-Up: New Stage-1 Init and Planned Early-Boot UI DevFeed: [Mobile NixOS January 2020 Round-Up: New Stage-1 Init and Planned Early-Boot UI]() Original publisher: [Read original article]() Author: Samuel Dionne-Riel Published: 2020-02-04T00:00:00Z Content type: article Language: en Sources: [Mobile NixOS news]() Topics: [Boot Process](), [USB](), [Mobile]() Tags: [boot-process](), [dependencies](), [implementation](), [logs](), [recovery](), [saving](), [ui](), [usb]() ## AI overview The January 2020 Mobile NixOS update describes a redesigned stage-1 init with USB gadget handling, USB networking, firmware loading, log multiplexing and saving, reboot and poweroff support, and handling for configured special file systems. Its dependency-based design reduced reliance on sleep and wait times and made boot steps quicker. Work was also in progress on a graphical early-boot interface for recovery, generation selection, and eventually entering a passphrase for an encrypted system. ## Source excerpt This update is the third in a series of regular updates on the state of the project. Usually, only changes that have been accepted and merged in Mobile NixOS in the given month are chronicled here. There's always more work currently in-progress. Notable changes Only 1 PR was merged during the month. Though, keep on reading, as one of the biggest PR, started in mid-December, was the main focus of the month. New Stage-1 init This is quite the misnomer, while true, that the PR mainly introduced a completely re-done init, it brought much more. "New-style" USB gadget (gadgetfs) handling. USB Networking for newer devices. Vendor partition firmware loading. Logs multiplexing and saving in stage-1. Proper reboot and poweroff in stage-1. Actual handling of NixOS-configured specialFileSystems. This new init is built using a dependencies-based system, reducing the complexities from the inflexible "big script" approach of the previous init. With this new approach, we can simply dump all of the things we need to happen in the init, tell them how they're linked, and boot. The current implementation is naïve, but even with a naïve approach, the benefits are apparent. First, the developer does not need to care about the ordering of things, only describing what has to be, and what to do. Then, the relatively surprising part: this made things a bit quicker to boot. This reduced reliance on sleep and wait times during the boot to provide assurance that things were ready, meaning that steps happen much quicker in succession. To the annoyance of the author, this means that the well-choreographed boot images whizz by too quickly, reducing their meaningfulness. In the end, this is a hidden change, that serves mainly to ensure a rock-solid foundation for what's coming soon. See the PR for more details. Upcoming changes Speaking of coming soon, As previewed in a tweet, work is in progress to provide a graphical interface that can be used in early boot. This can be used to make a "recovery"