[Bug 1970236] Re: Grub2 bios-install defaults to BIOS disk drivers, may break large disk boot

[Filofel]

Hi mkukri,

I'm using an HP Elitebook 8760W, released in 2011.
It's great fast, powerful, two internal SATA slots, very large RAM, and carbon footprint largely amortized by now.
And it's i7 is still largely fast and powerful enough for most usages, and I don't see the need for buying a new machine, and I would instantly recommend a similar refurbished machine over brand new cheap ones.  Heck, it was a Rolls Royce in 2011!
But its UEFI BIOS is a prototype (it warns / displays so and can't be fixed), not reliable, and hackable by rootkits and other malwares.

OTOH, it works and boots fine with Grub native drivers, and I haven't had any problem since I figured the default 32-bit BIOS drivers out (april 2022), fixed the problem and posted this message.  
The Grub config wasn't altered through OS and/or Grub updates / upgrades, not even upgrading from 20.04 to 22.04, so I guess I'm safe enough.

Too bad that Grub doesn't autodetect and autofix the BIOS-Grub / BIOS
driver on disks > 2TiB though, since that's a guaranteed failure. While
using native drivers is only a hazard - and not even one as far as I'm
concerned!

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to grub2 in Ubuntu.
https://bugs.launchpad.net/bugs/1970236

Title:
  Grub2 bios-install defaults to BIOS disk drivers, may break large disk
  boot

Status in grub2 package in Ubuntu:
  Won't Fix

Bug description:
  Description:	Ubuntu 20.04.4 LTS
  Release:	20.04
  grub-pc         2.04-1ubuntu26.15

  Booting Ubuntu 20.04.4 from a 4TiB partition partition on a 4TiB GPT disk.
  I have grub bootblocks installed in a bios-grub partition, sectors 34-2047, bios-grub flag set.
  The Ubuntu bootable partition is a plain 4TB ext4 filling up the rest of the disk.
  Suddenly, after a routine automatic Ubuntu kernel update, the boot started to break with message:
  "error: attempt to read or write outside of disk (hd0)."
  Boot-Repair didn't find nor fix anything.
  fscheck found nothing bad.
  Using Grub rescue showed this happened when loading the new kernel.
  Previous linux images were still booting.

  After a painful search, I realized that part of the new kernel file had been allocated by the filesystem above the 2TiB limit...
  Some more investigation suggested that by default, Grub uses BIOS drivers to load files from the target partition. This is tersely documented in the Grub 2.06 documentation, in the "nativedisk" command paragraph.
  And the BIOS drivers are limited to 32-bit sector addresses, i.e. 2TiB.
  When using native grub drivers (ahci in my case), everything works. Reliably, consistently, permanently.
  Reverting back to default (BIOS) grub drivers breaks the boot again.

  Native drivers can be activated from Grub Rescue using Grub command
  nativedisk
  But a better and longer-lasting solution is to insert the native driver into the bootblocks by running grub-install with a parameter such as
  --disk-module=ahci
  (could be ahci, ehci, ATA, ohci or uhci according to harware). E.g. something like:
  grub-install --disk-module=ahci /dev/sdaX

  The problem with that approach is that any further grub-install
  without this parameter (like an Ubuntu software update or upgrade
  might decide to do?) might zap the native driver from the Grub
  partition, reinstalling the default driver, and breaking the boot
  again.

  grub-install (and/or update-grub) should never generate a potential broken boot when it can avoid it:
  Couldn't it (shouldn't it) detect when one of the boot partitions in the boot menu crosses the 2TiB mark, give a warning, and generate a grub-install with the appropriate --disk-module=MODULE parameter?

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1970236/+subscriptions