Score:-1

Fix GRUB2 UEFI bootloader MBR after moving /boot mountpoint

mx flag

I have installed a debian based distribution on my drive. When I installed it, the / mountpoint was btrfs on a logical partition (/dev/sda7) with a mount point for /boot/efi on a fat32 logical partition (/dev/sda6).

I since wanted to use the savedefault feature of grub, which doesn't work on btrfs. So I booted up a live image with gparted and shrunk /boot/efi (/dev/sda6) added an ext4 partition /dev/sda8.

After that I adjusted /etc/fstab to use the new mount point and then followed the steps to repair grub.

  1. mount the root file system mkdir /tmp/rootfs && mount /dev/sda7 /tmp/rootfs
  2. mount the boot drive on the mounted file system mount /dev/sda8 /tmp/rootfs/@/boot
  3. mount the efi partition mount /dev/sda6 /tmp/rootfs/@/boot/efi
  4. mount sys mount --bind /sys /tmp/rootfs/@/sys
  5. mount dev mount --bind /dev /tmp/rootfs/@/dev
  6. mount proc mount --bind /proc /tmp/rootfs/@/proc
  7. for good measure mount home mount --bind /tmp/rootfs/@home /tmp/rootfs/@/home
  8. chroot into the rootfs chroot /tmp/rootfs
  9. repair grub, apparently

To repair grub I used this command:

grub-install /dev/sda

And it says it's successful. However when I then try to boot the system I get this error:

GRUB loading...
Welcome to GRUB!

error: file `/@/boot/grub/i386-pc/normal.mod´ not found.
grub rescue>

Of course it can't find it there because it's not in /@/boot/ anymore. I think this is an error with the stage 1 bootloader in the MBR. How do I fix that? I use an msdos partition table.

I have also managed to boot the system from grub loaded from a USB drive with this command

set root=(hd1,msdos8)
linux /vmlinuz root=LABEL=LinuxRoot rootflags=subvol=@ quiet splash rw
initrd /initrd
boot

I have tried to reinstall grub from there as well, with no success. I have also tried this command, which also didn't work (says successful, but same error appears on reboot).

grub-install --bootloader-id=grub --target=x86_64-efi --efi-directory=/boot/efi --no-nvram /dev/sda
mpboden avatar
do flag
I don’t understand the `@` symbol in your directory mounting points. Is this intentional? Could this have something to do with it?
FalcoGer avatar
mx flag
@mpboden No, that's intentional because that's how btrfs subvolumes work.
oldfred avatar
cn flag
Grub with UEFI is grub-efi-amd64 and normally in gpt partitioned drive. BIOS is grub-pc, if gpt you also need a bios_grub partition unformatted 1MB. The only reason for MBR (msdos) partitioning is if installing Windows in old BIOS boot mode. Ubuntu will let you boot in UEFI mode from MBR, but UEFI suggests gpt.
Score:0
mx flag

I was able to resolve this properly by converting my msdos partition table to a gpt partition table. I did that by booting a live cd and running

gdisk /dev/sdX
w

Afterwards I had to reinstall the windows bootloader with a live medium and open a command prompt. Then run this sequence of commands to install a new bootloader to the EFI partition.

diskpart
  list disk
  select disk <volume for EFI partition>
  assign letter=O
  exit
bcdboot D:\Windows /s O
O:
cd EFI
mkdir Microsoft
cd Microsoft
bootrec /Fixboot

After that I just had to reinstall grub (target x86_64-efi). os-probe didn't detect windows, so I had to add it manually by adding it a new file /etc/grub.d/42-windows file like so

cat<<EOF
menuentry Windows {
    search --no-floppy --set=root --file '/EFI/Microsoft/Boot/bootmgfw.efi'
    chainloader /EFI/Microsoft/Boot/bootmgfw.efi
}
EOF

After that run sudo update-grub and everything works fine.

Score:-1
mx flag

I was able to fix it by booting into the system as described above and then running

sudo apt install grub-pc-bin
sudo grub-install --bootloader-id=grub --target=i386-pc /dev/sda
sudo update-grub
sudo reboot

After reboot, run:

sudo apt remove grub-pc-bin
sudo grub-install --bootloader-id=grub --target=x86_64-efi --efi-directory=/boot/efi /dev/sda # no-nvram is detected automatically at this point?
sudo update-grub
sudo reboot

At this point everything is working as before. I just don't know why.

I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.