Alright, first day of getting this thing running. Seems like devuan can't be directly installed on arm devices so I will install latest debian instead and then migrate to devuan.

To start I am following this guide that uses oldstable debian version at the time of writing. It suggests using the iso image made by the author... but I don't trust it. Intead I am trying this using the official iso.

Parts that need to be done in windows are easy... resize partition and disable bitlocker. Then also disabling secureboot in the system setup. So far so good.

Then need to grab the latest iso and write it to a usb drive (a dual type-c/type-a drive is handy for constantly swapping between devices). That part is simple enough - go to debian website, grab iso, and dd it to the usb drive. Seems like debian only provides a netinstall image for arm64, I try it first.

Try to boot it... nothing. Device not found. Turns out that it can't boot from the charging port, but it can from the secondary port.

Now I can get to grub, and select install... black screen with a cursor, otherwise unresponsive. Waiting doesn't produce any results. So I decide to get the full dvd image instead in case there is some missing firmware, and just to make installation easier without an internet connection once it finally works. The way to do this is to use jigdo-file to build the iso locally for the target system, more details on that here.

With the full image written to usb I try again... still nothing. I remember that the boot is probably silencing something so I go in and remove the quiet` parameter. The result is:

EFI stub: Booting Linux Kernel...
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services...

Right, DTB files are necessary to boot, this being arm after all. I'm not sure if the file is on the system somewhere so I extract it from the latest kernel image and put it on the iso using isomaster.

This doesn't seem to solve the problem though, exact same output. After some googling around I run across this post which suggests adding earlycon=efifb to the kernel parameters.

This finally makes some difference. The same thing as before is printed, followed by a whole bunch of crap. Seems like it tries to start but still gets stuck somewhere immediately. This doesn't actually change anything, it just prints out more debug information that was previously hidden. To make sure I can go over everything that's outputted, I record the process with a 60fps camera. Some of the early output is only visible for about a second before it's gone. Unfortunately nothing interesting is visible: it correctly identifies the model, sees disabled secureboot, etc. In the end it's stuck at:

sched_clock: 56 bits at 19MHz, resolution of 52ms, wraps every 4398046511078ns

At this point I got kinda stuck and decided to try the iso I didn't trust. This one magically boots but even if I want to proceed with installation I can't - it only detects the usb drive and not the main nvme drive. Doing modprobe nvme doesn't seem to make any difference.

As a last resort I tried the latest weekly debian boot image but there's no difference. The cause I'm guessing is the one described in this pull request that was merged into fedora just yesterday.

That's enough for today, not in the mood to cross compile grub with and replace the one on the standard iso after spending so many hours on this already. Long road to working system ahead.