view · edit · print · history

This article pertains to:

  • Unslung 6.8-beta only

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:

 # dmesg | tail
 sda: Write Protect is off
  /dev/scsi/host0/bus0/target0/lun0: p1 p2 p3
 Adding Swap: 127964k swap-space (priority -1)
 kjournald starting.  Commit interval 5 seconds
 EXT3 FS 2.4-0.9.19, 19 August 2002 on sd(8,2), internal journal
 EXT3-fs: mounted filesystem with ordered data mode.
 kjournald starting.  Commit interval 5 seconds
 EXT3-fs: corrupt root inode, run e2fsck
 kjournald starting.  Commit interval 5 seconds
 EXT3-fs: corrupt root inode, run e2fsck

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


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.

 # cd /usr/bin
 # ls -l /usr/bin/mkfs.ext3
 lrwxrwxrwx    1 root     root            6 Dec 31  1969 /usr/bin/mkfs.ext3 -> mke2fs
 # mv /usr/bin/mkfs.ext3 /usr/bin/mkfs.ext3.orig
 # echo '#!/bin/sh' >/usr/bin/mkfs.ext3
 # echo '/usr/bin/mke2fs -j $@ >/tmp/mkfs.log' >>/usr/bin/mkfs.ext3
 # chmod +x /usr/bin/mkfs.ext3
 # ls -l /usr/bin/mkfs.ext3
 -rwxr-xr-x    1 root     root           47 Jun 11 08:20 /usr/bin/mkfs.ext3
 # cat /usr/bin/mkfs.ext3
 /usr/bin/mke2fs -j $@ >/tmp/mkfs.log

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.

 # dmesg | tail
 kjournald starting.  Commit interval 5 seconds
 EXT3 FS 2.4-0.9.19, 19 August 2002 on sd(8,1), internal journal 
 EXT3-fs: mounted filesystem with ordered data mode.
 kjournald starting.  Commit interval 5 seconds
 EXT3 FS 2.4-0.9.19, 19 August 2002 on sd(8,1), internal journal
 EXT3-fs: mounted filesystem with ordered data mode.
 kjournald starting.  Commit interval 5 seconds
 EXT3 FS 2.4-0.9.19, 19 August 2002 on sd(8,2), internal journal
 EXT3-fs: mounted filesystem with ordered data mode.
 EXT3 FS 2.4-0.9.19, 19 August 2002 on sd(8,1), internal journal
 # mount
 /dev/mtdblock4 on / type jffs2 (rw)
 /proc on /proc type proc (rw)
 usbdevfs on /proc/bus/usb type usbdevfs (rw)
 /dev/mtdblock4 on /dev.state type jffs2 (rw)
 ramfs on /dev type ramfs (rw)
 /dev/mtdblock4 on /var.state type jffs2 (rw)
 ramfs on /var type ramfs (rw)
 none on /tmp type ramfs (rw)
 /dev/sda1 on /share/flash/data type ext3 (rw)
 /dev/sda2 on /share/flash/conf type ext3 (rw,sync)

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.

view · edit · print · history · Last edited by Rolf.
Based on work by bluebear, bouvin, Stan Sieler, russemailnu, and mwester.
Originally by mwester.
Page last modified on August 04, 2008, at 12:25 AM