nixos / mobile-nixos Goto Github PK

The first goal would be to make any closed-source .so work with libhybris, as simple it is.

Then, with the knowledge gained, document the next steps.

Resources:

• https://github.com/libhybris/libhybris
• https://github.com/ubports/libhybris/blob/master/debian/rules

Seeing that @ashkitten was having an issue with always booting into recovery (#104), I was reminded of this diagram from the following document: https://source.android.com/devices/tech/ota/ab/ab_implement

This might suggest that @ashkitten's partitions had been marked invalid, and as a result, it would always boot into recovery. This could also explain why I had not encountered this problem yet with a freshly flashed phone.

I've only spent a few minutes looking into how this system operates, but I think to make this system operate properly for us, we would also need to mark the partition as having successfully booted at some point.

There is an existing bootctl utility available in android here: https://android.googlesource.com/platform/system/extras/+/master/bootctl/
It, among other things, has the ability to run bootctl mark-boot-successful.
Since this operates through a HAL, the underlying implementation (for qualcomm), appears to be here:
https://android.googlesource.com/platform/hardware/qcom/bootctrl/+/refs/heads/master
And briefly skimming this it appears to hold the BOOT_SUCCESSFUL status in the attributes field of the GPT partition entry.

I can take a stab at working on this (maybe this weekend), but figured I should post this first in case there is any feedback. Is anyone aware if other projects implement this?

Do you plan on supporting Android's Project Treble with this? It would instantly give you support for many newer Android phones, though I'm unsure what support for it would entail implementation-wise. Or maybe I'm misunderstanding the meaning of Project Treble?

Also, this project is awesome! I'm in the process of building my own distro that sits on top of (a pretty stock) NixOS, and I'd love to get it running on a mobile device at some point!

Edit: It looks like PostmarketOS say that treble will not impact them, since it needs to be updated by the vendor. What are your thoughts on this?

Have you considered building the website with Antora?

While i like the current design, Antora might offer some interesting features.

Their website is build by the tool too, so a landing page can be designed with it.

The default documentation layout looks like this: https://docs.antora.org/antora/2.2/

• fastboot getlog
• ramoops
• Hardware serial cables (only those actually tested).
• → Suzy-Q for ChromeOS-based devices
• → SBU1/SBU2 as TX/RX (check the correct order of RX/TX) (Pixel 2, 3)

This seems like it will be a harder issue to handle.

Looking at TWRP, it looks like they hardcode this as a device-specific build option. It seems true for at least asus-flo.

From experience, asus-z00t's framebuffer can be configured using fbset from busybox.

This fix doesn't seem to work for asus-flo; I get fbset: FBIOPUT_VSCREENINFO: Invalid argument. (This error doesn't happen when the colours are ordered RGBA in fb.modes, while the panel shows BGRA.) (This may not happen with the mainline kernel, which I'll need to package next.)

This may cause issues for Xorg support, unless composition with libhybris + vendor EGL fixes that.

I would assume that anything using vendor libraries will be handled properly (e.g. OpenGL) as they probably do the dirty work themselves.

This looks like it's related, on the android side:

• https://android.googlesource.com/platform/system/core/+/jb-dev/include/system/graphics.h#42
• https://github.com/libhybris/libhybris/blob/master/hybris/tests/test_ui.c#L34
• https://github.com/libhybris/libhybris/blob/22beee4adf88779c7bad0347d11ef95fd6dcd009/hybris/egl/platforms/common/eglplatformcommon.cpp#L119-L121
• https://github.com/libhybris/libhybris/blob/22beee4adf88779c7bad0347d11ef95fd6dcd009/hybris/egl/platforms/common/eglplatformcommon.cpp#L77-L80
• https://github.com/aosp-mirror/platform_external_qemu/blob/master/docs/GOLDFISH-VIRTUAL-HARDWARE.TXT#L417-L447

I do wonder how to get this HAL data.

As a follow-up to #46,

#46 (review)

Hard-mode: could we get a real usable console attached so that an attached keyboard can work with it? Thinking about breaking to a shell in initrd, allowing keyboard input on-device, in case there's issues with adb and rndis.

From #80.

Implement

• Keyboard input
• Mouse input

Keyboard input should, in addition to basic keyboard input, map:

• Volume up to LV_KEY_LEFT
• Volume down to LV_KEY_RIGHT
• Power to LV_KEY_ENTER

(LEFT/RIGHT and not PREV/NEXT, otherwise changing number values would fail.)

See: https://docs.littlevgl.com/en/html/overview/indev.html#keypad-and-encoder

This is required for it to work in QEMU and for it to work on non-touch devices e.g. pinebook pro.

The problem:

A user wants to compile using nix-build on their x86_64 system, when an aarch64-linux machine is configured as a builder.

Currently, it doesn't end up being used as the system detects it may need cross-compilation.

Not sure exactly how.

The easy way right now would be to configure nixpkgs.crossSystem = lib.mkForce null in the system's configuration.

Another way would be to add a setting so that --arg crossCompile false forcibly disables the check.

I dislike both options, as I would like it to be transparent, but detecting the ability to build natively through other machines is probably not detectable.

Please add the support level to the devices documentation.

https://mobile.nixos.org/devices/index.html

I like the structure of the list here organized by brand:

https://wiki.lineageos.org/devices/

There could be the overall support level like "basic" or "full". At the bottom could be a list of tested devices that are known not to work.

Then a page for every device can get generated with the README content and support level.

The support of specific features can be saved as structured data (Nix/JSON/?).

Good presentation example from https://wiki.postmarketos.org/wiki/Xiaomi_Redmi_Note_4_(xiaomi-mido)

I'm not sure if it is helpful to have the device specification there also, but if that is wanted, it an get scraped from https://github.com/LineageOS/lineage_wiki/blob/master/_data/devices/mido.yml

(that's the device i currently use)

As discovered today, this may cause issue during the boot process

• https://logs.nix.samueldr.com/nixos-chat/2020-03-24#1585010117-1585010237;

The symptoms are init being killed quickly (as discovered in a console ramoops)

[    2.713781] c1      1 Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100

The exit code may or may not be relevant here.

The solution would be to have an option to enable/disable this at build time, rather than editing the console cmdline.

This affects: (but not exhaustively)

• google-marlin @danielfullmer

This may affect:

• google-walleye @samueldr

If this can be reproduced by disabling UART in fastboot on walleye, this will be trivial to work on an appropriate solution.

The current workaround for users without serial enabled is to remove console= from the boot params.

Additional notes: It may be crashing even before the custom init. It may be bootlogd that is unable to set itself up.

Follow-up to #80.

• Better split the "loader" from init
• Provide "shared" libraries (as .mrb?)
• Figure out better semantics for "applets" and the loader

Additionally

• Fix the "simulator", something got borked at the last moment.

Notes

Provide "shared" libraries

There are some repeat libraries, e.g. the one handling adding "File.write".

We could also bundle them as "trivial" mrbgems. Explore making a "trivialMrbgem" builder that automatically creates the structure of a gem to shove given .rb files into mrblib.

Better semantics for "applets" and the loader

Right now it's a kludge. We have /loader that is globally available, and copy some "applets" in /applets/ so it's globally available.

It would be better, keeping mkExtraUtils in mind, if we could simply add a package with a .mrb in $out/share/script-loader/XXX.mrb or something like that, and use an invocation like script-loader XXX to load the right script.

Part of this also includes a "builder" to trivially build an applet. Not sure what shape this would have.

 $ nix-build -A all -I nixpkgs\=channel:nixpkgs-unstable --argstr device asus-z00t
these derivations will be built:
  /nix/store/kyqkgiima57fczglk8a98vzmij46jg6x-fbv-aarch64-unknown-linux-gnu.drv
  /nix/store/g5y10hfw6jmwky4afzk9k02njn1j4hfh-extra-utils-asus-z00t-aarch64-unknown-linux-gnu.drv
  /nix/store/2vgz1vjfzfr7y6lcpil28nafkif4hgqc-stage1-aarch64-unknown-linux-gnu.drv
  /nix/store/kbmr35hqa1rhg347gi5yv201g80l7pxv-initrd-aarch64-unknown-linux-gnu.drv
  /nix/store/0ss3hdkxf9pc89yx87zljn5z2mqgambq-initrd-asus-z00t-aarch64-unknown-linux-gnu.drv
  /nix/store/pa79lwbzdg189ap37zp5zx9ydyhs3hk9-nixos-mobile_asus-z00t_boot.img-aarch64-unknown-linux-gnu.drv
building '/nix/store/kyqkgiima57fczglk8a98vzmij46jg6x-fbv-aarch64-unknown-linux-gnu.drv'...
unpacking sources
unpacking source archive /nix/store/b3pi8ygkpj4xzkd5s45gfwsj1043hjir-fbv-1.0b.tar.gz
source root is fbv-1.0b
setting SOURCE_DATE_EPOCH to timestamp 1094566655 of file fbv-1.0b/Make.conf
patching sources
updateAutotoolsGnuConfigScriptsPhase
configuring
configure flags: --prefix=/nix/store/biskykra79jgz034w58v5mpvh3kbil2b-fbv-aarch64-unknown-linux-gnu --build=x86_64-unknown-linux-gnu --host=aarch64-unknown-linux-gnu
./configure: line 57: getopt: not found
Usage: ./configure [options]
Options: [defaults in brackets after descriptions]
If a long option shows an argument as mandatory, then it is mandatory
for the equivalent short option also.  Similarly for optional arguments.
General:
  --help        print this message
  --libs=LIBS   additional libraries required (try -lX11 for ungif, -lz for PNG)
Directory and file names:
  --prefix=PREFIX       install files in PREFIX [/usr/local]
  --bindir=DIR          binary executable in DIR [PREFIX/lib]
  --infodir=DIR         info documentation in DIR [PREFIX/info]
  --mandir=DIR          man documentation in DIR [PREFIX/man]
Features and packages:
  --without-libungif    disable libungif support even if found
  --without-libjpeg     disable libjpeg support even if found
  --without-libpng      disable libpng support even if found
  --without-bmp         disable bmp support
builder for '/nix/store/kyqkgiima57fczglk8a98vzmij46jg6x-fbv-aarch64-unknown-linux-gnu.drv' failed with exit code 1
cannot build derivation '/nix/store/g5y10hfw6jmwky4afzk9k02njn1j4hfh-extra-utils-asus-z00t-aarch64-unknown-linux-gnu.drv': 1 dependencies couldn't be built
cannot build derivation '/nix/store/2vgz1vjfzfr7y6lcpil28nafkif4hgqc-stage1-aarch64-unknown-linux-gnu.drv': 1 dependencies couldn't be built
cannot build derivation '/nix/store/kbmr35hqa1rhg347gi5yv201g80l7pxv-initrd-aarch64-unknown-linux-gnu.drv': 1 dependencies couldn't be built
cannot build derivation '/nix/store/0ss3hdkxf9pc89yx87zljn5z2mqgambq-initrd-asus-z00t-aarch64-unknown-linux-gnu.drv': 1 dependencies couldn't be built
cannot build derivation '/nix/store/pa79lwbzdg189ap37zp5zx9ydyhs3hk9-nixos-mobile_asus-z00t_boot.img-aarch64-unknown-linux-gnu.drv': 1 dependencies couldn't be built
error: build of '/nix/store/pa79lwbzdg189ap37zp5zx9ydyhs3hk9-nixos-mobile_asus-z00t_boot.img-aarch64-unknown-linux-gnu.drv' failed

This is caused by its non-standard ./configure script.

Work will need to be done to figure out why it has issues.

Even though this might be probably up to desktop environment to decide, I'll still leave this as an issue here. Feel free to close it if it doesn't really apply here.

My phone, Xiaomi Mi A3 (codename laurel_sprout, based on Xiaomi Mi CC 9e, codename laurus), has a display cutout. I'm currently contemplating making a NixOS port to this phone and thinking how should I deal with display cutouts. They probably should be dealt with on desktop environment level, but how? or maybe one could patch the kernel to ignore the area that results from cutout being present so the screen would emulate absence of the cutout...

I'm trying to build images for the Pinephone and I feel like I'm missing something in my stack, as I'm getting these errors:

$ nix-build --argstr device pine64-pinephone-braveheart -A build.disk-image 
trace: Building with crossSystem?: aarch64-linux != x86_64-linux → we are.
trace:     crossSystem: config: aarch64-unknown-linux-gnu
error: undefined variable 'lazyAttrsOf' at /home/craige/source/NixOS/mobile-nixos/modules/initrd.nix:33:8
(use '--show-trace' to show detailed location information)

I'm building on branch device/pine64-pinephone-braveheart (patched with PR #91) and the nixpkgs directory is cloned from github.com:samueldr/nixpkgs.git on branch mobile-nixos-wip.

As best as I can tell, lazyAttrsOf is only being called from initrd.nix which is not part of either PR #91 or PR #97.

I've been unable to determine how it should be defined correctly and suspect I'm missing something in my local setup.

Should in some way provide a framebuffer and serial console.

Should be configured as close as possible to the postmarketOS ones.

This depends on cross-compiling (#5).

The image-builder infrastructure should be made aware of compression, rather than manually post-processing it.

Outputs cannot be bigger than 2.2GiB on the foundation's Hydra instance.

My main idea right now is to save some metadata next to the filesystem images, $filename, something like $filename.meta where we save the final size of the uncompressed file, the compression scheme used, if compressed, and maybe some other useful data points.

This, in turn, would be used by the disk image bits to decompress on the fly the compressed parts.

The idea being that we shouldn't require all parts of to be compressed, we should be able to say that only the rootfs and the final disk image are compressed, not the other bits. Doing this will also allow users to refer to pre-built store paths for the rootfs in their local.nix to make complete images.

After I managed to build and flash an image of mobile-nixos I'm now wondering what is the intended way to write the /etc/nixos/configuration.nix on the device to include the mobile-nixos repo.
I cannot really figure out how to transform the local.nix that I used to build the image to a configuration.nix.

Some files are concatenated together in the hardware trees to build the /system/build.prop file. We may as well try and build build.prop too. Some of its information may be useful.

• https://github.com/LineageOS/android_device_asus_msm8916-common/blob/lineage-15.1/system.prop
• https://github.com/LineageOS/android_device_asus_Z00T/blob/lineage-15.1/system.prop

I have a feeling it may be necessary. Maybe it's only because the android system boots, then reboots to my system, then reboots to android, then reboots to my system, but it feels like the phone's getting a bit hot.

This is not necessarily make thermal/power management work 100%, but mainly figure out if it is an issue, and document where to look for for more information.

• https://halium.org/

(I have local notes I need to file)

They have manifests with repositories:

• https://github.com/Halium/android/blob/halium-5.1/default.xml
• https://github.com/Halium/halium-devices/blob/halium-7.1/manifests/asus_flo.xml

They are for repo AFAIUI, the android tool to manage repositories. With some massaging and/or scripting, it may be possible to automate something with nix/nixpkgs and those XML files.

Their website seems to indicate they want to standardize some useful hardware. Though, there is a scary "android chroot" thing. I'm not sure whether it means full apps or only the minimal services to make the hardware work.

https://github.com/postmarketOS/pmbootstrap/tree/master/aports/main/wcnss-wlan

First of all, i'm very excited about this project. But it's also not clear what it will offer.

It would be great to have a section on the website that explains it in more detail.

What is it?

NixOS on my phone

OK, that's great. Like it's great to boot linux on a Playstation. But can it actually replace Android for daily usage? Can i install android apps? Can we package every F-Droid app automatically in nixpkgs? Do i have a touch UI? (the previous video shows Xfce with a cursor and desktop software which is not optimized for mobile devices)

The README has some information about the goals and previous work that should be added to the homepage.

https://github.com/NixOS/mobile-nixos/blob/master/README.adoc#goals

https://postmarketos.org/ has an excellent project description. You can use that as an example.

all proprietary components (even the WLAN, cellular modem and bluetooth firmware) are optional and you are asked whether you want to include them in your installation.

is that supported here as well?

I suggest to also add an FAQ where all this questions that come up can be answered.

Even if the answer is "that should be possible, but nobody has worked on it yet..."

My dream would be to be able to configure my phone like i configure my other systems (with NixOS :))! But be able to use it as before with all features and apps.

Update: More questions

• Why is this needed? Why can't i install an OS on mobile device like on a PC? (you probably can say all embedded devices...)
• Add list of known touch UI and package at least one (it helps to demonstrate the potential of the project a lot more than i3!)
• A section about funding. May ask for further funding through Liberapay, OpenCollective or just PayPal / SEPA. You can't have too much money. When you can't handle it, just hire more people or put bounties on issues :)
• A high-level roadmap would be nice on the website and using github milestones to organize issues
• refer to ANBOX (done, packaged https://nixos.org/nixos/options.html#anbox) and http://www.shashlik.io/ (packaging attempt NixOS/nixpkgs#20278)
• Do you consider pushing this upstream to NixOS when working properly and closing the dedicated project or is it a good idea to have it as a separate project to coordinate development, market it to different audience than NixOS etc? We don't have Desktop NixOS or Server NixOS.

Some notes:

The process looks a bit like that:

• https://wiki.postmarketos.org/wiki/Porting_to_a_new_device

Especially, with regards to the kernel. I haven't yet figured out the minimum required configuration options, but their check utility seems to make valid kernels for our purposes.

I just ported a new device, so the things I had to do are still fresh.

I was still using postmarketos simply for the fact that it is a valuable asset here: they have checks and some automation we don't have for that.

I followed the guide up until the kernel compiled. Once it compiled, I took the config file, the patches and got them into mobile-nixos.

• https://github.com/samueldr/pmaports/compare/motorola-addison/init

Once added (5624723) it all just worked™.

That is, going to stage-2.

The first step is to manage it like lxc containers, where an omnipresent init points to the last generation marked to boot. This will make it possible to do stage-2 without having to manage existing generations.

From #80.

Self-explanatory.

This is required for safer tinkering.

This is related to acting as a tertiary bootloader, and related to selecting NixOS configurations.

Find out existing work, either android-specific or other framebuffer-using samples. This is good for libraries and full applications.

Find documentation about the framebuffer, and how to use it.

Known applications and libraries

• Android-land
  • https://github.com/amarullz/AROMA-Installer
  • https://android.googlesource.com/platform/bootable/recovery/+/master/minui/
  • https://github.com/TeamWin/Team-Win-Recovery-Project/tree/android-8.0/minuitwrp
• DirectFB
  • https://github.com/aduros/SDL/blob/master/README.DirectFB
  • https://github.com/postmarketOS/osk-sdl
  • https://github.com/postmarketOS/charging-sdl
• https://github.com/dontpanic92/KernelFB
• http://www.netsurf-browser.org/projects/libnsfb/
• https://github.com/littlevgl/lvgl
  • https://github.com/littlevgl/lv_drivers → display/fbdev
• Cairo
  • https://gitlab.com/cairo/cairo-demos/blob/master/fbdev/cairo-fb.c

Random articles or sections of interest

• https://dvdhrm.wordpress.com/tag/fbdev/

Also better document the attrs available on direct nix-build, for the main default.nix, not only for the demo system.

NixOS/nixpkgs#42255

Let's make this as close to what upstream does.

Let's use /dev/kmsg when it exists as well; we won't need to use a file if /dev/kmsg is present.

I'm so amazed when the phone boots up and the NixOS logo appears.

I think a text "Mobile NixOS" could appear under it just half a second after it.

On the Website is a different logo that i also like. It's very simple, but looks elegant and professional.

But the project should only have one logo.

That is, to use mobile-nixos on a personal computer of mine as the stage-1 to what would be a more normal nixos installation.

To check:

• Use an efistub kernel with initrd appended as the product to be installed.

There are a couple issues:

• Using only upstream nixos to cross-compile everything
• Building gcc6 for cross-compiling

Uspstream nixos cross-compilation

The first point is a question of time, as ElvishJerricco/cross-nixos-aarch64 makes it possible to compile even mode stuff.

GCC6

This will be a bit harder. The asus-z00t kernel needs gcc6. It will seemingly build fine with gcc7, but will not boot.

Simply relying on what's currently in nixos will not work, as gcc6 apparently cannot build using gcc7 (which is partially expected). I do not know how to make it compile with gcc6, as depending it on a gcc6 stdenv causes recursiveness (expectedly).

Follow-up to #71.

Not sure what I want, yet, but most likely make if fall in line with the kind of README in the Nixpkgs repo.

The documented build method ./bin/build qemu-x86_64 initially fails with:

 $ env -i nix-build -A all -I nixpkgs\=/home/craige/git/NixOS/mobile-nixos/nixpkgs --argstr device qemu-x86_64
warning: Nix search path entry '/home/craige/git/NixOS/mobile-nixos/nixpkgs' does not exist, ignoring
error: file 'nixpkgs/lib' was not found in the Nix search path (add it using $NIX_PATH or -I), at /home/craige/git/NixOS/mobile-nixos/lib/eval-config.nix:20:16
(use '--show-trace' to show detailed location information)

When placing a copy of nixpkgs locally, it then fails with:

 $ env -i nix-build -A all -I nixpkgs\=/home/craige/git/NixOS/mobile-nixos/nixpkgs --argstr device qemu-x86_64
error: The option `sdImage.populateBootCommands' defined in `/home/craige/git/NixOS/mobile-nixos/system-image.nix' does not exist.
(use '--show-trace' to show detailed location information)

When building with nix-build --argstr device qemu-x86_64 -A all this first boot with ./bin/boot-qemu runs out of disk space and fails.

When you reboot that image, init panics and fails due to the state of the disk.

This is reproducible via the steps taken above. Happy to provide logs and console output if it will help.

Thanks!

The documented build method:

nix-build -I --argstr device qemu-x86_64 -A build.vm

Fails with:

 $ nix-build -I --argstr device qemu-x86_64 -A build.vm
error: getting status of '/path/to/source/mobile-nixos/device': No such file or directory

It's possible the documentation assumes some prerequisites I don't have. I was however able to build successfully with:

nix-build '<nixpkgs/nixos>' -A vm --arg device ./devices/qemu-x86_64

From the root of repo.

From #80.

ply-image is pretty redundant at this point.

LVGL allows us to do much more. Additionally, we gain SVG support, which allows us to have scalable graphics during boot.

Additionally, LVGL is much more than a tool to throw pictures in the framebuffer. We can use its ability to show text to show details about the errors!

Finally, we can also make the boot GUI aware of the current status of the boot process. We could do it in a simple manner and show x/y tasks done with a progress bar. We could also show the task name in there so a task that is "sticking" is more obvious.

Oh, and LVGL has some animation support in it. This could be used to "juice up" the boot GUI if desired.

According to my device tree the kernel is built with clang:

https://github.com/sm6150-dev/android_device_xiaomi_sm6150-common/blob/ff0849a9c79dc4949bff91972cde35506f96d97a/BoardConfigCommon.mk#L50

It would be nice to have a working clang cross-compiler and the kernel-builder.

I tried to add it myself, but compiler-rt fails to cross-compile: https://daten.reisen/fbahg1

(Now documented as a known issue.)

It seems that ply-image cannot always use the framebuffer. In those instances it fails with a Segmentation Fault. It happens for all calls to ply-image, when it fails during that boot, but does not seem to be a global issue, considering X11 can start.

/nix/store/8r56dnr007zd8q2wjgx4j8wanh5nvrd2-local-cmds: line 25:   769 Segmentation fault      /nix/store/w6b2gfiq270iglmx1fs8vsmy52597b9g-ply-image/bin/ply-image --clear=0x000000 /nix/store/y7l20cby57rbq56crjkrs0rz3awhwadd-splash.stage-2.png > /dev/null 2>&1

There are two sides to this:

• Simply getting make menuconfig working right and documented.
• Automatically handling saving the modified file to the devices/.../kernel/config.___ file.

The first part may be trivial enough. That alone is a good and probably simple improvement.

The second part is probably more tricky. Though it would make the development cycle easier.

I've tried hacking on the currently WIP pinephone branch today. I could only make a little progress by identifying that I fail to build against most recent nixpkgs-20.03 branch.

(It seems to me in some way mobile-nixos wants a static python build for u-boot. However nixpkgs u-boot by now builds against python37 which currently doesn't build statically mainly because of the forced link to "-lgcc_s": knedlsepp/nixpkgs@b1298d9).

Anyways, I was wondering if there was some way of having some means of communicating which version of nixpkgs we can expect to build against. A known good version might have gotten me a little further here, so I'm wondering if there was a feasible way to do this.
I'm not sure if pinning nixpkgs would be a good idea. Some CI setup against nixos-unstable could also help identifying breakage.
Are there any plans in that regard?

maybe also to README

also a proper description. support and communication belongs in the readme and on the website

right now it links to the outdated forum post

From #80.

The big idea is to properly define the spec for the file format.

Then, use a unix socket to wait for a boot selection, rather than read a specific file.

Inspired from:

• https://www.freedesktop.org/wiki/Software/systemd/PasswordAgents/

It would be useful to have the stage-1 work as a tertiary bootloader, which would in turn load initrd+kernel from an installed NixOS system on-device.

That is, make it possible to use a device withtout wayland nor X, when there are no framebuffer VT in the kernel.

boot/init/tasks/switch_root.rb

It would be better if we logged using the default logger why it decided to boot in recovery mode. Was it because the image is built to always boot in recovery mode (as configured)? Was it because it saw the lack of _kip_initramfs?

This will be moved to a new task, to be done outside this PR.

TODO

• Implement dependency failures

Right now, all dependencies are expected to resolve at some point. This means that any failure in a dependency to be fulfilled means it will be stuck in an infinite loop.

We might need to add timed delays and tries delays for dependencies.

Then, we need to transmit the error for a dependency to resolve to the tasks that depend on it. In turn, that function will be able to handle it.

Originally posted by @samueldr in #66

I've tried creating an SD Image for the PinePhone based on your pine64-dont-be-evil branch using my x86_64-linux box over the weekend. Sadly the result failed to boot. Since I've read that the issue might come from the fact that it has been cross compiled, I've been setting up a remote aarch64-linux builder on a Raspberry Pi.
However I'm currently having a little trouble to do distributed builds with it. With the nixpkgs repo, I've successfully launched a remote builder by just calling:

nix-build -A hello --system aarch64-linux

However when I try to build the mentioned SD image using:

nix-build --argstr device pine64-dont-be-evil -j0 -A build.diskImage --system aarch64-linux

I get the following error:

building '/nix/store/ylsbkyxw1kirbdzrylvgh2zxr98n4p5a-builder.pl.drv'...
while setting up the build environment: executing '/nix/store/59nin1ij2x7772l467m2b2glmyscs26y-bash-4.4-p23/bin/bash': Exec format error
builder for '/nix/store/ylsbkyxw1kirbdzrylvgh2zxr98n4p5a-builder.pl.drv' failed with exit code 1

The called bash is in fact an aarch64 binary:

file /nix/store/59nin1ij2x7772l467m2b2glmyscs26y-bash-4.4-p23/bin/bash                                                                 
/nix/store/59nin1ij2x7772l467m2b2glmyscs26y-bash-4.4-p23/bin/bash: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /nix/store/1ygglqib3lg0wywg95rk2kmxvl97zp08-glibc-2.30/lib/ld-linux-aarch64.so.1, for GNU/Linux 2.6.32, not stripped

So the --system option seems to be respected, which can also be seen in the lines coming from modules/system-target.nix:

trace: ******************************************
trace: * Evaluating device: pine64-dont-be-evil *
trace: ******************************************
trace: Building with crossSystem?: aarch64-linux != aarch64-linux → we're not.

I however don't understand why this build is being run locally on my x86 machine instead of being forwarded to the Raspberry Pi.

This includes

• Mounting the system's firmware partition
• Packaging closed-source components (e.g. TheMuppets repos)
  • https://github.com/TheMuppets/proprietary_vendor_asus/tree/lineage-15.1/msm8916-common/proprietary
• Making the firmware loader (?) know about the packaged firmwares AND the firmware partition.

A picture says more than a thousand words.

It may happen that you have a "sad phone" screen when booting.

How should i expect that to look? Just show it with a screenshot.

https://mobile.nixos.org/in-depth/stage-1.html#_about_sad_phone_screens