@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:
[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.


[0] https://git.savannah.gnu.org/cgit/grub.git/commit/?id=d1130afa5f

You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.

  Issue in Extended Disk Data retrieval (biosdisk: int 13h/service 48h)

To manage notifications about this bug go to:

ubuntu-bugs mailing list

Reply via email to