I am almost sure now that the reason I saw: 'Running /scripts/local-premount ... Scanning for Btrfs filesystems' is power supply or circuitry related.
What exactly is a question still. If I want to know, I have to go back to the situation on the day before yesterday when I tried to boot the new ROCK3A v1.31 with the original downloaded noble 6.2.62 based images.
Radxa wiki mentions 5V/2A is needed, so I took a known-to-work PSU (used for diskless RPi4B) rated 5V/2.4A, added my https://www.fnirsi.com/products/fnb48s and with HDMI, serial console, RJ45 connected as well.
The FNB48S displayed values well below 5V/2A. What worries me is that several strange things happened:
- with 2 different brand SD-cards, the board went in a low-power state, stalled. Disconnect and then reconnect USB-c power cable made it boot further mostly, until 1 time full success
- the HDMI monitor sometimes shows a shaky flash. That is the most strange; I suspect a loop in cabling somehow, but it isn't there (in theory). The workaround is to make sure no loops, so no HDMI, serial console connected laptop on batteries
- around kernel/systemd messaging about NPU power also something changed, either stall or success.
In the end, as stated already, Radxa Debian11 CLI image worked. But also the Armbian Bookworm minimal IoT image with kernel 6.6.62. So I used the latter one to set up some basic things like ssh access and keys and correct MAC/IP address (networkd fails somehow with DNS in my homelan, so purged netplan and (re-)installed NM). And the converted the whole rootfs of-line to Btrfs with btrfs-convert, put SD-card back in and it still worked.
Yesterday, the day after, I swapped the 5V/2.4A+FNB48S for just a new RaspberryPi 5V/5A PSU (not that the 5A matters) but was new/unused and also got 2 the other already setup noble rootfs systems onto extra partitions on the same SD-card. No issues, although now it is kernel 6.6.63 or 6.6.64 already as I put it on the beta repo.
My use-case was replacing an old dead Intel Asrock server board handling a large SATA HDD, so I needed the 6.1.84 vendor kernel which now includes a SATA overlay and that works (kernel sees it at least).
So my guess is I have/had some (GND)loop or whatever. I always can run the whole setup via an off-grid standalone 12V car-battery, in case I want some 'proof'. it was late in the evening, too tired as well I guess.
There is an issue with SD-card interfacing in the 'noble_current_6.6.62' images I think. I see the same:
Begin: Running /scripts/local-premount ... Scanning for Btrfs filesystems
and is is because after the kernel is loaded and starting to run (doing scripts from initramfs etc), the SD-card/MMC interfacing get flaky or so. That endless wait is just that initrd can't find the rootfs. It also happened in an earlier phase that communication with the SD-card gets into trouble. Then many block I/O errors. It seems on older slower card 1 out of 4 powercycles it works, and then also no problem at all. The successful run I managed to setup the full system KDE neon desktop. But now it always fails, so I took a complete image of the SD-card and will try later.
In my case it is a ROCK3A so different SoC. A Radxa Debian11 CLI image gives no problems. I will make an own topic later when I know more.