Recently I had to convert a PC's hard drive from MBR to GPT in order to install LMDE 2. Here are some notes on what I did:

I am NOT an expert on this. If my notes here don't quite fix your problem, then probably someone else on this forum can help you better than I can.

The PC had a previous Linux distro which I wanted to dual-boot into after LMDE was installed. (No M----Soft Windows )
The motherboard was by MSI, and I don't remember its UEFI firmware having any problems that interfered with this conversion & OS installation.

The reason for converting the disk from MBR to GPT was:

The LMDE installer requires a FAT32 EFI partition, which didn't exist on the disk, so I had to add one;

The disk already had 3 primary partitions & 1 extended partition, so I couldn't just add another primary partition;

If I were going to add the EFI partition & leave the disk as MBR, then I would want to add the EFI partition as a primary partition (my own preference).

So I chose to convert the disk to GPT.

Mostly, I followed the procedure by user "Portablejim" in the AskUbuntu question (link @ bottom of this post). After I modified the os-prober script in LMDE's /etc/grub.d/ (https://bugs.debian.org/cgi-bin/bugrepo ... bug=855976), the "update-grub" utility in LMDE correctly auto-detected the prior Linux distro for dual-boot. (This was the last thing I got working.) So I didn't ever need the section "Configuring (+ Dual Boot)" in Portablejim's posting.

Also, at first, the LMDE version of GRUB wouldn't boot because it didn't properly handle the Btrfs partitions on that PC. This problem & my solution are documented in https://bugs.debian.org/cgi-bin/bugrepo ... bug=854326
I had to use the prior OS's GRUB until I got LMDE's GRUB fixed.

After using "gdisk" to convert the drive from MBR to GPT (step 2 of Portablejim's posting), I used an LMDE 2 "live" USB stick and the prior Linux OS (an Ubuntu version) to install GRUB with the following commands. Commands in bold will be explained at the bottom.
The hash character (#) introduces comments.

[b]---BEGIN---[/b]
[b]sudo -s[/b] # Not conventional, but most or all of the following commands require root privilege, so I did it this way.
[b]mount -o subvol=@ /dev/sda2 /mnt[/b] # /dev/sda2 had the prior Linux OS that formerly booted from master boot record (MBR)
# In this case, /dev/sda2 was a Btrfs partition, and all of its data was in a Btrfs subvolume called "@".
# I think of /mnt as a "virtual folder" (not technically the right term) in the USB stick "live" OS. (This /mnt folder doesn't exist on the hard drive.)
[b]mount -t proc proc /mnt/proc[/b]
[b]mount -t sysfs sys /mnt/sys[/b]
[b]mount --bind /dev /mnt/dev[/b] # "--bind" means "make a reference to the existing folder & its subfolders, rather than making an entirely new set of /dev subfolders".
mkdir /mnt/boot/efi
# This folder (with nothing in it) stays on the hard drive.
mount /dev/sda1 /mnt/boot/efi
# /dev/sda1 is the EFI system partition.
cp /run/resolvconf/resolv.conf /mnt/run/resolvconf/resolv.conf
# So APT can access the network.
cp /etc/resolv.conf /mnt/etc/resolv.conf
# Symlink to the above resolv.conf file.
[b]chroot /mnt[/b] # From this point on, the binaries being run are on the HDD, not on the USB stick!
apt-get install grub-efi
# On that Linux distro, this un-installed the "grub-pc" package.
grub-install --target=x86_64-efi --efi-directory=/boot/efi
# This writes to the EFI system partition. This only needs to be done once, which is why commands related to it aren't in bold (explained in "Commands in bold..." below).
[b]update-grub[/b] # This generates /boot/grub/grub.cfg based on /etc/grub.d/* and /etc/default/grub (all of these files are on the prior OS's partition /dev/sda2).
[b]---END---[/b]

Commands in bold are used (if changing the GRUB configuration is needed) to run "update-grub" after the first run of "update-grub". Running "update-grub" on the prior Linux OS without the USB stick didn't seem to work. I'm not certain of the reason, but possibly the prior OS was old enough that it didn't have /dev/disk/by-uuid/
Anyway, once I dealt with the 2 issues noted above (Debian bugtracker links) in LMDE's GRUB, I could run "update-grub" in LMDE without either the prior LInux OS or the USB stick.

My Web browsing to get my questions answered was done using the LMDE 2 "live" USB stick, so the pages I visited aren't in my Web browser's history.
I know some of the following webpages helped me, although I don't remember the whole list perfectly:

A big thank-you to those who maintain the Arch Linux wiki. That documentation has been in the range from "useful" to "saved my bum" more times than I can count. (I think I can count up to 5. -- Of course I can count higher than that, it just sounded cool.)

Well I'm glad it worked for you. However, you didn't need to add the EFI partition in order to install LMDE2. I ran into the same problem with my MSI-based PC, and the solution that worked for me is actually much simpler. It has to do with the oddball UEFI BIOS that MSI uses. Their default boot priority settings have all available drives listed first as UEFI drives, and then again as legacy drives, so that if you boot to your LMDE2 installer DVD, it's as a UEFI drive--and so LMDE2 tries to install to a UEFI system. But you, like myself, lacked a EFI partition on your HDD so it failed. If you simply open your BIOS settings and drag the legacy DVD drive to the front of the list, the machine boots the live-DVD as legacy, so the installer assumes a legacy boot system and installs LMDE2 just fine. AFAIK MSI boards are the only ones that act like this, yours is I think the fourth case I've heard about including mine.

Also, I've just found out that the same PC's BIOS (which I've updated to its latest version) will boot from USB 2.0 thumbdrives but not from USB 3.0 thumbdrives. This fact may help someone who's unable to boot a USB stick on their machine, if their BIOS has this limitation and they didn't realize that the USB stick was USB 3.0.

In installing Linux Mint 18.1 "Serena" recently, I found the following: (I know this forum is for LMDE instead of the Main Edition, but the post is relevant to the previous ones in this thread

Unetbootin isn't in the LMDE repos, but I had Unetbootin on the prior Linux distro, so I used that to put a bootable copy of my preferred Linux Mint 18.1 ISO onto a USB stick.

The USB stick had the default MBR-style partition table, because I hadn't converted the USB stick to GPT.

The USB stick booted, but the Linux Mint installer failed when trying to update GRUB on the GPT hard drive. In fact, the installer crashed and told me it would give me debug info, but no debug info appeared.

I used gdisk to convert the USB stick to GPT (after using GParted to make sure there was 1MB unused @ end of disk [USB stick] as GPT requires).

I copied the files from my preferred Linux Mint 18.1 ISO to the USB stick as mentioned in section 1.2 of http://askubuntu.com/a/395880 (Nemo has a right-click-menu option to mount the ISO, although not worded quite the same as in the screenshot in that AskUbuntu answer.)

I used GParted to set the "esp" flag on the USB stick's FAT32 partition. Setting this flag clears automatically the "msftdata" flag and sets the "boot" flag.

The idea is that any FAT32 partition with "esp" and "boot" set meets the requirements to be an EFI system partition, and if a suitable EFI boot binary is in the /EFI/ folder of that partition (which it is on the ISO), then that EFI boot binary can boot the "live" Linux system even from the same partition (not only from a different partition as is usually done on a hard drive).

Due to the "esp" and/or "boot" flags being set, Nemo's desktop management didn't open a file-manager window (Nemo) on the USB stick when I plugged in the USB stick. I later noticed that another Linux file manager is this way too. So, in many cases, your GUI file-manager won't let you easily copy files from the ISO to the USB stick after the "esp" flag is set.

dg1727 wrote:Also, I've just found out that the same PC's BIOS (which I've updated to its latest version) will boot from USB 2.0 thumbdrives but not from USB 3.0 thumbdrives. This fact may help someone who's unable to boot a USB stick on their machine, if their BIOS has this limitation and they didn't realize that the USB stick was USB 3.0.

Interesting. Since USB3 devices are supposed to be backwards-compatible, I wonder if the USB3 thumbdrive would boot if inserted in a USB2 port? I'd try it on mine except that I believe my front ports are all unreliable and I've been too lazy to replace them. And too lazy to attempt to get behind my machine and rearrange all umpteen USB cables back there.

kevinthefixer wrote: Since USB3 devices are supposed to be backwards-compatible, I wonder if the USB3 thumbdrive would boot if inserted in a USB2 port?

I tried this recently. The USB3 thumbdrive didn't boot when inserted in a USB2 port. BUT...
The USB3 thumbdrive in a USB2 port also wasn't automounted, nor automatically given a desktop icon, by Thunar's desktop management. Only the device file /dev/sdX1 (X = a lowercase letter) existed.
It might be that this particular USB3 thumbdrive is designed to work less conveniently on USB2, possibly to keep people who plug it into a USB2 port from saying, "This isn't any faster than my USB2 thumbdrives!" This drive is a Sandisk Ultra.

kevinthefixer wrote: I'd try it on mine except that I believe my front ports are all unreliable and I've been too lazy to replace them. And too lazy to attempt to get behind my machine and rearrange all umpteen USB cables back there.

I have a USB2 extension cable which instantly turns a USB3 port into a USB2 port.

Edit: Updated the title.

Last edited by dg1727 on Thu Mar 09, 2017 11:01 am, edited 1 time in total.

Ah, now, Sandisk has a bad habit of using unique formatting on their thumbdrives and flash cards, so that they can give you "free software" with them. I recommend you use gparted to write a new partition table to it. Yes, that'll eliminate anything you have stored on it.

I can't elaborate with specifics because I don't own any Sandisk products. I picked up this gem of wisdom from the Chromebook forums, it seems that Chromebooks and OOTB Sandisk drives don't get along. The cure seems to be as above.