Booting into "Minimal BASH-like editing is supported screen", despite having Fedora instance

Ask Fedora
1

So, after the disastrous update a few days ago. I attempted to reinstall my Nvidia drivers, since my system was forced to llvmpipe. Upon restart. I cannot see my Fedora instance at all. I attempted chrooting per these instructions:

  1. Mount root partition on /mnt/root.

  2. Mount EFI boot partition: mount /dev/sda1 /mnt/boot/efi

  3. Bind mount special partitions:

mount -o bind /dev /mnt/root/dev
mount -o bind /proc /mnt/root/proc
mount -o bind /sys /mnt/root/sys
mount -o bind /run /mnt/root/run
mount -o bind /sys/firmware/efi/efivars /mnt/root/sys/firmware/efi/efivars
  1. Chroot to the broken install:

chroot /mnt/root /usr/bin/bash

  1. Reinstall Grub: sudo dnf reinstall shim-* grub2-* (or any other rescue operations).

I have 3 partitions: Root (mounted on mnt/root), /boot (mounted on /boot) and boot/efi (mounted on boot/efi)

Attempting to reinstall GRUB returns: sudo grub2-mkconfig -o /boot/grub2/grub.cfg sudo: unable to allocate pty: No such device

What do I do to fix my Fedora instance?

2

If you mounted your root filesystem at /mnt/root, then you would need to mount your ESP at /mnt/root/boot/efi.

Also, if /boot is a separate partition (it typically is), that would need to be mounted before you mount /boot/efi.

Note that /mnt/root/boot and /mnt/root/boot/efi should be mounted from the Fedora Linux installation on your HD (probably something like /dev/sda1 and /dev/sda2), not bind-mounted from the Live installation as the “special” partitions are.

Edit: I typically do all the mounts before I run chroot, but I guess mounting the /boot and /boot/efi partitions after you run the chroot command should also work.

Edit2:

That probably means you need to bind mount /dev/pts to /mnt/root/dev/pts. Again, note that the mounts need to be done in order – mount /dev before you mount /dev/pts. (And then unmounting needs to be done in reverse order – /dev/pts before /dev. But you can probably just let the unmounting be done by the OS when you reboot.)

1 Like
3

Thank you. So, I have 3 partitions: /root, /boot and boot/efi (ext4, ext4 and efi respectively)

/root: nvme1n1p5
/boot: nvme1n1p1
/boot/efi: nvme1n1p2

Could you please suggest a working order for me? This issue is already driving me crazy.

4

What you had looked close to correct.

It should be something like the following (my PC is different, so I cannot test this):

mkdir /mnt/root

mount /dev/nvme1n1p5 /mnt/root

mount /dev/nvme1n1p1 /mnt/root/boot

mount /dev/nvme1n1p2 /mnt/root/boot/efi

for i in dev dev/pts sys sys/firmware/efi/efivars proc run; do mount -o bind /$i /mnt/root/$i; done

chroot /mnt/root /bin/bash

Then run your commands to fix Grub or whatever else needs to be done and reboot.

5

I am sorry, could you elaborate the last command before chroot, the long one?
It asks for superuser permissions like the rest of them but putting sudo at the top, doesn’t fix it.
How should I run it exactly?

6

Not correct for a btrfs file system.

That should be mount /dev/nvme1n1p5 /mnt
Then mount /dev/nvme1n1p1 /mnt/root/boot
Then mount /dev/nvme1n1p2 /mnt/root/boot/efi
and chroot /mnt/root

Mounting the btrfs device instead of the root subvolume will always give the directories /mnt/root and /mnt/home when doing an ls on /mnt after the mount is completed.

Your suggestion would create the path /mnt/root/root to reach the installed root file system.

8

When I ran the command for special partitions, after putting sudo right before mount. It ran, but now my terminal is empty. I do not see liveuser@fedora or something.

My system is ext4, by the way.

What is the correct order to run them?

9

That command really does not need to mount /dev/pts since if /dev is bind mounted properly that dir will be available.
The correct path must be given to the mounted root file system or errors such as shown will occur.

10

sudo mount /dev/nvme1n1p1 /mnt/root/boot returns:

mount: /mnt/root/boot: mount point does not exist.
       dmesg(1) may have more information after failed mount system call.
11

As I stated above. The file system is likely accessible at /mnt/root/root and not at /mnt/root if you followed the suggestion given by Gregory.

13

Oh, I had to mkdir the directory for it to work. However, the special permissions by Gregory do not work, unfortunately. Do you know how to fix them?
I checked around a little bit and it seems that /dev needs to be mounted with -rbind rather than -bind?
Do you happen to know the correct order?

14

I will repeat the entire sequence I have previously posted but cannot find right now.

  1. boot to the live media
  2. open a terminal
  3. switch to root with su (everything from here on requires root)
  4. mount the installed root file system on /mnt
    sudo mount /dev/nvme1n1p5 /mnt
  5. bind mount the misc necessary directories
    for i in dev proc sys run sys/firmware/efi/efivars ; do mount -o bind /$i /mnt/root/$i ; done
  6. chroot to the installed system chroot /mnt/root
  7. mount the remaining file systems mount -a
  8. At this point you should be in the installed system as root and can perform needed repairs
  9. Once the repairs are complete exit from chroot with exit
  10. reboot to the normal system

The only thing missing detail there is the steps required for the repair in step 8. That is dependent entirely upon the actual problem (and yes I know this appears to be a problem with grub since it never actually gets to rescue mode.) The message in your title seems to indicate that.

Note that if you use one of the respins available at Index of /pub/alt/live-respins you would have a kernel booted that is current and not old as it would be if you use the original live media from the time f41 was released.

1 Like
15

I’m not sure what happened. I did neglect to mention that I usually run sudo -i as a first step before running all the remaining commands. When you run sudo -i, your prompt should change from ending in $ to ending in # to indicate that you are running in “super user” (root) mode. When you are running as root, the commands should work without prefixing sudo. (Be sure to exit super user mode when you are done running the privileged commands.) (You’ll have to exit twice to get out of both the chroot and the sudo -i.)

Yes, using --rbind instead of --bind is another way to do it. Then you can leave dev/pts and sys/firmware/efi/efivars off the list. (--rbind is just another way of writing -o rbind but if you use the former, be sure to use two leading dashes.)

16

Thank you, I just need to clear one thing though. If I mount by root partition as /mnt, what do I do with /boot and /boot/efi then?
Should I mount them as /mnt/boot and /mnt/boot/efi respectively?

1 Like
17

Can you post the full order please?
How should I mount my root, /boot and /boot/efi partitions? as mnt/root, mnt/root/boot and mnt/root/boot/efi respectively?

UPDATE: I managed to reinstall GRUB. I don’t boot into BASH-like editing screen now. However, the only things I see is “UEFI Firmware settings”.
I tried to get some AI assistance and regenerate the GRUB configuration file. It still adds “UEFI Firmware settings” only. It suggested adding .conf files for kernels, checking my etc/default/grub entry. However it didn’t succeed in regenerating my Fedora intro. What am I missing?

18

Sorry, I don’t know why GRUB would only show “UEFI Firmware settings” and I cannot guide you through what the settings should look like because I changed my PC to use the systemd-boot boot loader instead a long time ago. (I got frustrated with GRUB’s complexity and gave up on it.) Maybe Jeff (or someone else) can help you figure it out.

19

I have found the solution to this. Surprisingly, I had to use some AI assistance for this, but it worked this time:

sudo mount /dev/[boot partition] /mnt/boot
sudo mkdir -p /mnt/boot/efi
sudo mount /dev/[boot/efi partition] /mnt/boot/efi
sudo cp /etc/resolv.conf /mnt/etc/resolv.conf
sudo mount --bind /dev /mnt/dev
sudo mount --bind /dev/pts /mnt/dev/pts
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys
sudo mount --bind /run /mnt/run
sudo mount --bind /sys/firmware/efi/efivars /mnt/sys/firmware/efi/efivars
sudo chroot /mnt /bin/bash
1 Like