On Fri, 28 Oct 2022 18:31:41 -0000
"Jake D" <techsupport_accounts(a)riseup.net> 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/commo...]
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/#r...]
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. :-)