[ale] USB "duplicate" drive issue on CentOS
Alex Carver
agcarver+ale at acarver.net
Thu Jun 16 15:52:08 EDT 2016
If you use a udev rule then the device name *won't* change (or you can
avoid needing to care). You identify the device based on its bus and
device IDs (which are fixed) and the udev rule will put it in the same
spot every time.
Here's an example using serial ports but concept is the same:
ACTION=="add",KERNEL=="ttyUSB*",SUBSYSTEMS=="usb",KERNELS=="1-1.3.1.4:1.0",SYMLINK+="dymo"
ACTION=="add",KERNEL=="ttyUSB*",SUBSYSTEMS=="usb",KERNELS=="1-1.3.1.3:1.0",SYMLINK+="supra"
If the USB-serial adapter is plugged into the same port (or present at
boot) it's going to get the same symlink every time.
You could also match against the UUID of the disk. You would add the
check to your rule:
ENV{ID_FS_UUID}=="UUID_IN_HEX_NO_HYPENS"
So something like
ACTION=="add",KERNEL=="sd?1",ENV{ID_FS_UUID}=="4A6F2ABC1232FA37",RUN+="my_luks_mounting_script
$devpath /mnt/backup"
Or you can just symlink it and let your script handle mounting and
unmounting
ACTION=="add",KERNEL=="sd?1",ENV{ID_FS_UUID}=="DEADBEEF1COFFEE2",SYMLINK+="BACKUP"
You can get the data from udevadm info /devpath_to_device when you have
the drive plugged in.
On 2016-06-16 11:54, Edward Holcroft wrote:
> After the backup script has run, it unmounts the drive, which is then changed
> out by the local office manager who removes it from the dock and puts the next
> day's drive in place.
>
> In order to deal with USB device names changing, I set the script to mount by
> label. This works nicely with my MON through FRI drives. When it works, that is. :-)
>
> ed
>
> On Thu, Jun 16, 2016 at 2:03 PM, Jim Kinney <jim.kinney at gmail.com
> <mailto:jim.kinney at gmail.com>> wrote:
>
> I agree with Phil. This needs to be activated by usb tools instead of
> autofs. The usb connection will usually change as it's done on the fly. A
> udev event process will map into user space from kernel space where autofs
> is is the reverse.
>
> How are the drives being removed?
>
> On Jun 16, 2016 1:50 PM, "Edward Holcroft" <eholcroft at mkainc.com
> <mailto:eholcroft at mkainc.com>> wrote:
>
> I guess I don't have to use autofs. It just seemed like the easiest way
> at the time to script automated, remote, encrypted daily backup based on
> the label of the drive that gets inserted by the office manager at the
> remote site. Since I only have this issue at some of my sites, all with
> the same hardware and software (CentOS 7 on HP ML350), I'm optimistic
> that there's a fix, hoping that I've just done something stupid on some
> of the servers.
>
> Here's an example of a log where I place the drive into a freshly
> rebooted server ... encrypted drive ready to go at 12:31:16. Then pull
> the drive and reinsert it ... and I get the "different syspaths" issue.
> In googling that message, many forums refer to it as "harmless" and "to
> be ignored". Clearly not in this case though, since my servers that do
> work, do not have this anywhere in the logs. One systemd bugfix that I
> read merely changed the verbosity level to get rid of the message,
> without changing underlying behavior.
>
> Jun 16 12:31:16 atlfs kernel: usb 2-2: USB disconnect, device number 3
> Jun 16 12:31:16 atlfs kernel: sd 3:0:0:0: [sdd] Synchronizing SCSI cache
> Jun 16 12:31:16 atlfs kernel: sd 3:0:0:0: [sdd] Synchronize Cache(10)
> failed: Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
> Jun 16 12:31:16 atlfs systemd: Stopping Cryptography Setup for THURSDAY...
> Jun 16 12:31:16 atlfs systemd-udevd: error opening USB device
> 'descriptors' file
> Jun 16 12:31:16 atlfs systemd: Stopped /dev/mapper/THURSDAY.
> Jun 16 12:31:16 atlfs systemd: Stopped
> /dev/disk/by-uuid/dc142de3-42a6-4793-aa2d-796c9fdcf588.
> Jun 16 12:31:16 atlfs systemd: Stopped /dev/disk/by-label/THURSDAY.
> Jun 16 12:31:16 atlfs systemd: Stopped
> /dev/disk/by-id/dm-uuid-CRYPT-LUKS1-0a647b12fce74745b6f78bfa3ffd56d8-THURSDAY.
> Jun 16 12:31:16 atlfs systemd: Stopped /dev/disk/by-id/dm-name-THURSDAY.
> Jun 16 12:31:16 atlfs systemd: Stopped /dev/dm-2.
> Jun 16 12:31:16 atlfs systemd: Stopped /sys/devices/virtual/block/dm-2.
> Jun 16 12:31:16 atlfs systemd: Stopped Cryptography Setup for THURSDAY.
>
> Jun 16 12:32:58 atlfs kernel: usb 2-2: new SuperSpeed USB device number
> 4 using xhci_hcd
> Jun 16 12:32:58 atlfs kernel: usb 2-2: New USB device found,
> idVendor=174c, idProduct=55aa
> Jun 16 12:32:58 atlfs kernel: usb 2-2: New USB device strings: Mfr=2,
> Product=3, SerialNumber=1
> Jun 16 12:32:58 atlfs kernel: usb 2-2: Product: ASM1053
> Jun 16 12:32:58 atlfs kernel: usb 2-2: Manufacturer: Asmedia
> Jun 16 12:32:58 atlfs kernel: usb 2-2: SerialNumber: 0123456789ABCDEF0124
> Jun 16 12:32:58 atlfs kernel: usb-storage 2-2:1.0: USB Mass Storage
> device detected
> Jun 16 12:32:58 atlfs kernel: usb-storage 2-2:1.0: Quirks match for vid
> 174c pid 55aa: 400000
> Jun 16 12:32:58 atlfs kernel: scsi host5: usb-storage 2-2:1.0
> Jun 16 12:32:58 atlfs mtp-probe: checking bus 2, device 4:
> "/sys/devices/pci0000:00/0000:00:02.0/0000:04:00.0/0000:05:00.0/0000:06:00.0/usb2/2-2"
> Jun 16 12:32:58 atlfs mtp-probe: bus: 2, device: 4 was not an MTP device
> Jun 16 12:32:59 atlfs kernel: scsi 5:0:0:0: Direct-Access ASMT
> 2105 0 PQ: 0 ANSI: 6
> Jun 16 12:32:59 atlfs kernel: sd 5:0:0:0: Attached scsi generic sg5 type 0
> Jun 16 12:33:11 atlfs kernel: sd 5:0:0:0: [sdd] 3907029168 512-byte
> logical blocks: (2.00 TB/1.81 TiB)
> Jun 16 12:33:11 atlfs kernel: sd 5:0:0:0: [sdd] Write Protect is off
> Jun 16 12:33:11 atlfs kernel: sd 5:0:0:0: [sdd] Write cache: enabled,
> read cache: enabled, doesn't support DPO or FUA
> Jun 16 12:33:11 atlfs kernel: sdd: unknown partition table
> Jun 16 12:33:11 atlfs kernel: sd 5:0:0:0: [sdd] Attached SCSI disk
> Jun 16 12:33:11 atlfs systemd: Device
> dev-disk-by\x2duuid-0a647b12\x2dfce7\x2d4745\x2db6f7\x2d8bfa3ffd56d8.device
> appeared twice with different sysfs paths
> /sys/devices/pci0000:00/0000:00:02.0/0000:04:00.0/0000:05:00.0/0000:06:00.0/usb2/2-2/2-2:1.0/host3/target3:0:0/3:0:0:0/block/sdd
> and
> /sys/devices/pci0000:00/0000:00:02.0/0000:04:00.0/0000:05:00.0/0000:06:00.0/usb2/2-2/2-2:1.0/host5/target5:0:0/5:0:0:0/block/sdd
>
>
> Even if I delete the duplicate target, it still keeps the original and
> adds a new one, incrementing the number each time. Restarting autofs
> does not help, but a reboot does.
>
> ed
>
> On Thu, Jun 16, 2016 at 1:17 PM, Phil Turmel <philip at turmel.org
> <mailto:philip at turmel.org>> wrote:
>
> On 06/16/2016 11:33 AM, Edward Holcroft wrote:
> > All,
> >
> > I am running USB HDD backups (encrypted with LUKS) on multiple CentOS 7
> > boxes using rsync. The drives get swapped out for each day of the week
> > and I use autofs to mount them. On some (not all) of these servers I
> > encounter an issue whereby the drive does not automount and shows has a
> > duplicate entry in messages:
> >
> > Jun 16 10:48:01 atlfs systemd: Device
> > dev-disk-by\x2duuid-0a647b12\x2dfce7\x2d4745\x2db6f7\x2d8bfa3ffd56d8.device
> > appeared twice with different sysfs paths
> > /sys/devices/pci0000:00/0000:00:02.0/0000:04:00.0/0000:05:00.0/0000:06:00.0/usb2/2-2/2-2:1.0/host5/target5:0:0/5:0:0:0/block/sdd
> > and
> > /sys/devices/pci0000:00/0000:00:02.0/0000:04:00.0/0000:05:00.0/0000:06:00.0/usb2/2-2/2-2:1.0/host92/target92:0:0/92:0:0:0/block/sdi
>
> So autofs isn't letting go. I don't know if that's a bug or if autofs
> was just never updated to handle devices going away. Is there a reason
> you have to use autofs? Could you not use a udev rule to trigger mount
> and backup and then have an explicit unmount after backup is done?
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org <mailto:Ale at ale.org>
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>
>
>
>
> --
>
>
>
>
> _________________________________________
>
> *Edward O. Holcroft*
> IT Operations Manager
>
> *Madsen, Kneppers & Associates, Inc.*
> Construction Consultants & Engineers
> 11695 Johns Creek Parkway, Suite 250
> Johns Creek, GA 30097
>
> *O*770.446.9606 <tel:770.446.9606> | *F*770.446.9612 <tel:770.446.9612>
> | *C*770.630.0949 <tel:770.630.0949> | eholcroft at mkainc.com
> <mailto:eholcroft at mkainc.com>
>
> www.mkainc.com <http://www.mkainc.com>
>
> MADSEN, KNEPPERS & ASSOCIATES USA, MKA Canada Inc.
> WARNING/CONFIDENTIALITY NOTICE: This message may be confidential and/or
> privileged. If you are not the intended recipient, please notify the
> sender immediately then delete it - you should not copy or use it for
> any purpose or disclose its content to any other person. Internet
> communications are not secure. You should scan this message and any
> attachments for viruses. Any unauthorized use or interception of this
> e-mail is illegal.
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org <mailto:Ale at ale.org>
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org <mailto:Ale at ale.org>
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>
>
>
>
> --
>
>
>
>
> _________________________________________
>
> *Edward O. Holcroft*
> IT Operations Manager
>
> *Madsen, Kneppers & Associates, Inc.*
> Construction Consultants & Engineers
> 11695 Johns Creek Parkway, Suite 250
> Johns Creek, GA 30097
>
> *O*770.446.9606 <tel:770.446.9606> | *F*770.446.9612 <tel:770.446.9612> |
> *C*770.630.0949 <tel:770.630.0949> | eholcroft at mkainc.com
> <mailto:eholcroft at mkainc.com>
>
> www.mkainc.com <http://www.mkainc.com>
>
> MADSEN, KNEPPERS & ASSOCIATES USA, MKA Canada Inc. WARNING/CONFIDENTIALITY
> NOTICE: This message may be confidential and/or privileged. If you are not the
> intended recipient, please notify the sender immediately then delete it - you
> should not copy or use it for any purpose or disclose its content to any other
> person. Internet communications are not secure. You should scan this message and
> any attachments for viruses. Any unauthorized use or interception of this e-mail
> is illegal.
>
>
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>
More information about the Ale
mailing list