Distribution Upgrade to karmic freezes on gtk-doc-tools

Bug #456523 reported by Markus Schulz on 2009-10-20
16
This bug affects 1 person
Affects Status Importance Assigned to Milestone
apport (Ubuntu)
Undecided
Unassigned
emacsen-common (Debian)
Fix Released
Unknown
emacsen-common (Ubuntu)
Undecided
Loïc Minier
update-manager (Ubuntu)
Undecided
Unassigned

Bug Description

Binary package hint: update-manager

markus@cindy-desktop:~$ ps -A
...
 6604 ? 00:33:30 karmic
...

markus@cindy-desktop:~$ sudo ubuntu-bug 6604
Traceback (most recent call last):
  File "/usr/share/apport/apport-gtk", line 348, in <module>
    app.run_argv()
  File "/usr/lib/python2.6/dist-packages/apport/ui.py", line 435, in run_argv
    return self.run_report_bug()
  File "/usr/lib/python2.6/dist-packages/apport/ui.py", line 317, in run_report_bug
    self.report.add_proc_info(self.options.pid)
  File "/usr/lib/python2.6/dist-packages/apport/report.py", line 346, in add_proc_info
    assert os.path.exists(self['ExecutablePath'])
AssertionError

ProblemType: Bug
Architecture: i386
Date: Tue Oct 20 13:36:43 2009
DistroRelease: Ubuntu 9.10
NonfreeKernelModules: nvidia
Package: update-manager 1:0.126.4
PackageArchitecture: all
ProcEnviron:
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.28-15.52-generic
SourcePackage: update-manager
Uname: Linux 2.6.28-15-generic i686
XsessionErrors:
 (gnome-settings-daemon:4510): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed
 (gnome-panel:4579): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget with width -4 and height 24
 (gnome-panel:4579): libglade-WARNING **: Unexpected element <requires-version> inside <glade-interface>.
 (firefox:17931): Gtk-CRITICAL **: gtk_widget_destroy: assertion `GTK_IS_WIDGET (widget)' failed
 (gnome-panel:4579): libglade-WARNING **: could not find glade file '/usr/share/gnome-panel/glade/panel-run-dialog.glade'

reassign 153860 emacsen-common
thanks

Note for the emacsen-common maintainer:

I ALREADY know that gettext-el in woody does not depend on emacsen.
This was a required compromise for the gettext/gettext-el split.

gettext_0.10.40-7 already depends on emacsen, I don't need you to make
a crusade against gettext-el, thanks, so please make emacsen-common
more robust. Giving an error just make everybody to waste time
and does not help anybody.

> Package: gettext-el
> Version: 0.10.40-6
> Severity: important
>
> whilst performing my daily apt-get upgrade.. (can reproduced this on two machines):
>
> grumble:~# apt-get upgrade
> Reading Package Lists... Done
> Building Dependency Tree... Done
> 1 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> 18 packages not fully installed or removed.
> Need to get 0B/41.9kB of archives. After unpacking 0B will be used.
> Do you want to continue? [Y/n]
emacsen-common> (Reading database ... 34443 files and directories currently installed.)
> Preparing to replace gettext-el 0.10.40-6 (using
> .../gettext-el_0.10.40-7_all.deb) ...
> ERROR: emacsen-common being used before being configured.
> ERROR: This is likely a bug in the gettext-el package, which needs to
> ERROR: add one of the appropriate dependencies.
> ERROR: See /usr/share/doc/emacsen-common/debian-emacs-policy.gz
> ERROR: for details.
> dpkg: warning - old pre-removal script returned error exit status 2
> dpkg - trying script from the new package instead ...
> ERROR: emacsen-common being used before being configured.
> ERROR: This is likely a bug in the gettext-el package, which needs to
> ERROR: add one of the appropriate dependencies.
> ERROR: See /usr/share/doc/emacsen-common/debian-emacs-policy.gz
> ERROR: for details.
> dpkg: error processing
> /var/cache/apt/archives/gettext-el_0.10.40-7_all.deb (--unpack):
> subprocess new pre-removal script returned error exit status 2
> ERROR: emacsen-common being used before being configured.
> ERROR: This is likely a bug in the gettext-el package, which needs to
> ERROR: add one of the appropriate dependencies.
> ERROR: See /usr/share/doc/emacsen-common/debian-emacs-policy.gz
> ERROR: for details.
> dpkg: error while cleaning up:
> subprocess post-installation script returned error exit status 2
> Errors were encountered while processing:
> /var/cache/apt/archives/gettext-el_0.10.40-7_all.deb
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> grumble:~#

severity 153860 serious
thanks

Hi.. I've experienced this problem as well, this time with the sawfish
package.

I did a full upgrade today, which included an upgrade of sawfish and a
new install of emacsen-common. As a result:

  Preparing to replace sawfish 1:1.3+cvs20031104-2 (using
    .../sawfish_1%3a1.3+cvs20031104-3_i386.deb) ...
  ERROR: emacsen-common being used before being configured.
  ERROR: This is likely a bug in the sawfish package, which needs to
  ERROR: add one of the appropriate dependencies.
  ERROR: See /usr/share/doc/emacsen-common/debian-emacs-policy.gz
  ERROR: for details.
  dpkg: warning - old pre-removal script returned error exit status 2
  dpkg - trying script from the new package instead ...
  ERROR: emacsen-common being used before being configured.
  ERROR: This is likely a bug in the sawfish package, which needs to
  ERROR: add one of the appropriate dependencies.
  ERROR: See /usr/share/doc/emacsen-common/debian-emacs-policy.gz
  ERROR: for details.
  dpkg: error processing
  /var/cache/apt/archives/sawfish_1%3a1.3+cvs20031104-3_i386.deb
  (--unpack):
   subprocess new pre-removal script returned error exit status 2

I presume the error was generated by the prerm for the old sawfish,
which calls emacs-package-remove. At this stage emacsen-common has been
unpacked but not configured.

I'm marking this as serious since it causes packages to fail to
configure. If it's a sawfish problem, feel free to reassign it - I'm
not particularly familiar with emacs policy. However, if emacsen-common
requires itself to be configured before use then it seems that packages
such as gettext-el and sawfish should pre-depend on emacsen-common,
which is certainly not mentioned in emacs policy.

CCing the sawfish maintainer also.

Thanks - Ben. :)

reassign 153860 sawfish
thanks

This bug looks like it was fixed in gettext-el, but the latest
addition to the bug report suggests that sawfish has the same problem
(i.e. calls emacsen-common code without arranging the dependencies as
per /usr/share/doc/emacsen-common/debian-emacs-policy.gz), so I'm
reassigning this bug to sawfish.

--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

This should be closed then, since it looks like the gettext bug has
also been fixed.

Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

reassign 153860 gettext-el
thanks

<email address hidden> (Debian Bug Tracking System) writes:

> Processing commands for <email address hidden>:
>
>> reassign 153860 sawfish
> Bug#153860: gettext-el: apt-get update. dpkg: error processing /var/cache/apt/archives/gettext-el_0.10.40-7_all.deb (--unpack)
> Bug reassigned from package `emacsen-common' to `sawfish'.

Thanks for the Cc: ...

> This bug looks like it was fixed in gettext-el, but the latest
> addition to the bug report suggests that sawfish has the same problem
> (i.e. calls emacsen-common code without arranging the dependencies as
> per /usr/share/doc/emacsen-common/debian-emacs-policy.gz), so I'm
> reassigning this bug to sawfish.

Sorry but no, sawfish don't need to byte-compile sawfish.el and thus
don't need to depends on emacsen-common.

Also this bug report display gettext error messages and nothing is
related to sawfish.

Christian

reassign 153860 emacsen-common
retitle 153860 emacsen-common SHOULD be more robust
severity 153860 important
thanks

Christian Marillat wrote:

> Processing commands for <email address hidden>:
>
> > reassign 153860 gettext-el
> Bug#153860: gettext-el: apt-get update. dpkg: error processing /var/cache/apt/archives/gettext-el_0.10.40-7_all.deb (--unpack)
> Bug reassigned from package `sawfish' to `gettext-el'.

This bug was fixed in gettext_0.10.40-8 as shown by the changelog:

  * Made gettext-el prerm and postinst fault-tolerant, since emacsen-common
    is not. Should allow upgrades from woody.

I reiterate that emacsen-common needs to be more robust. Failing to
work just because a missing dependency WHEN IT IS PERFECTLY POSSIBLE
for emacsen-common to deal with this is just WRONG.

There is NOTHING vitally important in emacsen-common.postinst which may
not be done in /usr/lib/emacsen-common/emacs-package-install AS WELL
the first time it's used.

Reassigning again, since emacsen-common has not changed at all since
woody was released.

On Thu, 8 Jan 2004, Rob Browning wrote:

> Santiago Vila <email address hidden> writes:
>
> >> This should be closed then, since it looks like the gettext bug has
> >> also been fixed.
> >
> > Please don't. Failing to work just because a missing dependency when
> > it is *perfectly* possible for emacsen-common to deal with this is
> > wrong.
>
> It seems like a reasonable counter-argument to claim that packages
> shouldn't be expected to work around missing package dependencies in
> their install scripts, even if it's possible, and that it's the
> responsibility of the package to get its dependencies right.

I mostly agree with that, but only as a general rule. In this case the
dependency is not the typical shared library dependency, it's just a
dependency to make sure emacsen-common.postinst is executed at least
once before emacs-package-install is executed for the first time.

Now let's analyze: What does emacsen-common.postinst really do?
It does several things, but it basically creates the file
/var/lib/emacsen-common/installed-flavors as an empty file
if it does not exist. This is a trivial task which could well
be done by emacs-package-install, it's not such a complex task.

My point is that failing to create an empty file, which is a rather
trivial task, should not make an entire upgrade to fail.

People expect upgrades to be smooth. I of course agree that packages
not following emacs policy deserve a bug and they should be fixed, but
in the hypothetical case that we release sarge with packages not
following emacs policy, many upgrades will fail miserably, causing
trouble to lots of people, this could be avoided easily by
emacsen-common being a little bit fault-tolerant, I'm not talking
about doing weird things, it's just a matter of creating a single
file if it does not exist.

> Breaking the install just highlights the problem, and probably makes
> sure the package won't get into testing or stable until it's fixed.

But that's not a proportionate effect for not creating a single file
which emacs-package-install could create trivially.

As for "highlighting the problem", I have already suggested that you
stop the upgrade while the warning message is shown to the user.
If you stop the upgrade and ask the user to report it as a serious
bug and then press enter, it is almost sure that bugs will be filled,
but even if it's not and we release sarge with packages having this bug,
upgrading from woody to sarge will not be a nightmare.

If by accident we release sarge with packages not following emacs policy,
there will be no point in making upgrades to fail "so that bugs are
reported", because these bugs will never be fixed in sarge, the will
only be fixed in unstable.

For this reason I think the lack of fault-tolerance is disproportionate.
It's just a matter of creating a single file.

Santiago Vila <email address hidden> writes:

> Now let's analyze: What does emacsen-common.postinst really do?
> It does several things, but it basically creates the file
> /var/lib/emacsen-common/installed-flavors as an empty file
> if it does not exist. This is a trivial task which could well
> be done by emacs-package-install, it's not such a complex task.

But it also makes the guarantee that if a postinst succeeds, then
emacsen-common (and whatever packages are properly configured using
it) are properly installed and ready to go.

What I'm vaguely concerned about is setting emacsen-common up in any
way that can make it look like everything's OK, when in fact say gnus
(for example), is now misconfigured (or partially configured) in some
way that can lose mail. I'm not *sure* this is critical, but I'm not
sure it's not either, and hence my hesitation. I'm also wondering
about how this problem might be amplified by broken emacsen-packages
that other emacsen packages depend on (i.e. if gnus depends on
mail-foo-el, and mail-foo-el doesn't get set up right).

Causing the install to fail at least guarantees that it will be
obvious that something's wrong, and may prevent compounding the
problem by proceeding anyway.

I suppose one possibility might be to change the error to say
something like "It looks like this package is using the emacs
infrastructure improperly, please report this as a bug, and, as a
temporary fix, you should probably be able to just remove this package
and then resume your install/upgrade." Would that address any of your
concerns, or would it still be too severe?

> For this reason I think the lack of fault-tolerance is disproportionate.
> It's just a matter of creating a single file.

To me it's not "creating the single file" that's my main concern, it's
the semantic implications of exiting without an error code when
emacsen-common knows something has gone wrong.

Don't get me wrong, I'm not convinced either way yet, but I need to
think it over a bit more before I could comfortably decide to change
the behavior. I'll think about it a bit, and perhaps ask on
debian-emacsen.

--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Santiago Vila <email address hidden> writes:

>> This should be closed then, since it looks like the gettext bug has
>> also been fixed.
>
> Please don't. Failing to work just because a missing dependency when
> it is *perfectly* possible for emacsen-common to deal with this is
> wrong.

It seems like a reasonable counter-argument to claim that packages
shouldn't be expected to work around missing package dependencies in
their install scripts, even if it's possible, and that it's the
responsibility of the package to get its dependencies right. Breaking
the install just highlights the problem, and probably makes sure the
package won't get into testing or stable until it's fixed.

I'll have to think about it, but at the moment I'm still inclined
toward closing this.

In any case, I appreciate the discussion, and sorry that bug got
reassigned to you *again*.
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

reopen 153860
originator 153860 <email address hidden>
thanks

On Wed, 7 Jan 2004, Rob Browning wrote:

> This should be closed then, since it looks like the gettext bug has
> also been fixed.

Please don't. Failing to work just because a missing dependency when it
is *perfectly* possible for emacsen-common to deal with this is wrong.

Please change the ERROR messages into a WARNING and modify
emacs-package-install so that it does whatever it's required to
initialize the database. Pause the upgrade until the user press Enter
if you like, so that the user has time to write down the message and
report it as a bug, tell the user to submit a serious bug if you like,
but Debian is known (and we aim) to be *robust*. The fact that
emacsen-common makes the upgrade to fail when there is not a real and
absolute need damages the reputation of Debian being robust.

submitter 153860 <email address hidden>
thanks

Sorry, it was "submitter", not "originator".

Package: emacsen-common
Version: 1.4.15
Followup-For: Bug #153860

This bug has been biting for looks like a couple of years. I think it's
high time to stomp it, yes? It hasn't gone away -- because the postinst
script at: /var/lib/dpkg/info/emacsen-common.postinst doesn't appear to
have been fixed, AFAIK.

There are at least TWO places it actually fails -- and not gracefully.
Right at the top:

 ##!/bin/sh
 #
 #set -e
 #
 #if [ "$1" = "configure" ]
 #then
 # if [ -d /usr/doc \
 # -a ! -e /usr/doc/emacsen-common \
 # -a -d /usr/share/doc/emacsen-common ]
 # then
 # ln -sf ../share/doc/emacsen-common /usr/doc/emacsen-common
 # fi
 #fi

If I'm not mistaken, this code fails because:
 # ln -sf ../share/doc/emacsen-common /usr/doc/emacsen-common
fails -- since the operation is not carried-out inside /usr/doc.
And it, of course, causes all depending package installs to fail too.
(This bug is just "important", right? Not 'grave'..?)

I fixed it by running:
 # ln -sf ../share/doc/emacsen-common /usr/doc/emacsen-common
myself.

The script also bails out (for me, anyway) at your favorite spot:

 #if [ ! -e /var/lib/emacsen-common/installed-flavors ]
 #then
 # # Be super-careful.
 # echo -n "" > /var/lib/emacsen-common/installed-flavors
 # chmod 644 /var/lib/emacsen-common/installed-flavors
 # echo -n "" > /var/lib/emacsen-common/installed-flavors
 #fi

I note that /var/lib/emacsen-common/ itself didn't exist on my
system -- and that is enough for the script to fail AFAIC see.
This problem went away(?) after I just created /var/lib/emacsen-common/
and THEN touched /var/lib/emacsen-common/installed-flavors.

All in all I'd say that having this buggy script hanging around for
2+(?) years causing problems is reason to be asking a few questions
beyond the technical.

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (998, 'testing'), (99, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.4.20
Locale: LANG=en_US, LC_CTYPE=en_US

Versions of packages emacsen-common depends on:
ii bsdmainutils 6.0.15 collection of more utilities from

-- no debconf information

"Jim W. Jaszewski" <email address hidden> writes:

> If I'm not mistaken, this code fails because:
> # ln -sf ../share/doc/emacsen-common /usr/doc/emacsen-common
> fails -- since the operation is not carried-out inside /usr/doc.

Agreed, that's probably wrong. I'll try to have a fix out shortly.

> The script also bails out (for me, anyway) at your favorite spot:
>
> #if [ ! -e /var/lib/emacsen-common/installed-flavors ]
> #then
> # # Be super-careful.
> # echo -n "" > /var/lib/emacsen-common/installed-flavors
> # chmod 644 /var/lib/emacsen-common/installed-flavors
> # echo -n "" > /var/lib/emacsen-common/installed-flavors
> #fi
>
> I note that /var/lib/emacsen-common/ itself didn't exist on my
> system

Hmm, I'm not sure how it couldn't exist since it's in the
emacsen-common package, and this script is the postinst.

--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Binary package hint: update-manager

markus@cindy-desktop:~$ ps -A
...
 6604 ? 00:33:30 karmic
...

markus@cindy-desktop:~$ sudo ubuntu-bug 6604
Traceback (most recent call last):
  File "/usr/share/apport/apport-gtk", line 348, in <module>
    app.run_argv()
  File "/usr/lib/python2.6/dist-packages/apport/ui.py", line 435, in run_argv
    return self.run_report_bug()
  File "/usr/lib/python2.6/dist-packages/apport/ui.py", line 317, in run_report_bug
    self.report.add_proc_info(self.options.pid)
  File "/usr/lib/python2.6/dist-packages/apport/report.py", line 346, in add_proc_info
    assert os.path.exists(self['ExecutablePath'])
AssertionError

ProblemType: Bug
Architecture: i386
Date: Tue Oct 20 13:36:43 2009
DistroRelease: Ubuntu 9.10
NonfreeKernelModules: nvidia
Package: update-manager 1:0.126.4
PackageArchitecture: all
ProcEnviron:
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.28-15.52-generic
SourcePackage: update-manager
Uname: Linux 2.6.28-15-generic i686
XsessionErrors:
 (gnome-settings-daemon:4510): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed
 (gnome-panel:4579): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget with width -4 and height 24
 (gnome-panel:4579): libglade-WARNING **: Unexpected element <requires-version> inside <glade-interface>.
 (firefox:17931): Gtk-CRITICAL **: gtk_widget_destroy: assertion `GTK_IS_WIDGET (widget)' failed
 (gnome-panel:4579): libglade-WARNING **: could not find glade file '/usr/share/gnome-panel/glade/panel-run-dialog.glade'

Michael Vogt (mvo) wrote :

Thanks for your bugreport.

This looks like it is triggered by a bug in gtk-doc-tools. Please attach file in /var/log/dist-upgrade/*

Changed in update-manager (Ubuntu):
status: New → Incomplete
Michael Vogt (mvo) wrote :

The assertion error is something for apport:

markus@cindy-desktop:~$ sudo ubuntu-bug 6604
Traceback (most recent call last):
  File "/usr/share/apport/apport-gtk", line 348, in <module>
    app.run_argv()
  File "/usr/lib/python2.6/dist-packages/apport/ui.py", line 435, in run_argv
    return self.run_report_bug()
  File "/usr/lib/python2.6/dist-packages/apport/ui.py", line 317, in run_report_bug
    self.report.add_proc_info(self.options.pid)
  File "/usr/lib/python2.6/dist-packages/apport/report.py", line 346, in add_proc_info
    assert os.path.exists(self['ExecutablePath'])
AssertionError

affects: update-manager (Ubuntu) → gtk-doc (Ubuntu)

Something in my profile was bad... gnome was not longer starting the desktop... computer froze with black screen and round waiting mouse icon not longer spinning... thanks to don't zap settings I can not longer ctrl alt backspace the the system... the only way to recover was to boot to recovery console (thanks to upstart this is also not working line in the pase... always kicks me out because of mountall error???) and delete the whole content of my home directory... this upgrade was a disaster! Anyway... here are the files.

Michael Vogt (mvo) wrote :

Thanks for the logs and sorry for the trouble. The upstart recovery menu issue is in the process of being fixed now (the upload will happen today).

Here is the error from the gtk-doc-tools:
2009-10-20 08:11:36,324 ERROR got an error from dpkg for pkg: '/var/cache/apt/archives/gtk-doc-tools_1.11-4_all.deb': 'subprocess new pre-removal script returned error exit status 2

And here is the terminal log:

Preparing to replace gtk-doc-tools 1.11-3 (using .../gtk-doc-tools_1.11-4_all.deb) ...
b) ...
ERROR: emacsen-common being used before being configured.
ERROR: This is likely a bug in the gtk-doc-tools package, which needs to
ERROR: add one of the appropriate dependencies.
ERROR: See /usr/share/doc/emacsen-common/debian-emacs-policy.gz
ERROR: for details.
dpkg: warning: old pre-removal script returned error exit status 2
dpkg - trying script from the new package instead ...
dpkg: error processing /var/cache/apt/archives/gtk-doc-tools_1.11-4_all.deb (--unpack):
 subprocess new pre-removal script returned error exit status 2

Changed in apport (Ubuntu):
status: New → Invalid
Changed in gtk-doc (Ubuntu):
status: Incomplete → Confirmed
Michael Vogt (mvo) wrote :

@Markus did ctrl-alt-f1 no longer work for you as well? To enter a console when gnome was hanging?

Loïc Minier (lool) wrote :

gtk-doc-tools uses the dh_installemacsen maintainer scripts snippets; a bunch of other packages do this. I think we could either fix the snippet to also check before using the hook that emacsen-common is configured too (and not merely unpacked), or we could fix the hook to not do anything if emacsen-common isn't configured yet.

Loïc Minier (lool) wrote :
affects: gtk-doc (Ubuntu) → emacsen-common (Ubuntu)
Changed in emacsen-common (Ubuntu):
status: Confirmed → Fix Committed
assignee: nobody → Loïc Minier (lool)
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package emacsen-common - 1.4.19ubuntu1

---------------
emacsen-common (1.4.19ubuntu1) karmic; urgency=low

  * emacs-package-install: don't throw an error when maintainer scripts call
    this hook while emacsen-common isn't yet configured; LP: #456523.

 -- Loic Minier <email address hidden> Mon, 26 Oct 2009 11:39:15 +0000

Changed in emacsen-common (Ubuntu):
status: Fix Committed → Fix Released

@Michael Vogt: after the freeze I was not able to switch to a console. My first plan was to kill the xserver before the freeze and change the user (I have auto login - and if you start a root console from recovery console: and start X you can not change the auto login because the root account can not unlock???)... because I knew the freeze was very late in the boot, like right before the black screen with the two white bars on top and bottom change to the normal looking desktop... this gave me the hint that there is something in my home folder that is preventing me from starting up... so I created a new user to test this... but at this time I didn't know all I needed was to start gdm... so I rebooted and tried to zap the x server so I see the login (because of auto login, this worked in the past), but this was not enabled (is there a key I can hold down to abort the auto login?).
So I changed back to root console and renamed my home directory and copied the new uses directory in it's place... since this time I have no more problems. Except all my personal configuration is lost, but this is only the kids PC with Edubuntu. I'm not sure what is causing the issues, if there is a logfile you know about that could help I would like to look.

Michael Vogt (mvo) wrote :

Thanks for your reply Markus.

The ~/.xsession-errors file from the session when it hangs would be interessting. Maybe it gives a clue about the hang.

I wonder if maybe when update-manager hanged a "apport" window was on the same screen that was blocking the input of update-manager? You don't happen to have a bigger photo of the screen with the taskbar ?

Changed in update-manager (Ubuntu):
status: New → Incomplete
Changed in emacsen-common (Debian):
status: Unknown → New
Changed in emacsen-common (Debian):
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.