Sylvander wrote:Code: Select all
# dmesg | tail -9
. . .
[ 5516.321762] FAT-fs (sdb1): bogus number of reserved sectors
[ 5516.321766] FAT-fs (sdb1): Can't find a valid FAT filesystem
OK, so this is what mount is choking on: "bogus number of reserved sectors".
If it is looking at the correct sector (by using the LBA fields, not the CHS fields) then this would indicate a formatting error, since the number of reserved sectors would be written to the first sector (the "boot sector") of the partition by the utility that created the FAT filesystem (mkdosfs).
I see that, last Sunday, TestDisk reported the number of reserved sectors (and all of the other values it found in the boot sector) as zero, which is certainly wrong. This was after you used gparted to re-format the partition and it failed, so its not too surprising that the boot sector was incorrect.
Based on reports from Monsie who "had problems with gparted in the past when it came to formatting a disk with Windows file systems," and from proebler's experience "where gparted could no longer be used to reformat a flash drive," this could certainly be attributed to a failing of gparted. Or, of course, it could be attributed to a failing of the flash drive itself.
I noticed that when you first tried to format it with gparted, you had success, and after you started having problems, gparted then failed to format successfully, as it had done previously. That sounds ominous.
But you formatted it again on Tuesday, using mkfs.vfat (which I think is usually a symlink to mkdosfs), and then again on Thursday, using mkdosfs, so good values should have been written to it. Unfortunately, the error message that was logged when you tried to mount the partition doesn't tell us the actual value that it considered bogus.
And my guess is that there are probably other bogus numbers, the "reserved sectors" value was just the first one encountered, so the mount operation quit when it saw that.
If you haven't yet tired of trying new things, you could try this command so we can see what's currently in the first half of your boot sector:
Code: Select all
dd if=/dev/sdb1 bs=256 skip=4096 count=1 2>/dev/null | hexdump -C
[CORRECTION, Mar-04: Sorry, the above command is wrong. The correct command is:
Code: Select all
dd if=/dev/sdb bs=256 skip=4096 count=1 2>/dev/null | hexdump -C
The skip offset I gave was from the start of the drive, not the partition, so I should have said "if=/dev/sda".]
Then to see what is in the first half of the sector that the CHS start field points to, in case mkdosfs believed the CHS numbers and put the boot sector there:
Code: Select all
dd if=/dev/sdb1 bs=256 skip=640 count=1 2>/dev/null | hexdump -C
[CORRECTION, Mar-04: Sorry, the above command is also wrong. The correct command is:
Code: Select all
dd if=/dev/sdb bs=256 skip=640 count=1 2>/dev/null | hexdump -C
The skip offset I gave was from the start of the drive, not the partition, so I should have said "if=/dev/sdb".]
Note that this time if=/dev/
sdb1 since we are looking at the partition, unlike the other day when we were looking at the drive so it was if=/dev/
sdb.
[CORRECTION, Mar-04: So the above paragraph is also wrong. Normally we would use /dev/sdb1 to read from the partition. But since your partition table has problems I wanted the command to ignore it, and use the desired offsets from the start of the drive, so I should have said "if=/dev/sdb". I thought I'd tested the command, but somehow I managed to confuse things. Sorry about that. (See my latest post: http://www.murga-linux.com/puppy/viewto ... 480#689480).]
The bs=256 lets us deal in half-sectors, and the LBA start field indicates that the first sector of the partition is at sector 2048 on the drive, so skip=4096 (half-sectors).
Likewise, the incorrect CHS start field indicates that the first sector of the partition is at sector 320, so skip=640 (half-sectors).
Sylvander wrote:I haven't been unplugging and re-plugging the Flash Drive.
Might this be why all my efforts come to naught?
.
No. Running "fdisk -l /dev/sdb" immediately after writing the partition table to the drive would show any changes you made if the write had worked. I only removed and reinserted my drive to be sure that the changes I saw were really getting written to the drive, and not just sitting in a buffer in RAM somewhere.
Thanks for attaching the TestDisk.log file. As well as the "CHS and LBA don't match" problem (for both "heads/cylinder" and "sect/track"), it showed (as mentioned above) that the boot sector of the partition wasn't created correctly.
Sylvander wrote:5. "Assuming that there is an LED on your flash drive, does it blink just after you use the write command in fdisk?"
No, it doesn't.
Not a good sign, eh?
No, it's not.
The fact that it has not been possible to write to the partition table is certainly troublesome. I am curious to see if you have any better luck with writing to it when you try deleting the partition from the table.
Do you remember if the LED blinked when running mkdosfs?
It will be interesting to see what is in the partition's boot sector, to see if there is any sign of it being formatted properly. If not, perhaps it is no longer possible to write to the partition either.
[Edited 2013-Mar-04 to add above corrections in red.]