My Ubuntu 16.04 MythTV box has two hard drives sda and sdb, connected to the SATA1 and SATA2 interfaces respectively. They have partitions sda1, sda2 and sdb1, sdb2 etc. I am installing a 240GB SDD and having, researched this subject, I was expecting this to be sdc when connected to SATA3. For some reason, gparted sees it as sdb, and what was sdb is now sdc, so all the partition names are wrong. I.E. sdc has partitions sdb1, sdb2 etc.

The intention is to move everything onto the SDD apart from the two 1GB partitions used for the MythTV recordings, one on each HDD. Ideally sda should be the SDD on SATA1 with the current sda becoming sdb on SATA2, and the current sdb becoming sdc on SATA3, with all the partitions being named appropriately.

Just a few questions then:-

  1. Is this a reasonable goal and possible to achieve without re-installing, and how would this be achieved?

  2. Would it be preferable to somehow force the name of “sdc” for the SDD so that partitions can be named more appropriately?

  3. Are there any OS overheads or any other problems (other than confusion) in having partition names mismatching the disk that they are on?

  4. Do partition names have to be unique system wide or just per disk, i.e. can you reference it by including the disk name e.g. /dev/sda/sdb4?

I’m sure there are probably a few more questions here but I can’t think of any at the moment.

  • How is this related to Ubuntu?
    – David
    Mar 4, 2021 at 16:48

2 Answers 2


The short answer is “not anymore”. I think it was around 16.04 when udev rules to specify storage devices at /dev/sdX went away. You can use udev to create additional symlinks with predefined names, but /dev/sdX (and some others) fall under the purview of the kernel.

The kernel names devices based on the order they’re discovered. The boot drive will always be discovered first so, if it is on a bus that gets assigned a letter in /dev/sdX, the X will always be a. If the SSD responds to the probe command during boot faster than the HDD, then it will probably always get assigned next, followed by devices that respond slower. If the SSD and the HDD have very close response times that fluctuate for whatever reason, you might see that swap assignments with different boots.

For reasons like this, we generally use mount points with UUIDs so that things generally “just work” and we don’t have to fiddle with settings or modify fstab more often than necessary 👍🏻

  • FYI: In my case, my "boot" drive (which is also older than my "home" drive) is assigned the name sdb and my "home" drive is assigned the name sda. Before the time I added my "home" drive to the system, my "boot" had the name sda. Of course, this change did not create any problem because my system uses UUID.
    – FedKad
    Mar 4, 2021 at 17:01

Partition names are unique system wide no two can be identical or you are looking at big problems. You will get into a situation where you will not know which partition is mounted at the time without checking the physical location. It can change between boots as it will depend on which drive was seen first by the system for it to be mounted. This is the reason why your SSD turned up as /dev/sdb it got seen before the other drive or it was on a controller channel that is in line before the second spinner, the result is the same it gets seen first so gets the next drive letter in line for assignment. To ensure a predictable way of doing it the PARTUUID or LABEL can be used in your /etc/fstab when mounting to prevent the confusion of the drive letter change will do to you. To find the required information use the blkid command as root or with sudo.

root@buster-raspi:~# blkid
/dev/mmcblk1: PTUUID="8ed03b0d" PTTYPE="dos"
/dev/mmcblk1p1: SEC_TYPE="msdos"   LABEL_FATBOOT="RASPIFIRM" LABEL="RASPIFIRM" UUID="AC25-5007" TYPE="vfat" PARTUUID="8ed03b0d-01"
/dev/mmcblk1p2: LABEL="RASPIROOT" UUID="cce1d06d-e567-4b48-a624-e823b516507f" TYPE="ext4" PARTUUID="8ed03b0d-02"
/dev/sda1: SEC_TYPE="msdos" UUID="3651-174E" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="9fad4e77-177d-4a3c-929a-3897e6bc1810"
/dev/sda2: UUID="4a349c2c-0df5-4fdb-a99f-906423554de9" TYPE="ext4" PARTUUID="59097f66-f9fb-4a50-a491-8a71becaa2bd"

There I show you my Pi 4 output below the /etc/fstab.

root@buster-raspi:~# cat /etc/fstab
# The root file system has fs_passno=1 as per fstab(5) for automatic fsck.
#LABEL=RASPIROOT / ext4 rw 0 1
PARTUUID=59097f66-f9fb-4a50-a491-8a71becaa2bd / ext4 rw 0 1
# All other file systems have fs_passno=2 as per fstab(5) for automatic fsck.
LABEL=RASPIFIRM /boot/firmware vfat rw 0 2

In that file you can see how it is mounted with the LABEL=RASPIFIRM for the booting of the machine and the PARTUUID=59097f66-f9fb-4a50-a491-8a71becaa2bd / ext4 rw 0 1 for the / of the system which I copied from the commented out #LABEL=RASPIROOT partition to have the files loaded from a SSD instead of the sd card they were on.

This method ensures you get a constant reliable naming of your file systems to mount with on boot. Those never change unless you format the partition or manually in the case of the LABEL change it. Both deliberate acts on the users part who should know, that now changes are needed to be able to boot again.

For the boot again without re-install, well for that to happen you need to copy the files on your current /. Once this is done if BIOS boot then GRUB is installed to the new drive using a re-check method to ensure the new install is found. You then boot into that install and wipe the old drive and do GRUB again to eliminate the error of it not being found once erased. GRUB is so wonderful it will refuse to even attempt a boot if a non-involved operating system is not present. Until that entry is removed by re-install the boot will fail even though that OS has nothing to do with booting the one you want. If EFI system, which it seems you do not have I think, you would need to copy the tiny /dev/sda1 at the beginning of the drive to its corresponding partition on the new drive and go through the GRUB double install all over again. You can see this partition in my output above on the /dev/sda1 of the SSD drive I use as it is partitioned GPT a requirement to boot using the EFI method. I think I have covered it all for you. Beaten to it by the above poster while writing it, I will leave it anyways.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .