[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Zhang Boyang
Subject: Re: [RFC PATCH] kern/dl: Add module version check
Date: Wed, 21 Dec 2022 19:38:28 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0


On 2022/12/21 17:43, Thomas Schmitt wrote:

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

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

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

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 :)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]