El 3/9/24 a las 18:25, Roland Clobus escribió:
Hello list,
On 31/08/2024 00:38, adrian15sgd wrote:
...
In the live-boot MR discussion Roland Clobus has suggested to bring
the discussion here in the Debian Live mailing list.
So I'll try my best to make a summary so that this can discussed here.
I'm primarily focussed on the scenarios, regarding booting the image,
that need to be supported by live-build. I would like to know the
scenarios first, before the solution is chosen.
We currently have as boot test (in openQA [1]):
* 'walk boot options': activates every single entry in the
syslinux/GRUB menu: (BIOS, UEFI, UEFI secure boot) x (ISO as CDROM,
ISO as USB device) -> 6 variants.
A trimmed down version would only need to boot into the live
environment (instead of testing every menu entry)
To test the booting of the correct device we additionally need:
* 2 different bootable devices, BIOS/UEFI is configured to boot the
first device
* 2 different bootable devices, BIOS/UEFI is configured to boot the
second device
Questions:
* Would it be sufficient to differ only in desktop environment (e.g.
GNOME vs KDE) or would is also need a different distribution (e.g. sid
vs trixie)?
From the liveid point of view what you are going to be using to detect
if a wrong bootable device has been boot it's if a given file is found
inside of it (the full live id path, e.g.
/LIVEID/A2345678/B2345678/C2345678/D2345678) or not.
* Does this need to be duplicated for BIOS/UEFI/UEFI secure? (i.e. 2 x
3 scenarios)
* Would it matter if the devices are CD-ROM or USB? (i.e. a
multiplication by a factor of 4 for the scenarios)
Well, this was originally a problem for booting CD-ROM from UEFI. So
that would be the only variant to be added.
As an update to liveid I am currently experiment with barebones Grub
autodetecting its CD-ROM device without having to resort to searching
for a .disk/info file .
The only variant that might be a problem would be booting USB from UEFI
by the means of using 'Boot from file' option from your UEFI but I'm not
sure we want to support that specific boot option in any case.
Other scenarios that might need to be supported:
* FST File System Transposition
-> First an USB stick of suitable size (at least 5GB) needs to be
prepared and then booted. This will also enable tests for persistence.
This mimics how some tools for installing live images prepare an an
USB stick.
Ok.
* Booting with the bootiso GRUB option, in which another tool
chainloads one of the ISO files on a USB stick
Yeah, you mean the findiso option. Super Grub2 Disk would be the one. We
could adapt some of its scripts for that.
I can help with that.
Regarding Grub finding its own device in that case... well... what
happens is that Super Grub2 Disk already knows the device... so... what
I mean is that in that situation we are not using the live cd's grub
images but our own grub. The only files being used from the live cd's
are grub.cfg which in turn loads kernel and initrd.
* More scenarios?
If I understood from Adrian's comments correctly, in some BIOS/UEFI
implementations the information about the original boot device get lost.
Well, I also thought that for booting a CDROM from an UEFI firmware
because of how ElTorito specification works but it actually seems to
work (but I need more testing).
With kind regards,
Roland Clobus
[1]
https://openqa.debian.net/tests/overview?distri=debian&version=sid_gnome&groupid=14
So I guess that I will be replying to this email again when I'm more
sure about how reliable is this Grub autodetecting its own boot device
when booted from UEFI CD ( With ElTorito ).
That way I will know for sure what are the variants to be tested.
adrian15
