0

So I'm gonna start out with this: http://paste.ubuntu.com/10720995/

Okay, so I have Ubuntu 14.04 and Windows 7 installed on separate hard drives like this:

sda: Ubuntu 14.04
sdb: Windows 7
sdc: Extra Storage (badly partitioned)

When I boot, I want to boot to grub on sda, but the boot info script says its on sdc! (the main problem being that grub can't find windows) IIRC, I had Ubuntu installed on sdc before and windows on sda. Which would explain the mess. I want to move grub from sdc to sda, but the Boot Repair won't let me (It tells me I have GPT and SRS).

I think this is because of the sda1 and sda2 partitions. I wanted to delete them, but I still don't quite know what I'm doing and I don't want to corrupt/wipe a drive by accident. So I thought I would ask for advice before I end up with a blinking cursor.

1

First, disk device filenames (/dev/sda, etc.) are subject to change. They can change because you physically move disks around, because you plug in additional disks (even external devices), because of changes in the way drivers load, because of changes in firmware settings, or even randomly (typically because two drivers may be competing to load first, and which one succeeds varies from boot to boot). Thus, don't get too attached to your device filenames or rely on them.

Second, your boot configuration is unclear and complex. Using the device identifiers in your Boot Info Script output:

  • /dev/sda uses GPT and has an EFI System Partition (ESP), which in theory holds EFI boot loaders. I say "in theory" because the Boot Info Script didn't find any boot loader files on your ESP. OTOH, sometimes the Boot Info Script misses things, so they may be there. Also, efibootmgr found an entry for an Ubuntu GRUB in the firmware's NVRAM, so clearly at one point you had installed Ubuntu in EFI mode. It's not clear if that entry still works, but it does exist.
  • /dev/sdb uses MBR and has two NTFS volumes with Windows boot files. It therefore appears as if the computer is set up to boot Windows in BIOS mode. This would not get along too well with an EFI-mode Linux boot, although there are ways to get the two to coexist.
  • /dev/sdc uses MBR, but with a Windows Logical Disk Manager (LDM) configuration layered on top of that. You should NOT attempt to access your /dev/sdc* partitions directly in Ubuntu, much less install Ubuntu on that disk. If necessary, you may be able to access that disk via device files in the /dev/mapper directory. If you need to do more than that, you must convert from LDM to plain MBR partitions. You can do this with various third-party Windows partitioning tools. To make matters more twisted, you've got GRUB installed in the MBR of /dev/sdc.

Two ways to cut through this mess occur to me:

Method 1:

  1. Physically unplug /dev/sdb and /dev/sdc.
  2. Boot an Ubuntu live CD or live USB.
  3. Use GParted, parted, or gdisk to create a new BIOS Boot Partition on /dev/sda (your GPT disk).
  4. Install GRUB to /dev/sda. In principle, you should be able to use Boot Repair to do this if you like. Note, however, that if you run Boot Repair in EFI mode, it may try to install the EFI version of GRUB, which you do not want. Check for a directory called /sys/firmware/efi to determine your boot mode; if it's present, you've booted in EFI mode and if it's absent you've booted in BIOS mode. If you're in the wrong mode, you'll need to reboot and select the right boot option in your firmware's boot manager or reconfigure the firmware to not support EFI-mode booting. (Details vary greatly from one machine to another, I'm afraid.)
  5. Shut down the computer and re-attach the other two disks.
  6. Boot to Linux using the GRUB you've just installed. (You may need to adjust the default boot order in your firmware.)
  7. Run update-grub. This should cause it to detect your Windows installation and enable you to boot Windows from GRUB the next time you reboot.

This method has the advantage of keeping everything booting in a single mode (BIOS/CSM/legacy). That boot mode is better understood by the community as a whole than is EFI-mode booting. OTOH, you'll be messing with your disk and boot loader configuration with no guarantee that the changes will actually work, so you could end up making matters worse.

Method 2:

  1. Download the USB flash drive version of my rEFInd boot manager.
  2. Prepare a USB flash drive with rEFInd.
  3. Mount the USB flash drive and edit the EFI/BOOT/refind.conf file it contains: Uncomment the scanfor line and ensure that hdbios is among the options. You might also need to uncomment the uefi_deep_legacy_scan option, although I recommend leaving that as-is for now and use it only if you can't boot Windows in a couple of steps.
  4. If necessary, reconfigure your computer's firmware to enable EFI-mode booting. You may also need to disable a "fast boot" option. (It might already be set up this way.)
  5. Boot to the rEFInd USB flash drive. With luck, it will show you options to boot Ubuntu and one to three more with gray diamond-shaped icons to boot in BIOS mode. One of those should boot Windows. Test to be sure you can boot both Ubuntu and Windows.
  6. If all this works, install rEFInd to your hard disk by booting Linux via rEFInd (and not via one of the gray diamond legacy options) and installing the Debian package or PPA version noted on the downloads page. You'll need to edit /boot/efi/EFI/refind/refind.conf as you did earlier on the USB flash drive. If you've got too many options in rEFInd, you can use dont_scan_volumes or dont_scan_files to remove redundant options from the menu.

This approach has the advantage that you won't make any changes to your permanent configuration until you've fully tested it via the USB boot of rEFInd, so there's very little risk of making matters worse. It assumes that your computer is EFI-capable and that it provides a CSM, though. It also assumes that your Windows boot loader is intact on /dev/sdb. (Boot Info Script says it's there, but whether it works or not is another matter.)

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.