Comment 18 for bug 1284196

Revision history for this message
Filofel (filofel) wrote (last edit ):

I ran into the same bug too, booting 20.04.4 from a 4TiB GPT partition partition on a 4TiB disk.
I have grub bootblocks installed in a bios-grub partition, sectors 34-2047.
The problem seems to be that by default, Grub uses BIOS drivers to load files from the target partition (32-bit LBAs, access limited to the first 2TiB of the disk). This is (tersely) documented in the GNU GRUB manual, command "nativedisk".
When using native grub drivers (ahci in my case), everything works (64-bit LBAs).
I solved the problem by re-running a grub-install with parameter
--disk-module=ahci
The problem with that approach is that any further grub-install without those parms (like an Ubuntu software update might decide to do) will zap the native driver from the Grub partition, and break the boot again.

grub-install should never generate a broken boot when it can avoid it:
Ideally, when grub detects that at least one of its target partitions crosses the 2TiB boundary, it should give a warning and do a grub-install with the --disk-module=MODULE parameter.

4TB SSD disk prices dropping fast (below 350€ these days). This problem might increasingly show up...