The following a troubleshooting steps you can follow (as root) to identify the problem
After attemping the diversion scripts mentioned below one thing to note is that the mounting procedure is dependent on the order in which the devices are connected to your USB hub. You should connect the hard drive you want to use in the first port of the USB hub and then everything else. If that doesn't work try the last since it may be mounting drives from last to first instead!
The source of many of these cases have now been found.
When running 3.17 (and maybe also 3.16) the startup script malfunctions if the file /opt/sbin/insmod (which is a symbolic link to /opt/bin/busybox) is present. Just delete this link (if you really want to run this version of BusyBox insmod later, you can do that by writing "busybox insmod"). After deleting the link, just reboot and your drive should again be recognized as formatted and your shares available.
If this does not work for you and your drive was marked as "Not formatted" and not as "Not installed", you can still benefit from the old workarounds below. If these work but not the simple deletion of /opt/sbin/insmod, please notify on IRC.
I checked HD1? with 'fsck.ext3 -y -f /dev/sda1' (if not -y, too many questions asked to confirm), after that HD1? didn't want to mount anymore. First fsck gave tons of problems that were fixed by using -y switch. Previous fsck was also done manually (shutdown, disconnect HD, boot, logon, connect HD, umount, fsck) about two weeks ago, also giving plenty of things fixed.
After checking output from the first fsck, noticed that journal was removed (partition downgraded from ext3 to ext2 ?). Moved HD to a linux box, and run
tune2fs -j /dev/sda1
Reconnected HD back to slug, and it boots fine now.
Just wonder, how many people have problems with failing HDs?, corrupted data, not-formatted-conditions, etc. Looking at this page, and mailing lists, not much help is provided for such problems. Not being able to fsck HDs? that are unslung (through the web, or scheduler) is not helping as well.
Having no access to your NSLU2 no more? Can't find your NSLU2-harddrive in the net anymore? Then this is the place to be..
1. Shut the NSLU2 down.
2. Switch USB-HDD off or disconnect it.
3. Turn NSLU2 on.
4. Enable Telnet (e.g. via http://192.168.1.77:/Management/telnet.cgi)
5. Telnet into NSLU2 with root/uNSLUng login/password.
6. Type 'sh' (not necessary, just more comfortable)
7. Type 'mount -t ext3 /dev/sda1 /mnt/tmpmnt'.
8. Type 'ls /mnt/tmpmnt'. So now you (hopefully) see your data.
9. Type 'df' is there sda1? no? then we have a problem, we are still working on...solution here hopefully soon. at least you can backup your data now.
Sometimes steps 4-9 isn't needed. Just have the drives disconnected on boot and connect them later. USB_Detect will se them and mount them. Go figure.
I have symptoms similar to those described here. I have an unslung 5.x box which was working fine until, during a heavy data transfer, the box stopped responding (even to pings). The box boots without the drive, but if I either boot it with the drive, or attach the drive after booting, the box becomes unresponsive (to pings and web access).
I can telnet into the box following a diskless boot, and when I then attach the drive, the box remains responsive, but the drive is not automounted. I ran fsck.ext3 on the drive, and it found one small problem, but fixed it. I can ls the drive, but even after multiple successful fscks, the problem remains.
Any ideas? --Pat / firstname.lastname@example.org
Preliminary workaround for this problem
Note: This will only work if the above solution works - you must be able to mount your data partition manually. Also, this solution can in theory be used to mount lots of different file systems on the slug and should be integrated with /etc/fstab, but this is a proof of concept.
The startup mounting and detection system in Unslung 3 is based on the Linksys utility /etc/rc.d/rc.bootbin for which not source code is availabale. To make the system boot and mount drives that rc.bootbin does not recognize, one solution is to make a replacement diversion script for rc.1 which does not use rc.bootbin. This means the following:
NOTE: Scripts below are testing quality at best. Also, I have no serial console so logging is done to HDD to check for problems. Lots of useless logging statements can be removed.
I had a problem where my drive showed up as "Not formatted". I formatted it and got no errors, and then tried to unsling to it. This didn't work, and at this point the drive still appeared as "Not formated" in the web interface. After first clearing the partition table (the drive was used for other things previously) and reformatting again, the problem went away.
To clear the partition table, do something like this (for Disk 1):
Another workaround for this problem
I've found that the sequence of applying power to the the drive and the NSLU2 helps me solve problems like this. First I switch on the NSLU2 and after a few seconds the drive.
I checked the hard disk 1 with
Some problems when running three times (killed, memory aborts) and the problems were fixed after rebooting the NSLU2.
I unslung 6.8 to a Hitachi 250GB Deskstor in port 1. When I later added another Hitachi disk to port 2, it wasn't formatting. In the end I put it on to an XP and did a quick format. Unplugged it put it back in port 2. Did a format again, but df only showed 80GB of space. Bad karma.
I plugged the drive into XP box. This showed the 80GB partition, plus 3 other partitions approximately 150MB each. I deleted all the partitions and then did a FULL FORMAT.
I powered the drive off, plugged the drive back in to port 2 and then switched on the drive. Using the web interface, the drive popped up in the disk pages. I then ran the format which worked :D