preseeded installation hangs

Bug #52097 reported by sean finney on 2006-07-06
Affects Status Importance Assigned to Milestone
pkgsel (Ubuntu)

Bug Description

hi colin et al,

i've been attempting to use a customized install via preseeding the installer questions. however, the installer will hang semi-reliably
during "select and install software", with no recourse but to kill
some offending processes.

when this happens, poking around inevitably shows the same problem. there's a defunct aptitude process, along with a bunch of other cruft which leads back up to pkgsel.

iirc, along with the defunct process, there was an apt cdrom method process running as a child of the same parent process, and killing this would cause the parent to reap them both in and the installer would continue (with the big red screen etc). i'm re-running it right now and i'll try and post some specifics shortly.

this can be semi-regularly reproduced, though sometimes it does seem to go through if i make an unrelated change and rebuild the iso, only to break a build or two later...

about my customizations: i haven't really done much at all except
specify some values to skip most of the questions except disk partitioning, which is still manually done. it also uses the oem package. afterwards, there's a custom script that runs and installs a bunch of stuff and deactivates the oem mode, so that after first reboot the user is immediately prompted with the username/login questions.

so i'm not sure if this is genuinely a problem in pkgsel, or whether it's d-i, apt, dpkg, debconf, etc, but it's the first thing i can tie it to and i'm running with it from there.

sean finney (sean-stickybit) wrote :

okay, just got it to happen again. i'm going to attach a few files:

- tail /var/log/syslog outside of chroot (nothing interesting)
- ps x (shows the zombie process)
- the preseed settings (in case they're worth anything)

and in case it's helpful, the isolinux config setting used to boot the installer is:

  kernel /install/vmlinuz
  append preseed/file=/cdrom/preseed/stickybit.seed anna/choose_modules=oem-config-udeb kbd-chooser/method=se-latin1 debian-installer/locale=en_US initrd=/install/initrd.gz ramdisk_size=16384 root=/dev/ram rw --

tail /var/log/syslog

output of ps -x

nothing too fancy...

sean finney (sean-stickybit) wrote :

and if it's helpful, i have this in a vmware session for testing. i'll leave it going right now in case you want me to try anything else. if you like, i can even pause it and let you download the image :)

sean finney (sean-stickybit) wrote :

two weeks and not a comment?

Timo Aaltonen (tjaalton) wrote :

Hey, I can confirm this one.. We have ~230 dappers, and some of them used to hang during pkgsel. If some processes were killed, the installation could be restarted and it would always finish the second time.

We preseed almost 2000 packages to it, so maybe it's more likely to hang. I haven't seen this on edgy or feisty, although it must be noted that those installations were on the same test-machine so maybe I've been just lucky.

Changed in pkgsel:
status: Unconfirmed → Confirmed
Timo Aaltonen (tjaalton) wrote :

sorry for making this a duplicate.. re-read #47178 and decided to keep this separate after all.

Bo Kersey (bo-vircio) wrote :

I have found a work around for this problem (that is aptitude going zombie), I believe...

Spent some time trying to strace main-menu as follows:

/target/usr/bin/strace -f -F -s 1024 -o /target/tmp/main-menu.trace -p XXXX

where XXXX is pidof main-menu

I attached the strace during at the "Select and install software" point. However, strace seems to keep the problem from happening. I guess you can't observe a phenomenon without changing the outcome.....

So, there are two ways to work around the bug...

1) The preferred way is to run debconf in text mode.... Add 'd-i debconf/frontend string text' to your preseed file.

2) The nasty way is to kill the process that spawned the zombie aptitude.

With either work around you end up with the same outcome. However, killing the spawning process requires intervention.

I have not done extensive testing of running debconf in text mode, but if I change nothing else in my preseed the install finishes properly. If I change back to newt the install always hangs.... YMMV

Colin Watson (cjwatson) wrote :

I think this is bug 62986. I also think I've got it fixed now (will land in Gutsy soon); testing much appreciated once it lands!

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers