Upgrade from kubuntu Dapper requires manual intervention and kdm shutdown

Issue #1, here's the web page I followed:
http://www.ubuntu.com/getubuntu/upgrading#head-db224ea9add28760e373240f8239afb9b817f197

Towards the bottom of that page, is the following:

Network upgrade for Kubuntu desktops (recommended)

To upgrade from Kubuntu 6.06 to 8.04 over the Internet, use the same procedure as for Ubuntu server, below.
Network upgrade for Ubuntu servers (recommended)

If you run an Ubuntu server, you should use the new server upgrade system.

   1......

I believe this should read:

To upgrade from Kubuntu 6.06 to 8.04 over the Internet,
    1. Log out of KDE, and log in as root to a console TTY session.
    2. Use the same procedure as for Ubuntu server, below.

Thanks for reporting this issue and helping make Ubuntu better.

I know this may be an ironic question, but: do you remember what the manual interventions were that it requested of you? At least which package it was referring to or something. The more information on that you can provide would be best.

Thanks!

Well, the first one was about manually configuring nut. There was
something about manually converting postgresql databases. There were lots
of errors from some perl module telling me that it couldn't set locale
because of some missing file, and listed three environment variables it
was trying to set, and said it was defaulting to LANG=C.
   I wish you could tell me that all those messages were archived in a file
somewhere...

   How did your party go the other night? Sorry I didn't make it, but I
chose to go to the Dance for the Earth in A2 instead.

Thanks for your bugreport.

Please attach the files in /var/log/dist-upgrade to this report. If kdm can not upgrade while it is running that is a serious issue, I haven't seen that in my tests, but the logs may give us a better idea why this happend.

I reassigned to kdm for now, please add additional bugtasks for the various other packages that are affected.

Here are the logs. The evidence is in apt-term.log, although it isn't
easy to see. It's surrounded by curses escape sequences...

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". ;-)

I don't see any evidence in the logs to be honest.

Also, I did about 5 upgrade scenarios and in none of them I had to restart KDM (which is indeed not required at all mid-upgrade).
However
  "
  Restarting services possibly affected by the upgrade:
    kdm: stopping...starting...done.
  "
apparently output by libpam0g, is absolutely sensible (KDM uses PAM for authentification, so if PAM gets updated all the services relying on it do as well. But if I recall correctly it only presents a lost if services which _should_ be restarted (editable list actually).

Please confirm that, or clearify what the dialog says _exactly_.

To be clear:

For me, the issue with having to *shutdown* kdm *prior* to doing the upgrade is separate from the issue of configuring 'libpam0g'. I don't think I even had the dialog about libpam0g.

What I did have, however, was that the dist-upgrade started, downloaded the package lists and calculated required changes, and at this point (before starting the actual upgrade), asked me stop kdm and try again.

So I cancelled out, logged out of X and stopped kdm, and started the dist-upgrade process again.

This time around it seemed to download (again) the same things, and calculate the required changes (again). But it managed to continue alright.

In sum:

In retrospect I cannot be sure if my issue with kdm is the same as the original submitter's issue with kdm. I assume yes, because the requirement to shutdown kdm was *unconditional* (as per the OP's "has to be manually shut down before it can proceed"), no options were given.

If this wasn't the case also for the OP, this may be a different issue.

Re: "several issues actually" (the OP)

It seems there was the unconditional "shutdown kdm" requirement, and then there were other interruptions, where options were given on how to proceed. Could/should these be handled separately, actually?

Other issues should go to new reports.

Ok.
This bug needs a lot more information.
Does it happen in clean dapper -> hardy upgrades?
What does the KDM-requires-restart-dialog say exactly?
When _exactly_ does it appear?

"What does the KDM-requires-restart-dialog say exactly?
When _exactly_ does it appear?"

Apologies for puttings this directly in the comment, but it seems sufficiently relevant and not excessively long. (Plus it's an extract of a log already attached to the report.)

Based on the logs, I have also now confirmed that my issue with 'kdm' *is* the same as the original submitter's issue.

As per the *very beginning* of the attached 'apt-term.log' (I've formatted it to remove the curses escapes, my 'apt-term.log' has the same):

"Log started: 2008-04-27 08:16:29
(Reading database ... 138739 files and directories currently installed.)
Preparing to replace apache2 2.0.55-4ubuntu2.3 (using .../apache2_2.2.8-1_all.deb) ...
Unpacking replacement apache2 ...
dpkg: linux-kernel-headers: dependency problems, but removing anyway as you request:
 libc6-dev depends on linux-kernel-headers (>= 2.6.11.2-0).
(Reading database ... 138741 files and directories currently installed.)
Removing linux-kernel-headers ...
Selecting previously deselected package linux-libc-dev.
(Reading database ... 137644 files and directories currently installed.)
Unpacking linux-libc-dev (from .../linux-libc-dev_2.6.24-16.30_i386.deb) ...
Preparing to replace binutils 2.16.1cvs20060117-1ubuntu2.1 (using .../binutils_2.18.1~cvs20080103-0ubuntu1_i386.deb) ...
Unpacking replacement binutils ...
Preparing to replace libc6-dev 2.3.6-0ubuntu20.5 (using .../libc6-dev_2.7-10ubuntu3_i386.deb) ...
Unpacking replacement libc6-dev ...
Preparing to replace libc6 2.3.6-0ubuntu20.5 (using .../libc6_2.7-10ubuntu3_i386.deb) ...
Checking for services that may need to be restarted...
Checking init scripts...

# *** N.B. The relevant dialog starts here. As said, extra formatting removed, plus emphasis stars added by me. ***

Ubuntu Configuration
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. The installation process is able to restart some
services (such as ssh or telnetd), but other programs cannot be restarted automatically. One such
program that *needs manual stopping and restart* after the glibc upgrade *by yourself* is xdm -
because automatic restart might disconnect your active X11 sessions.

This script detected the following installed services which *must* be stopped before the upgrade:
kdm

If you want to interrupt the upgrade now and continue later, please answer No to the question
below.

Do you want to upgrade glibc now?

<Yes> <No>

# *** Selected <No> to avoid the disconnecting active X11 sessions mentioned above. ***

*Stopped glibc upgrade. Please retry the upgrade after you have
checked or stopped services by hand.*
dpkg: error processing /var/cache/apt/archives/libc6_2.7-10ubuntu3_i386.deb (--unpack):
 subprocess pre-installation script returned error exit status 1
Errors were encountered while processing:
 /var/cache/apt/archives/libc6_2.7-10ubuntu3_i386.deb
Log ended: 2008-04-27 08:18:51

Log started: 2008-04-27 08:40:38

# (normal logging continued)"

Please note the time stamps of the last "Log ended" and "Log started" mentions. Between those 'kdm' wa...

Thank you kko for confirming this bug and parsing the evidence out of the
log file for easy readibility.

I gave a suggested resolution in one of my first posts: A one-line warning
in the web page, instructing the user to use the server update process
from a console TTY, not from an terminal window within KDE.
   It was a DUH! when I encountered it, and realized (too late) that the
server edition doesn't have a gui, so it would make sense to run the
server upgrade process from a tty, but I'm impatient, and I'm reading
instructions on a web page in a graphical browser, so I just open a
terminal window and start typing as I'm told. It would save someone else
the dope-slap if the web page had that one-line reminder.

   So why does it take six months to get a one-line change made to a single
web page???

"So why does it take six months to get a one-line change made to a single
web page???"

Hmm well, there's a limited number of eyes looking at bugs and of people fixing things, so patience is a virtue. You did mention you're impatient though. :-)

Then again, it seems the fact that 'kdm' did require manual stopping wasn't actually expected. Perhaps there are other remedies for the issue that may allow dist-upgrades directly from X in the future also for Kubuntu? (Not a huge priority for me, but may be more important from the developers' / other users' point of view.)

KDM doesn't require manual stopping.
NSS is, KDM uses NSS so glibc suggests to restart KDM.

I am still thinking about this, but in my humble opinion this is really an issue with the wording of the libc6 posinst script. It should advise to do a KDM restart _after_ the upgrade. It really doesn't make any difference if I restart it mid-upgrade or post-upgrade for KDM.

I'll just make this bug affect glibc and see what it's specialists think.

On Mon, 6 Oct 2008, kko wrote:

> "So why does it take six months to get a one-line change made to a single
> web page???"
>
> Hmm well, there's a limited number of eyes looking at bugs and of people
> fixing things, so patience is a virtue. You did mention you're impatient
> though. :-)
   Yes, I posess the best of qualities: Impatience when I want to get
something done, and Procrastination when I have to do something myself.
>
> Then again, it seems the fact that 'kdm' did require manual stopping
> wasn't actually expected. Perhaps there are other remedies for the issue
> that may allow dist-upgrades directly from X in the future also for
> Kubuntu? (Not a huge priority for me, but may be more important from the
> developers' / other users' point of view.)
>
Somehow, the gnome folks have accomplished a dist-upgrade from within the
gui, but from my old knowledge of X, the server dies when its initial
process terminates, so any attempt to restart kdm, which I believe is X's
'initial process', will cause X to die and all the subordinate
applications to spill their guts on the floor.
   So if it is indeed possible to upgrade kdm or even X itself while it is
running, it sems to me somewhat akin to changing the engine while speeding
down the freeway. That's clearly above my pay grade.
   So the one-line warning on the web page would be considered a
'circumvention' rather than a 'resolution', but I still think it would
save a few people some grief if that were added to the published
procedure.

Dapper to Hardy upgrades are no longer supported for Kubuntu, so marking kdm wontfix.

Marking glibc as invalid then.