Re: [RFC PATCH] kern/dl: Add module version check

[Zhang Boyang]

Hi,

On 2022/12/21 17:43, Thomas Schmitt wrote:
> Hi,
>
> Pete Batard wrote:
> > > unlike what is the case for UEFI, one can not expect
> > > to be able to pick all the GRUB core files needed to convert a GRUB
> > > based ISO bootable media to a GRUB based USB bootable media [...]
> > > Typically, one of the
> > > missing files will be a 'core.img' that can work for USB BIOS boot of a
> > > MBR partitioned FAT or NTFS media, and that even a GRUB based ISOHybrid
> > > image will not readily provide.
>
> Zhang Boyang wrote:
> > The situation is, for BIOS boot, there is no grub core file in ISO
> > because it's written to sectors instead of files? Did I understand
> > correctly?
>
> I think it is rather about the fact that GRUB equipped hybrid ISOs boot
> on legacy BIOS from USB stick via the MBR code (~440 byte) to the
> El Torito boot image, which is in charge for booting from optical media.
> In grub-mkrescue ISOs it is called
>    /boot/grub/i386-pc/eltorito.img
> The MBR code is taken by grub-mkrescue.c from the file "boot_hybrid.img"
> in source_dirs[GRUB_INSTALL_PLATFORM_I386_PC].
>
> So no core.img is needed and the filesystem module set can be sparse,
> because the filesystem type is known from which GRUB will read its further
> software.

Thanks for explaining! So I think the best solution for Rufus is to 
overwrite distro's .mod files with its owns (if mismatched modules is a 
problem).

> Pete Batard wrote:
> > > Rufus usually recommends to write such images in what it calls
> > > "ISO mode" (shorthand for "ISO extraction mode") with the ISO content
> > > extracted to a FAT or NTFS file system and with a GRUB core.img
> > > bootloader
>
> Maybe one should not only put a copy of the EFI boot image's /EFI/BOOT
> tree into grub-mkrescue ISOs but also an outdoor pack with the GRUB
> equipment that is needed to make bootable a USB stick with FAT or NTFS.
> (The filesystem modules are included in Pete Batard's proposal for the
>   /EFI/BOOT tree. But the disk MBR image and core.img are not.)
>
>
> Zhang Boyang wrote:
> > test whether that commit (052e6068be62) breaks Rufus
> > (e.g. Rufus with latest git GRUB, to boot Debian ISO).
>
> Debian ISOs still boot on legacy BIOS via ISOLINUX.
> Archlinux, Ubuntu, Fedora, and others meanwhile use GRUB in their ISOs for
> both, legacy BIOS and EFI.

Oh, yes, Debian seems using isolinux instead of grub.... So please use 
Ubuntu ISOs for testing, which uses grub in BIOS mode. By the way, I 
also tried Arch Linux, it also uses isolinux (but it has a theme looks 
like grub).

I did reversed tests (i.e. old GRUB core + new GRUB modules) just now:

1) I used Rufus 3.21 and ubuntu-22.04.1-desktop-amd64.iso (which uses 
GRUB 2.06) to create a USB stick. To simulate mismatched modules, I 
overwrited "\boot\grub\i386-pc\relocator.mod" (on USB stick) with my 
latest git build. Then that USB stick failed to boot in BIOS mode, 
showing "452: out of range pointer: 0x100010" error.

2) I tested supergrub2-2.06s1-beta2-multiarch-CD.iso with latest Arch 
Linux (BIOS mode, grub 2:2.06.r403.g7259d55ff-1). It doesn't have 
problems booting Arch Linux because it has $prefix properly set to its 
own GRUB path in CDROM, so it is using its own modules. If I manually 
run "set prefix=(hd0,msdos1)/boot/grub", it will failed to boot, showing 
"error: symbol `grub_debug_malloc' not found."

By the way, I googled "452: out of range pointer" and there seems a lot 
of them. Probably the root cause of many of them is mismatched modules, 
so I think giving a clear message to user should be helpful (if similar 
things happens in future).

Best Regards,
Zhang Boyang

> I think that in any case an ISO made by grub-mkrescue should be tested.
> Maybe a distro developer is here who uses it for making a full fledged
> installation ISO or a live ISO.
>
>
> Have a nice day :)
>
> Thomas