[Hardy] startupmanager-1.9.10-2 hangs at "Performing post-configureation tasks"

Open a terminal and run 'sudo update-initramfs -uk all' to see if that hangs too. If not, try 'sudo update-grub'.
Those are the two commands sum run at shutdown, so I am guessing the problem lies with one of those.

The problem seems to have corrected itself....

great

I suppose that's what "Fix Released" meant...

I guess I can put it as incomplete as well.

I recently ran into this problem as well, where /usr/sbin/startupmanager is stalling on post-config.

System Monitor shows the following dependencies:
>gksu (gksu /usr/sbin/startupmanager)
->/usr/sbin/start (python /usr/sbin/startupmanager)
-->sh (sh -c /usr/sbin/update-grub)
--->frontend (/usr/bin/perl -w /usr/share/debconf/frontend /usr/sbin/update-grub)
---->update-grub (/bin/bash /usr/sbin/update-grub)
----->ucf (/bin/bash /usr/bin/ucf --debconf-ok --debconf-template grub/update_grub_changeprompt_threeway --three-way /tmp/file7lzQIC /var/run/grub/menu.lst)

Note: Yes, I changed the way startupmanager gets su privileges. I have had the same issue whether using my 'gksu /usr/sbin/startupmanager' or the default 'su-to-root -X -c /usr/sbin/startupmanager'. Also, the dependency list is mostly the same as expected. All programs are running as 'root' except gksu which is running under my user name.

This seems to be an issue with X(?) not activating the ucf window for me to decide to keep my menu.lst or switch to the new one created by the changes made in startupmanager.

When I try to 'End Process' on ucf, update-grub goes into Zombie mode since it doesn't know what to do next; I cant end or kill it. Next up: frontend. I can't reproduce this at the moment b/c a new problem just occurred...
.....
System-Monitor crashes while trying to restart itself as su to 'End Process' the root program ucf. "Starting Administrati..." shows up in the window-list applet, but then just goes away after a few seconds. This sys-mon crash happens anytime sys-mon tries to RESTART itself as su. It does not happen if I initiate sys-mon with gksu/sudo.

I will eventually look more into this and file it if needed. But for now, here is the command log output if you're interested:
derek@torproxy1000101:~$ gnome-system-monitor --sync

** (gnome-system-monitor:13032): WARNING **: SELinux was found but is not enabled.

The program 'gnome-system-monitor' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadMatch (invalid parameter attributes)'.
  (Details: serial 78267 error_code 8 request_code 1 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

I must use gksu/sudo gnome-system-monitor for it to work properly. All-in-all, it seems like Ubuntu 8.04 has a serious problem with starting su tasks from non-su'd administrative programs and making them interact properly with the X desktop. (Although all my "Unlock" buttons work OK, i.e. Time/Network applets.)
.....
Anyways, had this new problem not shown up, I would 'end' ucf, ignore the Zombie'd update-grub, 'end' frontend, sh exits by itself immediately after frontend stops, then about 0.5 seconds later gksu & startupmanager exit on their own.

To redo these fracked up attempts. I re-open startupmanager, make a simple change, save/exit (Note: It never stalled on me when I was quick), re-...

Forgot to say I have version 1.9.11-1~hardy1 from hardy-updates.

Also, I did a bit more testing and found that when I ran 'sudo startupmanager' from gnome-terminal, the post-config correctly launches the DOS-style diff for menu.lst and does not stall when it does so.

This only occurs when major items are changed in the GUI, such as boot splash/boot text, resolution, depth; which all change entries like 'defoptions' in menu.lst. These are then translated to the Automagic Kernel List at the bottom of menu.lst by update-grub. Agreeably, this is much better than trying to parse through the list and make the changes manually with startupmanager alone.

However, the default Gnome menu launcher does not seem to allow ucf to come to the users attention to make the needed changes to update the Automagic Kernel List. Alternatively, if ucf has a option to force the use of the newly created menu.lst (they call it the package manager's version), then that option should be used when ucf/update-grub is called.

I believe I have explained this error quite well. I have not looked at the source in order to verify my line of thought, nor would I be very qualified to; so, I leave that up to you guys. Please let me know if I can be of anymore help.

TEMP. BUG WORK-AROUND
----------------------------------
NOTE: If you have custom boot options for Windows/Etc. make sure they are above the "### BEGIN AUTOMAGIC KERNELS LIST" and/or below the "### END DEBIAN AUTOMAGIC KERNELS LIST" lines in your /boot/grub/menu.lst file PRIOR to using any program that runs update-grub, including StartUp-Manager, OR ELSE YOU WILL LOSE THEM.

1) Launch StartUp-Manager from a terminal (gnome-terminal) using "sudo startupmanager".
2) Make your changes, close, and wait for your terminal to come back to you while post-config runs.
3) If the ASCI-style window comes up in the terminal window, select the option to use the package maintainer's version. This will replace your old menu.lst with the updated menu.lst that StartUp-Manager created for you.

Sorry if this bug wont get any attention, but just so you know, I have retired from this project. Got tired of fixing these bugs caused by the changes in every new version of the operating system. If noone else steps up I guess it is dead.

Just a question for you who get the "ASCI-style window":
Have you manually edited menu.lst or used another tool to edit it before using sum?
Since this is triggered by edits to the automagically(by update-grub) generated part of menu.lst, which sum NEVER touches, my guess is that something else has been messing with that part.

I thought you were done with sum Jimmy! :)

Anyways, I have upgraded to Intrepid since I had this problem. With Intrepid's version (1.9.11-1) I have changed the resolution/color depth, the usplash theme, menu colors, and recently checked one (1) misc boot option all without any problems. Post-config took maybe 30-45 seconds on my latest changes.

Back to your question: I may have had my Vista boot option in the wrong place in menu.lst, but cannot verify that this is true as I no longer have my backups from Hardy, but any custom options would have been wiped by update-grub (or whatever is run to update menu.lst) and this never happened. So, I do not believe I manually edited any of the Automagically created kernel list. Besides, any changes needed can easily be made to other sections/options of menu.lst and update-grub will pull them to the automagic list.

Just to test further, I removed the recovery mode check box, closed sum to apply the changes (they went quick, much quicker than the 30-45 secs for the boot option change earlier), re-ran to verify the new list of kernels, re-checked the recovery mode option, closed to apply, re-ran to check: everything went A-OK.

Then, to test the theory that the more time sum is opened and running the longer it takes to apply changes: I made no changes, just left the program running for 5-7 minutes clicking around occasionally, closed it, post-config ran for at least 40seconds as my 40pixel 1000ms sysmon gauge was completely full with 100% cpu (75%user 25%system). But, it did finish eventually and exited happily.

Basically, a good program, a little finicky, but it only needs run once every blue moon; so, not really a problem in my eyes now that it's working better under Intrepid.

It happened again...See the following for detailed description:

https://bugs.launchpad.net/ubuntu/+source/fontconfig/+bug/271246/comments/7

Maybe update-grub doesn't like a menu.lst~ or a menu.lst.backup being in /boot/grub?

After fixing the problems listed in bug 271246 and removing the 2 old files, running startupmanager from a terminal window brings up the ASCI window during "Performing pre-configuration tasks" and I selected to keep the local version (I'm gonna redo it all anyways).

Did my stuff in sum, and during post-config, the ASCI window came up again...selecting to view a 3-way difference shows the following:

5a
||||||| Older
kernel /vmlinuz-2.6.28-11-generic root=/dev/mapper/dereksbox-root ro
splash vga=795
=======
kernel /vmlinuz-2.6.28-11-generic root=/dev/mapper/dereksbox-root ro
vga=795 splash
>>>>>>> New
.
4a
<<<<<<< Current
.

The only difference seems to be the order of vga= and splash... I selected to install the package maintainer's version (sum's?) this time.

Complete terminal log:

derek@dereksbox:/boot/grub$ sudo startupmanager
Grub2 not detected
Version: ImageMagick 6.4.5 2009-01-22 Q16 OpenMP http://www.imagemagick.org
Copyright: Copyright (C) 1999-2008 ImageMagick Studio LLC

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 ... found: /grub/splashimages/grub-fingerprint-0.11.xpm.gz

Found kernel: /vmlinuz-2.6.28-11-generic
Found kernel: /memtest86+.bin
Updating /boot/grub/menu.lst ... done

Grub Legacy detected
Usplash detected
Splashy not detected
Using '/usr/lib/usplash/usplash-theme-ubuntu.so' to provide 'usplash-artwork.so'.
Using '/usr/lib/usplash/afisufi-high-tech-0.1-alpha-4.so' to provide 'usplash-artwork.so'.
update-initramfs: Generating /boot/initrd.img-2.6.28-11-generic
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 ... found: /grub/splashimages/grub-fingerprint-0.11.xpm.gz

Found kernel: /vmlinuz-2.6.28-11-generic
Found kernel: /memtest86+.bin
Replacing config file /var/run/grub/menu.lst with new version
Updating /boot/grub/menu.lst ... done

Now 'ls /boot/grub | grep menu' shows:
menu.lst
menu.lst~
menu.lst.backup

They are back! Subsequent runs of sum go off without any problems. Hope this helps some.

Forgot to mention:

Ubuntu 9.04
sum 1.9.12-1
grub 0.97-29ubuntu53
initramfs-tools 0.92ubuntu29

Just a me too; karmic

jarkko@gandalf:~$ sudo apt-get dist-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 0B of additional disk space will be used.
Do you want to continue [Y/n]?
Setting up kexec-tools (20090000-2.0.0ubuntu10) ...
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: /vmlinuz-2.6.31-3-generic
Found kernel: /vmlinuz-2.6.31-2-generic
Found kernel: /vmlinuz-2.6.31-1-generic
Found kernel: /vmlinuz-2.6.30-10-generic
Found kernel: /memtest86+.bin
hanging here.... forever..

Ctrl-c causes it to continue;
^Cdpkg: error processing kexec-tools (--configure):
 subprocess installed post-installation script killed by signal (Interrupt)
Processing triggers for initramfs-tools ...
update-initramfs: Generating /boot/initrd.img-2.6.31-3-generic
Errors were encountered while processing:
 kexec-tools
E: Sub-process /usr/bin/dpkg returned an error code (1)
jarkko@gandalf:~$

Ops, sorry, this was not startupmanager related bug.

This package has been removed from Ubuntu. Closing all related bugs.