Exploring the K1 scripts last night, that I previously archived as part of my backup procedure, I learned a few things. One was that I should always use full absolute paths (not relative such as "./script.sh", or even "sh script.sh"), as mentioned previously in this thread.
I also learned how to explore the unusual (for kindles) filesystem and flash storage. Here is a manual (PDF file) from Samsung, for those interested (this filesystem is common on Samsung smartphones):
http://pdfstream.manualsonline.com/b...1cf720b9eb.pdf
I added some code as used in K1 scripts to my "k1snoop" script. Here are the results:
Code:
cat /proc/rfs/bmlio
minor position size blocks id
1: 0x00000000-0x00180000 0x00180000 12 3
2: 0x00180000-0x00300000 0x00180000 12 17
3: 0x00300000-0x00480000 0x00180000 12 16
4: 0x00480000-0x005c0000 0x00140000 10 15
5: 0x005c0000-0x00700000 0x00140000 10 14
6: 0x00700000-0x01500000 0x00e00000 112 8
7: 0x01500000-0x02400000 0x00f00000 120 9
8: 0x02400000-0x03a00000 0x01600000 176 10
9: 0x03a00000-0x0fa00000 0x0c000000 1536 11
10: 0x0fa00000-0x0fa40000 0x00040000 2 4
(0) bad mapping information
No BadBlock RsvBlock
0: 1354 2006
0: OneNAND 256MB 1.8V
BML code : out
This information tells us a number of interesting things. One is that the flash block size is 0x2000 (128K) bytes. Another is that there is a bad block @ 1354 (which appears to be inside block device ID 11, the largest partition mounted as /mnt/us). The bad block contents on my specific onboard flash device were relocated to reserved block 2006. That suggests that whatever partition contains block 2006 (partition ID 3) is a reserved partition for bad flash block relocation by the sector translation layer (stl) filesystem driver. There are other small partitions of the same size, perhaps also reserved for special use by STL (including sector remapping metadata).
The only partitions normally mounted are for /mnt/us (rw,vfat,stl), / (ro,squashfs,blm), /mnt/dc (ro,squashfs,blm), and /opt (rw,ext3,stl). I was hoping one of them might be a diags partition, though for all I know now, some of them may contain boot kernels (and I saw potential evidence that one might be the initrd (initial RAM disk) used to boot the kernel. More investigations to follow.
The code that mounts /mnt/us is a LOT more complicated than that for newer kindles, with all sorts of management for both the raw block device and the sector translation layer, with a lot of processing going on to determine locations and sizes, with sane fallbacks for cases where not available (in cases where /mnt/us gets reformatted). This code also give hints about how I should be able to mount (or unmount) STL (sector translation layer) devices so I can get contiguous backups. Even though there is only one bad block on my device, it is likely that sectors were remapped for write wear-levelling, making the raw underlying block device images I now have a bit scrambled for my purposes. A number of the BML devices failed with "dd", and none of the STL devices could be backed up with "dd" (yet). Hopefully using some of that info (as posted above in this post) may help.
TTYL