Comment 7 for bug 223226

Confirmed here for the kdm issue.

That said, stopping kdm manually was a non-issue (for me), because the upgrader wouldn't get confused by being interrupted at this point and having to start again (though I won't argue if the developers value "not having to stop xdm/kdm for upgrading" as a more important goal).

My only gripe would be that neither
http://www.ubuntu.com/getubuntu/upgrading#head-db224ea9add28760e373240f8239afb9b817f197 nor https://help.ubuntu.com/community/HardyUpgrades#head-e7f287c730b93116f89de7ea7e05efbe95fa6dd1 mention the need for this (as of today, 28.07.2008). (I believe I used 'do-release-upgrade -m desktop', based on the advice given on the latter page.)

Also the perl locale failures and other minor warnings ("The update-modules command is deprecated and should not be used!" and what have you) and errors had no visible effect on the results of the upgrade process.

(The upgrade did leave me with a few regressions, but they are off-topic here.)

*

The other "manual intervention" would be this ('grep "Running services" apt-term.log'):

"Configuring libc6

Running services and programs that are using NSS need to be restarted, otherwise they might not be able to do lookup or authentication any more (for services such as ssh, this can affect your ability to login). Please review the following space-separated list of init.d scripts for services to be restarted now, and correct it if needed.

Note: restarting sshd/telnetd should not affect any existing connections.

Services to restart for GNU libc library upgrade:
vsftpd rsync postfix cupsys cron atd_____________________________________

Ok"

I will leave it up to the developers to decide on how to deal with and correctly assign this issue.

*

Richard Green: I wonder if all the other manual interruptions you mention were of the type "you have a modified configuration file, what do you want to do?"

In this case, I doubt that automation would be desirable (unless by providing a specific option to force-override all custom configuration files OR force-preserve all such, both of which would remove the need for manual intervention in the middle of the upgrade process).

(According to the logs ('grep -6 "show" apt-term.log' or 'grep "show" apt-term.log|wc -l') you had 12 of these. I had a few as well, and now that I checked the logs I know which ones they were. I did take notes of the most essential ones though, "in case". ;-)