I am using a combination of u-boot and GRUB to provide a consistent and manageable boot process across a variety of SBCs. By doing this I can largely deal with the custom u-boot implementations by chainloading grub.efi and booting from there.
I have just started playing with mender and I notice that when I am using the UEFI image it starts the partition at a 16Mb offset which doesn’t allow me to install u-boot without clobbering the boot partition.
Is there a variable I have missed that will allow me to move the starting offset of the boot partition for a UEFI image?
Hi @PhoenixMage,
Not sure I understand the situation correctly, sorry. The BeaglePlay and BeagleBone AI-64 use a very similar booting strategy (U-Boot to GRUB).
There, the enabled MENDER_FEATURES included mender-grub, causing the integration to be injected into GRUB. Do I understand right that this is also the route you are following?
Additionally, it sounds like you have mender-image-uefi enabled and want to use the resulting .uefiimg. So the problem is not having a space reserved for the U-Boot environment? Or what causes the mentioned clobbering of the boot partition?
Greetz,
Josef
Hey Leto,
Good to know the Beagle’s are doing something similar, I will see if adding mender-grub to the MENDER_FEATURES does what I am after. Does the Beagle solution also use the grub.efi?
I was manually dd’ing the u-boot files to the microSD just to see if I could get it running, basically I was manually globbering it. I am using Rock boards and they require the idbloader at offset 64 and the u-boot.itb at offset 16384 which already has the boot fs there, hence hoping to move boot partition along.
I will trying your suggestion, I might hit you up on the yocto IRC to chat at some stage.
Cheers
Howdy @PhoenixMage,
sure, feel free to ping me on IRC. I see, this is quite RK-specifc it seems. A random thought, have you tried adding an --offset parameter to this line? If it does the trick, we can look into polishing and upstreaming such.
Greetz,
Josef