Wiki Resources

Sponsored Links

This article is preliminary. If you have additional information, or wish to comment, please do so by adding to the end of this article. The author will update the body to reflect changes, incorporate feedback, provide clarification, etc.

2008.04.18 - comment by bluebear:
For another possible solution of this problem also see:
FAQ.CannotFormat

A fairly common failure mode is the inability to format a device from the Linksys Web GUI.

Normally this would not be a big problem, as on most Linux-based systems one would
simply go ahead and perform the operation manually. However, it is not currently
possible to do so with Unslung 6.8-beta (and earlier), for several reasons.

This article (currently) describes one failure mode, and a work-around for that
failure. The precise nature of the failure is unknown, so we currently have no
good way to know how many formatting failure scenarios this workaround may fix.
This article describes a known reproducible failure mode, and a workaround.

While this document describes an example involving the use of a specific flash device, it is almost certain that this failure, and the workaround herein, affects many other types of devices. Give this procedure a try, and if it works (or even if it doesn't) please add your notes to the end of this article to share your findings. Perhaps with enough feedback we'll be able to better understand the precise nature of this problem, and how to better work around it.

Failure Symptoms

The reproducible cases for this failure include the use of a specific hardware device
(The 1.0GByte Sandisk Mini Cruzer flash device).

Starting from booting up a just-flashed NSLU2 with a fresh copy of the Unslung 6.8-beta
firmware, the user follows the standard procedure to enable telnet, and telnet into
the device. Having read the appropriate documentation, the user then plugs the storage
device into the selected USB port (either one, the failure is the same, although the logs
and examples below will all assume USB Port 2). The flash device is correctly identified
by the firmware, and the Linksys Web GUI Disk Management screen displays the status as
"Formatted (FAT16/32)".

The user then begins the formatting procedure from the Web GUI in the normal fashion.
The GUI changes to reflect the state of the disk to be "Formatting". After a time,
the state returns to "Formatted (FAT16/32)" -- clearly not what was expected (it should
read "Formatted (EXT3)" if it was successfully formatted).

Preliminary Diagnosis

At this point, repeated attempts to format the device will fail. Placing the USB device
in a Windows system will show that it is partitioned into three partitions, of the correct
sized (the second and third partitions are each 128MBytes in size, and the first partition
makes up the balance of the device).

Confirming the Problem

The problem, in this specific instance, is that the first file system on the device
is corrupted during the creation process. This can be easily verified as follows.
Immediately after the failed format attempt, execute the following command in the
telnet session:

Note the presence of the text indicating that the filesystem was corrupted. (Advanced
users can also use the "e2fsck -f /dev/sda1" utility to perform a file-system integrity
check on the suspect device; the utility will find a number of corruption problems.)

Identifying the Hardware

Use the command below to identify the hardware in use. The example below identifies
one flash device known to fail in this manner (field reports indicate that the revision
0.1 devices have also been known to fail).

# dmesg | grep Vendor

Vendor: SanDisk Model: Cruzer Mini Rev: 0.2
#

Workaround

The failure occurs in the actual utility that writes the empty filesystem onto the
newly-partitioned device, in the middle of the Linksys Web GUI process. We cannot
alter the Linksys code, but we can replace the utility in question with a
simple shell script that fixes the problem and calls the original utility, all
transparent to the Linksys Web GUI code.

You must have an NSLU2 that has not been unslung already; if you have previously unslung
the device (successfully executing the unsling command on that NSLU2, regardless of
which disk or flash device you used), you must reflash the firmware to start afresh.
NOTE: you can't use the web utility to reflash!

Warning! You must enter the commands below exactly as you see them, character for character. Every character is significant, and altering even one of them may cause this procedure to fail, requiring that you reflash the NSLU2 and start over. Use extreme care.

The procedure below moves the original Linksys utility aside (renaming it with a
".orig" suffix), then writes a short shell script to replace it.

Test your work by running the utility with a bogus device name. You should
observe the same error message shown in the example, and you should see the
existence of the empty (size of zero) log file. If you don't, go back to the
previous step, and try again. If this is the second time or more that you've
not managed to get the identical results as below, a good way to verify your
work is to have someone else read the text to you as you type it, and verify
that you are typing it correctly. If you cannot get the same results as below,
do not proceed. It will fail.

# /usr/bin/mkfs.ext3 -m 1 /dev/fooey

mke2fs 1.34 (25-Jul-2003)
Could not stat /dev/fooey --- No such file or directory
The device apparently does not exist; did you specify it correctly?

# ls -l /tmp/mkfs.log

-rw-r--r-- 1 root root 0 Jun 11 08:27 /tmp/mkfs.log
#

Verifying that the Workaround Works

No reboots are necessary. If you followed the process above to confirm the
problem, then created the script, and tested it as described above, you can
simply proceed. If you rebooted, no problem -- just make sure that you have
enabled telnet, are telnet'd in, and have the device plugged in.

Go to the appropriate Linksys Web GUI page, and format the device. This time
the format should succeed.

Confirm this using the "dmesg" command, as illustrated below, and ensure that
the final messages appear as they do in the example here. Then use the "mount"
command to verify that /dev/sda1 and /dev/sda2 are mounted, as illustrated below.

If all is well, proceed with the "unsling" command as documented in the README
file.

Technical Notes:

This workaround probably has some folks scratching their head wondering how the workaround
is any different from the original. The documentation clearly states that if mke2fs is
invoked via mkfs.ext3 (which is a symbolic link to mke2fs), it is equivalent to invoking
mke2fs -j -- which is exactly what the shell script workaround is doing.

That's correct -- but that's not what "fixes" this issue. In fact, the magical item that
makes it work is the redirection (!) of STDOUT. Lacking the redirection to /tmp/mkfs.log,
the script fails in exactly the same manner as the original symbolic link.

An interesting hint to the nature of the problem can be obtained by piping the output from
e2mkfs to tee instead of redirecting it to the log file:

/usr/bin/e2mkfs -j $@ | tee /tmp/mkfs.log

Doing this will also solve the problem (it seems that e2mkfs doesn't care where it's
STDOUT is directed, just somewhere other than where it's directed by the Linksys code
(utility.cgi) that is invoking it). However, the log file will contain two copies of
the log information -- each character will be doubled up. This implies that the tee
command (which is supposed to send a copy of its STDIN to its STDOUT and another copy
to the named file) is having some troubles with its STDOUT, and ends up sending both
streams of data to the named file.

It raises some interesting questions about the nature of a number of the failures
observed with the Linksys code, and if they all may have in common the same strange
settings as it relates to STDOUT. How to investigate this further, and how to
ultimately resolve this, is yet to be figured out. Bright people with bright
ideas are welcomed to experiment, and add their observations to this article, in the
section below!

Comments/Feedback Below:

After an attempt to recover a forgotten password on a successfully unslung slug, involving playing with passwd file before adequate reading of the wiki, I ended up with a memory stick (1 gig Jet 10) now not recognised, wouldn't format ( the web page indicated 'formatted', no fs indicated, but the log showed 'format failed'). I reflashed (after learning i can't use the web utility once unslung!) The web utility then successfully reformatted to ext3, and i then successfully unslung. Theory: after flashing with unslung originally, I loaded 'ftp-topfield' (no external disk). This fits, but only just. I then decided I wanted to load more packages, and added a flash drive and finished unslinging. Perhaps there was now insufficient space to allow format to run without the unslung external disk. anyway, thanks for the wiki!
- update. didnt work after all. The newly formatted disk would hang the slug as soon as it was plugged in. I've now followed the complete script, and am apparently unslinging successfully...

2007-09-29 Problem also seen with Lexar Jumpdrive 2.0 Pro 256 MB.

2007-11-20 I encountered this problem with my new Maxtor onetouch III 500 GB drive. Inspired by this forum post, I tried to delete the file system, that had been created. This did the trick, and I could then format the drive using the Web interface.

2008-08-04 I encountered the same problem but instead of following all those suggestions I just downloaded the Partition Manager (30 day trial) and formatted the USB device on a windows machine with the ext3 format. After that I connected the USB drive to the slug again and formatted it again through the web interface of the Slug. After that the Slug was recognizing and formatting the USB stick correctly. That was nice and easy and took only 10 minutes.