[Feature] UUID strategy consideration when M.2 MVME or SATA Enclosures failed or are not connected on boot

[SoSie]

 

Hello all,

 

I succeed to boot on sata usb by seting the UUID of the armbian_root from mmcblk1p1 to sda1

I tested several M2 SSD enclosures both NVME and NGFF most of the time,

 

 

one in the middle, has a USB Hub and micro SDCARD port.

Now if the USB enclosures is not connected, we are stuck in initramfs stage because the UIID partition given in /boot/ArmbianEnv.txt does not exist.
I changed the UUID of emmc armbian_root (mmcblk1p1) thinking it would be overmapped with partition of S2 usb enclosure (sda1).
It is not the case, it will only boot on emmc , ignoring S2 enclosures when mmcblk1p1 and sda1 shares the same UUID.

I suggest USB enclosures should comes in higher boot priority than emmc after a bootable sdcard is present or not,
so the end user is not lost in initramfs jungle.

 

 

 

Edited September 11 by SoSie
Fix

[going]

31 минуту назад, SoSie сказал:

It is not the case, it will only boot on emmc , ignoring S2 enclosures when mmcblk1p1 and sda1 shares the same UUID.

Each attached memory disk must have its own unique UUID. This is its essence.

 

37 минут назад, SoSie сказал:

I suggest USB enclosures should comes in higher boot priority than emmc after a bootable sdcard is present or not

This depends on the platform (BROM bootloader flashed into the chip) and possibly the switch soldered to the board.

[SoSie]

 

Hello @Going,

 

I mean If uboot is available on a sdcard plugged in, it will boot on it else on emmc, Sometimes when UUID are the same, it is the last device discovered that overlaps. Wehen cloning emmc UUID back to sdcard do'nt change. My mind was to have a multiboot like refind or ventoy that helps if a system crashed. having a failsafe system aside to fix it graphically can be a must.

 

Changing /boot/boot.cmd that affect u-boot may do the work

Edited September 14 by SoSie