# Automount fails for partitions 1 and 3 of an HDD in a USB dock.

I am in the process of trying to copy my data from an old HDD with Fedora 21 installed to a new HDD with Fedora 24 installed by booting with one fedora system and afterwards switching power on on an USB HDD docking station containing the other HDD.

It does not matter whether the boot drive is Fedora 21 or Fedora 24, the symptoms are the same, only partition /dev/sdb2 of size 504 MB is recognized. I cannot use the mount command because I do not know the type to specify. Commands that list partitions only show dev/sdb3 which is the data partition to be an LVM volume and nothing about the logical drives it contains.

This is not the first time I have had this problem as I encountered it several years ago. Usually when I have a problem I record information about it and its solution in a document on my computer but I cannot find such a document and fear it is on a HDD that has crashed. What I can remember is that it is a name conflict, somewhere on each of the 2 HDDs is a name set by different versions of Fedora to the same default during install but this name must be unique on all disks or partitions for them to exist together in a system. It is necessary to ensure that this name is different.

However I am dammed if I can remember exactly what this name is. .

edit retag close merge delete

start gnome-disks and decrypt by the LVM. then it should show content of volumes.

( 2016-11-18 21:23:03 -0500 )edit

Sort by » oldest newest most voted

Things to look at if you need it to be "automounted" (a manual mount may be a quick-fix if you just want to transfer files):

"sudo lsblk --fs /dev/sdb" should list the disk/partition/volume/filesystem types for the "partitions" on sdb, including those that aren't currently mounted.

I'm not familiar with automount failures due to naming conflicts, but If the "filesystem on sdbX" is ext2/3/4: "sudo e2label /dev/sdbX" should tell you the current label for the filesystem on "sdb partition X" "sudo e2label /dev/sdbX MYNEWLABEL" should allow a change to MYNEWLABEL such that there isn't a label conflict. "sudo tune2fs /dev/sdbX -U MY-NEW-UUID" should allow a change to a new UUID if a duplicate UUID for the filesystem is the problem (might be the problem if you used dd to "copy" the drive). There are other options for the -U parameter, "clear", "random", "time". They should get a potential UUID conflict out of the way.

If the "sdbX partition/volume" is lvm, look into "man lvm", or for naming conflict ("man pvrename", "man vgrename", or "man lvrename") If the filesystem is encrypted (like luks or dm-crypt), look into "man cryptsetup" (sorry, out of "my wheelhouse")

Manual mount: Alternatively, if the filesystem is one that is at least "recognized" (i.e. it is listed via "sudo cat /etc/filesystems"), you could always try a manual mount with no explicit options, ala:

"sudo mount /dev/sdbX /MountDirectory"

and of course, if this manual alternative works, you'll need to manually unmount it before you unplug it from the usb port (or perhaps before you pull your machine from the dock), ala:

"cd /ToSome(Non-sdbX)Directory" "sudo umount /dev/sdbX"

more