Unable to Format USB device with ext2

jrp13149 · 02-04-2014, 04:56 PM

I have been using unix/linux for almost 20 years, and never encountered this problem before, so some help would be appreciated.

I recently purchased a raspberry pi, and a 64gb USB memory stick.

I have no idea what was on the stick initially, I just plugged it in, and used dd to wipe the first 1mb of the device /dev/sdb.

I then used fdisk to create a new partition table, and first partition, and mkfs to format the partition as ext2.

When I tried mounting the partition, I got a bad superblock error.

I wiped the first 1mb again, and took the stick to a win7 machine, which immediately prompted me to format as fat32. Stick works perfectly in this mode. But when I plug it back into the pi, I get loads of error messages about corrupt partition table etc

Any thoughts, or questions? Suggestions for diagnostic commands I can run and post output?

Thanks,

Jeff.

ondoho · 02-05-2014, 01:20 AM

unfortunately, bombing the stick with dd would have been my first advice.
of course you can always try to wipe more than 1MB, or try different dd options (block size), but...
i recently had a conversation about something maybe related, take a look.

jrp13149 · 02-05-2014, 02:48 AM

Thanks for the comments. Do you think I might need to fill the whole stick with zeros? Is the dd block size important here? I used bs=1000 count=1000, to basically write 1000000 zeros. Should I be using bs=512 count=2000? Also, outputs from the system are attached. Even though there are no complaints during the process, fsck fails at the end.

Insights appreciated,

Jeff.

#sudo fdisk -l

Code:

Disk /dev/sdb: 67.1 GB, 67108864000 bytes
64 heads, 32 sectors/track, 64000 cylinders, total 131072000 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/sdb doesn't contain a valid partition table

It's means to be a 64Gb stick - a little odd that it shows up as 67.1, but lets run fdisk:

#sudo fdisk /dev/sdb

Code:

Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
Building a new DOS disklabel with disk identifier 0x97f870d5.
Changes will remain in memory only, until you decide to write them.
After that, of course, the previous content won't be recoverable.

Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)

Not sure what to make of the statement about partitition table 4, but lets carry on and make a new partition:

Code:

Command (m for help): n
Partition type:
   p   primary (0 primary, 0 extended, 4 free)
   e   extended
Select (default p): p
Partition number (1-4, default 1):
Using default value 1
First sector (2048-131071999, default 2048):
Using default value 2048
Last sector, +sectors or +size{K,M,G} (2048-131071999, default 131071999):
Using default value 131071999

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.

run fdisk -l again:

Code:

Disk /dev/sdb: 67.1 GB, 67108864000 bytes
64 heads, 32 sectors/track, 64000 cylinders, total 131072000 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x97f870d5

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1            2048   131071999    65534976   83  Linux

and make file system on stick:

# sudo mkfs -t ext2 /dev/sdb1

Code:

mke2fs 1.42.5 (29-Jul-2012)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
4096000 inodes, 16383744 blocks
819187 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=0
500 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
        4096000, 7962624, 11239424

Allocating group tables: done
Writing inode tables: done
Writing superblocks and filesystem accounting information: done

file system created - try fsck:

#sudo fsck /dev/sdb1

Code:

fsck from util-linux 2.20.1
e2fsck 1.42.5 (29-Jul-2012)
ext2fs_check_desc: Corrupt group descriptor: bad block for block bitmap
fsck.ext4: Group descriptors look bad... trying backup blocks...
fsck.ext4: Bad magic number in super-block while using the backup blocksfsck.ext4: going back to original superblock
Note: if several inode or block bitmap blocks or part
of the inode table require relocation, you may wish to try
running e2fsck with the '-b 32768' option first.  The problem
may lie only with the primary block group descriptors, and
the backup block group descriptors may be OK.

Block bitmap for group 1 is not in group.  (block 0)
Relocate<y>?

pan64 · 02-05-2014, 02:56 AM

do not fill the whole stick, erase a few kb should be enough. You can try to format it using your RPi. or try mkfs (on the whole device) without partitioning.

jrp13149 · 02-05-2014, 04:56 AM

Pan64 - tried formatting the whole device - again, process ran smoothly, but same errors regarding missing superblocks. It's like fdisk and mkfs are accessing the device on a different level from fsck and mount.

pan64 · 02-05-2014, 05:40 AM

looks like a damaged device

ondoho · 02-05-2014, 12:56 PM

make web searches on the error messages from the last output you posted.
those are very detailed error descriptions, you should be able to make sth out of them.
i wouldn't so easily discard a 64gb usb stick.
or maybe you have some warranty on it still? in which case i wouldn't tell them you formatted it with linux.

Prince Imhotep · 02-05-2014, 08:05 PM

Why don't you try and fill it with random data? this is what I usually do.

Code:

sudo dd if=/dev/urandom of=/dev/sdXY bs=50M & pid=$! && watch -n 1 --differences=cumulative sudo kill -USR1 $pid

And let it count for a couple of minutes, then see what happens.

Also you might want to use "cat" or "shred" instead of dd if you want to wipe larger ammounts of space.

If urandom is not fast enough -which is the case- you might want to use "frandom" kernel module.

Good luck.

rknichols · 02-05-2014, 08:55 PM

Quote:

Originally Posted by Prince Imhotep

Why don't you try and fill it with random data? this is what I usually do.

The problem seems to be that data does not read back as written rather than I/O errors occuring during the write process. If you fill the device with random data, it's going to be awfully hard to know whether the data you read back later is what was written.

Here's a suggestion. Fill the device with encrypted zeros; then see if decrypted zeros can be read back.

Code:

echo blahblah | cryptsetup --key-file=- create ztest /dev/sdXY
dd if=/dev/zero bs=32k of=/dev/mapper/ztest
cryptsetup remove ztest
echo blahblah | cryptsetup --key-file=- create ztest /dev/sdXY
hexdump /dev/mapper/ztest
cryptsetup remove ztest

hexdump will helpfully squeeze out the repeated all-zero lines. Any other output indicates a bad device. Note that I closed and re-opened the encrypted container. That is to force reads to be done from the device rather than possibly being satisfied from the kernel's cache.

Note also that encrypting zeros is way faster than the kernel's random number generator.

jefro · 02-05-2014, 10:21 PM

Could try to format with ext3 and not use journal. See if that works.

Prince Imhotep · 02-06-2014, 11:54 AM

I have tried before to use zero filling an usb stick, I just remembered now

.
There seems to be some sort of hardware compression of data inside usb sticks, when I tried before to fill one with zeroes, dd reported segnificantly high write rates.

So I think the problem here is just the data that is transfered to usb device, is not necessarily written all to it

. And the same partition data that is on the device is still there, not replaced by zeroes. This is why when I low level format any usb device, I usually use quality random data, that is incompressable random data.

Hope this helps.