System boots to grub> prompt

Hi All,

I have a weird problem, I’m in the process of upgrading a system from Leap 15.6 to slowroll. To do this I needed to increase the size of my /boot/efi partition (as I had done a trial run on another system of the upgrade and it had failed because the 512MB efi got full!).

So I sourced a new ssd, created a 2GB fat32 partition, flagged it boot and esp. I then created my root partition as xfs, mounted it and the old root an rsynced the data over.
Followed by finally creating a swap partition at the end.

I then swapped the new drive into the system, booted from the leap install media, to the rescue system, ran the mount-rootfs-and-chroot script, did a mount -a to mount the filesystems, and changed the UUIDs in /etc/fstab to be the correct ones for the new drive.

I then ran mkinitrd followed by grub2-install and grub2-mkconfig -o /boot/grub2/grub
All went as I would expect without errors.

Now when I boot the system from the new drive it drops straight to a grub> prompt in text mode. If at this point I type exit, I then get the normal Leap startup menu, and can boot the system as normal.

Having done a net search I found a post on this forum that suggested looking at the output of efibootmgr :

Timeout: 3 seconds
BootOrder: 0001
Boot0001* opensuse-secureboot	HD(1,GPT,b9ee96e0-0327-4371-99e0-b00465a86556,0x800,0x400000)/File(\EFI\opensuse\shim.efi)..BO

The above uuid doesn’t match that of any of my disks (or the previous disk) , so I’m guessing that it needs to match the uuid of my current disk? How can I go about doing that?

Cheers.

Phill.

The output from “efibootmgr” typically gives the partition UUID rather than the file system UUID.

You can use the command “blkid” (as root), and look for the PARTUUID information. It is probably the old disk, since it is going to grub.

When you use exit from there, it tries again. It is then likely looking at “EFI/BOOT/bootx64.efi” in the new EFI partition.

You might need to add a new entry, with “efibootmgr -c” (check the man pages for details).

Humm,

aurigae:~ # efibootmgr -v
Timeout: 3 seconds
BootOrder: 0001
Boot0001* opensuse-secureboot	HD(1,GPT,b9ee96e0-0327-4371-99e0-b00465a86556,0x800,0x400000)/File(\EFI\opensuse\shim.efi)..BO
aurigae:~ # blkid | grep b9ee96e0
/dev/nvme0n1p1: UUID="D7BA-1C20" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="b9ee96e0-0327-4371-99e0-b00465a86556"
aurigae:~ # lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
nvme0n1     259:0    0 931.5G  0 disk 
├─nvme0n1p1 259:1    0     2G  0 part /boot/efi
├─nvme0n1p2 259:2    0 925.5G  0 part /net/aurigae
│                                     /export/src
│                                     /export/mail
│                                     /export/home
│                                     /
└─nvme0n1p3 259:3    0     4G  0 part [SWAP]
nvme1n1     259:4    0 931.5G  0 disk 
└─nvme1n1p1 259:5    0 931.5G  0 part /export/other
                                      /other

So it looks like (to me) that entry IS pointing to the efi partition of the first drive, which is odd.

Cheers.

Phill.

That’s not really odd. It is expected.

Keep in mind that the EFI boot entries are stored in NVRAM, which is part of your hardware. So when you remove that disk, the entry stays there.

If you want to remove that entry, you can use:

efibootmgr -b 0001 -B

If you want to add an entry for your second disk, try:

efibootmgr -c -l `\EFI\systemd\shim.efi` -L openSUSE

but you might also need to specify the disk (with -d 2) if the old disk is present. Check the man pages for “efibootmgr” for details.

Still not working…

Deleted the previous entry and then used

efibootmgr -c -d /dev/nvme0n1 -p 1 -L "OpenSuse" -l '\EFI\opensuse\shim.efi'

To add a new entry :

efibootmgr -v
Timeout: 3 seconds
BootOrder: 0000
Boot0000* opensuse	HD(1,GPT,b9ee96e0-0327-4371-99e0-b00465a86556,0x800,0x400000)/File(\EFI\opensuse\grubx64.efi)

Is still displaying grub> until I type exit.

Cheers.

Phill.

There are some systems where the BIOS keeps strict control, and ignores what you try to do with “efibootmgr”. You probably have one of those systems. You can try going into BIOS settings to delete the unwanted entry.

If when you created the new larger ESP you merely created a new one elsewhere on the disk, or on an additional disk, and did not reallocate the space allocated to the old ESP with another filesystem, then its content remains. A poor EFI BIOS may still know about and use it even after partition “deletion”, which only removes the table entry, not the content. Try wiping that space and you may see the issue disappear. My brother’s Biostar A78M-E35 motherboard had me vexed solving basically the same problem for more than a week about 3 months ago. I recreated the old ESP, put an ext4 filesystem on it, then wiped and deleted the partition, and the problem was gone.

Right I think I got it working after much faffing about with bios updates and uefi shells, which didn’t have any bearing, but live and learn…

So it looks like there may have been 2 thinks in play, in /boot/efi/efi/boot I had a grub.efi and grub.cfg that my other systems don’t have, don’t know if this affected the problem but deleted them as they probably shouldn’t be there.

The main problem seemed to be the file /boot/efi/efi/opensuse/grub.cfg had the UUID of the old root filesystem, once I edited the file and put the new root in, it boots straight to the menu now.

Thanks for the help, much appreciated.

Cheers.

Phill.

With my brother’s Biostar, I thought I had the problem solved several times. It would boot OK a random number of times, as few as once, but eventually grub> would return, until I did the wipe.