7:12 a.m.
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