yesterday was a bit annoying for me, but I got it back together in the end. there were many more hours involved than the tips below cover, so maybe if something like this happens to you/yours, this info will help to get it all back more quickly.

first mistake: I had "http://repository.nrcc.noklab.com bora extras" in my sources.list, probably thinking it would offer me up cool new software toys from nokia labs. does not seem to have been a problem in the past, but recently they put in libpango and libglib2.0 binaries apparently from ubuntu. I happily upgraded and crashed shortly thereafter, then subsequently found my tablet wouldn't boot any more: the blue line would run across to about 1 inch short of the right side and stop, while I could hear the 'nokia theme' play but nothing changed on the display. I don't have it set to automatically search for connections, so don't know if I might have gotten in that way.

my tablet boots off the sd cards, though I only have one partition set up for booting. I rebooted into flash and started poking around. Since it happened after the upgrade, I had a reasonable clue that it was probably something to do with the libpango I saw being upgraded or other system libraries. naturally I've been enjoying my tablet recently but forgetting to run my backup script, and don't have an external sdhc card reader yet (I thought) so never did make a full backup of the bootable filesystem on the card.

I looked around in /lib and /usr/lib ('ls -lt' to get files in date order), and saw right away that only a few files in /usr/lib had been changed before it all went down. guess I usually reboot after an upgrade or other change to make sure all is well, not making too much effort to get a record uptime -- and that was a good thing in this case.

so I started looking at mv'ing some libs around to see if I could get it to boot again off the mmc card. this led to

second mistake: I was inadvertently faffing around in /usr/lib instead of /media/mmc1/usr/lib, so not only did I have no effect on the targeted mmc card, I managed to trash my flash install as well and could no longer boot from it either . grrrrrr.....

note to Fanoush, Nokia, anyone else who might be able to hack at this level: wouldn't it be cool and useful to be able to mount or otherwise access and modify this filesystem through usb or something in this situation? I see that jffs2 doesn't seem to be an option for my x86 linux kernel, so probably that's yet another issue that would hold this back....

so, coupla hours later I've re-flashed, sdhc kernel back in, xterm, ssh, and initfs_flasher so could get back to try booting off of the sd card. I've previously formatted both my sd cards to ext2 as I use linux pretty much exclusively and didn't see a point to vfat for any of it. thing is, the newly-flashed system doesn't have the modules mbcache.ko and ext2.ko automatically loaded, so can't mount the cards without getting to a terminal.

tip: probably useful to keep a vfat partition around with some recovery tools, e.g. debs for xterm, ssh, maybe e2fsprogs for e2fsck. still no way I've found to execute a script on a newly-flashed system, but looks like you could do 'install from file' under the application manager to get started at least.

now, back to the problem at hand. I no longer have the patience to mess around with individual libs, so I

cd /media/mmc1/usr
mv lib lib.mmc
cp -a /usr/lib .

now I have the /usr/lib dir from the flash install to try booting with. this is reasonable since part of the process for setting up the mmc boot is to copy everything over from a flash install.

yup, now I can boot all the way through from the sd card (yay!). many of my installed apps don't start up / work of course because all their libs are missing, but no matter -- I can ssh in and start doing things (like step 1, run the backup script for all my application data!).

next I carry on fiddling with libs, as now I have a clear recovery path if it goes wrong. this is pretty tedious and not the right way to do it, but along the way I discover:

tip: if you remove the sd card from the external slot and boot to the flash install with the usb cable hooked up, the internal card becomes mountable to your (linux with ext2fs) pc on the other end of the cable. this is the fastest way (probably assuming usb2) to back the card up, far better than relying on tar inside the n800 due to the cpu speed. you don't need the ext2 modules loaded on the n800, it's just like a sdhc card reader. note that I do have rd mode enabled (would you have thought otherwise having read this far? ), not sure if this is what makes this work. also note, use tar to back up the filesystem as it will do the right thing with file links and nodes in /dev -- unlike cp -- and also save some space assuming you compress the whole thing.

finally after much struggling and efforts to force-reinstall all packages, which dpkg and apt-get seem remarkably averse to doing in bulk, I come back to this posting:

http://www.internettablettalk.com/fo...t=dpkg+apt-get

which I had bookmarked long ago to help in maintaining the list of installed packages. with some further work I found:

when booted from the flash install, and the ubuntu one installed when I booted from the mmc card. I was able to re-download the necessary debs (which turned out to be for libpango, libpango-common, and libglib2.0) from

http://repository.maemo.org/pool/bora/free/binary/

(useful bit here is to notice the 'pool' in the url, as otherwise I couldn't easily find the files)

now, once I've booted to the sd card with the flash version of the /usr/lib dir, I can swap them back around and have the old, broken sd card /usr/lib dir in place. the libs in use should be loaded into mem and not care too much about what happens on the filesystem, but just the same this is an iffy proposition and probably many situations where it won't work. in my case I'm ssh'd in doing most of the work so probably ok. this is important of course because I really do want to repair the right files this time.

then I reinstalled the downloaded debs with 'dpkg -i' (didn't even need the --force-downgrade). once I had disabled the noklabs entry from the app manager / sources.list and rebooted, even 'apt-cache policy' and the app manager didn't suggest there was another version to try. yes, on the reboot everything came back to normal as I'd set it up in the morning.

all's well that ends well I guess, plus I learned a few things and have some ideas on how to set things up (and backup!) better for the future. if you think this has been a long read, I can tell you that living it was much worse....

here's to hoping you never need this info!

rob.

Yes, that sound cool and is even possible to do :-) What could be done from bootmenu is to bring up USB networking and start dropbear. Then you could ssh in and mount rootfs in internal flash or mmc and fix it or at least recover data (over ssh/scp). This only needs dropbear compiled with correct uclibc toolchain. There is not much free space in initfs but dropbear could fit and everything else in already in place.

I was thinking about it but so far other things had higher priority. Also when one keeps at least one system bootable (flash or some mmc partition) it is easier to recover by booting full system. But yes, it would be cool to have such recovery option and it would definitely help in situations such as yours.