Usb drive

From NAS-Central Buffalo - The Linkstation Wiki

USB Drive Problems

A USB drive attached to the linkstation (as purchased) will normally show up with a description under the USB Details area.

Sometimes you will be informed that the drive information cannot be acquired.

This will be the case if there is no drive attached. If there is a drive attached, this is probably due to badly dismounting the USB drive.

In some situations, however, the drive information will show, but the drive will not be available in the screen for formatting.

This is the situation I am encountering. I don't know the cause yet, but as I narrow down the possibilities I'll update this page to correct it. The questions facing me:

Are there any reasons a USB hard drive which has no problem attaching to a computer in Windows may not be available for formatting when attached to the rear port of the link station?

For example, are there

  1. compatibility issues with any hard drives?
  2. known issues?
  3. firmware upgrades to unlock functionality?
  4. issues related to the operating system on the USB drive?
  5. requirements that the USB drive be fresh formatted in Windows BEFORE attaching it to the
     LinkStation?
  6. Issues related to files ON the USB drive?

Bootable/Active Partition

On my stock Linkstation Pro LS-GL(v2) and my Linkstation Pro Duo, a USB drive failed to show up in the web interface. In my case, the drive already had a partition that was marked as active (boot), and this triggered a bug in the file /usr/local/bin/libbuffalo that stopped the hotplug script from recognising the filesystem ID number on an active partition. Notice the asterisk in the output of fdisk /dev/sdb below. The asterisk makes the ID value the 6th item in the row, rather than the 5th, and awk gets the blocks value instead of the filesystem ID:

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *           1       38913   312568641   83  Linux

The mount_usbdisk() function in libbuffalo will only attempt to mount partitions of certain IDs (NTFS, FAT16, FAT32, Ext2 and Ext3).

The simple fix was to turn off the active flag on the partition, and after a reboot (and probably a re-plug of the USB drive), the drive showed up. Ultimately, I patched the libbuffalo file and put it into a new initrd file so that it survived a reboot. The patch to libbuffalo is here:

*** /usr/local/bin/libbuffalo.bak      Fri Jul  4 16:08:30 2008
--- /usr/local/bin/libbuffalo  Wed Jan 26 11:47:13 2011
***************
*** 634,640 ****
       /sbin/fdisk -l /dev/$BASENAME >/tmp/fdisk_usb
       for minor in 1 2 3 4 5 6
       do
!              PART=`cat /tmp/fdisk_usb|grep ${BASENAME}p${minor}|awk '{print $5}'`
               echo "minor=$minor ($PART)" > /dev/null
               case "$PART" in
               "7")
--- 634,640 ----
       /sbin/fdisk -l /dev/$BASENAME >/tmp/fdisk_usb
       for minor in 1 2 3 4 5 6
       do
!              PART=`cat /tmp/fdisk_usb|grep ${BASENAME}p${minor}| { read LINE; set - ""$LINE; while [ "$3" ]; do shift; done; echo $1; }`
               echo "minor=$minor ($PART)" > /dev/null
               case "$PART" in
               "7")

Hotplug Bug on Linkstation Pro Duo

I found this bug on my Linkstation Pro Duo, but it might also exist on other models. I didn't see it on my Linkstation Pro (LS-GL).

The SCSI USB hotplug script /etc/hotplug.d/scsi_device/usb-buffalo.hotplug contains a bug whereby, under some kernel releases, a flawed command syntax attempts to get details about the newly added device. Instead of finding the device name from the SCSI device's directory name, the directory contents are listed, which breaks the logic. The patch to the usb-buffalo.hotplug file is here:

*** /etc/hotplug.d/scsi_device/usb-buffalo.hotplug.bak Fri Jul 18 10:57:49 2008
--- /etc/hotplug.d/scsi_device/usb-buffalo.hotplug     Wed Jan 26 11:09:01 2011
***************
*** 200,208 ****
       while read i
       do
               if [ `uname -r` = "2.6.16.16-arm1" ]; then
!                      DEVNAME=`ls /sys/class/scsi_device/$i:0:0:0/device/block:*|cut -d':' -f5`
               elif [ `uname -r` = "2.6.22.7" ] ; then
!                      DEVNAME=`ls /sys/class/scsi_device/$i:0:0:0/device/block:*|cut -d':' -f5`
               else
                       TMP=`cat /sys/class/scsi_device/$i:0:0:0/device/block/dev`
                       GetDevnameFromScsiBlockDev $TMP
--- 200,208 ----
       while read i
       do
               if [ `uname -r` = "2.6.16.16-arm1" ]; then
!                      DEVNAME=`ls -d /sys/class/scsi_device/$i:0:0:0/device/block:*|cut -d':' -f5`
               elif [ `uname -r` = "2.6.22.7" ] ; then
!                      DEVNAME=`ls -d /sys/class/scsi_device/$i:0:0:0/device/block:*|cut -d':' -f5`
               else
                       TMP=`cat /sys/class/scsi_device/$i:0:0:0/device/block/dev`
                       GetDevnameFromScsiBlockDev $TMP

I've only tested this patch on a 2.6.16.16-arm1 kernel. In fact, the problem might not even exist on 2.6.22.7 kernels. Feedback here would be gratefully accepted.

The usb-buffalo.hotplug file does not get replaced at boot time, so this patch doesn't need to be updated in initrd. Simply patch and re-plug.