ucf UI issues can cause upgrade failures

[sim]

There are two problems here with the current ucf that can cause upgrade failures:

a) when the user clicks "cancel" in the debconf gnome prompt, the script exists with 1 and update-grub fails

b) when the user starts a shell, the shell gets started in the terminal window that the upgrade is running in. this means that it may be difficult to find (its hidden by default) and that its obscured by the debconf gnome window that is on top of the upgrader window with the termianl

The problem with (b) is that people tend to get frusted and think it hangs and kill the debconf process (because it is not responding anymore).

Binary package hint: update-manager

I don't know the source of the problem

ProblemType: Package
Architecture: i386
Date: Sat Jun 28 21:56:29 2008
DistroRelease: Ubuntu 8.04
ErrorMessage: ErrorMessage: SystemError in cache.commit(): E:Sub-process /usr/bin/dpkg returned an error code (1)

NonfreeKernelModules: nvidia
Package: update-manager 1:0.87.27
PackageArchitecture: all
SourcePackage: update-manager
Title: package update-manager 1:0.87.27 failed to install/upgrade: ErrorMessage: SystemError in cache.commit(): E:Sub-process /usr/bin/dpkg returned an error code (1)
Uname: Linux 2.6.22-15-generic i686

[Michael Vogt (mvo)]

Thanks for your bugreport

This looks like a bug in ucf/update-grub to me, from the log:
Paramétrage de linux-image-2.6.24-19-generic (2.6.24-19.34) ...
Running depmod.
update-initramfs: Generating /boot/initrd.img-2.6.24-19-generic
Running postinst hook script /sbin/update-grub.
Searching for GRUB installation directory ... found: /boot/grub
Searching for default file ... found: /boot/grub/default
Testing for an existing GRUB menu.lst file ... found: /boot/grub/menu.lst
Searching for splash image ... none found, skipping ...
Found kernel: /boot/vmlinuz-2.6.24-19-generic
Found kernel: /boot/vmlinuz-2.6.22-15-generic
Found kernel: /boot/vmlinuz-2.6.20-16-generic
Found kernel: /boot/vmlinuz-2.6.20-15-generic
Found kernel: /boot/memtest86+.bin
root@simon-desktop:/#
...
root@simon-desktop:/etc# ex
root@simon-desktop:/etc# exi
root@simon-desktop:/etc# exit
exit
The application 'frontend' lost its connection to the display :0.0;
most likely the X server was shut down or you killed/destroyed
the application.
User postinst hook script [/sbin/update-grub] exited with value 1
dpkg : erreur de traitement de linux-image-2.6.24-19-generic (--configure) :
 le sous-processus post-installation script a retourné une erreur de sortie d'état 1
/usr/share/debconf/confmodule: line 42: printf: erreur d'écriture : Relais brisé (pipe)
dpkg : des problèmes de dépendances empêchent la configuration de linux-ubuntu-modules-2.6.24-19-generic :

So this seems like after you entered the shell and exited it again that made ucf/debconf fail with a exit code and that caused the postinst script of the kernel to fail. I will try to reproduce this.

I assume you had a gnome dialog that asked you about changes in a config file before the crash?

[Michael Vogt (mvo)]

I tried various ways to reproduce the problem and I think there are two problems here with the current ucf:

a) when the user clicks "cancel" in the debconf gnome prompt, the script exists with 1 and update-grub fails
b) when the user starts a shell, the shell gets started in the terminal window that the upgrade is running in. this means that it may be difficult to find (its hidden by default) and that its obscured by the debconf gnome window that is on top of the upgrader window with the termianl

Thanks,
 Michael

[Steve Langasek (vorlon)]

Hi Michael,

I'm interested to know what you would recommend we do instead of erroring out in this first case. Should the user not be allowed to cancel the debconf prompt? Should it immediately respawn the prompt? Should the cancel be treated as equivalent to the default option?

I have a hard time accepting that any of these options are an improvement over the current behavior - to me, "cancel" translates to "defer this until later", which is exactly what happens now with all the negative side effects - but I'm certainly happy to consider ways that this can be improved and help to implement them.

For the second case, I agree that it's a bug. What would you advise we do here? Some options that come to mind would be to suppress the shell option based on the debconf frontend, to reword the template to always tell users the shell will appear in the background, or to unconditionally drop the shell option.

[Michael Vogt (mvo)]

Hey Steve,

sorry for me late reply. You are right about (a) cancel should mean cancel. However it may be better to display either a warning that this will make the upgrade of this package fail so that the user has a choice about it. It seems to me like a lot of users who don't know what to choose just click on cancel as a way say "make this dialog go away".

For (b) I was thinking of something like this:

diff -Nru ucf-3.007/ucf ucf-3.007ubuntu1/ucf
--- ucf-3.007/ucf 2008-05-30 08:22:03.000000000 +0200
+++ ucf-3.007ubuntu1/ucf 2008-08-05 20:31:07.000000000 +0200
@@ -953,7 +953,11 @@
                 exit 0
                ;;
            shell|Z|z)
- bash >/dev/tty </dev/tty || true
+ if [ -n "$DISPLAY" ]; then
+ x-terminal-emulator || true
+ else
+ bash >/dev/tty </dev/tty || true
+ fi
                ;;
            keep_current|n|N|o|O|'')
                replace_md5sum;

Maybe with a added "[ "$DEBIAN_FRONTEND" = "gnome" ] || [ "$DEBIAN_FRONTEND" = "kde" ]; "

What do you think?

Thanks,
 Michael

[Michael Vogt (mvo)]

I added code to the gnome debconf frontend now that will hide the cancel button and the close button on release upgrades. This should fix (a). I also sent the patch upstream and hope it gets accepted as new default.

[Steve Langasek (vorlon)]

This bug has been fixed upstream in ucf 3.0017:

  * [989de4e]: No longer use a non debconf method to prompt the user
    Also, only run bash directly is the script has a terminal backend.
    Failing that, if DISPLAY is set, try to start a terminal emulator.
    If there is no tty and no DISPLAY, gibber and do nothing.

 -- Manoj Srivastava <email address hidden> Sat, 21 Mar 2009 00:02:03 -0500

I've confirmed that when using the GNOME debconf frontend there is no tty set even though update-manager provides one for the parent script, so this works even though ucf gives preference to launching the shell directly instead of through an xterm.

If I've overlooked some case where this is still an issue, please reopen.