Quote:
Originally Posted by knc1
The last time (a long time ago), twobob and I worked on his (wife's) DXG -
I don't think we thought to check (the DXG uses multiple storage devices) but just used 4096 in our scripting.
|
Actually, I have only made my own backups and have never used those backups to restore the partition. I just use the image to keep as a record and use to explore the past setups. I typically use:
mount -t ext3 -o loop rootfs.img /mnt/kindle-image
The requirements for using the rootfs.img to flash the kindle might be totally different for all I know and might cause a brick if not done properly so I think this is an important topic.
I have been looking at Yifan Lu's original kindleupdater.zip and the way he made the backup of the rootfs and found he used bs=1024 for some reason. I wonder if that was selected as a divisor of the partition size. I worry that somebody might try to restore the partition and possibly overwrite data by accident.
The problem is even worse when writing the two kernel images to the mtdblocks. I expect those could easily overwrite an adjacent block if not done properly. There Yifan uses bs=131072 to calculate a block count. Fortunately, few people should be changing their DX kernels without Yifan's techniques.
When writing the rootfs to the mmcblk0p1 with the wrong size image, the excess might just result in an 'Out of Disk Space' error with the unwritten data and just being nulls anyway. That would be a best case so I hope anybody trying to restore from the rootfs images would check out these details first. I am now unwilling to experiment with my trusty DXG.