Duplicate marker files will make chainload fail to launch subiquity

[Taihsiang Ho]

Focal beta iso efi.img manipulates grub when searching for the target device to boot. The current searching method uses /.disk/info as a marker file to identify the target live usb device. efi.img assumes there is only one live bootable device inserted with the marker file /.disk/info and searches in this way:

 search --file --set=root /.disk/info
 set prefix=($root)/boot/grub
 source $prefix/arm64-efi/grub.cfg

In some use cases, people pre-insert many different distributions so they could easy to boot to and re-install different distributions. The marker file method will block this kind of multiple bootable setup.

[Steps to Reproduce]
1. Pre-insert one or more Ubuntu Bionic (or above) live usb sticks to your target machine
2. Boot from focal beta iso live usb stick

[Expected Result]
We boot to the subiquity and start to install the system.

[Actual Result]
We will boot to the grub menu provided by the other live usb sticks. The unexpected grub menu may lead you to load incorrect installer files and fail on installation.

[More Information]
The issue is reproducible 100% by a combination of Marvell Cavium ThunderX2 Sabre with Bionic live usb pre-inserted and intended to install the system via focal beta iso live usb. Use dd to destroys the bionic live usb will make the chainload boot to the expected focal one (and completed the installation with subiquity).

[Dimitri John Ledkov (xnox)]

Normal way to have multiple .isos at the same time is to place all .iso's on a single stick and use loopback.cfg support.

However, I'm not sure if our loopback.cfg is correct, as I have never tested it.

How do you expect us to uniquely find the disk to boot? Should we first check if /.disk/info exists in the current root, and just carry on? And only execute the search when we didn't find anything?

[dann frazier (dannf)]

Our use case is that we test remote systems that have both physical USB sticks and virtual USB sticks so that we can validate both modes of operation (we're looking to validate specific platforms, not just the correctness of the installer). If we left an installer dd'd onto a physical stick and boot an installer over a virtual stick, we can hit this problem. Removing the physical stick (or destroying its contents, as @taihsiangho did in this case) would of course workaround the problem - but that assumes the user is able to recognize the cause.

One option might be to generate a /.disk/info-$(uuid) into the ISO and have grub search for that instead of the generic /.disk/info. Another might be to just provide a hint to the user on failure that multiple installation media maybe what blew things up.

[Dimitri John Ledkov (xnox)]

@dannf can I get a grub shell prompt on such a system?

[Dimitri John Ledkov (xnox)]

We do have a uuid stamp file unique for each disk build, but we at the moment reuse the same grub.cnfg. I.e. we could be inspecting for

# cat .disk/casper-uuid-generic
49746a8d-baa5-4dcc-99a8-fbeafb606232

which is a unique id, per-kernel flavour, per live-server build.

[Dimitri John Ledkov (xnox)]

I think I found the problem!

On x86_64
# Skeleton configuration file which finds the real boot disk.
cat >"$workdir/grub.cfg" <<EOF
if [ -z "\$prefix" -o ! -e "\$prefix" ]; then
 if ! search --file --set=root /.disk/info; then
  search --file --set=root /.disk/mini-info
 fi
 set prefix=(\$root)/boot/grub
fi
if [ -e \$prefix/$platform/grub.cfg ]; then
 source \$prefix/$platform/grub.cfg
elif [ -e \$prefix/grub.cfg ]; then
 source \$prefix/grub.cfg
else
 source \$cmdpath/grub.cfg
fi
EOF

is used inside the monolithic/gcdx64.efi

However, during d-i build, self-built bootaa64.efi is used with:
 cat >"$workdir/boot/grub/grub.cfg" <<EOF
search --file --set=root /.disk/info
set prefix=(\$root)/boot/grub
source \$prefix/$platform/grub.cfg
EOF

The monolithic one is the one that gets signed, and imho we should use that one on arm64 for now.

[dann frazier (dannf)]

@Dimitri - is the significant difference there that $prefix can and should be trusted to uniquely point to the boot disk and only fallback to the .disk/info search?