Ubuntu – Completely messed up grub/efi/gpt dual boot

dual-bootgptgrub2uefi

I seem to have almost entirely screwed up my machine. I was attempting to install an ubuntu liveusb to my external hdd, but in the process I messed up my internal setup. The external one works 😉

It's a dual boot system, and it originally came with win8 plus a whole bunch of Lenovo/windows recovery partitions. It has a 24gb SSD hybrid as well. I had secureboot disabled before, and installed ubuntu 13.04, and recently upgraded to 14.04. It was working fine until my little misadventure. All of my boot flags seem to be constantly changing now, too. I'm not entirely sure why.


Output from boot-repair (which wouldn't allow me to choose /dev/sda2 or /dev/sda11, only sda8 (which is my home partition?). I tried it anyway. It said it succeeded, but didn't do anything obviously.

http://paste.ubuntu.com/7303953/


My (many) partitions are as follows:

/dev/sda1 — WINRE_DRV (1000mb ntfs, flags: hidden, diag)

/dev/sda2— this was my original EFI partition I think (was originally labelled as SYSTEM_DRV and was formatted as fat32, but now it's an unrecognized filesystem).

/dev/sda3 — unknown, msftres ??

/dev/sda4 — Windows8 OS (68GB ntfs, flags: msftdata)

/dev/sda11 — I created this as fat32 with the 'boot' flag, in the hopes of creating another efi partition and moving it over, but it doesn't seem to be recognized by boot-repair.

/dev/sda5 (350mb, ntfs flags:hidden, diag) — No idea what this is.

/dev/sda6 (20GB ext4, flags: hidden?) — my system partition for ubuntu. Not sure why it now has a 'hidden' flag.

/dev/sda7 — 4GB swap

/dev/sda8 — my home partition for ubuntu (75gb ext3, flags: msftdata)

/dev/sda10 — 290GB ntfs shared data partition (flags: msftdata)

/dev/sda9 — Lenovo recovery (10GB ntfs, flags: hidden, diag)


Something is seriously screwed up here. I'd really rather prefer to not reformat. I've read most of the articles regarding UEFI and GPT, etc, but I can't seem to fix my problem, and actually just seem to be making it worse.

It's also possible that the livecd grub isn't using the right files? It tries to install with i386-pc, when I thought i should be using something like x86_64-efi-signed or something.

Could someone please help walk me through this?


Edit:

Ok, so I downloaded and installed rEFInd to windows and made a bootable USB with that, which allowed me to boot into my actual Linux OS and not a LiveCD. From there I was able to use boot-repair properly to install grub (to /dev/sda11) and to boot /dev/sda6.

The problem with boot-repair before was that it didn't detect my EFI partition so it was trying to install non-efi to my /dev/sda6 (likely because I was doing it from a livecd). It seems to be an issue with the grub which comes with ubuntu14.04 though, that it doesn't have EFI support or something?

Anyway, now I have EFI on /dev/sda11, but I have two unknown partitions (sda2 and sda3). What was sda3 in the first place? And what can I do with sda2 and the files on it (like for Lenovo recovery stuff)? Can I just delete those partitions, or will that cause more issues?

Finally, is it just a matter of running windows recovery now? I imagine that will break my ubuntu and grub again.

Thanks!

Best Answer

First, you're missing an EFI System Partition (ESP), which is used to hold EFI boot loaders. Most computers that ship with Windows 8 use /dev/sda2 as the ESP, and your /dev/sda2 is about the right size for that; but your /dev/sda2 holds a Linux filesystem and has no EFI boot loaders. My hunch is therefore that you've accidentally trashed your ESP, rendering the computer unbootable.

Related to the first point, you don't seem to have any EFI boot loader programs on either your hard disk or your SSD.

Your /dev/sda11 is about the right size to be an ESP and does have a FAT filesystem (which an ESP must have), but it's marked as a BIOS Boot Partition.

As a first step, you must create a proper ESP. There are two relatively easy ways to do this:

  • Adjust the type code on /dev/sda11. In GParted, you can do this by removing the "bios_grub flag" and setting the "boot flag." In gdisk, you'd do this by setting the type code to EF00.
  • Adjust the type code on /dev/sda2 and make it FAT32. In GParted, you'd do this by setting a "boot flag" and creating a FAT32 filesystem on it. In gdisk, you'd set the type code to EF00 and then use the separate mkdosfs utility to create a FAT32 filesystem on the partition.

Once that's done, you can begin recovery. In theory, you can use Boot Repair to do the task, at least for Linux; but as it appears it led you down the wrong path before, you might want to do something different:

  1. Download and prepare a bootable USB flash drive or CD-R version of my rEFInd boot manager.
  2. Boot with rEFInd. It should show you at least one option for booting Linux.
  3. Boot to Linux.
  4. Open a Terminal window.
  5. Edit your /etc/fstab file to mount your ESP (/dev/sda2 or /dev/sda11) to /boot/efi.
  6. Type sudo mount -a.
  7. Type df -h and ensure that there's a line for /boot/efi, showing the correct partition mounted. If not, go back to step #5.
  8. Download and install the Debian-package version of rEFInd.

At this point, rEFInd should enable you to boot Linux. Your Windows installation will remain unbootable, though, until you run a Windows recovery tool. You should be able to download something from Microsoft's site to repair the Windows boot loader, but I don't happen to have a URL or instructions handy. I recommend you ask on a Windows site if you have problems with this part of the task. Note that after you're done, the Windows boot loader will be set as the default, so you'll need to change that. You can either follow steps 2 and 10-11 in this procedure or use the USB flash drive to boot to Linux and then re-install rEFInd from there. Alternatively, you could repair Windows before you repair Linux, but you'll need to fix the ESP before you do either OS-specific repair.

Related Question