[GPT+SSD] Grub update renders system unbootable

I now understand what happened. The installer creates (by default) an EFI install, with grub-efi-amd64. The automatic update replaces grub-efi with grub-pc, and the latter doesn't work. I manually reinstalled grub-efi and everything works now.
But something is clearly wrong: an automatic update shouldn't be breaking a clean install. So, what went wrong here? Is it a bug in the installer? in grub? in apt? Should I have done anything differently during installation?

Good to hear you've got this sorted out but I wonder if your computer is really UEFI and not BIOS. Asking as some systems are really bios and 'faking' UEFI. Also if it is UEFI, is the SSD partitioned properly with GPT, ie flagged as bios_grub, /boot etc...

The motherboard is ASUS P8P67 -- don't know for sure if the UEFI is real or fake. The SSD is partitioned exactly the way that Natty installer partitioned it by default. It has EFI System Partition; I thought bios_grub was for BIOS. Here's the layout:

$ sudo parted /dev/sda print
Model: ATA Corsair CSSD-F12 (scsi)
Disk /dev/sda: 120GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number Start End Size File system Name Flags
 1 17.4kB 20.0MB 20.0MB fat16 boot
 2 20.0MB 111GB 111GB ext4
 3 111GB 120GB 8569MB linux-swap(v1)

If this isn't proper then the installer is to blame :)
I've also attached the complete output of boot_info-script.sh in the original bug.

Thanks for your reply Lev, a properly gpt partitioned device will have in the parted output one partition flagged as 'bios_grub' (the first partition) and another flagged as 'boot'. The first partition 'bios_grub' is 'like the mbr' of a msdos partitioned device and we do not 'touch' it, and the 'boot flagged' partition is where we put our bootloader, '/boot' in the case of linux. But I see you have your /boot in / which is sda2.

One more request Lev, can you print output of "sudo fdisk -l" as well?
Thanks.

IIRC fdisk doesn't understand GPT and gdisk needs to be used instead. Is this what you're looking for?

Disk /dev/sda: 120.0 GB, 120034123776 bytes
255 heads, 63 sectors/track, 14593 cylinders, total 234441648 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes

Partition Boot Start Sector End Sector # of Sectors Id System

/dev/sda1 1 234,441,647 234,441,647 ee GPT

GUID Partition Table detected.

Partition Start Sector End Sector # of Sectors System
/dev/sda1 34 39,096 39,063 EFI System partition
/dev/sda2 39,097 217,705,112 217,666,016 Data partition (Windows/Linux)
/dev/sda3 217,705,113 234,441,598 16,736,486 Swap partition (Linux)

"IIRC fdisk doesn't understand GPT and gdisk needs to be used instead. Is this what you're looking for?"
Yes. Exactly.
So the output is not from fdisk then.
Well, perhaps then the installer should create a /boot in another partition and flag it 'boot' as well. Then the install should proceed more smoothly.

Okay then, Lev, still good to know you've got it working.
Take care.

Thanks. Should I open a bug against the installer, then?

Thanks. Should I open a bug against the installer, then?
Yes, I'll think that'll be good.
Cheers.

@Lev Makhlis
Before reporting this against ubiquity in Ubuntu (or any other bug in Ubuntu), I highly recommend carefully reading https://help.ubuntu.com/community/ReportingBugs. Ideally, you would report this by performing the problematic installation and, at the end of the installation before quitting the installer, run ubuntu-bug with the PID of the running ubiquity process. (That will make sense after you read ReportingBugs.) Apport will then automatically attach a lot of useful information pertaining to your setup and to what the installer has done. To report the bug that way, you'd want to select Try Ubuntu rather than Install Ubuntu when you boot the installation media (so you have a functional desktop to find ubiquity's PID and to fill out the bug report in the web browser). After selecting Try Ubuntu you can start the installation process by double-clicking on the Install Ubuntu icon on the desktop.

After reporting the bug, I recommend linking it to this question using the "Link existing bug" link on this question page.

@Eliah Kagan
Thanks for the guidance. But this being my primary home computer, reinstalling it from scratch (again) is something I very much want to avoid if I can help it.

If you have any trouble upgrading (using the Update Manager) from Ubuntu 9.10 to Ubuntu 10.04 LTS (which does not require that you reinstall from scratch), please feel free to post a request for help with that. Usually, there are no problems.

Sorry, please ignore my previous post (numbered #11 at https://answers.launchpad.net/ubuntu/+source/grub2/+question/166162). I was confusing this question with a wholly different question. I will post a more appropriate response shortly.

You should be able to report the bug against ubiquity with "ubuntu-bug ubiquity" in the installed system (after carefully reading https://help.ubuntu.com/community/ReportingBugs if you haven't already done so)--that is probably the next best thing to do. It might attach your partman and syslog files automatically--otherwise, those files from installation are inside the /var/log/installer directory.

Lev,
I am having the same problem after auto update. When you say "I manually reinstalled grub-efi" can you give some basic outline of the steps? I booted a livecd, mounted the system and boot partitions, chroot, apt-get remove grub, apt-get install grub-efi-amd64. But it still isn't working for me. Any help would be appreciated!
Thank you,
Tim

Tim, did you run grub-install after reinstalling grub-efi? Did it give you any errors?

From memory, my steps were something like
$ sudo mount /dev/sda2 /mnt
$ sudo mount -o bind /proc /mnt/proc
$ sudo mount -o bind /dev /mnt/dev
$ sudo mount -o bind /sys /mnt/sys
$ sudo mount -t vfat /dev/sda1 /mnt/boot/efi
$ sudo chroot /mnt
# apt-get install grub-efi
# update-grub
# grub-install --recheck /dev/sda

Timothy, you installed "grub-efi-amd64", that is for intel-based Mac computers. You should install "grub-efi", that is valid for both i386 and amd64 computers.

Lev and Goh,

Thank you both so much for your help, it was a combination of things I was forgetting/didn't know--

1. I wasn't mounting the boot partition to /mnt/boot/efi, I was mounting it to /mnt/boot. Although I don't completely understand what the difference is since there was originally an /sdb1/efi folder on my sdb boot partition.

2. I was installing the wrong package, as Goh pointed out, should be grub-efi for non-mac computers.

3. After the grub install, I forgot to run grub-update and the recheck.

Aside from changing the device/partition information to match my system, Lev's steps worked perfectly. They should be added to the Ubuntu grub2 and the efi wiki to make everyone's life a little easier--
https://help.ubuntu.com/community/UEFIBooting
https://help.ubuntu.com/community/Grub2

Now that I've done this, recheck comes back with no errors found. There is still one abnormality that I am having (although my system is eventually booting correctly and everything is working), on booting and after the bios splash screen I am getting a series of messages (I assume from grub):

error: file not found.
error: file not found.
error: no suitable mode found.
error: no video mode activated.
error: file not found.
error: file not found.

Then I get a blinking cursor for about 10 seconds, a black screen for about 20 seconds, and then viola, my Ubuntu desktop appears (skipping the normal ubuntu splash screen with the flash white/red dots that I am accustomed to).

I think this probably has to do with the fact that I tried to install grub a whole bunch of times before you two pointed me in the right direction, so maybe its something leftover from a previous install? Really the system is now working fine, so it isn't a big problem-- but if you have a quick idea of something to check, I'd appreciate.

Thanks again for all your help, I would of spent another 10 hours trying to figure this out on my own.
Tim

Timothy, you're welcome, but it's mainly Lev who's doing the heavy lifting.
But instead of putting in the wiki, it is better that grub be installed automatically and without hassles.

So please go to the bug that Lev initiated
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/820723
add "affects me too" and perhaps add a comment with it.

Cheers

Those message look familiar, although I don't know a fix. At one point, I installed the PC/BIOS (not EFI) bootloader in the MBR of my second hard drive (sdb), which is an old-fashioned disk with an old-fashioned non-GUID partition table. I was then able to boot from the second drive, but with the same symptoms you're describing. I have no such problems with EFI boot, but since you mention that your EFI system partition is on sdb, perhaps it's related.

@Goh: grub-efi is a wrapper for both grub-efi-amd64 and grub-efi-ia32. The reference to Mac is only an example, as there were the most current PC to use EFI, which is less and less true.

@Lev: I have no good solution. A workaround should be, after a kernel delivery:
1-boot from Live CD (or USB stick)
2-sudo apt-get install grub-efi # to get the efi version in RAM disk of live session
3-reinstall grub from CD (https://help.ubuntu.com/community/Grub2#Copy%20LiveCD%20Files)
4-reboot from computer
So you will avoid to reinstall whole system.

I'm one of main answerer about Grub issue on this forum, and decided this week to start managing GPT issues, even if I have not such a PC, as I see more and more question about this. So I will follow this question until its end. Before I avoided such subject.

Please tell me if previous procedure works. If yes, I will write a FAQ.
N.B. : I will be back Monday.

@delance: Isn't it better to install grub-efi in the system on disk (as I did)? Seems to me like that won't have to be repeated after each kernel delivery.

@delance:
[1] Mac uses EFI, newer pc's uses UEFI
[2] I used --boot-directory method from live cd, but I purged grub-pc before installing grub-efi
      yes it works; but I see nothing wrong with Lev's method. There are many ways to skin a cat.

Lev, I don't usually debate individual preferences, as long as the job gets done. But it is useful to know alternative methods. Like you, I'd like to go direct to the OS and sort things out rather than chroot to the partition. It's safer, for one thing and more direct. However in this case, using --boot-directory, there is no chrooting and it is absolutely safer too and in my opinion direct as well.

But, as I said, I think it's very fine about your method, and that's why I did not dispute your method in the first place. And most of all, you've got it working! Cheers!

@Goh Lip.
[1] Some PC use GPT partition table without using UEFI, and some PC, like some Dell PowerEdge use UEFI firmware. As I face more and more questions about those configuration, I get more and more conscious of rising usage of both UEFI and GPT. You could have a look at Wikipedia, which explains this.
You'll have to learn to be less susceptible and more open to others. I accept easily that such people as Collin Watson or Eliah Kagan detect my wrong assumptions, and explain me in what I'm wrong, so I'm able to progress.

@Lev
What I propose is to install grub-efi packet temporarily on RAM disk. And from this Live Session, to install grub-efi MBR (on first 32 sectors of hard disk) and other boot files (on /boot of hard disk).
After, you could install grub-efi on your hard-disk to configure it.
The presence of MBR and boot files is independent from the presence of grub packet, even if you need to have during boot configuration grub packet installed somewhere.
As I have no GPT computer (I planned later to use UEFI boot from Virtual Box), I can't check proposed solution, so I'm extremely interested by your experience with it.

@delance, I am not disputing you, least of all debating you here. So I hope you get less defensive.

In fact I thought I was telling you that the method of "grub-install --boot-directory" works which I thought you wanted to know.

If you are not willing to learn from people less capable than Colin or Eliah, or indeed less capable than yourself, I think you are in the wrong place here.

@delance: So, install grub-efi in Live Session, use it to repair bootloader, boot from hard disk and then install grub-efi there as well. I assume this would work, but testing it would require me to do a clean install first, which I don't want to do (as I mentioned above, this is my primary home computer, and it's working now).

As a side point, if I were installing the OS again now that I know about the problem, I would just install grub-efi after the auto update, before rebooting.

-rw-r--r-- 1 root root 13180812 2011-07-14 08:00 initrd.img-2.6.38-10-generic
Previous kernel was delivered in July, so I presume next one will be delivered on September (not sure).
What you can do is print this procedure and wait next kernel delivery to apply it.
It means that you must have a Ubuntu CD ready to do it.
I asked some help to Andrew (actionparsnip) to a way to block packet upgrade, as he is more competent than me in packet management.
I understand you doesn't want to check on a healthy configuration.
I can only recommend you to check, when update-manager show, to check in a new kernel is delivered, or if a boot is required after an update.

http://www.asus.com/Motherboards/Intel_Socket_1155/P8P67/
UEFI BIOS (EZ Mode) - Flexible & Easy BIOS Interface
Your motherboard has a true UEFI BIOS. It's becoming usual when a motherboard has SandyBridge chip.

@Goh well said. i hope this is a language/translation problem and delance isn't really as abrasive as he comes off in english.

Timothy, thank you for your kind thoughts.
English is not my native tongue either. :)
Cheers.