Could the next SSU contain a fix for bug 472: https://bugs.maemo.org/show_bug.cgi?id=472

I use Openntpd to resolve it but it would be a handy feature to haven delivered through the OS.

I tried an experiment: trying to install the community SSU update directly on an SD-based OS to which I boot using Penguinbait's Console-Tools. It was unable to update due to numerous "Application packages missing"

I'm supposing that the experiment failed (as I anticipated) because the community SSU can be installed only into the N8x0's own internal flash memory. Correct?

Will installing it on the internal flash memory impact my dual-booting? I'm supposing it won't; OTOH, to get it to my SD-card-based OS (which is my primary OS), I'd have to clone using the updated system, which would mean lots of re-building of what I've done on my SD-based OS since my SD-based OS and Apps is much more tweaked and developed than my flash-based system. Right?

I have tried the Testing SSU and This new stable one and 2 different installs. On external SD, and Internal storage. Neither gave me any problem. Before saying install/ok to install, you should have a details and/or installing/problems tab in application manager. That might tell you what packages are missing, or at least give us a clue of the issue.

I don't think the problem is with booting on anything other than internal flash.

Success!!!

I'm using Nuvo Clear (sp?) theme.

Never once did I encounter this during the year or so using stock Diablo kernel.

It occurs after locking then unlocking the device.

Reboot brings it all back without even needing to recheck applets.

This bug seems almost impossible to fish for.

cant say i have seen the error being described, tho i have seen some graphical issues (statusbar icons that come and go, osk that goes missing when a drop down list from say a addressbar covers it). But if its related to the community update or just general bit rot (i have yet to reflash since the update to diablo) i am unsure.

Installed last one (stable) upgrade.
Now mmc2 seems to be "Read-only filesystem". My /var/cache/apt and /var/lib/apt were moved to mmc2 and they worked perfect, but after upgrade apt-get update says that it can't work because of read-only filesystem.
Maybe I broke it, but I think it happened because of update. Now I moved apt dirs back and apt-get works.

For example:
Cannot change anything in /media/mmc2/var/cache/apt - Read-only file system
Cannot delete /media/mmc2/var/cache/apt - Read-only file system

Have you tried manually deleting the virtual memory file?

I use openntpd too and find it invaluable, but I think it works fine as a package in extras rather than forcing it on everyone.

Thanks, using version 4.0 from https://garage.maemo.org/frs/?group_...elease_id=1971 but no crashes so far. Not sure if it's the right one, as the taskbar icons look like the stock ones while yours are very different. The font does look a bit smaller than the default, though not as small as in your previous screenshots.

I don't think it's the kernel, if there's anything in the community that triggers it I would suspect the X server (I'm still not 100% sure I guessed the build flags correctly on that one).

Is that device lock or screen lock? Does it also happen when the screen is re-activated after blanking? If so it sounds like an applet crashing and taking hildon-desktop down with it.

Yeah, that's standard. As a defence mechanism, when hildon-desktop crashes it gets restarted without loading any third-party plugins (otherwise it could easily find itself in an endless restarting loop), but it doesn't modify its configuration so a reboot brings it back as set up by the user.

The usual way of tracking something like this down is disabling all desktop/statusbar/taskbar applets and re-enabling them one by one until the bug reappears.

But since we now have two reports, you can start by listing your applets. Chances are the trigger would be one common in both tablets.