4

I'm running Raspbian 7.4 on a Raspberry PI that has two USB storage devices connected to it. This Raspberry PI will remain running during a power failure because it has console cable connected to it that provides a continuous power source.

My problem is when my house experiences a power outage the Raspberry PI sees the USB storage device go away "USB disconnect" message is displayed, however when power is restored and the USB devices reconnect they are assigned new device names.

The issue is that mount shows the drives with their previous device names which no longer exist. At this point any attempt to access the drives using their mount point names fails with an I/O error. I have to manually umount and re-mount the drives.

I use the UUID of the drives in /etc/fstab to avoid having any issues with device names and to maintain consistency over how the drives are mounted to mount points.

Should I instead use udev rules to create a SYMLINK alias for each drive using the drive's unique serial number and change /etc/fstab to use these drive aliases instead of UUIDs for mounting?

The syslog below shows the drives going away and then coming back as sdc and sdd. They were sda and sdb prior to the power failure.

Of course I could just put the USB drives on a small UPS, which I will probably do anyway, but I would like to know the best way to handle this type of problem, namely having consistent USB disk device naming.

Dec 31 06:45:46 raspberrypi kernel: [8332934.611538] smsc95xx 1-1.1:1.0 eth0: link down
Dec 31 06:45:47 raspberrypi ifplugd(eth0)[27446]: Link beat lost.
Dec 31 06:45:48 raspberrypi kernel: [8332935.871532] usb 1-1.2.3: USB disconnect, device number 47
Dec 31 06:45:48 raspberrypi kernel: [8332936.048631] usb 1-1.2.4: USB disconnect, device number 48
Dec 31 06:45:57 raspberrypi ifplugd(eth0)[27446]: Executing '/etc/ifplugd/ifplugd.action eth0 down'.
Dec 31 06:45:57 raspberrypi ifplugd(eth0)[27446]: client: /sbin/ifdown: interface eth0 not configured
Dec 31 06:45:57 raspberrypi ifplugd(eth0)[27446]: Program executed successfully.
Dec 31 06:46:22 raspberrypi kernel: [8332970.159145] usb 1-1.2.3: new high-speed USB device number 52 using dwc_otg
Dec 31 06:46:22 raspberrypi kernel: [8332970.176208] smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
Dec 31 06:46:22 raspberrypi kernel: [8332970.261060] usb 1-1.2.3: New USB device found, idVendor=0480, idProduct=d010
Dec 31 06:46:22 raspberrypi kernel: [8332970.261096] usb 1-1.2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Dec 31 06:46:22 raspberrypi kernel: [8332970.261111] usb 1-1.2.3: Product: External USB 3.0
Dec 31 06:46:22 raspberrypi kernel: [8332970.261128] usb 1-1.2.3: Manufacturer: TOSHIBA
Dec 31 06:46:22 raspberrypi kernel: [8332970.261142] usb 1-1.2.3: SerialNumber: 20131223xxxxxx
Dec 31 06:46:22 raspberrypi kernel: [8332970.267325] usb-storage 1-1.2.3:1.0: USB Mass Storage device detected
Dec 31 06:46:22 raspberrypi kernel: [8332970.268372] scsi16 : usb-storage 1-1.2.3:1.0
Dec 31 06:46:22 raspberrypi kernel: [8332970.509204] usb 1-1.2.4: new high-speed USB device number 53 using dwc_otg
Dec 31 06:46:22 raspberrypi kernel: [8332970.611100] usb 1-1.2.4: New USB device found, idVendor=0480, idProduct=d010
Dec 31 06:46:22 raspberrypi kernel: [8332970.611136] usb 1-1.2.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Dec 31 06:46:22 raspberrypi kernel: [8332970.611154] usb 1-1.2.4: Product: External USB 3.0
Dec 31 06:46:22 raspberrypi kernel: [8332970.611171] usb 1-1.2.4: Manufacturer: TOSHIBA
Dec 31 06:46:22 raspberrypi kernel: [8332970.611186] usb 1-1.2.4: SerialNumber: 20131223xxxxxx
Dec 31 06:46:22 raspberrypi kernel: [8332970.612810] usb-storage 1-1.2.4:1.0: USB Mass Storage device detected
Dec 31 06:46:22 raspberrypi kernel: [8332970.616236] scsi17 : usb-storage 1-1.2.4:1.0
Dec 31 06:46:23 raspberrypi ifplugd(eth0)[27446]: Link beat detected.

Dec 31 06:46:31 raspberrypi kernel: [8332979.800679] scsi 17:0:0:0: Direct-Access     TOSHIBA  External USB 3.0 0201 PQ: 0 ANSI: 6
Dec 31 06:46:31 raspberrypi kernel: [8332979.803181] sd 17:0:0:0: Attached scsi generic sg0 type 0
Dec 31 06:46:31 raspberrypi kernel: [8332979.804978] sd 17:0:0:0: [sdc] Very big device. Trying to use READ CAPACITY(16).
Dec 31 06:46:32 raspberrypi kernel: [8332979.828186] sd 17:0:0:0: [sdc] 732566645 4096-byte logical blocks: (3.00 TB/2.72 TiB)
Dec 31 06:46:32 raspberrypi kernel: [8332979.828999] sd 17:0:0:0: [sdc] Write Protect is off
Dec 31 06:46:32 raspberrypi kernel: [8332979.829037] sd 17:0:0:0: [sdc] Mode Sense: 2b 00 00 00
Dec 31 06:46:32 raspberrypi kernel: [8332979.831227] sd 17:0:0:0: [sdc] Write cache: disabled, read cache: enabled, doesn't sup
port DPO or FUA
Dec 31 06:46:32 raspberrypi kernel: [8332979.834218] sd 17:0:0:0: [sdc] 732566645 4096-byte logical blocks: (3.00 TB/2.72 TiB)
Dec 31 06:46:32 raspberrypi kernel: [8332979.865016]  sdc: sdc1
Dec 31 06:46:32 raspberrypi kernel: [8332979.871007] sd 17:0:0:0: [sdc] 732566645 4096-byte logical blocks: (3.00 TB/2.72 TiB)
Dec 31 06:46:32 raspberrypi kernel: [8332979.872197] sd 17:0:0:0: [sdc] Attached SCSI disk
Dec 31 06:46:32 raspberrypi kernel: [8332980.064257] scsi 16:0:0:0: Direct-Access     TOSHIBA  External USB 3.0 0201 PQ: 0 ANSI: 6
Dec 31 06:46:32 raspberrypi kernel: [8332980.065680] sd 16:0:0:0: Attached scsi generic sg1 type 0
Dec 31 06:46:32 raspberrypi kernel: [8332980.067627] sd 16:0:0:0: [sdd] Very big device. Trying to use READ CAPACITY(16).
Dec 31 06:46:32 raspberrypi kernel: [8332980.092080] sd 16:0:0:0: [sdd] 732566645 4096-byte logical blocks: (3.00 TB/2.72 TiB)
Dec 31 06:46:32 raspberrypi kernel: [8332980.092708] sd 16:0:0:0: [sdd] Write Protect is off
  • I am having the same problem. Did you ever find a solution? – Alexander Garden Apr 12 '16 at 16:20
  • @AlexanderGarden unfortunately my solution was to put the external drives on a UPS to avoid the problem. – HeatfanJohn Apr 12 '16 at 18:41
  • Udev already creates symlinks in the various /dev/disk/by-* directories. It doesn't matter if you use those or the UUIDs, but never rely on /dev/sd* names staying the same across reboots/hibernation/power outage. That's why the symlinks exist. – dirkt Jan 21 '17 at 11:19
1

Your problem would be solved if both the Pi and the powered storage device were on a UPS.

This is a common problem with /media. It will take the assigned name and begin adding digits if it hasn't cleared its cache (usually requires a reboot) before you unplug then replug (or unpower then repower the storage device).


Conversely, one thing always remains constant: The USB connection to the (first) Arduino Nano is always named /dev/ttyUSB0 and the (first) USB connection to an Arduino Uno is /dev/ttyACM0 -- They just disappear when it is unplugged then come right back when replugged.

The only way to confuse them is if you have more than one of the same type (Nano or Uno) and you replug them in a different order than was done initially.

This only matters in the Arduino IDE on the Rpi because if you have more than one of the same type there is no way to tell them apart other than knowing the order which you used to plug them in.

If you forget, then close the IDE, unplug them, then use

ls /dev/tty*

repeatedly to watch what changes as you plug them back in.

Then you can restart the IDE and they'll show up as available ports.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.