I am using an Upboard so a x86 system with Grub as bootloader.
When booting, the eMMC is referred as hd0 by Grub so the script grub.cfg handle the partitions properly.
But for my system I need an external flash drive to be plugged at boot some time.
But in that case, Grub refers the USB flash drive as hd0 and the eMMC as hd1 so the Grub script do not work and ends with the Grub command line.
Is there a mean to force grub to always use hd0 for the eMMC?
Actually, I have found that the grub command search allows to find partition by label or UUID but the default grub.cfg would need a lot of changes.
Does anyone managed to handle this?
Are you using Yocto and in that case which version?
@mirzak Yes, I am using Yocto with the sumo version.
Thanks
Ah, unfortunately we do not support booting using UUID on sumo, but on thud you can active this feature.
It is unclear to me what the workaround would be on sumo, and I wonder if the “bios” boot priority can affect what gets assigned to hd0.
Ah, interesting.
I am stucked on sumo because of meta-upboard for now but I may try to port it to thud.
In my case, the bios boot priority does not seem to affect grub naming.
One quick way to move to thud is to utilize meta-intel and intel-corei7-64 machine which also works on Up boards.
But this depends on if you rely on functionality that is available in meta-up-board.
Ah yes, I should go that way because I do not use specific UpBoard features like GPIO.
And anyway, I can apply upboard kernel patches manually on top of meta-intel.
@mirzak I have moved my system to the thud branch but the partuuid feature does not fix my issue because it is the whole disk the issue.
With no USB drive inserted, the internal eMMC of the Upboard appears has hd0 in Grub but with the USB drive inserted, the eMMC appears has hd1.
Changing boot order does not change anything.
Did you think of any solution?
Makes sense now, that partuuid only applies to the mender_root variable and not to the mender_grub_storage_device.
I can not think of an easy way to get around this, because GRUB is not able to scan/probe for a partuuid.
But I know of one user who has solved a similar problem using the GRUB search command, which supports looking up filesystem image by label or fs-uuid. But this would require changes to the grub.cfg file + making sure that the partitions are labeled accordingly on each update.
Copy and paste my response from 992 so people can find it in either place.
I somewhat solved this issue back when I implemented partuuid.
A small secret about the grub disk order is that it is derived from the BIOS boot priority order (in most cases). So if the disk you have grub on is highest in boot priority there is a good chance it will always be hd0 regardless of new media being added.
Not a perfect solution but it should cover most embedded cases where someone isn’t expecting to boot from a different device.
@mdavis777 Oh great. You seem lucky. I could not managed to do the same on the UpBoard, even after updating the BIOS.
Unfortunately that is why I had to add the caveat of in most cases. It is supposed to be 100%, but not every BIOS does the magic grub is expecting.
You may want to contact UP and see if they have something in the BIOS that is forcing USB to always be higher in boot priority.
Also make sure to check the setting with the USB drive inserted. Sometimes they only show the devices connected in the priority list.
FYI, there are changed up for merge that will resolve this, meaning that mender_grub_storage_device is dynamically determined at run-time.
Thanks a lot for the update @mirzak I really appreciate it!