Quote:
Originally Posted by rynax
here's the AFTER FIX working state of the Kindle Touch:
Code:
[root@[192_168_15_244] root]# df -h
Filesystem Size Used Available Use% Mounted on
/dev/root 62.2M 53.5M 5.5M 91% /
tmpfs 124.9M 4.0K 124.9M 0% /dev
tmpfs 124.9M 0 124.9M 0% /dev/shm
/dev/mmcblk0p3 31.0M 12.4M 17.0M 42% /var/local
fsp 3.2G 299.4M 2.9G 9% /mnt/us
/dev/loop/0 3.2G 299.4M 2.9G 9% /mnt/base-us
BEFORE THE FIX, there was no fsp nor /dev/loop/0 mounted at all. So I wasn't able to use the mmcblk0p1.img on the Kindle I copied over via USB for dd purpose, and there's not enough space for transferring mmcblk0p1.img(358MB) via SCP to anywhere(only 124.9MB~).
So I can't do this step:
So how I fixed it?
Lucky enough, the main partition was not broken, by just doing the following step, it fixed my Kindle Touch:
My question is, what could causing the fsp part won't be mounted under diags mode?
If the main partition was broken, and the fsp part can't be mounted, then the kindle can not be restored using this diags mode method?
Another question is, what you do would fill up/break the /var/local ? It has only 31MB and half of it has been filled up, it seems it's very easy to be fed up and brick the Kindle. Know why Linux is so week on this part? One of my NAS filled up the partition with log files and it can't boot at all to even let me clear the logs. |
That df listing looks a lot like you are running the "diags" partition (which you should be, if intending to update the "main" partition).
Your machine is a "dual boot" machine. The two system are not the same, nor even close to the same size.
Try instead:
cat /proc/partitions
Which will show kernel recognized partitions (as devices) even if not mounted.
- - - -
The usual cause of filling up /var/local (which is the file system on /dev/mmcblk0p3) is book indexes (indices). Index fewer books. The "too small" /dev/mmcblk0p3 partition was a lab126 design decision.
- - - -
Your NAS can probably be put back into service, but you will probably need a to use the serial (kernel operator console) port to do it.
Plus, on something that "runs forever" your syslog configuration and log rotation configuration needs to be setup for that usage so that the current fill-up does not happen.
You should also suspect something different or additional wrong with your NAS - lack of space for log files (or even utmp) should not prevent it from booting.