On Fri, Oct 28, 2022, at 5:53 PM, Jonathan Billings wrote:
It sounds like you only wiped the /boot partition, which should be
fairly easy to get back.
But /boot/grub2 and /boot/loader/entries are on /boot so the real grub.cfg and BLS
snippets are gone, which are trivial to create if you're an expert. If you're not,
it might as well be ouji board antics.
There's so many tiny things like this that the installer does, that it sorta makes it
a grand experiment in "what the hell did we miss" doing the fix manually.
We can just (a) reformat the boot partition, get its new fsUUID put into (b)
/boot/efi/EFI/fedora/grub.cfg and (c) /etc/fstab on the existing root (d) mount everything
in the proper order so we can do a chroot (e) run grub2.mkconfig (f) do a dnf reinstall
kernel so that we for sure have a vmlinuz on /boot and modules of the same version in /usr
and BLS snippet
But uhh what am I missing? Like, I'd just reboot at this point and wait for the
failure to give me a hint what I'm missing. But in this case, the user gets stuck in a
way they maybe can't get out of or describe and then we're worse off having
wasted the time.
Reinstalling the kernel and grub2 packages
will get you the packaged bits, and running dracut like you ran should
get you the initrd, although only after you’ve got the kernel.
reinstalling the kernel will run dracut, we don't need to run it again
After everything is reinstalled, then run the grub2-mkconfig command to
create the grub config file in your new /boot partition.
Just make sure you do everything from the chroot in an EFI booted
rescue environment, either on a livecd or booting the NetBoot iso with
the rescue option.
So unfortunately Live images don't have Anaconda rescue environments. And while the
netinstaller does, it will fail to find /boot by UUID in the /etc/fstab because it
doesn't exist anymore so the assembly and chroot will fail.
The manual method means high likelihood of missing a step or getting it in the wrong
order. Or asking someone to test all the steps in a VM.
Hence why reinstallation is easier.
If it's Btrfs, we can keep the old root and swap roots.
We need to fix two things (a) change the rootflags=subvol argument in the BLS snippets, so
they mount root subvolume instead of root00 subvolume (b) update the /boot fsUUID in
/etc/fstab
Right? Is that it? I think that's it.
OH OK there is one more problem. Probably the kernel in the new /boot is old and that
version's modules don't exist anymore in the (old) root subvolume's /usr and
therefore we can't boot. So yeah that has to get fixed somehow...
If the Btrfs volume is mounted normally (without any options) to /mnt we can copy the old
kernel modules from the new root to the old root and now the old root will boot.
cp -r /mnt/root00/usr/lib/modules/$theonlydirpresent /mnt/root/usr/lib/modules/
Right? That will return fairly instantly because it'll be a reflink copy, so it might
lead some folks to think it didn't work because it was too fast :P What should be true
is in the first path with root00, if you hit TAB after the last /, it should autocomplete
the only directory present which is the shipping kernel for Fedora 36.
Or hey I have that kernel in a btrfs snapshot I created after an F36 clean install. It
should be 5.17.5-300.fc36.x86_64 so the actual command ought to be
cp -r /mnt/root00/usr/lib/modules/5.17.5-300.fc36.x86_64 /mnt/root/usr/lib/modules/
OK I think that's everything?
--
Chris Murphy