PDA

View Full Version : [SOLVED] 10.10 won't boot after new partitions added



pete_l
January 24th, 2011, 10:41 PM
I recently bought a new 2TB disk and installed 10.10 i386 on it. I used the installation CD and manually created a single 400GB partition for Ubuntu. I successfully installed 10.10 onto this - including many reboots to get upgrades installed.
Once I had the config sorted out - about 2 days effort, I added a couple more partitions which used up all the unallocated space. These I filled with data of smaller disks that I consolidated onto the one, biggie.
After finishing the data migration I now find that 10.10 won't boot. The boot process hangs just at the point it tries to load Grub. Investigations show that the boot sectors no longer contain anything bootable.

I have *not* installed any other operating systems. It's just one instance of Ubuntu 10.10

Using the installation CD, I now find I am unable to reinstall Grub, getting errors of the form:

grub-setup: warn: This GPT partition label has no BIOS Boot Partition; embedding won't be possible

I have checked out the disk in another box. It has no hardware faults and the EXT4 filesystems I have created are all in good shape - fsck reports no errors.

Further investigation makes it seem like this is a manifestation of a known bug [link]506670 2TB/GPT: Must warn if BIOS boot partition is missing (https://bugs.launchpad.net/ubuntu/+source/partman-base/+bug/506670) which has been known about for a year or so - but is still being shipped in the latest Ubuntu release.

So far, all the advice I've seen has been along the lines of "Uh, yeah we know about that, you've got to create a small partition for Grub - I guess we really should get round to telling people - sorry!" Which is fine if you haven't already allocated all the free space on your disk.

So, my question is, apart from destroying the root partition and writing off 3 evenings worth of effort in getting this thing installed and set up, what other ways are there to get make this disk bootable - or have I just wasted my time?

All suggestions gratefully considered.

wilee-nilee
January 24th, 2011, 11:20 PM
The best thing you can do at this point I think is to post the bootscript in my signature, this will give more exacting information.

So from a booted live Ubuntu cd or thumbdrive lets see the bootscript read out; in my signature just click on it and follow the instructions. Come back to the thread and click on the (#) in the reply panel this makes code tags paste all the text in between.

drs305
January 24th, 2011, 11:27 PM
GPT requires a separate /boot partition, if that is what you are using to define your partitions. You also need one if your BIOS can't see the entire size of your Ubuntu partition (check in BIOS).

If you need to create a /boot partition, you haven't wasted the past three days. You can use Gparted to shrink your Ubuntu a bit, move it to the right, and then create a small /boot partition at the start of the disk.

I'm not a fan of moving partitions to the right (moving all the data) - it can take a really long time and to me offers more risk of data loss (although that hasn't happened to me). But it is a way to work things out if you do need a /boot partition.

You could also install Grub2 on a flash drive and keep that inserted when you boot, although I would find that inconvenient...

pete_l
January 24th, 2011, 11:29 PM
The best thing you can do at this point I think is to post the bootscript in my signature, this will give more exacting information.

So from a booted live Ubuntu cd or thumbdrive lets see the bootscript read out; in my signature just click on it and follow the instructions. Come back to the thread and click on the (#) in the reply panel this makes code tags paste all the text in between.
That script was my starting point and how I reached the conclusion that the boot blocks had been destroyed..
The salient parts (I'm not going to post it all, most of the content is not relevant) were:

Boot Info Script 0.55 dated February 15th, 2010

=============== Boot Info Summary: ====================
=> Grub 2 is installed in the MBR of /dev/sda and looks on the same drive in
partition #1 for /boot/grub.
=> No boot loader is installed in the MBR of /dev/sdb

This was the result of installing the 2TB disk in a Ubuntu 9.10 box and running the script from there. Just to be clear, sda was the 9.10 disk and sdb was the one that got it's boot blocks wiped.

pete_l
January 24th, 2011, 11:35 PM
GPT requires a separate /boot partition, if that is what you are using to define your partitions. You also need one if your BIOS can't see the entire size of your Ubuntu partition (check in BIOS).

If you need to create a /boot partition, you haven't wasted the past three days. You can use Gparted to shrink your Ubuntu a bit, move it to the right, and then create a small /boot partition at the start of the disk.

I'm not a fan of moving partitions to the right (moving all the data) - it can take a really long time and to me offers more risk of data loss (although that hasn't happened to me). But it is a way to work things out if you do need a /boot partition.

You could also install Grub2 on a flash drive and keep that inserted when you boot, although I would find that inconvenient...<shudder>Yes, I'm not a fan of resizing partitions, either, but it seems that that there are not many other options. The alternative seems to be a highly risky/experimental/speculative approach with blocklists, but this install has already O-D'd on, errr ... unorthodox practices.

srs5694
January 25th, 2011, 03:34 AM
GPT requires a separate /boot partition, if that is what you are using to define your partitions.

This is incorrect. The BIOS Boot Partition (GPT code 21686148-6449-6E6F-744E-656564454649) is a specialized partition that can be as small as about 32 KiB (yes, K). It's used without a filesystem to hold part of GRUB that, on an MBR disk, would normally be installed to the unallocated sectors immediately following the MBR. A BIOS Boot Partition is recommended, but usually not required, for use of GRUB 2 on a GPT disk with a BIOS-based computer. If it's omitted, the installation is likely to fail if certain key files that GRUB needs to access are moved or upgraded.

The /boot partition is an optional partition that holds a normal Linux filesystem and that's mounted in Linux at the /boot directory. It was common practice a decade or so ago to create this partition and place it early on the disk to work around BIOS limitations. Modern BIOSes are not so limited, but today it's sometimes created to work around GRUB Legacy limitations in reading RAID and LVM configurations. On most installations, including most installations on GPT disks with normal partitions (no RAID or LVM), it's not required.

Thus, the BIOS Boot Partition and the Linux /boot partition are entirely different concepts.

As to the original problem, I suggest this:

First, download and install GPT fdisk (gdisk) from its Sourceforge download page. (http://www.rodsbooks.com/gdisk/) (Don't install it from Ubuntu's repositories; the version available that way is hopelessly out of date.) Installing to your emergency session in live CD mode should work fine. Launch the program on your disk and use the "v" option to verify disk integrity. This has the side effect of displaying the free space on the disk, like this:



$ sudo gdisk /dev/sda
Password:
GPT fdisk (gdisk) version 0.6.14

Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): v
No problems found. 4670 free sectors (2.3 MiB) available in 1
segments, the largest of which is 4670 (2.3 MiB) in size.


This example shows 2.3 MiB of available space. There's a good chance you've got such a gap. If you do, you can easily create a BIOS Boot Partition in gdisk:



Command (? for help): n
Partition number (6-128, default 6):
First sector (976768465-976773134, default = 976768465) or {+-}size{KMGTP}:
Last sector (976768465-976773134, default = 976773134) or {+-}size{KMGTP}: +1M
Current type is 'Linux/Windows data'
Hex code or GUID (L to show codes, Enter = 0700): ef02
Changed type of partition to 'BIOS boot partition'

Command (? for help): w


In this example, I selected the defaults for most values, but I specified a size of 1 MiB (just to leave a bit in case some other dinky partition is needed in the future) and set the type code to EF02 (the code gdisk uses for a BIOS Boot Partition). If you've got less than 1 MiB of free space, either fill it all up or set some smaller size, but not smaller than 32 KiB -- in fact, try to make it at least 100 KiB, just in case future GRUBs need a bigger BIOS Boot Partition. Don't worry about the start sector, which will almost certainly not be the same as in this example; that shouldn't matter unless you've got an ancient BIOS that's limited to reading a small part of your disk. The "w" option saves your changes to the disk. (You can use "p" to view your partition table first, if you like.)

If you really have no free space available on the disk, then I recommend either resizing or deleting your swap partition and then re-creating it just a little bit smaller. The 1 MiB or so you lose in the swap space shouldn't matter unless you made it exactly the minimum required for your needs. Be careful, though; if you delete it and then re-create it with gdisk, the data structures will remain behind, so it might look like it's still valid, but it won't be. Be sure to use mkswap to create fresh swap data structures, or do this job with GParted. You may also need to adjust the UUID value for your swap space in /etc/fstab.

Once you've got your BIOS Boot Partition in place, use Super GRUB 2 Disk (http://www.supergrubdisk.org/) to reboot Ubuntu and type "sudo grub-install /dev/sda" to re-install GRUB, this time using the BIOS Boot Partition. Alternatively, I believe there's a way to re-install GRUB from the Ubuntu live CD, but I don't recall the exact command offhand.

drs305
January 25th, 2011, 04:07 AM
This is incorrect. The BIOS Boot Partition (GPT code 21686148-6449-6E6F-744E-656564454649) is a specialized partition that can be as small as about 32 KiB (yes, K). It's used without a filesystem to hold part of GRUB that, on an MBR disk, would normally be installed to the unallocated sectors immediately following the MBR. A BIOS Boot Partition is recommended, but usually not required, for use of GRUB 2 on a GPT disk with a BIOS-based computer. If it's omitted, the installation is likely to fail if certain key files that GRUB needs to access are moved or upgraded.


Thanks for correcting this. I should have said that Grub2 prefers to have a boot partition with GPT for the reasons you stated.

pete_l
January 25th, 2011, 06:06 PM
Guys, thanks for your clear and timely assistance. Best of all it worked :p
Briefly, I followed DRS305's advice and slid a small, 30MB partition in at the start of the disk, after booting the Ubuntu 10.10 installation CD. As an FYI resizing that 400GB partition took 5½ hours - running while I slept. It turns out that there may already have been some unallocated space between the MBR and the start of partition #1 but since it was dead time, the extra step cost nothing. With some space freed up I tooksrs5694's suggestions and pulled down a working gdisk (v0.6.14) and duly created a BIOS Boot partition - then REBOOTED.

Restarting with the Ubuntu 10.01 CD, I noticed that the version of gparted (v2.3) on the CD now crashed every time it was run - I guess things have changed in the few months since 10.10 escaped. However, that application wasn't needed. Using apt-get to install it on the working disk apparently pulled down a version that works.

I mounted the disk as /a and chroot'd to it. After that it was a simple case of running grub-install and verifying with the bootinfoscript that something had, indeed, happened. Bootinfoscript reported:

Grub 2 installed in MBR of /dev/sda
but went on to say:

... looks at sector 40 of the same gard drive for core.img,
but core.img can not be found at this location

So, using the tried and trusted technique of ignoring messages I don't understand, I shut the box down and rebooted off the hard disk.
\\:D/ It booted
I got a GRUB menu with a bunch of Linux kernels to choose from, the boot process went according to expectations and the box came up - resized root partition and all.

I'm now torn between customising the GRUB menu to auto-boot and leaving it exactly as it is, in case I break something even more obscure.

srs5694
January 25th, 2011, 06:35 PM
I'm glad you got it working; however, I want to point something out for future reference....


Briefly, I followed DRS305's advice and slid a small, 30MB partition in at the start of the disk, after booting the Ubuntu 10.10 installation CD. As an FYI resizing that 400GB partition took 5½ hours - running while I slept. It turns out that there may already have been some unallocated space between the MBR and the start of partition #1 but since it was dead time, the extra step cost nothing.

In fact, resizing the partition unnecessarily was a risk. Particularly when changing the start point of a partition, as I suspect you did, sensitive data structures must be moved around. That's why in my own post I recommended taking the tiny amount required for the BIOS Boot Partition from swap space -- if the swap partition becomes corrupted, it's not a big deal (you just create a new one). Unless it's just a test partition with no important data, you should not resize a partition unnecessarily. Doing so is asking for trouble. You've escaped unscathed this time, but I want to point out, for your benefit and those of anybody else who might be reading, that partition resizing should not be done casually.

neotipper
February 7th, 2011, 05:30 AM
@ srs5694

You are AWESOME! I've been scouring for the past couple hours trying to fix my grub problem. This worked perfectly. Thanks!