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
