This is a story from the worst kind of user experience you can encounter and it can't even be put in one bugreport, so i think, here relevant discussion can happen. I really do not wanne make too much hassle about it, but I could happen anyone upgrading it's system instead of periodically reinstall the os ( and loose a loot of working tweaks which it ).
Backstory: "27 os-upgrades later"
Up First: "We are not Windows, we do not need to reinstall every year."
I installed a LUKS encrypted F15 as F15 was the thing. I upgraded and pampered it ever since. My first partition starts at sector 63, as all installations of that time did My actual PC would be UEFI compatible, but it never got upgraded from bios boot to efi. (I tried before i downgraded, but that grub2-install complained about missing secure boot for whatever reason)
== YESTERDAY ==
Because i wanted to play with Xen under Fedora, I foolishly installed the xen-hypervisor packages to my existing installation. This installed grub2-efi-x64-modules and whatever that did to the grub installation, is not known. Please find out!
Logs:
2023-10-16T14:42:56+0200 SUBDEBUG Installed: grub2-efi-x64-modules-1:2.06-94.fc37.noarch 2023-10-16T14:42:56+0200 SUBDEBUG Installed: xen-hypervisor-4.16.5-2.fc37.x86_64 2023-10-16T14:43:14+0200 INFO GRUB-Konfigurationsdatei wird erstellt … 2023-10-16T14:43:14+0200 SUBDEBUG Installed: edk2-ovmf-xen-20230524-3.fc37.noarch 2023-10-16T14:43:14+0200 SUBDEBUG Installed: xen-runtime-4.16.5-2.fc37.x86_64 2023-10-16T14:43:14+0200 INFO Created symlink /etc/systemd/system/multi-user.target.wants/xenstored.service → /usr/lib/systemd/system/xenstored.service. 2023-10-16T14:43:14+0200 SUBDEBUG Installed: xen-4.16.5-2.fc37.x86_64 2023-10-16T14:43:14+0200 INFO Created symlink /etc/systemd/system/multi-user.target.wants/xendomains.service → /usr/lib/systemd/system/xendomains.service. 2023-10-16T14:43:14+0200 INFO ls: Zugriff auf '/usr/lib/xen' nicht möglich: Datei oder Verzeichnis nicht gefunden
5 minutes later it got removed again:
2023-10-16T14:48:24+0200 INFO --- logging initialized --- 2023-10-16T14:48:28+0200 SUBDEBUG Erase: xen-4.16.5-2.fc37.x86_64 2023-10-16T14:48:28+0200 INFO Removed "/etc/systemd/system/multi-user.target.wants/xendomains.service". 2023-10-16T14:48:28+0200 SUBDEBUG Erase: xen-runtime-4.16.5-2.fc37.x86_64 2023-10-16T14:48:28+0200 INFO Removed "/etc/systemd/system/multi-user.target.wants/xenstored.service". 2023-10-16T14:48:28+0200 SUBDEBUG Erase: xen-hypervisor-4.16.5-2.fc37.x86_64 2023-10-16T14:48:41+0200 INFO GRUB-Konfigurationsdatei wird erstellt …
As you can see, for whatever reason, GRUB got changed and a new config was written.
== THIS MORNING ==
The system did not boot: Grub presented the grub menu, bot did not boot the kernel with the 'FATAL "grub_calloc" not found' message, you can find on the internet. It happens more often as you may think.
This means, grub bootloader has an issue, but it does not tell in which module(if any).
Suggested Fix from all sides: "boot with live disk, mount system / boot / proc / sys / dev and reinstall grub to boot device"
It took 5 hours ! to find out, that since F31 the bootloader can't not be updated in that way, because whatever ( i was unable to find out ) is written into /boot/grub2/i386-pc/core.img was TOO BIG to match into the 63 Sectors space gap of 32256bytes.
There seems no documentation what is written into it ( i assume mods ), how big the file really gets ( as it gets autoremoved after that stupid message ), how to debug such a problem and WTF an outdated "grub-mkimage" has to do with all this, as it's get displayed in the debug output of grub2-install.
As i'm pretty sure this message will make it to google search top#1 here is ...
== HOW TO FIX it really for Fedora:
Boot a matching Fedora Livedisk
su mkdir /mnt/system mount /dev/bootdevicePsystem /mnt/system mount /dev/bootdevicePboot /mnt/system/boot mount --rbind /proc /mnt/system/proc mount --rbind /run /mnt/system/run mount --rbind /sys /mnt/system/sys mount --rbind /dev /mnt/system/dev chroot /mnt/system
dnf downgrade grub2-pc --releasever=30 -y grub2-install --target=i386-pc /dev/bootdevice dnf update grub2-pc -y exit
reboot
Optional: recreate the grub.cfg from your rebooted system with dracut, otherwise LUKS passwordprompt looks different
THE BIG QUESTIONs:
A) why does XEN needs to change grub config to efi if no efi is used to boot the system?
I have to guess, to be sure that cpu virtualisation is turned on, but the user has to decide here. The package should not change the boot config at all. I'm aware it adds boot options with specialized grub.mods , but that should not damage the running boot config.
B) How could this fuck up the bootloader on disk?
==> This is of course the most important question here: How did it destroy the bootloader and how can it be prevented <==
I never found out what exactly happend!
C) How can the user nowadays update grub on disk, without moving it's partitions aside? ( which could not be possible regarding the age of the installationmedia or the setup)
I suggest to have a check ready, that detects this problem, and than uses a reduced amount of mods that's gets stored into "core.img". (I have to assume, that is what caused this).
I had an old core.img ready, which would have worked, but it got moved aside to create a new, now too big core.img :(
I also suggest an option to grub2-install to force a small core.img.. If I do not need ZFS, why bothering about it? ( Just an Example )
D) Fix the output of grub2-install for an up2date mkimage process, the display output is obsolete for years.
A word about man pages: They are useless if they copy "cmd --help" .
It's this kind of problem, where you need infos, when a browser is not available, but you would need to search for answers.. guess what, that's what man pages are for ;) Guess what was no help, grub manpages :(
I hope we can improve the situation for others here by adding some safty checks and an rescue core.img mode .
best regards, Marius Schwarz
-
Marius Schwarz