Stuck at 3 dots

[tekknogenius]

Any other option besides reinstalling ermine?

My battery ran down, now I'm stuck at three dots. PE won't go any further. I may go ahead and create a serial cable so that I can see what is going on.

[ivanjt]

Originally Posted by tekknogenius

Any other option besides reinstalling ermine?

My battery ran down, now I'm stuck at three dots. PE won't go any further. I may go ahead and create a serial cable so that I can see what is going on.

The serial cable is most probably the best idea - at least you should find what stage the boot process is at and you should find what running out of power does, what doesn't get written back from memory.

BTW - battery size

[vicinc]

serial. maybe you are luckier than me. my second unit is doing the serial jobby fine.
just the first one is corrupted badly.

[tekknogenius]

Originally Posted by ivanjt

BTW - battery size

LOL I have not forgotten about it. I was waiting until I received the soldering iron in the mail before I open it up again (do not want to mess it up further LOL)

[ivanjt]

Originally Posted by tekknogenius

LOL I have not forgotten about it. I was waiting until I received the soldering iron in the mail before I open it up again (do not want to mess it up further LOL)

Good idea.

I'm too immersed in our working practices - once a machine is opened it doesn't get closed up again until the work is finished, we even have anti-static storage boxes to put them in if we have to wait for parts.

[vicinc]

The USB2Serial cable sellers own some business to entourage. chop, chop.

[tekknogenius]

Finally got my serial cable setup.

Seems to get stuck in the power management somehow. Log attached. Here's where it keeps looping...

[ 131.819490] init: sys_prop: mis-match msg size recieved: -1 expected: 128
[ 132.009725] kernel/power/earlysuspend.c at line 165: request_suspend_state new_statn
[ 132.018008] request_suspend_state: wakeup (0->0) at 132012673541 (2011-10-30 03:41
[ 132.030737] init: untracked pid 1442 exited

I wonder if I can somehow clear that...hmmm

[tekknogenius]

In reality, the PE is not stuck, meaning that from the serial connection I can access everything. I can run commands and what not. The problem is that the boot process fails prematurely therefore it does not go past the three dots. I can always do the update process but am trying to get the PE to proceed that way (since it seems to have happened to me more than once I'd like to figure out what is going on and possibly fix or prevent it the next time).

Anyone know the script it runs for the boot process? Is it the init.pxa168.rc?

[nikkie]

Hi Tekknogenius.
The first thing in your log indicating that there is a problem that does not also occur in other serial logs is this bit:

[ 12.965490] UBI error: ubi_io_read: error -74 while reading 516096 bytes from PEB 3s
[ 12.976857] UBIFS error (pid 1): ubifs_check_node: bad CRC: calculated 0x1cbf602a, a
[ 12.985859] UBIFS error (pid 1): ubifs_check_node: bad node at LEB 450:99392
[ 12.992947] UBIFS error (pid 1): ubifs_scanned_corruption: corruption at LEB 450:992
[ 13.009837] UBIFS error (pid 1): ubifs_recover_leb: LEB 450 scanning failed

The many errors after that seem related. It sounds like your file system is corrupted. I've noticed this device is more prone to disk corruption than other devices.

[tekknogenius]

Originally Posted by nikkie

Hi Tekknogenius.
The first thing in your log indicating that there is a problem that does not also occur in other serial logs is this bit:



The many errors after that seem related. It sounds like your file system is corrupted. I've noticed this device is more prone to disk corruption than other devices.

Thanks for the look. Funny thing is that I am able to execute commands manually. I can look through the file system fine. It seems to hang (obviously), but not sure where it blows (at what command). Perhaps if I have a good log I can see where it is blowing up and try to fix that. Like I said, this has happened to me before under similar circumstances (namely battery dies down to point of red blinking light) and I assume that it may be an issue with the PE in general running the beta ermine.

I'll give it another couple days of trying to revive it before I reflash the ermine. Maybe I can get the offending image portion updated manually. As shown below (and in your post) the /data portion is the portion in error:

[ 12.402854] init: do_mount: calling mount: dev ubi:userdata dir /data s ubifs flags)
[ 12.495822] UBIFS: recovery needed
[ 12.965490] UBI error: ubi_io_read: error -74 while reading 516096 bytes from PEB 3s
[ 12.976857] UBIFS error (pid 1): ubifs_check_node: bad CRC: calculated 0x1cbf602a, a
[ 12.985859] UBIFS error (pid 1): ubifs_check_node: bad node at LEB 450:99392
[ 12.992947] UBIFS error (pid 1): ubifs_scanned_corruption: corruption at LEB 450:992
[ 13.009837] UBIFS error (pid 1): ubifs_recover_leb: LEB 450 scanning failed

[tekknogenius]

Looking through the update.sh and I think I'll just try to reflash the userdata portion.
# data partition
################
echo "extracting data files..."
echo "extracting data files..." >> $TMP_LOG
# get only desired zip from update.zip
unzip -o $SRC_MOUNT_POINT/$UPDATE_FILE $DATA_ZIP >> $TMP_LOG 2>&1
status $? 1 $DATA_ZIP
if [ -e $DATA_ZIP ];
then
echo "updating data files..."
echo "updating data files..." >> $TMP_LOG
mount -t ubifs ubi:$USERDATA_VOL_NAME $ANDROID_DATA_ROOT >> $TMP_LOG 2>&1
unzip -o $DATA_ZIP -d $ANDROID_ROOT >> $TMP_LOG 2>&1
status $? 0 $DATA_ZIP
### enforce android FS ownership/permissions here ###
config_android_fs $DATA_ZIP
rm $DATA_ZIP
sync
df -h $ANDROID_DATA_ROOT >> $TMP_LOG
umount $ANDROID_DATA_ROOT
sleep 1
else
echo "$DATA_ZIP not included in package"
echo "$DATA_ZIP not included in package" >> $TMP_LOG
# mount/unmount to handle any "unrecovered" condition
mount -t ubifs ubi:$USERDATA_VOL_NAME $DST_MOUNT_POINT >> $TMP_LOG 2>&1
sleep 2
umount $DST_MOUNT_POINT
fi

and

# content partition
###################
# At this time, "content" is destined for /data
# This content is not put into /data at build time so it's not permanently
# in the OTA update.zip, but selectively added via add_content.
# If and when we have content destined for /fridge, duplicate this code

echo "extracting content files..."
echo "extracting content files..." >> $TMP_LOG
# get only desired zip from update.zip
unzip -o $SRC_MOUNT_POINT/$UPDATE_FILE $CONTENT_ZIP >> $TMP_LOG 2>&1
status $? 1 $CONTENT_ZIP
if [ -e $CONTENT_ZIP ];
then
echo "updating content files..."
echo "updating content files..." >> $TMP_LOG
mount -t ubifs ubi:$CONTENT_VOL_NAME $DST_MOUNT_POINT >> $TMP_LOG 2>&1
unzip -o $CONTENT_ZIP -d $CONTENT_DST_DIR >> $TMP_LOG 2>&1
status $? 0 $CONTENT_ZIP
rm $CONTENT_ZIP
sync
df -h $DST_MOUNT_POINT >> $TMP_LOG
umount $DST_MOUNT_POINT
sleep 1
fi



Also, in the update.sh I see the following, that I would assume is the recovery update???

# from boot command, figure out where update file is...
BOOT_COMMAND=$1
for i in $BOOT_COMMAND
do
case $i in
"--update_package=CACHE:update.zip"*)
UPDATE_FILE=update.zip
UPDATE_SRC_DEV=ubi:cache
UPDATE_SRC_FS=ubifs
;;
...

That coupled with the log make me think that this is where the recovery update.zip is located.

[ 13.018711] init: do_mount: calling mount: dev ubi:cache dir /cache s ubifs flags 0)
[ 13.109203] UBIFS: recovery needed
[ 13.196234] UBIFS: recovery completed
[ 13.199910] UBIFS: mounted UBI device 0, volume 2, name "cache"
[ 13.205870] UBIFS: file system size: 362815488 bytes (354312 KiB, 346 MiB, 703 LE)
[ 13.213795] UBIFS: journal size: 18063360 bytes (17640 KiB, 17 MiB, 35 LEBs)
[ 13.221394] UBIFS: media format: w4/r0 (latest is w4/r0)
[ 13.227250] UBIFS: default compressor: lzo
[ 13.231348] UBIFS: reserved for root: 4952683 bytes (4836 KiB)


I'll have to take a look at what is in that directory.

[tekknogenius]

Hmm...
I have to figure out how to erase a ubi volume. Running the update.sh script appropriately commented out works, but since I cannot mount that volume it will not copy the data.zip contents onto it.

On a side note, since i stoped the update.sh from rebooting it exits to the linux version it uses to do the boot/update (I'm assuming). It has all of the things I need at that point as far as the ubi user tools. Now I need to figure out how ubiupdatevol works.

[tekknogenius]

It's A L I V E ! ! ! !


It actually worked. I was able tog et it to finally boot by wiping the userdata volume then running the update.zip with the modified update.sh script within that only updated the userdata volume.

1. Run update.zip with modified update.sh that did not commented out the reboot command at the end.
2. Exited script at end back to boot linux
3. remounted the ubi image: ubiattach /dev/ubi_ctrl -m 6
4. see which volume number is userdata: ubinfo
5. wiped the userdata volume: ubiupdatevol -t /dev/ubi0_1
6. put update.zip back on scdard if necessary (should have commented out the part in the update.sh where it deletes the update.zip LOL)
7. reboot while pressing menu and rotate buttons to incoke the update process (again using modified update.sh)
8. Voila! She lives.

[tekknogenius]

Originally Posted by nikkie

I've noticed this device is more prone to disk corruption than other devices.

I believe it has to do with the version of u-boot we're running and perhaps the ubi as well. If I remember correctly reading that some of the earlier versions where prone to corruption upon power failure. This is consistent with my findings/symptoms which brought this about (after the battery died down to the red blinking light).

[nikkie]

Originally Posted by tekknogenius

I believe it has to do with the version of u-boot we're running and perhaps the ubi as well. If I remember correctly reading that some of the earlier versions where prone to corruption upon power failure. This is consistent with my findings/symptoms which brought this about (after the battery died down to the red blinking light).

Which would mean that using the reset button is particular dangerous, which is consistent with *my* experiences.