imnlfn

Fortunately, this time I didn't have to take apart my device in order to get it working again. It eventually allowed me to log in, and I was able to switch all of the links back to their original locations without too much trouble. This allowed me to regain access to my SSDs, and normal operation. This time, it was the 6.14.0-rc7-edge version of the kernel that left out NVMe support again. How the absolute Hell did this happen twice in less than three months??? Does anyone know what the most recent kernel version is that is safe to use as far as NVMe/PCIe support is concerned? This is frankly ridiculous.

I can't tell you how aggravating it is to read this, since this is the second time in three months that my Rock 4A has stopped booting after a kernel upgrade. I disabled kernel upgrades in armbian-config the last time it happened, but clearly that wasn't sufficient. What's especially annoying is that in order to fix this, I have to take apart my whole device and disconnect my NVMe connection in order to boot from an SD card instead of the onboard eMMC. I appreciate you pointing out how to stay on a specific kernel version using apt instead of relying on Armbian, since the latter is obviously unreliable. I'm likely to move to an x86 device in the not-too-distant future though, given occurrences like this, plus the lackluster support from the board vendor.

It's definitely not a power issue in my case. I'm using a Penta Hat with my 4A and it has its own barrel jack and 12V/5A power supply that powers both the board and the drives. In any case, I let my system boot from the original configuration and took a picture of the messages before all of the BOOTP messages ran them off of the screen. I saw that it was failing to load a bunch of files, so I booted off of the SD again, this time using a version of Armbian with the 6.6.63 kernel. I saw then that several of the symbolic links the boot process needs were broken, so I fixed them, copying over files as needed (the kernel itself, specifically). Now I'm back in action, exactly as I was before the kernel update. I've left the current version pinned in armbian-configure and will wait for a version using a 6.13 series kernel before updating again.

I don't have backups, but anything of any importance should be on the SSDs connected via NVMe (a copy of which is also on an external drive in case of an emergency), so if I have to rebuild what's on the eMMC, that won't be the end of the world. I will start taking backups though, to make this whole recovery process easier in the future. I think that I should have been able to do this with armbian-config, but it wasn't working properly. I have a theory that this was because I "pinned" the current kernel before attempting to rollback to an older one, but I can't test my theory anymore because something that I did has rendered my system unbootable, even with the SSD drives disconnected. This is what I am going to attempt to do. I have successfully booted a much older image from an SD card, and I have been able to mount the eMMC, so if I can figure out what I need to replace in order to get the system to boot again on its own, I'll do that. If that's unsuccessful, I will just reinstall to the eMMC and add back the applications that I was using. I get that this is what bootstraps the board, but that is the entire extent of my knowledge of it. I'd like to better understand the boot process, but I haven't been able to find any basic explanation of it. To complicate matters, my 4A has an onboard SPI, which I believe can also contain the bootstrap code, but I have no idea if that would be a better way to go or not. Thanks for your comments!

I am having issues with my Rock 4A that are similar to those that @north1 is having. The 6.6.63 kernel was working great and now I can no longer boot after upgrading to the 6.12.9 kernel, since it no longer sees the drives I have connected via NMVe. I tried reverting to the old kernel via armbian-config, but it continues to load the newer kernel. The documentation for armbian-config is frankly appalling, BTW.