>2TB/GPT: Must warn if BIOS boot partition is missing (unbootable system!)

This is happening with lucid 64bit server as well. should I create a new bug report for this (as lucid is LTS I reckon it is quite important RAID 1 installs should be possible), or just leave it as this?

Extra information: My install fails with two hard disks that are just 10Gigs each. Shouldn't this bug be marked as critical, or maybe I am missing something? Raid seems quite important for server installs imo.

I think the problem described here only happens for disks larger than 2TB - please create a new report for your problem.

The problem happens as a result of the drives being GPT which usually means >=2TB. GRUB cannot yet handle GPT boot.
It is more than a documentation bug, we need GRUB updated to provide a way to boot off RAID GPT drives as there will be more and more GPT drives as time goes on. Folks will continue to want to boot off these in RAID config.
Here's the scoop on GPT well described by IBM:
http://www.ibm.com/developerworks/linux/library/l-gpt/

So we need for the GRUB folks to come up with a solution. I'm guessing that they are thinking hard about this right now figuring out what will be the next generation.

Meanwhile a workaround for folks to use while waiting for GRUB to catch up is to do a manual mirror of the boot partition. One way is /boot on one drive and /mnt/boot on the other with both drives marked bootable. Keep them mirrored with a script to copy /boot to /mnt/boot wenever /boot is updated.

GRUB1 does not support GPT, but GRUB2 does - Karmic uses GRUB2, it just needs this BIOS boot partiton ( http://grub.enbug.org/BIOS_Boot_Partition ).

That is not my experience, but let's qualify that. Ubuntu grub 0.97 _does_
support GPT with RAID1, except for the boot partition which must, as
stated previously in the workaround, be on a non-RAID partition for the
reasons you stated. Currently as far as I can tell GRUB2 does no better.

I'm also not entirely sure that the desktop update for GRUB made it into the
server version. Last time I installed 9.10 server it used GRUB 0.97 by
default but worked with RAID1 just fine except for the boot. But maybe it
defaulted back to 0.97 as RAID1 was used.

# grub --version
grub (GNU GRUB 0.97)
# cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid -o value -s UUID' to print the universally unique identifier
# for a device; this may be used with UUID= as a more robust way to name
# devices that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
# / was on /dev/md0 during installation
UUID=43dd4718-11b9-4ab0-a584-69c3775d8f6a / xfs
defaults 0 1
# /boot was on /dev/sda1 during installation
UUID=dc4133c1-bac6-43e0-952d-190e10aebb40 /boot ext3
defaults 0 2
# /mnt/boot was on /dev/sdb1 during installation
UUID=bbe887cd-da41-4770-a2c0-f9d0f0d7bf90 /mnt/boot ext3
defaults 0 2
# /shares was on /dev/md2 during installation
UUID=4527056e-d0cf-4b2f-90ad-4d0f182545fc /shares xfs
defaults 0 2
# swap was on /dev/md1 during installation
UUID=1153890f-d1d9-44f6-8605-7efdf0d388df none swap
sw 0 0
/dev/scd0 /media/cdrom0 udf,iso9660 user,noauto,exec,utf8 0 0

Quote Colin Wilson
https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/436340/comments/23
"The solution in Ubuntu 9.10 is: *don't install grub2*. Continue to use
GRUB Legacy if you're using SATA RAID devices, since it's the only
version that will work in 9.10."

 Agreed then..., it _isn't_ a doc bug, GRUB2 needs updating.
Rather than
"How do I create a BIOS Boot Partition that will be suitable for GRUB?"
better question is:
"When will the installer create a BIOS Boot Partition that will be suitable
for GRUB?"

Thanks.
On Sun, Feb 21, 2010 at 3:34 PM, Jakob Unterwurzacher <email address hidden>wrote:

> GRUB1 does not support GPT, but GRUB2 does - Karmic uses GRUB2, it just
> needs this BIOS boot partiton (
> http://grub.enbug.org/BIOS_Boot_Partition ).
>
> --
> >2TB/GPT: Must warn if BIOS boot partition is missing (unbootable system!)
> https://bugs.launchpad.net/bugs/506670
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in “partman-base” package in Ubuntu: New
>
> Bug description:
> Binary package hint: partman-base
>
> (Ubuntu karmic, alternate install CD)
>
> If you manually partition a large disk (2TB or more), a GUID partition
> table (GPT) will automatically (and silently) be used.
> This means that you *have to* create a BIOS boot partition (
> http://grub.enbug.org/BIOS_Boot_Partition ), or the grub setup will fail
> and the system will be unb...

I apologize, I was mistaken, karmic 64-bit server uses GRUB2 (1.97) by default as you said.
That GRUB 0.97 found and shown above must be a vestige from my attempts to get the system to boot from RAID1.

However I would still like for the install software to have some way to boot from RAID1, a warning is not enough as folks installing server with large disks will expect the installer to be able to boot from RAID1 on large disks (>=2TB)
Thanks.

Agree with Huuanito comment above.

I expect to be able to install Ubuntu and mirror boot with RAID1 on my brand new 2TB drives. A few weeks ago I did testing of all the major linux distributions, the installers failed for a variety of different reasons.

The only Linux distro I found that included an installer that would actually work to mirror boot on 2TB drives was Sabayon Linux (based on Gentoo) with its latest installer. I believe Sabayon actually uses the Fedora installer so possibly cutting edge there has a solution.

This problem bit me tonight, trying to install 10.04.1 64bit onto a RAID0 array of size 3GB.

I managed to get the problem resolved though it was a bit of a pain. Had to burn a desktop livecd and then apt-get several things (mdadm, gdisk & friends) into the running system in order to create a BIOS_Boot_Partition. Fortunately there was some space left over where I could put this partition. It would be very helpful if parted (& if possible gdisk) is included in the alternate CD as you're pretty stuck in terms of having a powerful partition table editor to hand if you've got a gpt partition table and are trying to install from alternate cd...

I managed to fix this with the Ubuntu 10.10 Alternative (noted the same on Server CD) disk. Creating a 1mb partition at the beginning of both my 2TB drives and setting it to 'reserved bios partition' was what I needed.

Ubuntu creates this partition for you auto-magically when you use the guided partitioning tool. However I agree with Jacob: this really needs to come up with a warning if you've manually specified partitions, but failed to create these GPT / Grub / Reserved Bios partitions.

Still a problem on Natty install CD... and it just hit me. Thank god for launchpad to show me what I did wrong. I had no idea that with a larger drive I had to manually add a BIOS whatever partition.

Actuallly, I'm not sure that this was my problem. It appears that my problem might be related to my motherboard and it's inability to boot a disk installed with GPT (may be the 2TB thing, maybe not) (also, event though it's and intel board... didn't intel invent GPT)? Anyway, I actually got it to work by an ugly hack: I installed grub on a USB stick.

I suspect that if I were to repartition the drive using msdos partition table it would work. I may or may not try in the future.

The same problem in Ubuntu Server 11.04 !
please PLEASE fix this problem in installer, I think you will save so many people from nerve crisis !!!!
P L E A S E !

Unbelievable that this bug is still present in 11.10.
I had to redo the whole installation because of this, as attempting to go back to the partitioning step to add the missing partition makes all later steps fail irrecoverably because of the installer forgetting that partitioning was already performed.

Another Upvote for a fix PLEASE!!

Just spent two hours getting a system installed only to find that I had to start all over again.

A simple warning during the partitioning stage would be a great help!

I don't think you need to start all over again. You can just create the partition in gparted and retry. The error messages are not friendly though.

"Executing 'grub-install /dev/sda' failed.

This is a fatal error."

This should tell you why it failed, and give the actual error message. I had to discover that I needed to do a "chroot /target" before manually running grub-install or it would give an unrelated error.

Also, regarding "The debug log file from your installation would help us a lot but includes the password you used for your user when installing Ubuntu. " Why doesn't it just remove the password before uploading?

Still a problem with 14.04 (Trusty Tahr).
May be related to:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606408
Bug #417724
Bug #855871

lucid has seen the end of its life and is no longer receiving any updates. Marking the lucid task for this ticket as "Won't Fix".