1

So here's what happened. I got a Dell xps 13 and figured out how to get it to dual boot Ubuntu and Windows 10.

Everything was working great.

I switched out the ssd for a 500gb one because I only had the 128gb and with dual booting it would be nice to have a bit more space.

The new ssd works fine, but when I was preparing to transition from the one ssd to the other, I made the mistake of trying to make a windows recovery drive. It totally messed with the bios/UEFI settings and I was no longer able to easily switch from one or the other on my old ssd. The only thing that would show up was the Windows Boot Manager. I didn't think it would change or mess with the boot settings, I figured it would only copy, not change.

Anyway, I just continued forward and even though I was able to install Ubuntu again on my new ssd with slightly more trouble than usual, it seems that it is still giving me grief because after just figuring out how to install Windows 10 on another partition in a slightly different manager than last time, doing that did a similar thing as trying to create the Windows recovery drive on my old ssd. Now I am no longer able to get to my Ubuntu partition again and it is only showing the Windows Boot Manager. I've tried changing the Secure Boot option and taking a look at Legacy, but even though I can see my Ubuntu desktop clearly still exists when I use a trial version from a usb, it just won't show up in UEFI like it was before.

Does anyone have any idea what's going on here? This seems like it should be fixable, but I haven't found a solution yet.

L. D. James
  • 25,036
user2353266
  • 13

1 Answers1

2

When you installed Windows it replaced the the Grub (Linux Boot Manager) with Windows Boot Manager. The Windows Boot Manager doesn't see Ubuntu. You'll have to replace the Windows Boot Manager with Grub, which can see both Windows and Linux and will give you both as a boot option.

You can reinstall Grub with these steps:

  1. $ sudo mount /dev/sdX# /mnt
  2. $ for i in /sys /proc /run /dev; do sudo mount --bind "$i" "/mnt/$i"; done
  3. $ sudo mount /dev/sdY# /mnt/boot/efi
  4. $ sudo chroot /mnt
  5. # grub-install /dev/sdZ
  6. # update-grub
  7. # exit
  8. $ for i in /sys /proc /run /dev; do sudo umount "/mnt/$i"; done
  9. $ sudo umount /mnt/boot/efi
  10. $ exit


  • Steps #3 and #9:

They are for a UEFI mode setup. It doesn't hurt to perform those steps regardless of the mode. If you don't have the EFI partition, you'll get an error which can be ignored. Continue to the other steps (which shouldn't give errors and should not be ignored). If you do have the EFI partition, but you're installing Grub from a Legacy boot, the Grub Install will ignore the EFI partition.

  • The variables:
/dev/sdX#     - the partition that has your Ubuntu Installed (ext4).
/dev/sdY#     - the EFI System Partition.
/dev/sdZ      - the drive you will be booting from (/dev/sda, /dev/sdb, etc.).

You can identify your drives and partitions with this command:

sudo lsblk -o name,mountpoint,label,size,fstype,uuid;sudo parted -l

After you have completed those steps, you will now see Ubuntu as a boot option. Boot to it and you'll have the both Ubuntu and Windows as a menu choice.

Notice: The $ and the # part of the command-lines are the terminal prompts. It's important to show that the $ prompt is a normal user, requiring sudo to elevate the command. The # prompt which happens after chroot is a terminal logged in as root. The sudo prefix isn't required. While, for security, it's discouraged, some people always work under a # prompt by executing sudo su - before they start work. The $ prompt and sudo is the official Ubuntu recommended method.

L. D. James
  • 25,036
  • Is that a typo in line 2 and line 9? Shouldn't it be "/mnt$i" instead of "/mnt/$i"? Please check and correct if I am right, apologize if I am wrong please. – mook765 Jan 30 '17 at 08:14
  • @mook765 Thanks for the scrutiny! Either will work... sudo mount --bind /sys /mnt/sys or sudo mount --bind /sys /mnt//sys. This would produce the same output also ls /usr/bin and ls /usr//bin. In this case having the slash included in the command looks clearer (to me). The double slash in a pathname is treated as a single slash. – L. D. James Jan 30 '17 at 12:37
  • The double slash in a pathname is treated as a single slash. I didn't know that, thanks for the info. Having the slash included in the command looks clearer for me too... – mook765 Jan 30 '17 at 12:49
  • This worked beautifully, thank you so much. I had seen some information about getting grub back, tried a couple things, but none of it seemed to work. – user2353266 Jan 30 '17 at 16:56
  • I find the steps to be very easy also, with everything already on the live media. I've been spending a lot of time in refining them to make them as as easy as possible for a novice. Glad it worked! – L. D. James Jan 30 '17 at 17:00