Something trying to access beyond end of FAT partition

ordealbyfire83 · 06-17-2021, 09:29 PM

I have a USB GPS with internal flash memory formatted as FAT-16 used for storing logs. But when I try to retrieve the logs, I cannot actually open the files properly. Pluma complains that it cannot detect the encoding. Vim opens the file just fine but the last ~10% of the file or so is gibberish.

dmesg | tail shows

Code:

[496127.507796] sdb1: rw=0, want=15329, limit=15312
[496127.507801] Buffer I/O error on dev sdb1, logical block 15328, async page read
[496127.507805] attempt to access beyond end of device
[496127.507810] sdb1: rw=0, want=15332, limit=15312
[496127.507815] Buffer I/O error on dev sdb1, logical block 15331, async page read
[496127.507819] attempt to access beyond end of device
[496127.507824] sdb1: rw=0, want=15333, limit=15312
[496127.507828] Buffer I/O error on dev sdb1, logical block 15332, async page read
[496127.507909] attempt to access beyond end of device
[496127.507915] sdb1: rw=0, want=15418, limit=15312

And fdisk shows this:

Quote:

Disk /dev/sdb: 7.5 MiB, 7839744 bytes, 15312 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
Disklabel type: dos
Disk identifier: 0x00000000

Device Boot Start End Sectors Size Id Type
/dev/sdb1 63 15311 15249 7.5M 4 FAT16 <32M

It looks to me like the partition fits where it should, so where is the problem? Does the GPS in firmware think it has more storage than it does? These log files are only several hundred KB's with a few MB's free, so I'm not even close to being full. Any ideas?

chrism01 · 06-18-2021, 12:52 AM

This

Code:

Max. volume size	FAT12: 32 MB (256 MB for 64 KB clusters) 
                        FAT16: 2 GB (4 GB for 64 KB clusters) 
                        FAT32: 2 TB (16 TB for 4 KB sectors)

?

syg00 · 06-18-2021, 01:20 AM

That error often means the filesystem is larger than the partition . What does "df -hT" show.

ordealbyfire83 · 06-18-2021, 10:06 AM

I just copied something into here as a test, so it's almost full now. df -hT gives

Code:

/dev/sdb1         vfat      7.8M  7.4M  451K  95% /media/gps

But there's also this:

Code:

<username>@<hostname>:~$ sudo fsck.vfat -vVn /dev/sdb1
[sudo] password for <username>: 
fsck.fat 3.0.28 (2015-05-16)
Checking we can access the last sector of the filesystem
Seek to 8355328:Invalid argument

Not sure what to make of it.

computersavvy · 06-18-2021, 07:53 PM

Quite simply, I would verify the flash is actually 8 MB as shown by fdisk.
Then I would backup the data on it, reformat it, then put whatever is needed back on.

It looks like the fat table has gotten corrupted so the drive was written to by a file too large to fit and the fat table did not catch the actual end of the device. Or the weaknesses of the fat table have struck where the file structure is not properly followed due to severe fragmentation.

jefro · 06-18-2021, 10:04 PM

I agree with the others for ideas.

Guess a damaged flash or issue with controller could also be to blame.

sudo dosfsck -w -r -l -a -v -t /dev/sdc1

https://askubuntu.com/questions/1472...32-file-system

ordealbyfire83 · 06-21-2021, 10:45 PM

I opted to make a 'dd' back up of the partition and reformat. I'm not too sure about using mkfs.vfat for small fat16 partitions (fdisk type 4) as it seems there are some bugs. So I formatted in a Windows 2000 VM. Once I powered on the GPS, it started regenerating all sorts of log files even from before I bought it (it was used). Fortunately, I was able to get a new copy of my last corrupted log file.

It seems there is another (hidden) partition where the raw data is stored. The manual gives no indication of how to clear it, as now it claims that the free space has dropped rapidly since recreating the FAT partition. I thought before that this indicator referred to the FAT partition, but clearly not. I filed a ticket with the manufacturer for support but have yet to get a reply.

sundialsvcs · 06-22-2021, 10:44 AM

I'd say that either the filesystem is larger than the partition, or there's an error somewhere in the FAT ... something that contains a disk location which does not exist. fsck should be your first diagnostic step.

ordealbyfire83 · 06-29-2021, 10:36 PM

Turns out this device keeps its logs cached forever more in a separate, hidden partition that isn't accessible over the USB cable. And as you use it more, the cache fills up. Apparently you can only clear this cache using the manufacturer's iOS app - and you're totally out of luck if you don't have the latest model i-gadget. It's no wonder I got this so cheap, as the previous owner claimed to be "totally fed up" with it.

Anyone else with a Bad Elf Pro+ have any success on clearing this by some other means?

Just an aside, this GPS is not the least bit transparent on how it calculates its accuracy measurements. Likewise the NMEA sequences alternate between GPS and GLONASS rather than putting them together, as does the Garmin GLO. So if you use gpsd + xgps you will have difficulty maintaining a fix, but you will be able to get a more clear picture of what kind of accuracy you're getting. If you take 30 elevation readings from a Garmin GLO at random times over a week from the same location and plot them with error bars and calculate a weighted average, the average reading (with error bar) will pass through almost all of the other readings, with only a couple outliers. In contrast, practically everything with the Bad Elf is an outlier. Yet the weighted averages are very close to that measured by the Garmin GLO. That likely shows that Bad Elf seriously overstates their accuracy claims.