Comment 1 for bug 1097570

We have to find /boot/grub somehow in the signed memdisk configuration (generated in debian/build-efi-images, if you're curious), but none of the solutions I initially thought of work here. The filesystems are identical because they were copied, so we can't leave any clues in the file names or contents. Filesystem labels are reserved for sysadmins to set - at least if you're at all sensible - and we can't realistically bake a filesystem UUID into the signed memdisk configuration because we'd then end up changing the UUID of the filesystem containing /boot/grub and that doesn't sound like a great plan.

So, all the cleverer search strategies seem off the table, but EFI does have the Loaded Image Protocol which lets you find out where the image you're running came from. And oh look - GRUB's EFI initialisation code already sets $root from that if it can. I suspect the reason I didn't rely on this is that GRUB only does this for hard disks (which might well be reasonable), but this is in the startup code used on CDs and I needed it to work there as well. I think the right answer is probably something along these lines:

-if ! search --file --set=root /.disk/info; then
- search --file --set=root /.disk/mini-info
+if [ -z "\$root" ]; then
+ if ! search --file --set=root /.disk/info; then
+ search --file --set=root /.disk/mini-info
+ fi
 fi

But I need to do some testing to check exactly how the boot process behaves in a few different cases, and possibly add more sanity checking there to make sure that ($root)/boot/grub exists before committing to it.