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
@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
--
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:
I ran into the same bug too, booting 20.04.4 from a 4TiB partition partition on
a 4TiB disk.
No RAID or LVM, plain 4TB ext4 partition.
I have grub 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
Could narrow the problem down to both a Grub issue, but more relevant -
to a Dell BIOS issue as well. So, 2 bugs!
Regarding GRUB, the disk information is read through the int 13h/service
48h from BIOS[0]. But testing in an HP machine (with HW RAID as well),
and comparing that with what we call
After checking the fibmap files from the user, could verify that the
LBAs for the non-working files are very large compared to the ones that
are working - it's a data point reinforcing the theory that GRUB is
miscalculating something for files after some LBA offset.
Managed to reproduced the
