[Bug 1918948] Re: Issue in Extended Disk Data retrieval (biosdisk: int 13h/service 48h)
I guess GRUB could be changed to not truncate LBAs to 32-bit when using int 13h EDD services *on GPT* disks. Booting from >4TiB 512B sector disks on legacy BIOS with GPT isn't exactly a use case worth spending time on in the year 2024 in my opinion, but I am open to reviewing patches. ** Changed in: grub2 (Ubuntu) Status: Confirmed => Won't Fix -- 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
Re: [Bug 1918948] Re: Issue in Extended Disk Data retrieval (biosdisk: int 13h/service 48h)
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
[Bug 1918948] Re: Issue in Extended Disk Data retrieval (biosdisk: int 13h/service 48h)
@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 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
[Bug 1918948] Re: Issue in Extended Disk Data retrieval (biosdisk: int 13h/service 48h)
-- 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
[Bug 1918948] Re: Issue in Extended Disk Data retrieval (biosdisk: int 13h/service 48h)
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 target partition. This is tersely documented in the Grub 2.06 documentation, in the "nativedisk" command paragraph. When using native grub drivers (ahci in my case), everything works. Ditto after running the nativedisk command from the Grub rescue console. 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... -- 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
[Bug 1918948] Re: Issue in Extended Disk Data retrieval (biosdisk: int 13h/service 48h)
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 the EDD kernel module[1] output (the early boot kernel code that runs in realmode and performs the exact same query as GRUB), it seems GRUB is only filling the lower 32 bits of the total_sectors variable. This is indeed a bug, and I've reported that to GRUB community [2]. But notice I've mentioned an HP machine...because the Dell machine has an even worse bug. In the case of Dell, the BIOS reading both from kernel EDD module and GRUB as well is 0x - this value is the full 32-bit mask filled, which would correspond to a disk of 2TB. In my case, the HW RAID5 exposes a disk of 8TB! So, regardless if GRUB is only filling the lower 32 bits, the value from Dell BIOS is wrong. I've sought Dell support through some Dell contacts I've found in kernel commits [3]; they promptly responded, forwarding internally my issue report to their firmware team, but since then they are quiet - hope they can clarify us on the reason of this bogus return value from their BIOS. GRUB community is also quiet regarding my bug report in their code. [0] https://en.wikipedia.org/wiki/INT_13H#INT_13h_AH=48h:_Extended_Read_Drive_Parameters"; [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/boot/edd.c [2] https://lists.gnu.org/archive/html/grub-devel/2021-01/msg00052.html [3] https://lists.gnu.org/archive/html/grub-devel/2021-01/msg00050.html -- 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
[Bug 1918948] Re: Issue in Extended Disk Data retrieval (biosdisk: int 13h/service 48h)
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 issue in-house using a Dell machine with such HW RAID5 setup. The idea to reproduce is basically have a legacy-BIOS booting mode, and duplicate the vmlinuz/initrd pair until it almost fills the HDD - then, use fibmap to determine the ones living in the largest LBAs, and keep them, a few of them should be enough. Keep a valid vmlinuz/initrd and grub config files/modules in a first small "/boot" partition so the machine can always boot, and duplicate the kernel files in a huge "/" partition after "/boot" in the disk. -- 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
