Quickie answer here: dpkg -i packagename.deb

Ya ... I realize that. I was just being sarcastic since people seemed to be using that as the canonical list of reasons why they should entirely dismiss people having issues.

It is pretty intrusively replacing core bits but I found it really stable.

I am pretty sure that I had rtcomm-beta install before the last SSU and it went fine. There may have been an update to rtcomm-beta since then though. So if that is the culprit, that would narrow down the list of causes. Maybe I will reflash back to the old firmware again and try to cause it just by installing that one package.

Is it possible to cleanly "uninstall" the SSU package and revert back the the pre-installed state or is it the case where the SSU package is just a meta package that drags all the required updates in and is non-reversible?

I did not have rtcomm-beta nor pidgin installed in my N810 and suffered the death loop. I had Gizmo, though.

I have gone through 4 update installations to be finally able to know what fails and gather that information (1->reboot cycle-teeth gnashing, 2->white screen of death-head banging, 3->success, 4->document and check fixes)

I put this here in the hope it can help those of you who haven't still updated to avoid failure.
The first issue is the big update size. Make sure you have plenty of space before trying.
Second, you better make a backup of your system if you haven't done so (see this post http://www.internettablettalk.com/fo...8&postcount=31) and want to avoid a full reflash. Once you have a rootfs backup save the file in your PC to be able to reflash it with flasher, if things go wrong. If you have a bootable system in mmc, just do a tgz backup.

Now, lets start with all the issues I have found:

- The update can't be installed if sliderotate is installed. Simply uninstall sliderotate. Same with certain flash patch, it is documented in this thread (I do not have that patch)

- The update contains 32 deb archives. That in itself is not an issue, but, given how the package manager/apt works, means that if only one of such packages doesn't install, all packages will remain unconfigured leaving the system broken unless fixed by hand. So, for this very reason, use apt-get to install the update, and do not reboot if the update fails unless you have no other option.

- apt and the nokia repositories are updated too, if the update fails, the nokia repositories are borked and you won't be able to fix the system unless you already have all packages. Pre-download all packages first with "apt-get -d install osso-software-version-rx44"

- The update contains a documentation package. This package causes a lot of trouble, because it fails if the user has moved, removed or linked the documentation files:
It fails if there is no files in "/usr/share/pre-installed/MyDocs/.documents/". Create that directory and touch or put a file there if you have that deleted.
It fails if the "/home/user/MyDocs/.documents/osso_software_copyright.pdf" file is a symlink
It fails if the "/home/user/MyDocs/.documents/~sfil_li_folder_user_guides/" directory is a symlink or is empty. Make sure you have an actual directory with any file there.

- The init.d handling scripts are prone to fail, and because dpkg is not robust and/or post-install scripts have poor error recovery, causes the "dangling symlink /etc/rc2.d" problem. This problem doesn't affect everyone, and only happens on some packages. I think it is relate to how the post-install script passes arguments to the "invoke-rc.d" script, but I have to investigate further. In this update, the packages tablet-browser-daemon, mce, ke-recv and icd2 are affected by this problem and their installation will fail.
The best way to get rid of this problem once and forever is to edit the "/usr/sbin/invoke-rc.d" script and make sure it never fails the symlink check. There is already a thread about this in ITT. I have attached the fixed script here, so just copy it to /usr/sbin
A worse way to fix this is to delete the /etc/rc2.d related files (S99tablet-browser-daemon, S21mce, S30ke-recv, S59icd2) when the installation fails, then after successfully installing those packages (using "dpkg -i" because apt-get won't work) you'll have to create by hand those symlinks or otherwise the following things will not work right: usb, screen keyboard, network, power-off button. Those packages are tricky to get installed because they need other packages configured before installing, so you need to run "apt-get -y -f install" before "dpkg -i"

- Do not work through a ssh shell and don't let the tablet enter power-save mode. One of the packages is the network daemon (icd2) and will be shut down when installing, cutting off your shell. Since also mce is being reinstalled and has been shut down too, if you tablet enters power save mode you won't be able to regain control of it or even properly turn it off, leaving no other option than to remove the battery.

- It is possible to reboot with the update not configured if the only packages not installed are tablet-browser-daemon, mce, ke-recv, icd2 and the documentation, and then finish the installation by hand. Failure before that probably means endless reboot cycle.

- If the update has failed but you have been able to complete installation by hand, you have to "flash-and-reboot" to install the new kernel and initfs

While I had my problems with this update, having sliderotate installed wasn't one of them...unless sliderotate was responsible for removing osso-software-version, and uninstalling would have put it back. Even if it was responsible for that, reinstalling osso-software did the trick. Once the system updated, I just reinstalled sliderotate kernel from within sliderotate settings, and I was good to go.

It gave me a conflict with xserver-xomap, and didn't go away until I uninstalled sliderotate.

Recent versions of sliderotate do not conflict with osso-software-version-rx?4-unlocked; in any event uninstalling sliderotate would not restore that... Some early rotation packages did force removing an osso-software-version, but I think since the first SSU they've been largely ok.

Removing osso-software-version-rx?4-unlocked is an additional cause, however it happens, and can (AFAIK) only really be fixed ahead of time by installing it again.

I almost feel guilty in saying that my update went off without a hitch, but it did and thank the Gods for that because based on my topsy turvy life, I just need stress free gadgets right now and after a weekend of restoring a windows xp pc from scratch, the last thing I needed would have been a infinite boot loop issue on my N810. Just sort of stunned that so many users are having so many issues with this upgrade.

Key word was tend (I even emphasized it in the original post).

And if ya like, I can prove my premise with stats. I didn't get hired as a data analyst for my good looks.

I updated two N800's today, and both went fine. I did notice that when the devices were being halted at the end of the update, there was a period of time where the screen went dark, but the device wasn't fully shut down. The screen actually faded twice -- once from the hildon UI down to a powered dark screen (a very odd fade away), then later the LCD powered down completely. It looked down for a while, but wasn't quite.

Once shut down, I could start the devices again with no issues. Pressing the power button let the LED light up, device booted etc.

Are people being patient enough during the halt? Are files being corrupted if the battery is being yanked during the final writes out to flash memory?

Just one observation.