updating from 24.8.3 to 24.11.x no longer boots from µSD card

[Meestor_X]

Currently running 24.8.3 and have copied it to the eMMC, working fine on both the µSD image and eMMC.

(On the Rock-Pi-S, if you have a bootable image on the µSD card, it boots from that. If not, it boots from the eMMC.)

 

Today, running from the µSD, I did an apt update and apt upgrade, and it updated a few packages (here's the list):
 

# apt list --upgradeable
Listing... Done
armbian-config/unknown 25.2.0-trunk.154.1212.080011 all [upgradable from: 24.11.1]
armbian-firmware/bookworm,bookworm 24.11.2 all [upgradable from: 24.11.1]
base-files/bookworm 24.11.2-12.4+deb12u8-bookworm arm64 [upgradable from: 24.11.1-12.4+deb12u8-bookworm]
linux-dtb-current-rockchip64/bookworm 24.11.1 arm64 [upgradable from: 24.11.1]
linux-image-current-rockchip64/bookworm 24.11.1 arm64 [upgradable from: 24.11.1]
tzdata/stable-updates 2024b-0+deb12u1 all [upgradable from: 2024a-0+deb12u1]

 

Now, it no longer boots from the µSD card. So I assume it's done something catastrophic to the image on that card?
 

[eselarm]

I think a new U-boot is used now. At least I recognize this when I had updated the U-boot in my eMMC from original out-of-the-box (from FriendlyWRT, NanoPi-R6C) 2017.x to  mainline based 2024.10.x

I did this manually with dd myself after reading a lot about Rockchip booting etc. Your Rock-Pi-S may behave differently, it is not RK35xx (that should do Android originally).

 

The new U-boot contains a lot of extra functionality, I don't know all features of course, but If you hit a key to stop at autoboot, then it is possible to do 'bootflow scan' and many more things. It will give you the option so select what is found to be working (eMMC, SD-card, BOOT/TFTP/PXE in my case). The normal scripting found in boot.cmd (and converted to boot.scr) just picks the usual obvious as far as I saw, so if U-boot comes from eMMC, eMMC is selected. That should be ROM determined AFAIK. I do not know the details (yet).

 

At least I know that my ROCK3A had zeros in its SPI flash out-of-the-box. If the first 16MiB or so of the eMMC would all be zeros, the ROM can only go for SD-card.

 

If you would only fill the U-boot area with zeros (from after the GPT till 1st partition), it still could go loading from eMMC as it finds maybe a valid (old) boot.scr and Image and uInitrd and DTB. I had that yesterday. So make sure you don't have double/old paths for booting. And check you UUIDs.

 

[Meestor_X]

Thank you for your reply, @eselarm.

Any chance you could ELI5 what you just said? I didn't glean what specifically I would need to do to resolve the issue from what you wrote.

[eselarm]

I do not have an easy solution. For a start and better understanding, you will need a serial console cable between the rockpi and a laptop or so.

My way working is simply that I don't use SD-card anymore, just eMMC to boot an OS.

[Meestor_X]

35 minutes ago, eselarm said:

My way working is simply that I don't use SD-card anymore

Huh! And my feeling is that the ability test out new functionality without messing with a working system (the working system being on the eMMC) is to try things out on the µSD first. Also, SUPER easy to copy a working µSD build to the eMMC with Armbian-install.
Thanks anyway, I'll keep digging - using a serial monitor will be my last resort if I can't find another answer.

[eselarm]

It is indeed super easy to work with the concept of: 1 version of an OS = 1 SD-card or 1 storage device

 

However, there have been bootmanagers like GRUB or just in UEFI BIOS hitting DEL or F8 key that enable you to have/install multiple OSses on 1 storage device.  Small/cheap/embedded devices like SBCs or routers or TVboxes usually are strictly 1 OS, already because of the special HW and chips need a dedicated firmware/kernel. So only the OS of the HW vendor is used in principle.

 

But Armbian and most other Linux distros are complete Desktop capable OSses like Windows or MacOS. There is a lot of SW functionality available to have multiple versions/distros installed. You can have up to 128 partitions, I usually keep the first 4 for Windows, then add another 4 or so for various Linux OSses/variants. The trick is you need to know how to shrink partitions, then you can add multiple yourself with a partition manager tool (fdisk, gdisk, parted, etc).

 

I format the extra Linux partitions not with Ext4 but with Btrfs. That allows me to resize them online, so the OS itself is running from it when resizing is happening. So no need to take out the storage device (SD-card) and do that on a laptop or so.

 

In addition, Btrfs supports snapshots, so within 1 partition/filesystem one can easily make a read-only copy(=snapshot) of the working installation and then from there install new beta or testing packages. If that turns out not to work or complete mess up things, it is rather easy to go back to the snapshot copy (the working installation). This might sound like magic, but Opensuse Linux offers this already for almost a decade and it is done at startup of the PC. Of-course that assumes HDMI/keyboard perfectly working, that cannot be assumed for many embedded systems where Armbian is running on. So to interact at startup time, you need a serial console cable (cost 2 dollar), then there is also the option to have some menu selection (just text, selecting a number or so).

 

The new U-boot can offer that as far as I can see, but it is not something Armbian can easily have as default. It cannot know what other OSses are wished/installed/running. The Armbian build system just generates 1 bootable image for a certain HW board. You can select to use Btrfs for the rootfs, so then it is some btrfs commands to transfer that online from the image somewhere on a NAS to the eMMC or NVME of the SBC.

 

The OS or partition selection at boot-up/power-on can all be put in a script. Sofar, I just edit only armbianEnv.txt (the rootdev=  line) and make sure the correct files are on the FAT-formatted boot partition. If that works for you also depends how much special HW I/O (overlays etc) you use.

[Meestor_X]

Thank you for that detailed explanation.

I am using Armbian on tiny headless devices that are not made to be user-configurable. Just need to get things working again with the newer OS. Hopefully I'll have some more time soon to start from scratch with the latest OS, and see if armbian-install is working now.

[Meestor_X]

Update to say that I was able to update the RockPi-S to the latest armbian, and was able to copy the image to the eMMC and it boots properly, using armbian-install. armbian-install's menus are still broken, but it seems to still do the imaging properly.

So, let's call this one closed for now.

Edited yesterday at 05:27 AM by Meestor_X