Grub.cfg build with grub2-mkconfig

,

Hi …
since fedora 32, at every kernel update or system upgrade, I manually change my /boot/grub2/grub.cfg cause my system won’t start after the use of grub2-mkconfig. I’m now under fedora 37 and I try to build a working grub.cfg file but there’s always the same error at boot :
error: …/…/grub-core/net/net.c:1552:disk ‘hd0,msdos1’ not found.
After that, the boot menu is shown but selecting an item result always in the same error.
My install is /boot ext4 on sdd (historical reason) first partition and the rest of / (usr, var, etc, …) on a second partition same disk with one vgs and 5 lvm. No hd0 in grub.cfg …
Any idea ??

Sorry, I’m afraid there are not enough data.
First: be sure all important data are backed up !

First I assume that you have BIOS boot and that “sdd” is not a typo for “ssd” but /dev/sdd. That means that there should be sda, sdb and sdc and thus a “hd0” for grub.

Could it be that you boot from sda, used before for Linux, which contains grub in the bootsector, but dos partition 1 is replaced by some other partition scheme?
Grub boots from the boot sector, searches software in (hd0,msdos1)/grub2/i386-pc which is no longer there.
What is the partition table of the first disk sda?

Is the boot menu the menu just created with grub2-mkconfig on sdd/boot? That means that boot from sda fails and the systems boots sdd as second in order, but then I would expect it to work. I do not understand it yet, but a grub2-install into sdd and if the BIOS allows, setting sdd as first boot disk, should theoretically work.

What are the modification you apply manually?

Please post the output of cat /etc/default/grub and sudo ls -lr /boot along with sudo fdisk -l and lsblk -f

Thank you for answering …
Yes, I have a BIOS boot and as I said, my boot drive is hd3 or /dev/sdd (the only drive with a “boot” flag). My boot partition is (hd0,msdos1)/boot:


Disk /dev/sdd: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: ST1000DM003-1SB1
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x000ef9ba

Device Boot Start End Sectors Size Id Type
/dev/sdd1 * 2048 2050047 2048000 1000M 83 Linux
/dev/sdd2 2050048 421480447 419430400 200G 8e Linux LVM


Initialy (long time ago …) I’d a multiboot with sda as Windows disk and sdd as Fedora (with grub). Both disks where bootable (switching them at BIOS level if necessary) and the défault on sdd with grub showing Windows and Fedora. All works as well as possible but one day (sorry, I can’t remember when, surely after an update …), booting was no more possible so I decided to keep grub.cfg mannually up to date (adding a “menuentry” for each new kernel and erasing the oldest one). At the end of last year, boring by windows, I decided to erase sda.
Now, I would like to let the job to grub-mkconfig but when I boot using the new grub.cfg, error grub-core in net.c.
My old grub.cfg work and not the one build by grub2-mkconfig and I don’t know why.

We may be able to assist with the info I asked for above so we can see all the installed drives/devices

All what you want to know about …
Just for … I was an IT system and network on RedHat systems but I never give an eye inside “grub” and if it’s my last option I’ll do … What about “net.c” ? Something whith “Network boot” ?

[root@somewhere ~]# cat /etc/default/grub
GRUB_TIMEOUT=10
GRUB_DISTRIBUTOR=“$(sed ‘s, release .*$,g’ /etc/system-release)”
GRUB_DEFAULT=saved
GRUB_CMDLINE_LINUX=“rd.md=0 rd.dm=0 $([ -x /usr/sbin/rhcrashkernel-param ] && /usr/sbin/rhcrashkernel-param || :slight_smile: rd.lvm.lv=fedora_somewhere/root rd.lvm.lv=fedora_somewhere/usr vconsole.keymap=fr rd.luks=0 rhgb quiet”
GRUB_DISABLE_RECOVERY=“true”
GRUB_DISABLE_SUBMENU=“true”
GRUB_THEME=“/boot/grub2/themes/system/theme.txt”
GRUB_PRELOAD_MODULES=“usb usb_keyboard ehci ohci uhci”
GRUB_TERMINAL_INPUT=“usb_keyboard”
GRUB_ENABLE_BLSCFG=“false”
[root@somewhere ~]#
[root@somewhere ~]# ls -lr /boot
total 335924
-rwxr-xr-x. 1 root root 14225608 Apr 26 22:50 vmlinuz-6.2.13-200.fc37.x86_64
-rwxr-xr-x. 1 root root 14222920 Apr 21 01:56 vmlinuz-6.2.12-200.fc37.x86_64
-rwxr-xr-x. 1 root root 14227848 Apr 13 22:25 vmlinuz-6.2.11-200.fc37.x86_64
-rwxr-xr-x. 1 root root 12068776 Sep 26 2022 vmlinuz-0-rescue-4eead182a0ba4869a1babe292e2b4bb1
-rw-------. 1 root root 8435770 Apr 26 22:50 System.map-6.2.13-200.fc37.x86_64
-rw-------. 1 root root 8435408 Apr 21 01:56 System.map-6.2.12-200.fc37.x86_64
-rw-------. 1 root root 8434412 Apr 13 22:25 System.map-6.2.11-200.fc37.x86_64
lrwxrwxrwx. 1 root root 46 May 1 15:23 symvers-6.2.13-200.fc37.x86_64.gz → /lib/modules/6.2.13-200.fc37.x86_64/symvers.gz
lrwxrwxrwx. 1 root root 46 Apr 25 14:24 symvers-6.2.12-200.fc37.x86_64.gz → /lib/modules/6.2.12-200.fc37.x86_64/symvers.gz
lrwxrwxrwx. 1 root root 46 Apr 22 10:27 symvers-6.2.11-200.fc37.x86_64.gz → /lib/modules/6.2.11-200.fc37.x86_64/symvers.gz
drwx------. 2 root root 16384 Feb 10 2013 lost+found
drwxr-xr-x. 3 root root 4096 Jan 3 2019 loader
-rw-r–r–. 1 root root 564257 Jan 6 2017 initrd-plymouth.img
-rw-------. 1 root root 57468784 May 1 15:24 initramfs-6.2.13-200.fc37.x86_64.img
-rw-------. 1 root root 57472873 Apr 25 14:25 initramfs-6.2.12-200.fc37.x86_64.img
-rw-------. 1 root root 57463621 Apr 22 10:29 initramfs-6.2.11-200.fc37.x86_64.img
-rw-------. 1 root root 90126558 May 21 2021 initramfs-0-rescue-4eead182a0ba4869a1babe292e2b4bb1.img
drwx------. 6 root root 4096 May 2 15:08 grub2
drwxr-xr-x. 2 root root 4096 Apr 13 18:49 extlinux
drwxr-xr-x. 3 root root 4096 Jun 16 2018 efi
-rw-r–r–. 1 root root 255899 Apr 26 22:50 config-6.2.13-200.fc37.x86_64
-rw-r–r–. 1 root root 255930 Apr 21 01:56 config-6.2.12-200.fc37.x86_64
-rw-r–r–. 1 root root 255930 Apr 13 22:25 config-6.2.11-200.fc37.x86_64
[root@somewhere grub2]#
root@somewhere ~]# lsblk -f
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
sda
├─sda1 ext4 1.0 Ext4-D0V0-Svgs 5420d261-358b-4cf8-821c-c9c790511898
├─sda2 ext4 1.0 Ext4-D0V1-NEF 17c3cf30-2f8a-403a-9912-6baabd81c5a7
└─sda3 ext4 1.0 Ext4-D0V2-Tcqr 3e4e0290-f18b-4ee4-833c-7fc5ba999af8
sdb
├─sdb1 ext4 1.0 Ext4-D1V0-Pv 45e9b9c6-0829-4f0e-8bef-dca2db985064
├─sdb2 ext4 1.0 Ext4-D1V1-Wrk 50325cf9-56b1-41d7-a09d-d35c93e8a588
└─sdb3 ext4 1.0 Ext4-D1V2-Doc 028d274b-4703-4020-8a76-b006115b504a
sdc
├─sdc1 ext4 1.0 Ext4-D2V0-Music 16d40ac9-0677-410c-a201-6520140fa468
├─sdc2 ext4 1.0 Ext4-D2V1-Films c2963e93-2050-4b1d-967a-53372699df93
└─sdc3 ext4 1.0 Ext4-D2V2-Pics 28cb9a24-d727-4910-ba76-9f14a1298935
sdd
├─sdd1 ext4 1.0 caf993b6-66bf-4463-a7bc-3b7cc3b4fbc3 556.4M 36% /boot
└─sdd2 LVM2_member LVM2 001 bWqUxC-TOII-szpS-u906-2ghq-KJbV-u1552v
├─fedora_somewhere-root ext4 1.0 LV_root f86bee43-4853-47db-9529-91a2219d8a22 5.1G 41% /
├─fedora_somewhere-usr ext4 1.0 LV_usr 5037f2cd-74d2-4e8f-a203-0ed2053f7b66 16.4G 54% /usr
├─fedora_somewhere-home ext4 1.0 LV_home e9e512ab-6696-4e3f-8777-80e381253c15 10.9G 62% /home
├─fedora_somewhere-var ext4 1.0 LV_var de554e50-d2a5-4f80-80ba-b9d8780c6954 14.2G 22% /var
└─fedora_somewhere-swap swap 1 da470874-b1f5-450b-b4dd-52e514488f0d [SWAP]
sde
└─sde1 ext4 1.0 Ext4-Working 5c325fc8-afe0-4664-a054-b9aac35b9b78
sr0
[root@somewhere ~]#
[root@somewhere ~]# sudo fdisk -l
Disk /dev/sda: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: ST2000DM008-2UB1
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x5683ff9d

Device Boot Start End Sectors Size Id Type
/dev/sda1 2048 1258293247 1258291200 600G 83 Linux
/dev/sda2 1258293248 2516584447 1258291200 600G 83 Linux
/dev/sda3 2516584448 3907029167 1390444720 663G 83 Linux

Disk /dev/sdb: 465.76 GiB, 500107862016 bytes, 976773168 sectors
Disk model: SAMSUNG HD501LJ
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x354c354b

Device Boot Start End Sectors Size Id Type
/dev/sdb1 2048 327682047 327680000 156.3G 83 Linux
/dev/sdb2 327682048 655362047 327680000 156.3G 83 Linux
/dev/sdb3 655362048 976769023 321406976 153.3G 83 Linux

Disk /dev/sdc: 1.36 TiB, 1500301910016 bytes, 2930277168 sectors
Disk model: ST31500341AS
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x0168c00f

Device Boot Start End Sectors Size Id Type
/dev/sdc1 2048 976898047 976896000 465.8G 83 Linux
/dev/sdc2 976898048 1898498047 921600000 439.5G 83 Linux
/dev/sdc3 1898498048 2930272255 1031774208 492G 83 Linux

Disk /dev/sdd: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: ST1000DM003-1SB1
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x000ef9ba

Device Boot Start End Sectors Size Id Type
/dev/sdd1 * 2048 2050047 2048000 1000M 83 Linux
/dev/sdd2 2050048 421480447 419430400 200G 8e Linux LVM

Disk /dev/sde: 149.05 GiB, 160041885696 bytes, 312581808 sectors
Disk model: ST3160812AS
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x2045698f

Device Boot Start End Sectors Size Id Type
/dev/sde1 2048 312581807 312579760 149G 83 Linux

Disk /dev/mapper/fedora_somewhere-root: 9.77 GiB, 10485760000 bytes, 20480000 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disk /dev/mapper/fedora_somewhere-usr: 39.77 GiB, 42698014720 bytes, 83394560 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disk /dev/mapper/fedora_somewhere-home: 35 GiB, 37580963840 bytes, 73400320 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disk /dev/mapper/fedora_somewhere-var: 19.77 GiB, 21223178240 bytes, 41451520 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disk /dev/mapper/fedora_somewhere-swap: 9.25 GiB, 9936306176 bytes, 19406848 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
[root@somewhere ~]#


I just saw that … symvers under /boot is a link to /lib/modules/
But for me it’s not a problem because my old “grub.cfg” works !!!

AFAIK /boot/symvers… has always been a link to /lib/modules/…symvers…
That should not have been a factor.

I do not see a bios boot partition. With current releases of fedora an install in MBR mode creates a separate bios boot partition that replaces/supplements the MBR on the disk for booting.

It may be that lacking that space contributes to the need to manually update grub.cfg. I believe that grub2-mkconfig would also write into the bios boot partition as it updates the boot record.

If I understood correctly, the sdx1 partitions start at sector 2048 so grub has space to insert itself between MBR and first partition. Unless you do GPT partitioning which claims this gap too, then you need this additional 1M partition to have some space for grub. On this system it should be no problem. Disklabeltype=Dos.
As far I know, grub2-mkconfig creates grub.cfg, it’s grub2-install which touches the MBR.
It is strange, that grub tries to access (hd0,msdos1). Can you look in the “df” output whether /boot is mounted on /dev/sdd1 ? What are the “set root=” parameters and the menuentries in your own grub.cfg and in the grub2-mkconfig generated one?
I have no explanation for the “net.c” originated error too, there is no insmod of modulenet.

Currently grup2 is using the file system uuid to locate disk file systems. For example

search --no-floppy --fs-uuid --set=root 56a83e29-1e98-44f6-a33e-8988906ef2a1

Where you can find this uuid by running lsblk -f.

nvme0n1                                                                                 
├─nvme0n1p1 vfat     FAT32 efiboot  3056-3376                                 2G     0% /boot/efi
├─nvme0n1p2 ext4     1.0   homedisk 2ceb9488-262e-490b-91d9-f9bc93e6275c  210,5G    28% /home
├─nvme0n1p3 ext4     1.0   rootdisk 56a83e29-1e98-44f6-a33e-8988906ef2a1   78,3G    37% /
└─nvme0n1p4 swap     1     swapdisk 96621d97-5b40-497f-b0ce-d09430076c0c                [SWAP]

Yes, fortunately. With the UUID’s you’ve an unambiguous specification of the location, unless you want to do tricks like copying disks with dd.

If /boot is mounted on /dev/sdd1 and contains the proper kernel files, I am pretty confident that “/sbin/grub2-install /dev/sdd” will fix the problem, (or tell you that it has not enough space) but I do not want to give you advices which make your system unbootable. If you are able to prepare e.g. a Clonezilla USB and make an image of sdd on external (or one of the other disks), you should be on the safe side and can go back to original. The sdd1 is 1G, sufficient at least 7 kernels, but please check that it is not on the limit with old version’s kernels.

As said by h.janssen a bit later to your answer, grub.cfg is updated by grub2-mkconfig and it’s grub2-install who’s in charge of the MBR. No problem with that. I used both grub2 cmd without any error but some warnings (I think ??) like those for grub2-mkconfig :

File descriptor 29 (anon_inode:inotify) leaked on vgs invocation. Parent PID 4062: /usr/sbin/grub2-probe
File descriptor 33 (/memfd:pulseaudio (deleted)) leaked on vgs invocation. Parent PID 4062: /usr/sbin/grub2-probe

I said warnings because:
[root@somewhere ~]# grub2-probe --target=fs /boot/grub2
ext2
[root@somewhere ~]# grub2-probe --target=drive --device /dev/sdd1
(hd3,msdos1)
[root@somewhere ~]#

and all “menuentry” are valid (they are shown at boot and the “net.c” error appear before it is displayed and after the selection of an entry) stating that “grub.cfg” is found. But I could be wrong …

Well … 2 things …
First, I have already done a “grub2-mkinstall /dev/sdd” with success.
Second: when I answered to “Jeff V”, I noticed that grub2-probe with “fs” as target, the answer is “ext2” but my /boot/grub2 is on sdd1 which is in an ext4 format. A df -l show that:

Filesystem Size Used Avail Use% Mounted on
devtmpfs 4.0M 0 4.0M 0% /dev
tmpfs 2.9G 0 2.9G 0% /dev/shm
tmpfs 1.2G 1.7M 1.2G 1% /run
/dev/mapper/fedora_somewhere-root 9.5G 3.9G 5.1G 44% /
/dev/mapper/fedora_somewhere-usr 39G 21G 17G 57% /usr
tmpfs 2.9G 8.0K 2.9G 1% /tmp
/dev/mapper/fedora_somewhere-home 34G 21G 11G 66% /home
/dev/mapper/fedora_somewhere-var 20G 4.2G 15G 23% /var
/dev/sdd1 968M 345M 557M 39% /boot
tmpfs 592M 140K 591M 1% /run/user/1010

and with “mount -l”:
/dev/sdd1 on /boot type ext4 (rw,relatime,seclabel)

The df -h command is not really helpful in fixing this problem. It only shows currently mounted file systems and the problems you are talking about may be related to a different drive since it seems that the grub.cfg file built by grub2-mkconfig is not properly building the file for you.

I just installed a new system with legacy (BIOS) boot in a vm and this is what I see there.

$ lsblk -f
NAME   FSTYPE FSVER LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sr0                                                                           
zram0                                                                         [SWAP]
vda                                                                           
├─vda1                                                                        
├─vda2 ext4   1.0         7365c8f6-045a-4cd7-97bc-d8918c37600d  719.1M    19% /boot
└─vda3 ext4   1.0         f9eb66de-08e4-4794-a8ec-e3327ef51be7   10.3G    39% /

Note the UUID of the /boot partition.

$ sudo fdisk -l
Disk /dev/vda: 20 GiB, 21474836480 bytes, 41943040 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 21594B50-2595-44CD-ABDC-A3BACF4E78DA

Device       Start      End  Sectors Size Type
/dev/vda1     2048     4095     2048   1M BIOS boot
/dev/vda2     4096  2101247  2097152   1G Linux filesystem
/dev/vda3  2101248 41940991 39839744  19G Linux filesystem

Note there is a partition there (vda1) that is the bios boot partition


$ sudo cat /boot/grub2/grub.cfg
#
# DO NOT EDIT THIS FILE

.....trimmed..........

### BEGIN /etc/grub.d/10_linux ###
insmod part_gpt
insmod ext2
set root='hd0,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint='hd0,gpt2'  7365c8f6-045a-4cd7-97bc-d8918c37600d
else
  search --no-floppy --fs-uuid --set=root 7365c8f6-045a-4cd7-97bc-d8918c37600d
fi
insmod part_gpt
insmod ext2
set boot='hd0,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=boot --hint='hd0,gpt2'  7365c8f6-045a-4cd7-97bc-d8918c37600d
else
  search --no-floppy --fs-uuid --set=boot 7365c8f6-045a-4cd7-97bc-d8918c37600d
fi

Note that this shows the same UUID in that part.

None of the entries you show above with either lsblk or fdisk -l show a BIOS BOOT partition as is reflected on my post here. Probably because of the initial install with F32. I seem to recall that this change to using that partition for booting may have happened about the time F33 or F34 was released, but have not verified that. In any case, I believe it happened at the same time as fedora switched from using the full grub.cfg file under /boot/efi to the one under /boot/grub2 for those systems that were booting using UEFI.

This is the most up to date info I know for working with grub2.

I think that if you were to create a BIOS boot partition on /dev/sdd and then run grub2-install /dev/sdd and grub2-mkconfig -o /boot/grub2/grub.cfg that it would properly boot after that completes. The bios boot partition should be exactly 1M (2048 sectors) as is shown on my post here.

Ho !! But … I see that your “BIOS” boot partition is a partition for a GPT table isn’t it ?
My partition table is a “BIOS” table so … And my “hint=” option for the “search” function in grub.cfg is ‘hd3,msdos1’, the good one !! And for the UUID, they are OK too … It was one off my first check …

I saw some “strange thing” in grub.cfg build with grub2-mkconfig (thank’s for this thread) but I have to check if this is the origin of my problem …
I will let you know later …

So: sdd1 is mounted on /boot, is correct

557 Mbyte free on /boot: perfect

fsprobe=ext2: No problem, ext3 and ext4 are extensions on ext2 where grub is not interested in, filesystem can be read as ext2.

grub2-install already performed and no error. grub2-install gives a clear warning if it cannot embed it’s next stage and does not modify the mbr.
So one can assume that grub is launched and /boot/grub2/grub.cfg is read in.

On boot, there is this strange error message and afterwards the correct menu entries are displayd. But they do not work.
The manually entered grub.cfg file does work.

So the only thing left is to compare the grub2-mkconfig and manually edited files and see what upsets grub. Somewhat large pieces of text, I do not know the best way howto handle this on this forum.

You have 2 files. The one created by running grub2-mkconfig and the one you manually update.
The differences are easily seen with using the ‘diff’ command
diff file1 file2 will show exactly, line by line the differences with a < preceeding the lines in file2 that were removed and a > preceeding the lines that were added. The total making up the differences from file1 that would make it match file2.

If you were to post the diff output it may be that we could assist in identifying what is going wrong.

The full content of each file could be put where we could see it as well. On my system sudo cat /boot/grub2/grub.cfg | wc -l reveals there are only 217 lines in that file. The command sudo cat /boot/grub2/grub.cfg | fpaste should return a URL that you could post if the actual output is more than is allowed in a single post here. Then posting both files would allow us to see the differences and maybe provide a fix so the system boots properly.

GRUB_PRELOAD_MODULES=“usb usb_keyboard ehci ohci uhci” in your /etc/default/grub is probably causing the problem. This translates to
“insmod xxxx” lines at the top of grub.conf. Please remove ehci/ohci/uhci from grub.cfg and see whether the system boots. If yes, remove the line from /etc/default/grub. On my old BIOS system, “insmod ehci” causes the “net.c hd0,msdos1” error appear before the command is finished, the other ones destroy grub too. usb and usb_keyboard are no problem.

In combination with UUID search it should work.

Now I understand. Found a post explaining that these drivers are for USB/firewire disks and switch off biosdisk to prevent interference. This means that all disks are gone at once.

After the grub command nativedisk, native drivers are used and the disks are available as sata0,msdos1 (disk) , usb0,msdos1 (stick), sata4 (dvd)
This all in the grub shell. My old PC is from the XP time and USB stick can just be selected by F9 key and boots via BIOS, so I have no idea whether this all is still relevant and implemented in grub2-mkconfig/grub2-install. Only for very special configurations, I assume.

I came to the same conclusion …
After doing “sdiff” between my two grub.cfg (mine working and the one build with grub2-mkconfig), commenting/adding lines to have them identical and removing my comment/add one after one (each time rebooting, error, booting on a CD rescue and so on …) I came at the same solution …
My PC is more than 10 years old and is unable to boot from an USB stick/drive. So, after removing the “GRUB_PRELOAD_MODULES=” line from /etc/default/grub and running a “grub2-mkconfig”, IT WORKS !!!
I think that this is when the GRUB_PRELOAD_MODULES was taken into account in “/etc/grub.d/00_header” file that my problem occured … surrely during an upgrade from fedora 31 to 32 …
Thank you for your explanation … and I’ll mark your post as “solution” …
Just for … During my search, I found that default font where defined as “/share/grub/unicode.pf2”. I thought that all we needed to boot where under “/boot” … But …

Thank’s again for your help …