Debian external disks – /dev/sda1 /dev/sdb1 randomly swapping

I ran into a funny problem recently with Ridge’s debian fileserver – I connected a second external USB drive to it and it stopped working! It always had one external USB drive connected, this was mapped to /dev/sda1 and auto-mounted in /etc/fstab along the lines of:


/dev/sda1    /mnt/usb   auto    rw    0       0


Everything was running nicely until I introduced a second usb device, this time a large flash disk onto which our automatic backup script is going to periodically dump an encrypted tarball (to provide an easy way for us to move encrypted backups off-site.)


Anyway, I saw that the second disk was mapped to /dev/sdb1 and I optimistically modified /etc/fstab to cater for the new flash disk along the lines of:


/dev/sda1    /mnt/usb   auto    rw    0       0
/dev/sdb1   /mnt/flash  vfat  rw,users,umask=0   0    0


So far so good, after reboot both file systems successfully mounted. But after the next reboot things were not as expected, the original disk was mounted onto the new ‘flash’ mount point and the FAT flash disk was not mounted at all!


With the second USB disk connected the way in which the disks were mapped to Linux devices would change randomly every time the system was rebooted – sometimes a disk would appear as /dev/sda1 and sometimes as /dev/sdb1.  As you can imagine this completely ruined the file system setup as configured in /etc/fstab!!


I had never encountered this before, but after a little research I found a work around – this involved mounting the disks by label rather than by the more traditional device name.


All labelled disks/volumes can be found in /dev/disk/by-label/ , these labels are static and can be used to mount their volumes (instead of using the non-static /dev/sda1 etc.).  Only labelled device appear in the by-label directory, so if you don’t see a disk you may have to give it a label using the tune2fs command. I had to give my original USB disk’s volume a label, I determined that it was currently mapped to /dev/sdb1 and issued the following command to label it as ‘external’:


tune2fs -L external /dev/sdb1


Now with both disks labelled I modified /etc/fstab as follows:


/dev/disk/by-label/external    /mnt/usb   auto    rw    0       0
/dev/disk/by-label/CORSAIR    /mnt/flash  vfat  rw,users,umask=0   0    0


And thankfully that fixed the problem! – with the IT systems purring along I can get back to the many more mundane aspects of running a software development consultancy…

Debian steps into the Breach as Linksys NSLU2 NAS Dies

Our Linksys NSLU2 NAS finally died after a long and protracted fight to keep it on its legs and serving.  It has been acting up for a month or two now and now simply refuses to boot unless there are no drives plugged in (that’s not much use!!), I have a feeling that I could probably get it up and running again with freshly formatted disks etc., but I couldn’t really be bothered as I have wasted far too much time on the thing already.


It is only two years old, and although it is a very useable and low cost NAS solution I think that due to the shocking manner of its demise I couldn’t possibly recommend that anybody uses it at all!  My opinion has been backed up by the people to whom I have since talked, their Linksys NSLU2s suffered very similar fates at eirily similar ages.


Anyway, as the attached disks are formatted as linux ext3 volumes I just plugged them into a spare mini-ITX ‘black box’ type PC that we had here and installed a very slim and cut-down version of Debian with Samba.  A few quick fsck’s later confirmed that there was no damage to the volumes (phew!) and in an hour or two the disks were back on the network and stable.  A very acceptable gratis stop-gap solution thanks to Debian and a spare PC!