Install with large hard drive fails grub install

[Edward Sargisson]

Binary package hint: ubiquity

I have just installed Ubuntu 8.04 Hardy Heron on a 320GB external USB hard drive. I do not believe that this problem is because of the fact of the hard drive being USB or external.

EXPLANATION AND HISTORY

I used the manual partitioner because I wanted to have as big a partition as possible as the first partition and set as fat so that the partition would be easily viewable from Windows without twiddling.

The first time through I created a 5GB root partition for everything as the last partition on the drive. The new install failed to boot with the BIOS claiming Operating System not found. Trying to get grub to install manually failed. Grub couldn't find the partition.

Some research uncovered the 1024 cylinder limit. I then reinstalled by setting a 50MB /boot partition just below the 1024th cylinder and a / partition higher.

DEFECT

The first boot failed with Operating System not found. Booting from the install CD and attempting grub-install also failed. However, I could manually run grub and install onto the /boot partition.

MODIFICATIONS REQUESTED
1. The installer should identify that a /boot partition above the 1024th cylinder will fail. Either a warning message should display or this configuration should be denied depending on common that 1024 cylinder limit is.
2. The installer or grub-install should still manage to successfully install without manual intervention.

WORKAROUND
1. Create a /boot partition of at least 50MB and ensure all of it is below the 1024th cylinder. You will need to use fdisk manually to work out exactly where to put this. You can partition the rest as you like.
2. Expect the first boot to fail.
3. Boot from the install CD.
4. Open a terminal window and start grub.
5. Follow a guide, such as http://www.linuxquestions.org/linux/answers/Applications_GUI_Multimedia/Set_up_Grub_by_hand, to identify what grub calls your boot partition and then setup grub on it.

[Colin Watson (cjwatson)]

The 1024-cylinder restriction is very old; I understand that BIOSes since about 1997 have generally been supplied with the necessary extensions to avoid it as standard. How old is your BIOS? I'm reluctant to make the default behaviour of the Ubuntu installer be to create a /boot partition to work around this limit, since the PC partition table format is such that creating as few partitions as possible often makes life very much simpler, and this only affects systems that are now very old. Even a warning message would be extremely confusing noise for most people. Now, if somebody presented me with a way to detect such systems, that would be a different matter.

Could you supply the output of 'sudo dmidecode' on your system?

The secondary problem you had appears to be separate, and I suspect may in fact be due to using an external drive even though the 1024-cylinder limit problem probably isn't. Could you please attach the following files to this bug:

  /boot/grub/device.map
  /boot/grub/menu.lst
  /var/log/installer/syslog
  /var/log/installer/partman

You may need to use root privileges to read some of these files, particularly /var/log/installer/syslog.

[Edward Sargisson (esarge)]

Hi,
I'll accept your comment about the 1024 cylinder limit and older BIOSes. However, putting boot below that limit did work. This is an IBM ThinkPad T43 for reference.

As for how to detect it. The symptoms were that grub gave error messages when using root. Only rootnoverify allowed me to continue - though not very far. Therefore, perhaps a detection method would be to see if grub can read /boot before continuing.

Files attached as requested.

[Colin Watson (cjwatson)]

Thanks - I'll try to have a look through these soon.

[Phillip Susi (psusi)]

I can't believe that there's a modern system that still has the 1024 cylinder limit as that would mean that any Windows install would randomly die when a boot file moved above that point. I'm thinking that this problem was actually due to the fact that the partition started beyond 219 GB and grub had been using HDIO_GETGEO, which can't report a start larger than that. Bug #1237519 fixed this, so I think it may have fixed your issue as well. Can you see whether this is still a problem in the Trusty nightly? I'll see if I can reproduce it in a VM.

[Launchpad Janitor (janitor)]

[Expired for grub2 (Ubuntu) because there has been no activity for 60 days.]