Try running "mc-tool list" (mc-tool is in package libmissioncontrol-utils, see https://wiki.maemo.org/N900_Mission_Control#mc-tool) and see what comes out and if it makes any sense.

Perhaps it's time to "rsync -a /home/user some_backup_server:" and reflash. But then you miss the fun of figuring out what the problem was (or it comes back when you rsync back..)
Depends on how dependent you are on that particular N900.

or you can try to backup and then restore, iirc this should recreate all of the databases

In my experience, fsck on flash/sd always ends in tears. It was disabled until cssu, then enabled and wrecking partitions, then disabled again, and now I don't know if it's armed to nuke /home or not.

Anyway, my usual strategy after unexpected reboot, is to do as root:
cd /home
ls -laR >/dev/null

fs errors usually show up with that. If the damage is sma, I've made tarball of /home in backupmenu, then recreated fs and untarred.

If there are non-fs issues, like zeroed files, they wont be found by this.


Good luck!

Estel, already investigated deeper? Or reflashed?

Today I think I had exactly same behaviour, no call-ui came up, no call came through. Did not check about modest, as I needed phone functionality and did a reboot (before I remembered you and your prob).
After a reboot everything was back to normal.

As I still switch between SIMs and also have a high swap usage I sometimes have the feeling that 'some swap thingy here goes crazy'.
Please check your swap partitions or disable extended swap / enable stock swap partition and test once more. [a shot in the dark]

I don't suppose you have a log of that fsck? If you do, you should be able to identify which inodes were corrupted. Then you can run something like ls -aRi1 and grep for each inode to identify which filenames point to those inodes. You can then use dpkg -S with those filenames to identify which packages you should reinstall.

Finally found something, that might point in the right direction. One of the error messages digged up from mission-control extended logs:

Inability to init account utils would be in line with what I've been experiencing, and that dbus-glib-error-quark sounds like something - sadly, my debus knowledge is close to 0. Any ideas how to "approach" the problem?

As for all suggestions:

Sadly, no joy

No effect, either...

Unfortunately, I haven't kept that log (silly me). Thanks anyway, I'll keep that suggestion for the future, might come as invaluable one day! I had no idea about this method

I had the same method for checking filesystem until stopped using vanilla's fsck - albeit, I rather identified the problem with fsck segfaulting at certain passes, if fixing more serious issue (so, if it had to only recover journal, or fix minor thing it never nuked /home/opt, but anything requiring further passes was fatal).

Hoever, for a long time, we have updated fsck in CSSU, that doesn't segfault (and even before, I used e2fs progs from Debian, with libraries compiled statically). Using that, I did more than hundred (literally) fsck's during ~2 years, and never encountered any problem - it was working jusike fsck on normal HHD's. It's the first time (since using non-segfaulting fsck) that I got any issues. I guess that either something important got zero'ed and there is no safety recreation mechanism, or some text file got clone'd with content of other text file, that, by some bad luck, is parsed "sucessfuly" providing nonsense content, resulting in the fubar I'm in.
---

Anyway, thanks for all your input, people! I just started passing mission-control log (extremely busy week), so I'll report if I find something more (Althought, I'm quite positive, that the account utils and dbus thing is to blame).

/Estel

//Edit
No further joy with mc-tool, the thing from beginning of post is the only usable bit. BTW, plain mc-tool list results in just:
(as root or not).

BTW, while reinstalling "nokiamessaging", something caught my eye:

Sadly, reinstalling every package with "dbus" in name doesn't help...

/Estel