Re: Creating a multiboot live pendrive that works under EFI/UEFI
Hi Mikhail,
I previously responded only to point out that different tools are used
to create the different images, thus many differences are possible, but
that I did not know the cause of the problem offhand.
I may now have a better idea of the cause of the problem from work I
have been doing in the past few days. I recalled your email last night
and it occurred to me that this might relate to your problem.
So, current Debian live images are created with live-wrapper, while my
work has been entirely on the alternate tool live-build, but I believe,
without knowing the live-wrapper codebase that they are doing something
similar.
Live-build, when setting up the image for EFI, embeds a tiny grub.cfg
file in the EFI components, of the form:
```
search --set=root --file /live/vmlinuz
set prefix=($root)/boot/grub
configfile ($root)/boot/grub/grub.cfg
```
What this does is to search available devices to find one containing
the path '/live/vmlinuz' (on a filesystem readable to grub), assuming
that the first found is the one sought (which $root then points to),
and tries to load /boot/grub/grub.cfg from it to get its boot menu
displayed.
This is basically a sort of "bootstrap" to get from the embedded EFI
filesystem to the ISO's main filesystem, where its proper grub.cfg that
defines the menu lives.
Note at this point that I believe that live-wrapper instead uses the
path '/.disk/info', which live-build will be moving to also if work I
submitted yesterday gets merged.
Of course for this to work it depends entirely upon the path
(/live/vmlinuz', or '/.disk/info' as applicable) only existing on a
single filesystem, otherwise there's a good chance the wrong one will
be selected!
Normally such a path would never exist in persistent storage devices
(i.e. the installed OS and such), only be present in a single live-
disc, and thus will work fine, but (1) '/live/vmlinuz' has been found
to actually exist in some unusual HP system installations, which is
part of the reason for moving live-build to use '.disk/info', and (2)
is a problem if you happen to have multiple live-disc filesystems
available at the same time (i.e. multiple CDs/DVDs in drives; multiple
live USB drives plugged in; one or more of each, etc).
It may also be relevant in the cause of your situation of having
multiple ISOs crammed onto a single storage device, helping explain why
the rEFInd menu entries corresponding to individual ISOs result in the
wrong ISOs actually loading (or rather the right ISO loads, but then
its EFI redirects to a different one). (rEFInd entry loads the right
ISO, EFI grub.cfg from that ISO does a path search to jump out of the
small embedded EFI partition to the ISO's main filesystem, but the
search returns the filesystem of the wrong ISO).
I expect that the GParted-live image is doing a similar search to the
Debian-live images, but perhaps searching a different path hence why a
different ISO is selected compared to with the Debian ISO entries.
Note that in a standard OS installation, it is typical to refer to
partitions uniquely by UUID. This is not done for removable media like
live-images.
This path based search is obviously flawed. I do not believe it would
be possible to use UUID based identification, but it might be possible
to move to a disc label based identification, which presents greater
chance of uniqueness, thus solving the problem. Perhaps this is what
the Ubuntu images are already doing? I may grab an Ubuntu image to
examine later. Such possibilities of are already under consideration of
myself and another live-build contributor.
As to what can you practically do right now to fix the problem you're
experiencing, until such time that Debian images switch to using disc-
label based searches (if they ever do), well, if you absolutely must
have multiple ISOs on a single device like you're doing, you could
explore:
1. Modifying the images to get them doing a label based search instead
of file based search. This would involve rebuilding the
/boot/grub/efi.img file to contain a modified grub.cfg file.
2. Perhaps modifying the partition table of your device prior to using
the problematic entries to disable in some way (maybe change the
partition type) the partitions it mistakenly loads such that grub
ignores those partitions.
3. Building your own Debian live images using the available tools
(live-build or live-wrapper, though note that the latter is now said to
effectively be a dead project), but of course with a hack in place to
have them use a label based search.
Obviously these are all far from ideal, but unless you can find a way
to otherwise bypass the flawed search step the ISOs are doing, it's all
you've got for now.
Anyway, I hope this enlightenment helps :)
Regards,
Lyndon
On Sun, 2020-03-22 at 02:23 +0100, Mikhail Morfikov wrote:
> I'm trying to create a multiboot live pendrive that works under
> EFI/UEFI setup.
> This should be a really straightforward process, since you just need
> to:
>
> - create the GPT partition table on the pendrive
> - create the ESP partition and format it using fat32,
> - create one additional partition for each ISO file
> - install rEFInd and its ISO driver in the ESP partition
> - copy via dd each ISO file to its corresponding device /dev/sdb1,
> sdb2, etc)
>
> So the task is really easy to do, but for some reason not all images
> work well
> with this setup.
>
> Here's how the pendrive's partition layout looks like:
>
> # lsblk /dev/sdb
> NAME SIZE FSTYPE TYPE LABEL MOUNTPOINT UUID
> sdb 28.9G disk
> ├─sdb1 100M vfat part SD_ESP AD3E-
> 8645
> ├─sdb2 3G iso9660 part Ubuntu 18.04.4 LTS amd64 2020-
> 02-03-18-40-13-00
> ├─sdb3 3G iso9660 part Ubuntu 19.10 amd64 2019-
> 10-17-12-53-34-00
> ├─sdb4 3G iso9660 part d-live 10.3.0 gn amd64 2020-
> 02-08-12-48-50-00
> ├─sdb5 3G iso9660 part d-live 10.3.0 ma amd64 2020-
> 02-08-12-47-49-00
> ├─sdb6 3G
> ext4 part 1714184a-f3c2-405d-
> 988c-815d0f7fe107
> ├─sdb7 3G
> ext4 part 6ad21575-730b-424e-
> 8bcf-7ce691ffcbfa
> ├─sdb8 1000M iso9660 part GParted-live 2019-
> 09-03-06-21-27-00
>
> We have two Ubuntu images -- they both work just fine. I can choose
> whichever
> Ubuntu live system I prefer to boot from in the rEFInd boot menu.
>
> The next two are the Debian images (gnome and mate downloaded from
> here[1]).
> In the above configuration, when I choose either one of the Debian
> images,
> the Gparted live boots instead... When I remove the GParted-live
> partition,
> then the Debian Gnome boots, and works well, but I'm unable to boot
> from Debian
> Mate. When I choose Debian Mate image, then Debian Gnome boots
> instead...
>
> Any ideas why the two Ubuntu images work and the Debian's don't?
>
>
>
> [1]:
> https://cdimage.debian.org/debian-cd/current-live/amd64/bt-hybrid/
>
>
Reply to: