Dual booting Sardine - rsync reboots? - maemo.org

Milhouse | # 1 | 2006-09-16, 15:53 | Report

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 | # 2 | 2006-09-16, 19:57 | Report

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 | # 3 | 2006-09-16, 19:59 | Report

Also look at dmesg output right after device boots, do you see any jffs2 warnings/errors or bad block errors?

Milhouse | # 4 | 2006-09-16, 22:11 | Report

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 | # 5 | 2006-09-16, 22:15 | Report

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 | # 6 | 2006-09-16, 22:54 | Report

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 | # 7 | 2006-09-16, 23:57 | Report

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 | # 8 | 2006-09-17, 00:19 | Report

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 | # 9 | 2006-09-17, 01:25 | Report

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 | # 10 | 2006-09-17, 08:23 | Report

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.