Hi Guilherme, My machine is a 10-years old (but i7, quite powerful) HP Elitebook 8560w. Old BIOS, not maintained anymore, that has an experimental / early UEFI that I'd rather not use. The SSD is a 8TB ATA Samsung SSD 870 device. No RAID involved, just a plain 8TB disk. "--disk-module=ahci" get it to work because the Grub ahci native driver support 64-bit LBA adressing, while GRUB by default uses the BIOS LBA, that is 32-bit. Since the partition table is GPT, GRUB has access to all information about the disk size and partition addresses in 64-bit values. It does not have to rely on a legacy DOS partition C/H/S info. I assume GRUB uses BIOS by default to bet maximum compatibility with the real BIOS, and this is fine until your boot files land above the 4TiB limit... which is what happened to me a while after I upgraded my 4TB Crucial disk to an 8TB Samsung one. At that point, Grub failed with a message stating that an "attempt to read outside of hd0" message. The message is actually not accurate, since the boot files are indeed inside the partition. It's just that the BIOS driver is not able to reach them.
This problem should happen more and more now that the price of 8TB disks is going down - and people start upgrading. And this is not really Ubuntu not setting the default, as far as I understand it, it's a pure all-GRUB (thus GNU / FSF) problem: The official GRUB documentation mentions that GRUB defaults to BIOS drivers. It would be nice if GRUB were upgraded to default to native drivers when it detects the boot partition crosses the 4TiB limit... Best! On Thu, Jun 2, 2022 at 11:40 PM Guilherme G. Piccoli < 1918...@bugs.launchpad.net> wrote: > @Filofel, thanks for your report! Very interesting. Is your machine a > Dell, running with HW RAID? > > My experience so far with GRUB and this LP bug is that there are two > things here: > > (a) Seems commit [0] might be missing in old Ubuntu releases (IIRC > Xenial, but *maybe* Bionic). This might cause issues with some disks 2T+ > ... > > (b) [And this is the main issue reported in this LP] Dell HW RAID > *legacy BIOS* driver has a bug and fails to inform properly some data to > Grub. In other words: imagine 5x1T disks composing a HW RAID of 5T. Grub > asks BIOS data (through nativedisk likely) and the legacy BIOS driver > from Dell returns data from disk 01 only - 1T of size. So, if GRUB > itself (some module, for example) or the kernel/initrd are present in > sectors *after* disk 01 size, it fails to load. > > For more reference on that, please check the following thread: > https://lists.gnu.org/archive/html/grub-devel/2021-03/msg00380.html > [According Dell, this is "expected" and UEFI is required!] > > > So, your case seems a little bit different. Maybe wirth to clarify the > exact model of your 4T disk, the version of Firmware (and of course the > machine model) and maybe collect some GRUB logs. > Interesting that you mentioned running with "--disk-module=ahci" make it > works - I wonder why this isn't set by defualt on Ubuntu, likely there is a > reason and I'm not aware. > > Cheers! > > > [0] https://git.savannah.gnu.org/cgit/grub.git/commit/?id=d1130afa5f > > -- > You received this bug notification because you are subscribed to the bug > report. > https://bugs.launchpad.net/bugs/1918948 > > Title: > Issue in Extended Disk Data retrieval (biosdisk: int 13h/service 48h) > > To manage notifications about this bug go to: > https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1918948/+subscriptions > > -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1918948 Title: Issue in Extended Disk Data retrieval (biosdisk: int 13h/service 48h) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1918948/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
