YouTube Videos

FILTERS:
ALL
Dual Boot MultiBoot
3 Fast MultiBoot USB3 Sticks
Bootmenus
Desktop Screenshots
Dualboot Kubuntu 16.10 & Win-10 USB3
Dualboot Android-x86 Linux USB
Dualboot Windows Linux USB
Dualboot Win-10 and Kubuntu 16.04
Dualboot Win XP and RemixOS
Grub2 Multi-Bootmenus
How Repair GPT Boot Failures?
Linux MultiBoot Grub1
Linux MultiBoot Grub2
Mount Linux in Windows
Mount Windows in Linux
Moving Windows XP Installation
MultiBoot & Backup
MultiBoot - Recap
MultiBoot - Device Mixups
MultiBoot USB-Stick
MultiBoot USB3 Extreme
Ranish Partition Manager
Ranish PM - Installation
Ranish PM - Recap
Ultimate MultiBoot PC
Android
Android-x86
Backup Cloning
Chromecast
Linux
Messaging IM SMS
Misc. Soc Media
Music Jazz MPB
Remote Controls
Screen Recording
Smart-TV IPTV
USB Flash Drives
Windows

Krister's Blog
krister at hallergard dot com


Orig. version:
2016-06-16
Solution:
MultiBoot - Device Mixups SOLVED

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

Booting Windows - Diskmanagement:

Windows Boot: Disk 0 = 2TB and Disk 1 = 1TB


Booting Linux:

Linux boot 2TB device sdb



Linux Boot 1TB device sda


Previous GPT Boot Failures
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.

Device mixups
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?

Decided to boot openSUSE and there do the "update-grub", reboot and in the openSUSE bootmenu choose Linux Mint on /dev/sdb8 - and it booted ok! Well there I performed "update-grub", and I now have a working Mint grub2 bootmenu. Since then Linux Mint worked fine on /dev/sdb8 for about a week.

A couple of days ago the Linux Mint boot started stalling again. I ended up making a temporary fix with its /etc/fstab, swapping /dev/sda to /dev/sdb and vice versa, but not swapping their mount points. It has been working like that for a couple of days now, while the other distros on the 2TB disk work fine in their /dev/sdbx positions.


Linux Mint /etc/fstab on /dev/sda8!?


Would like to sort this out properly, and would very much appreciate if you could explain to me what causes these device mixups, and what to do about them!

SOLUTION:

It was pointed out to me that I should use the UUID instead of /dev/sdxy in the /etc/fstab file - not just for the partition being booted, but also for all partitions being mounted during the boot. This would look like the file to the right.

This will not change the behaviour that what usually is sdb sometime will become sda - just making this issue unimportant. I will be keeping the mount points in the format sdb4 because that is what all my shortcuts are based on. This will function also when sdb becomes sda, i.e. in this case sda4.

Update 2016-06-17


Linux Mint /etc/fstab on /dev/sdb8 or /dev/sda8
does not matter which!