I've had similar problems. I've tried running x-server manually and it did borked out with a message that it cannot fild dsmetool (although it was there). I have modified the x-server script and put the full pathname /usr/sbin/dsmetool instead of the shell -x check and the tablet booted ok.

Just a general question but is there a early boot filesystem check for the ext2 partition when booting from the very same partition ?

No.

You could perhaps copy some init script from debian. Just make sure to disable stuff that drops you to shell prompt requiring manual repair :-) Also as rootfs is mounted rw you need to remount it ro before checking or hack initfs. Maybe adding ro to bootmenu item filesystem options could work?

Having the same problem (device stops booting at the splash screen), and having read this thread, I still wonder how I am supposed to access the file system once the system is blocked? I would do a reflash as a next step. What are my options?

Same here: played in the latest update, now it won't boot... any solutions?

Well, the way to access the filesystem is from your other boot; you should have already cloned to SD if you're going to do this.

Since (I assume) you don't have an SD with a bootable system on it, you'll pretty much have to reflash, or do serial console stuff.

If, OTOH, you have such an SD about (perhaps your update just hosed bootmenu as well as bringing the system down), you can hook up with the USB cable as though to flash, and run
to set the device booting off mmc. Then once you get in, you can reinstall your bootmenu.

(I just did that one to pull my N800 out of a non-bootable (and non-updated) internal system coupled with a freshly updated (and initfs-hosing) system on the SD; still have yet to recover the internal, but it was straightforward to kick things back up like this to regain the SD...)

Alternatively, if you were all set up with bootmenu + SD, you could have backed up just the initfs partition, in which case you can do a straight flash of that.That would be like
If you'd backed that up ahead of time, of course, you'd be restoring it, not asking what to do, but I figured I'd mention it for future reference. (I should have done this before, too; would have saved me the above hassle. )

I've had similar (but not the same problem) with boot sequence today and had some interesting findings about that. First of all, syslog gives much more details than any kind of manual debug output. Then there are files in /var/lib/dsme/stats showing which startup script failed and how many times (and which one was the cause to reboot).

And finally my biggest finding - I used maemo-control-services to disable some "unnecessary" stuff like multimediad (who would need sound on N810 after all ). Afterwards I started having some problems with sound so I reenabled multimediad and decided to reboot. That's how I got into reboot loop. But fortunately I was able to boot from flash (normally I boot from external SD card), chroot into problematic partition and use syslog just to find out multimediad is dying. As I suspected, disabling it (update-rc.d is the script to do that from command line, in case anyone wonders) made the system start without problems. Moreover, I could start multimediad after bootup, but not using proper boot sequence.

I also thought that maybe /usr/sbin/multimediad file got corrupted, so I uninstalled the whole multimediad package (together with bunch of other sound-related stuff) and then reinstalled again (with the same stuff). And than I was enlightened: Maemo (like Debian, I suppose) has no boot script dependency, so disabling and reenabling services may lead to borked system. In my case original multimediad links in /etc/rc?.d dirs were prefixed by 25, while after disabling and reenabling it the prefix was 20. Considering that there is a service dsp-something with prefix 24 I guess it's quite easy to figure out why multimediad crashed after toggling it off and on again.

Btw. it really eludes me why there is no way to define boot script dependencies. I guess I'm a bit spoiled by Gentoo, which is my primary distribution for PCs, which eg. brings ssh down and up again when restarting network interface (basing on dependencies). There a situation like mine would never happen