On Fri, 28 Oct 2022 18:31:41 -0000 "Jake D" <techsupport_accounts@xxxxxxxxxx> wrote: > I seem to have got myself in a bit of a mess and I’ve having trouble > finding documentation that I can apply directly to my case . This is > my first time on Linux so I’m not familiar with much of the > terminology or background of these systems. On every linux system there is a help system called man. So, if you don't recognize a command, you usually can just do a, for example man ls or man cp or man chroot so you can understand what the command is doing, and the various options that you can use to tune the command. > > **Background** > > I have an internal drive that used to successfully dual boot windows > and a LUKS-encrypted F36 installation with BTRFS. > > I also had some spare unpartitioned space, which I used to fully > install some other linux distros (including another F36 installation) > to troubleshoot other minor problems (a tri-boot, so to speak) > > **What went wrong** > > The new distros installed fine, but I discovered afterwards I could > no longer find/boot into my original LUKS F36 installation. This is where you should have asked for help. At that point, it would have been simple to recover the system. UEFI only allows a single version of fedora (or any OS) to boot without some alterations that are complicated, and above your level of knowledge at this point. As Chris said, and I've personally experienced, panic mode is not the time to make any serious decisions. It has to do with human psychology. When we are in panic mode, we are in the acute stress response mode of our brain, fight or flight. In this state, we do not have access to our frontal cortex, so we lose all of our reasoning ability. A great precursor to making bad decisions. Take a few moments to inhale deeply, hold the breath for a few counts, and then exhale fully. Do this 5 or 10 times. That returns the brain to the default state, where your frontal cortex is again available. > In my > igornance, I tried deleting clearing the new installation partitions, > and now, if I select the Fedora option thru my BIOS boot menu, I just > get to a 'grub> ’ prompt. Right, it is trying to boot the linux partitions that you wiped. When it doesn't find them it drops you to a limited shell (command environment) in order to try to fix it. Way above your pay grade, and the chroot environment is a lot easier to work with to do the same thing, so you don't have to work at the grub prompt. > > I’ve tried a few commands there to boot manually but nothing worked > and it wouldn’t even decrypt the root partition, worse still, somehow > this process accidentally wiped the ORIGINAL LUKS F36 /boot partition > too. I have no idea how. > > **What I have now** > > Partitioning follows: > > nvme0n1p1: EFI partition (both win and DF36) > nvme0n1p2: MS Reserved > nvme0n1p3: Win10 > nvme0n1p5: Original Fedora /boot (accidentally wiped) > nvme0n1p6: LUKS volume > nvme0n1p7: Former ‘third OS’ boot partition (wiped) > nvme0n1p8: Former ‘third OS’ root partition (also wiped) > nvme0n1p4: Win Recovery > > **What I am trying to do** > > Unbork everything, somehow? > > I tried using these instructions in the official Fedora Docs, but > they seem to be …wrong? Out of date? They didn’t work, I suspect due > to LUKS/BTRFS. [ > https://docs.fedoraproject.org/en-US/Fedora/23/html/Multiboot_Guide/common_operations_appendix.html] > > The I found these...other Fedora Docs? Which seemed more up to date > and looked like they had relevant bits, bit still seem directly > applicable and didn't work. > [https://docs.fedoraproject.org/en-US/quick-docs/bootloading-with-grub2/#restoring-bootloader-using-live-disk] > > The only success I’ve had is with this guide: > https://fedoramagazine.org/os-chroot-101-covering-btrfs-subvolumes/ . > > I’ve managed to chroot (a very dumb word) thru a LiveUSB session, > with the following commands: > > >>cryptsetup luksOpen /dev/nvme0n1p6 fedora_crypt > >>mount /dev/mapper/fedora_crypt /mnt/ -t btrfs -o subvol=root > >>mount /dev/mapper/fedora_crypt /mnt/home -t btrfs -o subvol=home > >>mount /dev/nvme0n1p5 /mnt/boot > >>mkdir /mnt/boot/efi > >>mount /dev/nvme0n1p1 /mnt/boot/efi > >>mount --bind /dev /mnt/dev > >>mount -t proc /proc /mnt/proc > >>mount -t sysfs /sys /mnt/sys > >>mount -t tmpfs tmpfs /mnt/run > >>mkdir -p /mnt/run/systemd/resolve/ > >>nano /mnt/run/systemd/resolve/stub-resolv.conf (enter 'nameserver > >>1.1.1.1', save) chroot /mnt > > > I can ping google, and browse the original home folder with ls, so it > looks like ‘im in’ the original installation via chroot (which is > still a dumb word) The car is still there, but you've removed the starter. > What the problems are > > From there, I go back to the Fedora Docs and run > > >>dnf reinstall grub2-efi grub2-efi-modules shim What does ls -n /boot/efi/EFI/fedora show? Here, # ls /boot/efi/EFI/fedora/ BOOTIA32.CSV BOOTX64.CSV grubia32.efi grubx64.efi mmia32.efi mmx64.efi shim.efi shimia32.efi shimx64.efi > > That seems to work? Downloads and seems to install without any errors. Run dnf reinstall kernel-core If that command complains that the kernel isn't installed, then run dnf install kernel-core but that shouldn't be necessary, because you deleted the files outside of the package manager (dnf), it will still think they are installed according to its internal records. Then run, ls -n /boot Are there a bunch of files there? Do some of them have names like vmlinuz... or initramfs...? Then cd /boot/loader/entries ls -n * There should be a files there ending in conf. Here, # ls /boot/loader/entries ac21376ffcd448c1a1c1ebe04e09a89b-0-rescue.conf ac21376ffcd448c1a1c1ebe04e09a89b-6.0.0-0.rc5.20220914git3245cb65fd91.39.20220918.fc37.x86_64.conf ac21376ffcd448c1a1c1ebe04e09a89b-6.0.0-0.rc1.20220819git4c2d0b039c5c.16.20220821.fc37.x86_64.conf ac21376ffcd448c1a1c1ebe04e09a89b-6.0.0-0.rc7.20220930git987a926c1d8a.51.20221002.fc37.x86_64.conf ac21376ffcd448c1a1c1ebe04e09a89b-6.0.0-0.rc2.20220826git4c612826bec1.22.20220828.fc37.x86_64.conf ac21376ffcd448c1a1c1ebe04e09a89b-6.0.3-300.20221023.fc37.x86_64.conf ac21376ffcd448c1a1c1ebe04e09a89b-6.0.0-0.rc3.25.20220829.fc37.x86_64.conf You might only have one or two. If this is all true, and only if it is all true, you just need to go into /boot/grub2 and run the command grub2-mkconfig cd /boot/grub2 grub2-mkconfig -o grub.cfg At this point, your system should be able to boot your fedora install again. > The next step though; > > >>grub2-mkconfig -o /boot/grub2/grub.cfg > > fails with the following: > > >> /usr/sbin/grub2-probe: error: failed to get canonical path of > >> ‘/dev/mapper/fedora_crypt’ > I have no idea what that means. This command examines your whole system and checks for bootable partitions. A canonical path is an absolute path, a path without ambiguity. This might be a side effect of the missing kernel and initramfs. If it is still happening, what does running blkid show? How about less /etc/fstab or cat /etc/fstab > On the side, I also sees that despite the grub reinstall, theres no > vmlinuz or initramfs kernel files in the reconstructed /boot > partition, so I tried running > > >>dracut --regenerate-all You don't need to run the dracut command, because the kernel install does that automatically. You were so close, only missing the kernel reinstall step. Good job for a complete noob working from incomplete documentation! And you persevered and recovered from your own mistakes, you have potential. :-) _______________________________________________ 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
