[Bug 1284196] Re: Install to 3TB disk fails with "attempt to read or write outside of disk" error on reboot
Filofel
1284196 at bugs.launchpad.net
Mon Apr 25 13:21:03 UTC 2022
I ran into the same bug too, booting 20.04.4 from a 4TiB partition partition on a 4TiB disk.
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. When using native grub drivers (ahci in my case), everything works.
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
Foundations Bugs, which is subscribed to ubiquity in Ubuntu.
https://bugs.launchpad.net/bugs/1284196
Title:
Install to 3TB disk fails with "attempt to read or write outside of
disk" error on reboot
Status in ubiquity package in Ubuntu:
Won't Fix
Bug description:
I performed a test installation of Trusty server to a VirtualBox
installation with a 3TiB virtual disk. I chose default options for the
most part, although I opted for a non-LVM partition layout. Ubiquity
seemed to successfully install Ubuntu, but on reboot, I got the
following GRUB error:
Error: attempt to read or write outside of disk `hd0'.
Entering rescue mode...
grub rescue>
It appears that Ubiquity set up a single giant root (/) partition; as
shown by gdisk:
Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 6442450944 sectors, 3.0 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): 042174C8-0513-49FC-A04B-579D7A01D723
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 6442450910
Partitions will be aligned on 2048-sector boundaries
Total free space is 4029 sectors (2.0 MiB)
Number Start (sector) End (sector) Size Code Name
1 2048 4095 1024.0 KiB EF02
2 4096 6440355839 3.0 TiB 8300
3 6440355840 6442448895 1022.0 MiB 8200
My suspicion is that the kernel ended up above the 2TiB mark and so
became unloadable to GRUB, either because of a limitation of GRUB or
of the BIOS used by VirtualBox. Re-running the installation with
manual partitioning and a separate /boot partition at the start of the
disk resulted in a working installation.
This issue could result in failures of automated installations and
certification testing, should the target system have an over-2TiB
disk. My recommendation is that ubiquity default to creating a
separate /boot partition at the start of the disk when doing a BIOS-
mode installation on an over-2TiB disk.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1284196/+subscriptions
More information about the foundations-bugs
mailing list