Topic: N00b Alert: Odd erros when attampting to format 'new' NVMe

Hi there lovely people of the GParted forum!

I'm new here and apologies if I havn't seemed to do my research properly before posting - reason being I didn't really know what to search for so bear with me.

Long story short:
I had an NVMe that had gone completely haywire. I pretty much gave up on recovering anything and decided that if I could atleast wipe it and get a fresh format that could be ok . The original error leading me to wanting to format relates to some "Bad sectors" occouring and preventing me from booting into Ubuntu. Also when using a bootable USB I was unable run any reallocate-sector commands. Anyhow! I'm now trying to perform a good old format to erase everything and make one big FAT32 partition with the lovely Gparted. However this was easier said than done. After hanging in a frozen for ~20 minutes Gparted started moving and then interrupted the proccess. Ill mention the NVMe is only 2 months old and shouldn't have experienced any heat stress as far I can tell. I generated the following report, but I am honestly not able to interpret much from it. Any chance some format-wiz here would be able to hint me in the right direction?

GParted 0.32.0 --enable-libparted-dmraid --enable-online-resize

Libparted 3.2
Format /dev/sdb1 as fat32  00:00:01    ( ERROR )
calibrate /dev/sdb1  00:00:00    ( SUCCESS )
path: /dev/sdb1 (partition)
start: 2048
end: 1953523711
size: 1953521664 (931.51 GiB)
clear old file system signatures in /dev/sdb1  00:00:00    ( SUCCESS )
write 512.00 KiB of zeros at byte offset 0  00:00:00    ( SUCCESS )
write 4.00 KiB of zeros at byte offset 67108864  00:00:00    ( SUCCESS )
write 4.00 KiB of zeros at byte offset 274877906944  00:00:00    ( SUCCESS )
write 512.00 KiB of zeros at byte offset 1000202567680  00:00:00    ( SUCCESS )
write 4.00 KiB of zeros at byte offset 1000203026432  00:00:00    ( SUCCESS )
write 8.00 KiB of zeros at byte offset 1000203083776  00:00:00    ( SUCCESS )
flush operating system cache of /dev/sdb  00:00:00    ( SUCCESS )
set partition type on /dev/sdb1  00:00:00    ( SUCCESS )
new partition type: fat32
create new fat32 file system  00:00:01    ( ERROR )
mkfs.fat -F32 -v -I '/dev/sdb1'  00:00:01    ( ERROR )
mkfs.fat 4.1 (2017-01-24)
/dev/sdb1 has 255 heads and 63 sectors per track,
hidden sectors 0x0800;
logical sector size is 512,
using 0xf8 media descriptor, with 1953521664 sectors;
drive number 0x80;
filesystem has 2 32-bit FATs and 64 sectors per cluster.
FAT size is 238464 sectors, and provides 30516323 clusters.
There are 64 reserved sectors.
Volume ID is 95301b1d, no volume label.
mkfs.fat: failed whilst writing FAT


much love!


Re: N00b Alert: Odd erros when attampting to format 'new' NVMe

This filesystem size (931.51 GiB that is a 1-TB device) is within the specification of FAT32 that supports up to 2 TiB. I never did use it myself for partitions larger than 250-300 GB.
The FAT32 format is performed- by dosfstools. So, you need to have installed the respective package and libraries.

I'm not sure if this is related to any bug within dosfstools (mkfs.fat). I read several issues submitted to github concerning non-512 sector drives / 4K sector drives (SSDs are 4K).   

A proposed workaround would be to use the command line with the -s option to explicitly specify the cluster size. Nevertheless I see that GParted uses a 64-sector cluster size, that seems correct.

Did you try to apply another filesystem type? this could show eventual other problems, like hardware ones.
Taking as given that there are no hardware/connectivity problems, I would suggest some further ideas.

A good idea is very often to use the latest stable GParted Live CD or USB. It includes all dependencies and tool packages for the specific version. Actual version is 1.1.0-6

Try to re-partition the drive. In some cases it was helpful to erase the first some GB (5-10 GB) of the drive space with the dd command (be careful to select the right device).

Try to make a smaller FAT32 partition like 200-300 GiB to see if it works, and grow it next (although this isn't obvious, as smaller drives need a smaller cluster size).

*** It is highly recommended to backup any important files before doing resize/move operations. ***