maemo.org - Talk

maemo.org - Talk (https://talk.maemo.org/index.php)
-   Troubleshooting (https://talk.maemo.org/forumdisplay.php?f=6)
-   -   Dual booting Sardine - rsync reboots? (https://talk.maemo.org/showthread.php?t=3082)

Milhouse 2006-09-16 15:53
Dual booting Sardine - rsync reboots?
 
I've succesfully installed the reduced size initfs and now have a functioning dual boot menu (although I'm only able to boot from Flash right now). Whenever I attempt to copy (rsync) the IT2006 root filesystem from Flash to my ext2 partion (256Mb) the 770 reboots leaving a corrupt ext2 partition (I'm following the instructions here.

I've installed e2fsprogs and can run e2fsck to fix the ext2 partition, but continuing the rsync results in further reboots (different files each time).

Has anyone else seen this? I wonder if it's related to the hardware/memory problems discussed in other threads?

fanoush 2006-09-16 19:57
It looks like corrupted flash rootfs. rsync should not reboot the device. Can you find when it happens? What file is copied at that time? Does it happen at the same place everytimes? When you have rootfs mounted to /floppy try 'find /floppy' as root, does it reboot? Try 'tar cvf - /floppy >/dev/null', does it reboot? When? Try it over ssh so you still have the output on the screen when it crashes.

If it crashes always on same file it is very likely corrupted rootfs.

fanoush 2006-09-16 19:59
Also look at dmesg output right after device boots, do you see any jffs2 warnings/errors or bad block errors?

Milhouse 2006-09-16 22:11
Quote:
Originally Posted by fanoush
Also look at dmesg output right after device boots, do you see any jffs2 warnings/errors or bad block errors?
There are messages about empty blocks - this is an extract from dmesg after an rsync induced reboot:

Code:
[  545.213409] 128 words of entropy generated
[  545.298034] mmcblk0: mmc0:0001 SDR01G 1003264KiB
[  545.298675]  mmcblk0: p1 p2
[  545.320098] Empty flash at 0x00007ffc ends at 0x00008000
[  545.320312] Empty flash at 0x0000fffc ends at 0x00010000
[  545.320495] Empty flash at 0x00017ffc ends at 0x00018000
[  545.334503] Empty flash at 0x00027ffc ends at 0x00028000
[  545.334686] Empty flash at 0x0002fffc ends at 0x00030000
[  545.336883] Empty flash at 0x00037ffc ends at 0x00038000
[  545.351165] Empty flash at 0x00047ffc ends at 0x00048000
[  545.351623] Empty flash at 0x0004ff74 ends at 0x00050000
[  545.351898] Empty flash at 0x00057f58 ends at 0x00058000
[  545.365814] Empty flash at 0x00067ffc ends at 0x00068000
[  545.366027] Empty flash at 0x0006fffc ends at 0x00070000
[  545.366210] Empty flash at 0x00077ffc ends at 0x00078000
[  545.380371] Empty flash at 0x00087ffc ends at 0x00088000
[  545.380615] Empty flash at 0x0008fffc ends at 0x00090000
[  545.380828] Empty flash at 0x00097ffc ends at 0x00098000
[  545.394836] Empty flash at 0x000a7ffc ends at 0x000a8000
[  545.395080] Empty flash at 0x000afffc ends at 0x000b0000
[  545.395294] Empty flash at 0x000b7ffc ends at 0x000b8000
[  545.409393] Empty flash at 0x000c7fa0 ends at 0x000c8000
[  545.409667] Empty flash at 0x000cfffc ends at 0x000d0000
[  545.409912] Empty flash at 0x000d7ffc ends at 0x000d8000
[  545.424011] Empty flash at 0x000e7ffc ends at 0x000e8000
[  545.424285] Empty flash at 0x000efffc ends at 0x000f0000
[  545.424468] Empty flash at 0x000f7fac ends at 0x000f8000
[  545.438659] Empty flash at 0x0010fffc ends at 0x00110000
[  545.438964] Empty flash at 0x00117ffc ends at 0x00118000
[  545.453094] Empty flash at 0x00127ffc ends at 0x00128000
[  545.453796] Empty flash at 0x0012fffc ends at 0x00130000
[  545.468811] Empty flash at 0x00147ffc ends at 0x00148000
[  545.469543] Empty flash at 0x0014fffc ends at 0x00150000
[  545.470062] Empty flash at 0x00157fdc ends at 0x00158000
[  545.484313] Empty flash at 0x00167fb4 ends at 0x00168000
[  545.484619] Empty flash at 0x00177ffc ends at 0x00178000
[  545.498962] Empty flash at 0x001868b8 ends at 0x00187000
[  545.522247] VFS: Mounted root (jffs2 filesystem).
[  545.522735] Freeing init memory: 92K

.
.
.
[  638.091735] aic23_init_power() done
[  640.091857] JFFS2 notice: (419) check_node_data: wrong data CRC in data node at 0x05277000: read 0x51e34124, calculated 0x3d80d51b.
[  641.604949] aic23 powering down
[  648.058654] JFFS2 notice: (419) read_dnode: header CRC failed on node at 0x6866fd4: read 0xffffffff, calculated 0x29ad7efb
[  648.611541] JFFS2 notice: (419) check_node_data: wrong data CRC in data node at 0x06810000: read 0x74104c00, calculated 0xfb872b9d.
[  653.226470] JFFS2 notice: (419) check_node_data: wrong data CRC in data node at 0x06b35800: read 0xcaa93bcd, calculated 0x79517e9a.
[  653.649810] JFFS2 notice: (419) check_node_data: wrong data CRC in data node at 0x06928800: read 0xfb30f01, calculated 0xc68e5ff.
[  896.253417] hwa742: setting update mode to disabled
[  896.253479] omapfb_notifier_cb(): event = DISABLED
[ 1059.116180] hwa742: setting update mode to manual
[ 1059.116241] omapfb_notifier_cb(): event = READY

Milhouse 2006-09-16 22:15
Quote:
Originally Posted by fanoush
It looks like corrupted flash rootfs. rsync should not reboot the device. Can you find when it happens? What file is copied at that time? Does it happen at the same place everytimes? When you have rootfs mounted to /floppy try 'find /floppy' as root, does it reboot? Try 'tar cvf - /floppy >/dev/null', does it reboot? When? Try it over ssh so you still have the output on the screen when it crashes.

If it crashes always on same file it is very likely corrupted rootfs.

It reboots with different files, not always the same one (mainly due to rsync continuing from where it got to before the crash, so it finally crashes with a different file).

I'd been following the Sardine instructions running on battery power and using ssh, I've now tried again with mains power and xterm, and it seems a lot more stable (which is worrying!) - it has completed the rsync without errors from start to finish!

I'll try your "find /floppy" and tar suggestions shortly - many thanks for your help!

Milhouse 2006-09-16 22:54
Hi Fanoush

"find /floppy" and "tar cvf - /floppy >/dev/null" both worked OK (two runs each on battery power + ssh) - no crash.

The rsync copy on mains power and xterm completed ok, and I managed to boot off MCC partition 2 succesfully! However, the Sardine upgrade then fails due to a corrupt tar file (libdbus-1-2_0.61-osso19_armel.deb) - a subsequent reboot from Flash and running e2fsck reveals the ext2 partition to be heavily corrupted (this partition is also now non bootable due to the failed upgrade). This is the output from "apt-get upgrade" regarding the corrupt tar:

Code:
Unpacking replacement libdbus-1-2 ...
dpkg: error processing /var/cache/apt/archives/libdbus-1-2_0.61-osso19_armel.deb (--unpack):
 corrupted filesystem tarfile - corrupted package archive
.
.
.
Errors were encountered while processing:
 /var/cache/apt/archives/libdbus-1-2_0.61-osso19_armel.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
/home/user #
My /etc/apt/sources.list file contains only the tableteer and Sardine repositories.

I'm going to try again (on mains power and xterm) and see if I can get more luck upgrading second time around. :)

Milhouse 2006-09-16 23:57
After another successful rsync on mains power + xterm, I attempted the Sardine upgrade (also on mains power + xterm - previously battery+ssh) and this time all the packages were valid (no corruption) however there were numerous dependency errors and the Sardine partition is now unbootable (the progress bar stops just under the A in NOKIA then the device reboots after about 20 seconds). I'm guessing Sardine may still be a little too unstable for people like me :) Has anyone else got a working Sardine install?

As to why I have been getting different results comparing mains power and a fully charged battery - no idea, it's a bit disturbing though.

mallard 2006-09-17 00:19
Different results on different power sources probably means that the 770 tries to draw more power than the battery can provide, causing a temporary "brownout" which causes a reboot.

Milhouse 2006-09-17 01:25
Quote:
Originally Posted by mallard
Different results on different power sources probably means that the 770 tries to draw more power than the battery can provide, causing a temporary "brownout" which causes a reboot.
Quite - which must be considered a design flaw, surely?

fanoush 2006-09-17 08:23
Milhouse, are you using wi-fi for the ssh connection? Did you try also other combinations like on battery with xterm or ssh on mains? Looks like you always wrote ssh+battery xterm+mains. Would be interesting if it is caused by network connection or poor battery.

I never had such symptoms but I don't use wi-fi regulary for ssh into the device, I prefer bluetooth (better response time, lower power requirements, no random disconnects). Maybe wi-fi driver is buggy and reboots the device? There are many variables in wi-fi network (access point brand and settings) so there can be combinations which are not stable. So the battery may be ok, just wi-fi may be the problem.

As for unmet dependencies you mentioned only tableteer and sardine, did you try upgrading also with regular maemo2.0 repository added? I think sardine needs it.

As for the dmesg output it looks like you rootfs had very interesting time in the past :) It can still be OK but it may be also corrupted. All these messages are just warnings or infos but it definitely looks like there were random reboots with jffs2 filesystem in the middle of work. In theory it should still work but if there are some strange issues I'd try reflash (rootfs only, otherwise you loose the bootmenu). You can still backup old rootfs to mmc before reflash in case you need to boot it or want some data from it later.

Milhouse 2006-09-17 15:13
Quote:
Originally Posted by fanoush
Milhouse, are you using wi-fi for the ssh connection? Did you try also other combinations like on battery with xterm or ssh on mains? Looks like you always wrote ssh+battery xterm+mains. Would be interesting if it is caused by network connection or poor battery.

I never had such symptoms but I don't use wi-fi regulary for ssh into the device, I prefer bluetooth (better response time, lower power requirements, no random disconnects). Maybe wi-fi driver is buggy and reboots the device? There are many variables in wi-fi network (access point brand and settings) so there can be combinations which are not stable. So the battery may be ok, just wi-fi may be the problem.
I'll try the above combinations and let you know!

Quote:
Originally Posted by fanoush
As for unmet dependencies you mentioned only tableteer and sardine, did you try upgrading also with regular maemo2.0 repository added? I think sardine needs it.
This is the sources.list I used to upgrade to Sardine:

Code:
/opt/etc/apt # more sources.list
#maemo:essential
deb http://catalogue.tableteer.nokia.com/certified/    mistral user
deb http://catalogue.tableteer.nokia.com/non-certified/ mistral user

deb http://repository.maemo.org sardine main
deb http://repository.maemo.org maemo2.0 free non-free
What other repositories should I add? I read some documentation on the Sardine Wiki that suggested the above repositories were all that I required.

Quote:
Originally Posted by fanoush
As for the dmesg output it looks like you rootfs had very interesting time in the past :) It can still be OK but it may be also corrupted. All these messages are just warnings or infos but it definitely looks like there were random reboots with jffs2 filesystem in the middle of work. In theory it should still work but if there are some strange issues I'd try reflash (rootfs only, otherwise you loose the bootmenu). You can still backup old rootfs to mmc before reflash in case you need to boot it or want some data from it later.
And there's me thinking I've taken good care of my 770! :) I've only flashed the standard firmware (all OS2005 releases, then enabled r&d mode, then flashed OS2006 beta and final). Yesterday I replaced initfs, that's the full extent of my device flashing! Day to day usage is pretty stable - I have the occasional unexplained reboots (quite rare really) but I thought everyone had these! :)

I'm guessing if I restore rootfs I'll lose all installed applications etc. so will keep that as a last resort. If I've missed any Sardine repositories I'll add them and try upgrading to Sardine again, and if that still fails I'll consider reflashing my rootfs. However if I've got all the correct repositories that implies the Sardine upgrade may not be usable right now in which case I'll wait some more until it is! :)

Any idea where Sardine progress can be tracked/monitored (more from a device point of view than x86 desktop env)?

Many thanks for all your help! :)

fanoush 2006-09-17 18:41
Quote:
Originally Posted by Milhouse
What other repositories should I add? I read some documentation on the Sardine Wiki that suggested the above repositories were all that I required.
The list is OK. I thought you mentioned only sardine and tableteer repository but you have maemo2.0 too. This should be enough.

Quote:
Originally Posted by Milhouse
I have the occasional unexplained reboots (quite rare really) but I thought everyone had these! :)
Yes, one such reboot is enough to produce such warnings in the log (Empty flash at ... - jffs2 is a bit counfused that it found free flash not already marked as free, it is OK but not expected. Wrong data CRC in data node at ... - this is probably OK too but I don't understand why, just have read somewher these are OK, it is only jffs2 notice, not error)

Quote:
Originally Posted by Milhouse
I'm guessing if I restore rootfs I'll lose all installed applications etc. so will keep that as a last resort. If I've missed any Sardine repositories I'll add them and try upgrading to Sardine again, and if that still fails I'll consider reflashing my rootfs. However if I've got all the correct repositories that implies the Sardine upgrade may not be usable right now in which case I'll wait some more until it is! :)
It seems you did nothing wrong. I smell rotten sardine :)

Quote:
Originally Posted by Milhouse
Any idea where Sardine progress can be tracked/monitored (more from a device point of view than x86 desktop env)?
No idea, I haven't tried it yet. I'm waiting for bigger MMC card for sardine partition.
Quote:
Originally Posted by Milhouse

Many thanks for all your help! :)
I think I did not help at all :-)
Please let us know if you upgrade to Sardine successfully in future.

Milhouse 2006-10-01 01:54
Further news... battery+xterm would result in a reboot just reformatting the second partition... when it did succeed, rsync would cause a reboot. Didn't get as far as testing with ssh+mains - there's obviously something very wrong.

Have now reflashed again. It would appear that the following messages:
Code:
[  545.320098] Empty flash at 0x00007ffc ends at 0x00008000
[  545.320312] Empty flash at 0x0000fffc ends at 0x00010000
[  545.320495] Empty flash at 0x00017ffc ends at 0x00018000
are caused by flashing with the reduced sized initfs (needed to install the boot menu).

With the fresh image, reduced size initfs, boot menu, xterm, sshd, rsync and e2fsprogs I'm now trying again... :)

Milhouse 2006-10-01 02:05
So far so good - mk.ext2fs and rsync'ing OS2006 to mmc worked without a hitch (over ssh+battery)... now to upgrade to Sardine!!

Milhouse 2006-10-01 02:27
Bah! Looks like the on-device upgrade for Sardine is still broken, there are still tons of dependency problems resulting in a failure to boot :(

Oh well, at least my device seems a bit more stable! :)


All times are GMT. The time now is 16:11.

vBulletin® Version 3.8.8