StephanieSunshine
commented
2 weeks ago I might have found a work around. From the initramfs shell, I mounted the nvme root to /new_root as before, this time I went in and edited /new_root/boot/extlinux/extlinux.conf to point from the old root=UUID=... to root=/dev/nvme0n1p2, saved, fsync'd, and rebooted. It seems part2 was able to restart its install from there, and after a little massaging of the Ethernet network device to enable, the part2 install would complete.
I can now reboot into a working system. One thing I did do, is in part2 I saw pacman -Syu have some package fails. I ctrl+c'd part2 at the very end before reboot, and reran this command by hand and then updated after it had completed.
Greetings, I apologize ahead of time if this has been answered somewhere else. I tried to look at the closed issues before submitting this issue with no luck.
I have a Rock 5B+ that I went through the steps to enable NVME boot via the SPI bootloader update. Before, I tried to install to the NVME, I had used a USB stick with the same image (Latest for Rock5B+) and was able to get a booting instance after a few attempts. After that success, I decided to try and do the same, but from the NVME instead. I used gparted to zap all existing partition tables and then I dd'd the Arch for ARM image to the front of the NVME and rebooted. The installer came up and started the installation, after it rebooted a few times, initramfs fails because the root UUID changed. After manually mounting the correct partition from the NVME to /new_root and exiting, userland starts to boot, but gets to a point just after it syncs network time and reboots quickly without any clear error. I cannot escape this reboot loop.
Is there someway to disable this reboot loop from initramfs or from the working USB instance? I believe I have a mostly running system if I can just stop this and rebuild initramfs with the correct UUID for root and stop whatever is forcing this reboot.