[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