OT: Garmin Edge 705 FAT recovery needed
Hi, This is slightly off-topic, but given that the gmapsupp.img is a FAT file system, someone on this list might know the answer. Around March 10, the internal file system in my Garmin Edge 705 could no longer be mounted by Linux. I was also unable to convert saved tracks into training runs, which I guess means that the Garmin firmware failed to read the file system as well. Also the base map (gmapbmap.img) failed to load. So, currently the Edge 705 is crippled in that I can see the gmapsupp.img that is on the SD card, but cannot save any tracks. I saved the entire 1GB image from the device to my computer. There is about 23 MB of nonzero data followed by zero bytes. The actual payload may be smaller. It looks like the "boot" sector and all of FAT1 and most of FAT2 are zeroed out. From two Edge 705 users, I got file system dumps. One is from a 512MB model and another is from a 1GB model. Both appear to be further from pristine condition than my file system. I have only created and deleted *.tcx files (saved GPS tracks) and a gupdate.gcd (firmware update). On a copy of my backup image, I already tried replacing the FATs from one of the other dumps, but every combination would cause some important files to be truncated by dosfsck. Because I do not know if there are any unit-specific data stored in the file system, I would like to fix with as small changes as possible. This would mean rewriting only the "boot" sector and the two FATs. Everything starting with the root directory (apparently it is a FAT16 created by mkdosfs) looks intact. Any hints? How could I use dff or some other tool to reconstruct the file allocation tables? Is there a good presentation of the FAT16 file allocation table format somewhere, so that I could try to interpret the tables in a hex editor? Or is there a Linux tool for visualizing or pretty-printing the file allocation tables? Marko
On Mar 21, 2011, at 20:27, Marko Mäkelä wrote:
Around March 10, the internal file system in my Garmin Edge 705 could no longer be mounted by Linux. I was also unable to convert saved tracks into training runs, which I guess means that the Garmin firmware failed to read the file system as well. Also the base map (gmapbmap.img) failed to load. So, currently the Edge 705 is crippled in that I can see the gmapsupp.img that is on the SD card, but cannot save any tracks.
I saved the entire 1GB image from the device to my computer. There is about 23 MB of nonzero data followed by zero bytes. The actual payload may be smaller. It looks like the "boot" sector and all of FAT1 and most of FAT2 are zeroed out.
I doubt that there's any vital unit-specific data stored on a removable SD card. It's possible to use the Edge without the card right? Regardless, since you've backed up the data, messing with the content of the SD card should be safe. So what I'd probably do in your situation is to try formatting the sd card with one FAT partition (some mkdosfs invocation), insert it, and expect the device to work as it used to. Is it possible that your SD card has failed? Presumably, you didn't get any errors when making that backup, but maybe a write error also causes the errors you've been seeing? Cheers Robert
On Mon, Mar 21, 2011 at 10:01:55PM +0100, Robert Vollmert wrote:
On Mar 21, 2011, at 20:27, Marko Mäkelä wrote:
Around March 10, the internal file system in my Garmin Edge 705 could no longer be mounted by Linux. I was also unable to convert saved tracks into training runs, which I guess means that the Garmin firmware failed to read the file system as well. Also the base map (gmapbmap.img) failed to load. So, currently the Edge 705 is crippled in that I can see the gmapsupp.img that is on the SD card, but cannot save any tracks.
I saved the entire 1GB image from the device to my computer. There is about 23 MB of nonzero data followed by zero bytes. The actual payload may be smaller. It looks like the "boot" sector and all of FAT1 and most of FAT2 are zeroed out.
I doubt that there's any vital unit-specific data stored on a removable SD card.
Please read again. It is the file system in the internal memory that has been corrupted, probably due to a bad write. The bad write would most likely be due to a bug in the Garmin firmware. The Edge 705 that I had before this warranty replacement (a button gone imprecise; I sent it in shortly before the 2-year European warranty expired, a few months ago) produced corrupted *.tcx files in the past, or it crashed when converting data from its internal binary storage format to the XML format. Marko
On Mon, Mar 21, 2011 at 09:27:09PM +0200, Marko Mäkelä wrote:
Any hints? How could I use dff or some other tool to reconstruct the file allocation tables? Is there a good presentation of the FAT16 file allocation table format somewhere, so that I could try to interpret the tables in a hex editor? Or is there a Linux tool for visualizing or pretty-printing the file allocation tables?
I found http://en.wikipedia.org/wiki/File_Allocation_Table to be a useful resource. It contains a table of the FAT entry values. I tried writing the FAT entries for gmapbmap.img last night, but the file appears to be heavily fragmented in the file system. I restored the first two 16-kilobyte clusters so far. So, today I tried to automate the FAT reconstruction. From a good file system dump, I extracted gmapbmap.img and got 16-byte strings that I could search for in my file system hexdump: unzip -p Garmin.zip gmapbmap.img|od -Ax -t x1| sed -ne 's/.*[048c]000 /[26ae]200: /p' > gmapbmap.img-data grep -f gmapbmap.img-data garmin-sdb.txt > gmapbmap.img-addr (my hexdump has a : after the address, but od does not write it) This almost worked. One 16-byte string was all zero, and it produced lots of matches. [26ae]200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 So, I replaced that line with another: [26ae]210: 20 5c df 22 01 01 4b e7 00 24 00 d3 16 00 00 62 After this, I verified that I have exactly one match for each pattern, that is, the md5sum of the sorted lines of the 16-byte hexdumps is the same, and that the patterns are unique: sed -e 's/.*: //'<gmapbmap.img-data|sort|uniq -d sed -e 's/.*: //'<gmapbmap.img-data|sort|md5sum sed -e 's/[0-9a-f]*: //;s/ : .*//'<gmapbmap.img-addr|sort|md5sum The next step is to create a map from image file offsets in gmapbmap.img-addr to file offsets in the real gmapbmap.img, to convert that to FAT cluster numbers, and to write the values to FAT1 and FAT2. Then, dosfsck should be happy with this file, and mtype from mtools should produce an identical copy of gmapbmap.img from the image. This is quite a bit of work, but as I do not know if the device would boot if the entire file system were rewritten in a different layout, I prefer to go through the trouble. Once I am finished, I will archive a compressed file system image. It should be less than 6 megabytes, after all. Marko
On Wed, Mar 23, 2011 at 10:36:51AM +0200, Marko Mäkelä wrote:
The next step is to create a map from image file offsets in gmapbmap.img-addr to file offsets in the real gmapbmap.img
I did that. It turns out that there is exactly one gap. The first cluster is at 0x3e200, the very first data cluster, and subsequent clustes are located from 0x4a200 onwards. My explanation for the gap is that Garmin wrote a single-cluster file to 0x3e200, then wrote some files and the Garmin subdirectory, and finally deleted that single-cluster file before writing Garmin\gmapbmap.img. I am sure that I have not deleted or rewritten the gmapbmap.img, and another image has gmapbmap.img starting in the very first data sector as well. Marko
participants (2)
-
Marko Mäkelä -
Robert Vollmert