Also on Debian based systems [LWN.net]

Also on Debian based systems

Posted Jul 30, 2020 20:02 UTC (Thu) by leromarinvit (subscriber, #56850)
In reply to: Also on Debian based systems by zlynx
Parent article: Grub2 updates for Red Hat systems are making some unbootable

Interesting. Both the Debian wiki and the Arch wiki suggest using exactly this command. What does it break, and what should be used instead to (re-)install GRUB on UEFI systems?

to post comments

Also on Debian based systems

Posted Jul 30, 2020 21:43 UTC (Thu) by hmh (subscriber, #3838) [Link] (5 responses)

The correct command on Debian/Ubuntu, for EFI systems, is just "grub-install", and let it auto-detect what it should do. Unless you unmounted /boot/efi and removed its definition in /etc/fstab, in which case you're on your own. Do yourself a favor and ensure /boot and boot/efi are mounted read-write first. Feel free to change them back to a much safer read-only afterwards, though.

I have no idea where that /dev/sda in the wiki came from. It is never right for an EFI install, hopefully grub-install will ignore it, because if it doesn't, well, the result won't be pretty.

Heck, you don't tell anyone to grub-install /dev/sda *even* for grub-pc (the "PC BIOS" edition), you say something like /dev/<boot device>...

Also on Debian based systems

Posted Jul 30, 2020 21:46 UTC (Thu) by hmh (subscriber, #3838) [Link]

Fixed the Debian wiki page.

Also on Debian based systems

Posted Jul 30, 2020 22:56 UTC (Thu) by leromarinvit (subscriber, #56850) [Link] (3 responses)

> The correct command on Debian/Ubuntu, for EFI systems, is just "grub-install", and let it auto-detect what it should do.

Good to know, thanks.

> I have no idea where that /dev/sda in the wiki came from. It is never right for an EFI install, hopefully grub-install will ignore it, because if it doesn't, well, the result won't be pretty.

What would it do? Treat the GPT partition table as MBR and corrupt it? While definitely not pretty, that should be recoverable as GPT has a backup table hopefully not located in the first few sectors.

> Heck, you don't tell anyone to grub-install /dev/sda *even* for grub-pc (the "PC BIOS" edition), you say something like /dev/<boot device>...

That's definitely a useful clarification. While it's probably obvious to the average LWN reader that a bootloader needs to be installed on whatever drive the system wants to boot from, people blindly following instructions might run into trouble here.

Also on Debian based systems

Posted Jul 31, 2020 20:58 UTC (Fri) by kreijack (guest, #43513) [Link] (2 responses)

> > I have no idea where that /dev/sda in the wiki came from. It is never right for an EFI install, hopefully grub-install will ignore it, because if it doesn't, well, the result won't be pretty.

> What would it do? Treat the GPT partition table as MBR and corrupt it? While definitely not pretty, that should be recoverable as GPT has a backup table hopefully not located in the first few sectors.

Apart the fact that boot device could not be /dev/sda, the GPT table would be not affected. In fact both GPT and MBR partition can co-exist together (and say the same thing or different thing ! more often the latter).

I think that the real risk is that some bios doesn't start in UEFI mode if a MBR partition table is available. My BIOS (which is quite old) didn't show any UEFI related option until I removed all MBR partition table.

Also on Debian based systems

Posted Jul 31, 2020 21:23 UTC (Fri) by anselm (subscriber, #2796) [Link] (1 responses)

In fact both GPT and MBR partition can co-exist together (and say the same thing or different thing ! more often the latter).

Theoretically, GPT-partitioned disks have a fake MBR with one huge untouchable “partition” that covers all the space within the GPT partitions. (This only gets you so far if your disk is bigger than MBR will support.)

Also on Debian based systems

Posted Aug 2, 2020 6:05 UTC (Sun) by kreijack (guest, #43513) [Link]

> Theoretically, GPT-partitioned disks have a fake MBR with one huge untouchable “partition” that covers all the space within the GPT
> partitions. (This only gets you so far if your disk is bigger than MBR will support.)

Correct.

To complete the answer, I have to point out that below of the "MBR" label there are two kind if information:
- the partition table
- the boot loader

Both are stored in the first sector. Grub-install change only the latter. So in any case grub-installer can't change nor damage the GPT table. However installing a MBR boot loader, could start the bios in legacy mode (and not uefi one).