Bug#924053: live-build: UEFI shows grub> on HP250 G6 2SX60EA
El 09/03/19 a las 16:35, Thomas Schmitt escribió:
> Hi,
>
> adrian15 wrote:
>> replace:
>> search --set=root --file /live/vmlinuz
>> with:
>> search --set=root --label \"${LB_ISO_VOLUME}\"
>
> This looks ok for me, as far as GRUB2's work is concerned.
Yeah, it had TYPO but, yeah, as I said it worked for me.
>
> But when the GNU/Linux comes up, it may again be necessary for software
> in the initrd to locate the ISO filesystem.
> Unarchiving dim memories from last year:
> https://lists.debian.org/debian-live/2018/04/msg00005.html
>
> If the initrd indeed looks for marker files, then one should coordinate
> both find-the-ISO efforts.
> If it has other methods, then one should consider whether they are good
> and whether it is possible to join them in GRUB2 .cfg.
No, that's not the case. findiso works fine when the iso filename is not
repeated in many devices.
That's not going to happen too often.
The bug you were pointing out, although I have not tested myself I think
it's present nowadays in official Debian Live builds (based on lwr).
The loopback.cfg tries to load grub/grub.cfg while it should load
boot/grub/grub.cfg instead.
I'll try to reproduce it later and report it in a new bug if it's needed.
>
> -------------------------------------------------------------------------
>
> If you stay with the idea of an earmark file, then the GRUB2 efi.img
> and the initrd need to know the name for their version of a live ISO
> (or installation ISO).
> Any two debian-live ISOs which shall be distinguishable would have to bear
> different earmark files.
No, findiso works with the iso filename.
Then when the iso has been loopmounted in grub shell the loopback.cfg
pass the iso path and iso filename to the kernel.
Initrd then looks for this specific path and iso filename in all of your
devices.
And that's it.
I mean,... if you have one hard disk with /boot/boot-isos/debian.iso
and you also have another hard disk with the same exact
/boot/boot-isos/debian.iso then you cannot be sure about which one has
been boot.
The first hard disk iso might be run from Super Grub2 Disk but then the
initrd might load the squashfs from second hard disk.
Well, I don't care too much for this scenario because we are dealing
specifically with having the same iso path and iso filename, which it
would be very rare.
>
> This imposes some work on tools which want to remaster Debian ISOs and
> derive own distingushable versions. The benefit is that those remastered
> ISOs can coexist with the originals not only in the firmware's list of
> boot devices but also later in the initrd's list of possible storage
> devices for mounting the ISO.
> Tools which just want to add some packages may maintain the original
> earmark and bet on not meeting the original ISO at boot time on the same
> machine.
>
>
> How stupid is the idea to let GRUB2 tell initrd the earmark name in
> a kernel parameter ? I.e. in
> linux /live/vmlinuz-4.9.0-6-amd64 boot=live earmark="${earmark}" components "${loopback}"
> where "${earmark}" would be set in the GRUB configuration of efi.img ?
>
> Needs possibly coordination with "${loopback}" which already cares for
> ISO image files.
>
> If debian-live switches to GRUB2 for BIOS, then "${earmark}" would
> have to be known to the .cfg empire in the ISO. But for now it would
> suffice to let efi.img tell it to all others.
Well, I don't care too much about syslinux/isolinux because grub is what
we use in Secure Boot (and the fact that Secure Boot has a minimal grub
environment it's what triggers all of these problems).
adrian15
--
Support free software. Donate to Super Grub Disk. Apoya el software
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
Reply to: