SOLVED - Can't format flash drive to ext4

[Maurice]

I'm having a bit of trouble formatting a 15gb usb drive to ext4. It will format to fat32 but when I try to reformat it to ext4 I find there are invalid blocks as shown below in Konsole --.

Calling ioctl() to re-read partition table.
Syncing disks.
[root@localhost maurice]# umount /dev/sdb1
umount: /dev/sdb1: not mounted  
[root@localhost maurice]# mkfs.vfat -F 32 /dev/sdb1
mkfs.vfat 3.0.12 (29 Oct 2011)
[root@localhost maurice]# mkfs.ext4 -F 32 /dev/sdb1
mke2fs 1.42 (29-Nov-2011)
mkfs.ext4: invalid blocks '/dev/sdb1' on device '32'
[root@localhost maurice]#

Can I find where the bad blocks are so that I can use part of the drive or does it mean the drive is stuffed?

Thanks for any help -- Maurice

[muungwana]

[root@localhost maurice]# mkfs.ext4 -F 32 /dev/sdb1

I think the "-F 32" option is the problem,ext4 does not have such an option,remove it and try again

[Maurice]

[root@localhost maurice]# mkfs.ext4 -F 32 /dev/sdb1

I think the "-F 32" option is the problem,ext4 does not have such an option,remove it and try again

My word, that was a fast reply muungwana - thanks. However, when I check the usb in gparted it showed the file system as "unknown". I've tried to format this drive for some time now and this is the result I always get

This is from the terminal again --

[root@localhost maurice]# mkfs.ext4 /dev/sdb1
mke2fs 1.42 (29-Nov-2011)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
979200 inodes, 3915520 blocks
195776 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4009754624
120 block groups
32768 blocks per group, 32768 fragments per group
8160 inodes per group
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200,36, 1605632, 2654208

Allocating group tables: done                       
Writing inode tables: done                           
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information done   

Seems OK but does it tell you anything? 

[muungwana]

those output seem to be fine,

what does this command give you?

blkid

[Maurice]

those output seem to be fine,

what does this command give you?

blkid

Doesn't seem to see it.

[root@localhost maurice]# blkid
/dev/sda2: UUID="982747b2-c94c-4d41-93c9-97a244e05b67" TYPE="ext4"
/dev/sda1: LABEL="Windows XP" UUID="46BCF4A0BCF48C25" TYPE="ntfs"
/dev/sda3: UUID="d2fe4391-da74-409c-867e-747a546803be" TYPE="ext4" LABEL="Empty"
/dev/sda4: UUID="f87d428b-7fcc-4c21-b2ae-0db31d973bb5" TYPE="ext4" LABEL="Backups"

[muungwana]

thats odd.

if you have gparted open then close it first.

what do these commands give you?let see if vfat stick.

mkfs.vfat -F 32 /dev/sdb1
blkid

[Maurice]

thats odd.

if you have gparted open then close it first.

what do these commands give you?let see if vfat stick.

mkfs.vfat -F 32 /dev/sdb1
blkid

[root@localhost maurice]# mkfs.vfat -F 32 /dev/sdb1
mkfs.vfat 3.0.12 (29 Oct 2011)
[root@localhost maurice]# blkid
/dev/sda2: UUID="982747b2-c94c-4d41-93c9-97a244e05b67" TYPE="ext4"
/dev/sda1: LABEL="Windows XP" UUID="46BCF4A0BCF48C25" TYPE="ntfs"
/dev/sda3: UUID="d2fe4391-da74-409c-867e-747a546803be" TYPE="ext4" LABEL="Empty"
/dev/sda4: UUID="f87d428b-7fcc-4c21-b2ae-0db31d973bb5" TYPE="ext4" LABEL="Backups"
/dev/sdb1: UUID="222E-3E95" TYPE="vfat" [/color][/b]

This partitions the drive with a valid fat32 again. But I want to clone my Minime on it, that's why I need an ext4 partition.

[muungwana]

what you are seeing does not make sense 

the drive should not care what file system you are putting on it,it should work with all or with none.

It could be that the device is going bad and you are seeing old fragments of vfat when you reput vfat.

try to first wipe it out and then try to add ext4,when it fail,add vfat again and check

wipe the device with:

dd if=/dev/zero of=/dev/sdb1

then add ext4 fs

mkfs.ext4 /dev/sdb1

them check with blkid to see if the fs sticked.If it still does not show then add vfat and then run blkid to see if it now show

[Xenaflux]

OK, I am putting my nose where it does not belongs....again 

With Gparted , is it not possible to go to <Devices> and create a new partition table (Dos ),
which will (should) wipe the device clean,
and then, take it from there  ?

Just wondering 

[Maurice]

what you are seeing does not make sense 

the drive should not care what file system you are putting on it,it should work with all or with none.

It could be that the device is going bad and you are seeing old fragments of vfat when you reput vfat.

try to first wipe it out and then try to add ext4,when it fail,add vfat again and check

wipe the device with:

dd if=/dev/zero of=/dev/sdb1

then add ext4 fs

mkfs.ext4 /dev/sdb1

them check with blkid to see if the fs sticked.If it still does not show then add vfat and then run blkid to see if it now show

Same result as before - "unknown" file system.

[Maurice]

OK, I am putting my nose where it does not belongs....again 

With Gparted , is it not possible to go to <Devices> and create a new partition table (Dos ),
which will (should) wipe the device clean,
and then, take it from there  ?

Just wondering 

No go Xenaflux - already tried that.

[muungwana]

try a different file system,like ntfs or xfs or raiserfs and see if any one of them will stick

[Maurice]

try a different file system,like ntfs or xfs or raiserfs and see if any one of them will stick

Yes - Reiserfs did it.  I'll try installing Minime with Live USB Creator and let you know how I go


[root@localhost maurice]# mkfs.reiserfs /dev/sdb1
mkfs.reiserfs 3.6.19 (2003 www.namesys.com)
Guessing about desired format.. Kernel 3.2.18-pclos2.bfs is running.
Format 3.6 with standard journal
Count of blocks on the device: 3915520
Number of blocks consumed by mkreiserfs formatting process: 8331
Blocksize: 4096
Hash function used to sort names: "r5"
Journal Size 8193 blocks (first block 18)
Journal Max transaction length 1024
inode generation number: 0
UUID: f8d18a3f-da2d-445c-8a0b-b10367af58a1
ATTENTION: YOU SHOULD REBOOT AFTER FDISK!
        ALL DATA WILL BE LOST ON '/dev/sdb1'!
Continue (y/n):y
Initializing journal - 0%....20%....40%....60%....80%....100%
Syncing..ok

Tell your friends to use a kernel based on 2.4.18 or later, and especially not a
kernel based on 2.4.9, when you use reiserFS. Have fun.

ReiserFS is successfully created on /dev/sdb1.
[root@localhost maurice]# [3~6~

[Maurice]

No - didn't work. The USB Creator stresses that it must be a Linux ext partition (type #83).

Ah well - back to the drawing board (actually it's turning out to be a grindstone)

Many thanks for all your help muungwana - and Zenaflux.

Maurice

[Just17]

Are you unplugging the drive from the PC after reformatting and then plugging it back in again ?

Have you tried ext2 and ext3 formats?