My old PC conked out, so I had to buy a new one (new PC spec.). It has a 2 TB disk drive with a GUID Partition Table, GPT and Windows 10 preinstalled in UEFI mode. I started out by shrinking the Windows 10 partition (#4), by about 800 GB to about 1100 GB. I then used the created space for a 650 GB partition (#5) for storage of data and backups, and finally for another four 25 GB partitions (#6-#9) for installing Linux Distros.
I wanted to keep the 1TB disk - MBR disk - from the old PC, expecially since it was still possible to boot Windows 10 installed on partition #1 as well as the two Linux distros on partitions #3 and #4. Because of the different chipset, I had not expected them to boot. On partition #2 I had a Windows XP installation, which was not possible to boot, so I have now turned that space into another data and backups partition.
The strange thing is that Disk 0 when booting Windows becomes Device sdb when booting Linux. And Disk 1 booting Windows becomes Device sda booting Linux! It should be the other way around!
View Video 8 min
I suffered several catastrophic boot failures trying to get the GTP and MBR disks to coexist, and was not able to repair using any of Windows the advanced tools - as described here. I then thought the GPT partition table had been ruined - and I had not yet learned about the gdisk tool, which would have allowed restoring a backup of the GPT partition table (if I had had one). Possibly I could have saved myself from reinstalling from scratch, if I had known how to manage the boot flags of the EFI partition with e.g. GParted in Linux.
I now believe my problems were caused by this toxic combination:
1. Device mixups, as described here
2. The EFI partition I had created on the 1 TB disk
3. Windows 10: its willingness "attempting to repair"
May aim with adding an EFI partitions on the 1 TB disk was to subsequently convert its systems from Legacy to UEFI mode, without reformatting - keeping it as a MBR disk - to get faster boot times. I believe that the two EFI partitions on sda2 and sdb2 got mixed up with each other, causing a confusion that the "attempting to repair" made worse. Anyway, I have taken away that extra EFI partition (which was too big anyway) and given up on the idea of turning the 1TB disk into UEFI mode. After removing this EFI partition and reinstalling again from scratch, I have not had this type of boot failures.
The last time I installed the 2TB disk from scratch, I did spend some considerable time on this issue. I tried different settings of the motherboard firmware, clearing its CMOS values and swapping the sata cables around to different ports. In the end I decided to live with the problem: Disk 0 being Device sdb, etc. Linux Kubuntu installed fine to sdb6 and openSUSE to sdb7. Things have now been working well for over 3 weeks, though I have had two cases of Linux boots stalling. I suspect the boot disk was sda but the grub.cfg told them they were on Device sdb. But rebooting worked nomally. What decides which is the boot device? The motherboard firmware? Its NVRAM? The EFI partition?
Installing Linux Mint 17.3 KDE to sdb8
Booted the installation media and when I got to the Disk Setup I found that sda8 was available! I aborted and rebooted - same story. What to do? Proceeded with the installation, and was asked to reboot, but it stalled. What to do?