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/ > >
