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 _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
