Installation fails using preseed file and network install

[Daniel Manrique]

Binary package hint: ubiquity

Release I'm using: Natty (11.04) - the daily images from 20110119, 20110120 and 20110121
Version of package: Unsure of which version is shipped in these images.
What I expected to see: Installation completing successfully.
What I saw instead: Installation fails in various ways during the process, see below.

For testing purposes we install Natty on several dozen laptops and desktops, which boot via pxe, get the preseed file via http, and mount the installation files through nfs.

With the daily Natty images 20110119, 20110120 and 20110121, we've been having a problem that wasn't present before. The process proceeds normally, up to a point when the installers either reboot, or drop to a livecd environment. Some of the livecd ones show a "system program error" dialog box, while some do not.

The ones that reboot leave no clue as to what went wrong; all I was able to determine is that it happens during the "copying files" phase. There are no logs (and in some, not even a /var/log directory in the target filesystem).

For the ones that drop to the livecd environment, I observed the failure happening during the "configuring hardware" phase. I'm attaching partman and syslog output which I was able to obtain on these systems.

Also attached is the preseed file we've observed this problem with.

These systems are mainly used for testing, so if there's any particular test you need me to run, don't hesitate to ask.

[Colin Watson (cjwatson)]

Can you add the 'debug-ubiquity' boot parameter (without the quotes, obviously) to one of the systems that drops to a live environment, and attach /var/log/syslog and /var/log/installer/debug?

[Mario Limonciello (superm1)]

Curiously, do these systems have Intel graphics? I notice that there was a segfault in Xorg.

Jan 21 14:44:16 ubuntu kernel: [ 124.723710] Xorg[4889]: segfault at 0 ip 0813311e sp bfecee90 error 6 in Xorg[8048000+1a7000]

This may be a duplicate of bug 705078, which I've been able to replicate only on systems with Intel graphics thus far.

[Daniel Manrique (roadmr)]

Thanks Colin, I did as you suggested and here are the installer/debug and syslog files for the system (a Dell Vostro V13 that drops to the livecd environment).

Mario: this particular system does show a segfault in the syslog and it does indeed have intel graphics (Intel GM45 as per syslog).

[Daniel Manrique (roadmr)]

Just confirming (for Mario Limonciello) one of the systems that drop to livecd environment has ATI Radeon Graphics, I'm attaching the syslog and debug (with debug-ubiquity) for that one. too.

[Ara Pulido (ara)]

Marking back as New as Daniel provided the needed information.

[Mario Limonciello (superm1)]

Daniel:

That system with radeon graphics is a different failure than the Intel one. Looking at the syslog, it had trouble processing the installation of some packages in your late command:

Jan 24 12:27:21 ubuntu in-target: newaliases: fatal: file /etc/postfix/main.cf: parameter myhostname: bad parameter value: 200809-826."canonical.com"
Jan 24 12:27:21 ubuntu postfix/sendmail[15314]: fatal: file /etc/postfix/main.cf: parameter myhostname: bad parameter value: 200809-826."canonical.com"
Jan 24 12:27:22 ubuntu in-target: dpkg: error processing postfix (--configure):
Jan 24 12:27:22 ubuntu in-target: subprocess installed post-installation script returned error exit status 75
Jan 24 12:27:22 ubuntu in-target: Setting up libdpkg-perl (1.15.8.7ubuntu2) ...
Jan 24 12:27:22 ubuntu in-target: dpkg: dependency problems prevent configuration of bsd-mailx:
Jan 24 12:27:22 ubuntu in-target: bsd-mailx depends on default-mta | mail-transport-agent; however:
Jan 24 12:27:22 ubuntu in-target: Package default-mta is not installed.
Jan 24 12:27:22 ubuntu in-target: Package postfix which provides default-mta is not configured yet.
Jan 24 12:27:22 ubuntu in-target: Package mail-transport-agent is not installed.
Jan 24 12:27:22 ubuntu in-target: Package postfix which provides mail-transport-agent is not configured yet.
Jan 24 12:27:22 ubuntu in-target: dpkg: error processing bsd-mailx (--configure):
Jan 24 12:27:22 ubuntu in-target: dependency problems - leaving unconfigured
Jan 24 12:27:22 ubuntu in-target: No apport report written because the error message indicates its a followup error from a previous failure.
.
.
.
.
.
.
Jan 24 12:29:21 ubuntu in-target: Errors were encountered while processing:
Jan 24 12:29:21 ubuntu in-target: postfix
Jan 24 12:29:21 ubuntu in-target: bsd-mailx
Jan 24 12:29:21 ubuntu in-target: E
Jan 24 12:29:21 ubuntu in-target: : Sub-process /usr/bin/dpkg returned an error code (1)

[Mario Limonciello (superm1)]

a solution to bug https://bugs.launchpad.net/bugs/705078 was just uploaded, so look at today's live disks to see if it helps with the X segfault. if so, this bug is a actually a duplicate of 705078

[Daniel Manrique (roadmr)]

Mario:

Sorry for not updating the past few days. Also, thanks for your analysis of the logs and advice on the X segfault situation.

For the latter, we filed bug #708744 for xorg, which appears to be the root cause of the problem here. We did try the latest image (from today, January 27th) and the problem with the Xorg segfault persists.

For the former, re: installation of packages, it appears that postfix's main.cf file has some invalid parameters which cause configuration to fail, I'm investigating further into that. FWIW we're not even installing postfix expliticly, so it's probably a dependency for some other package.

I'll keep the report up to date with my findings.

[Bryce Harrington (bryce)]

Fwiw, it's not absolutely certain X is the root cause - the crashes that the backtraces illustrate are due to programming errors in the error handling code.

Basically something goes wrong in the system, yada yada, we run out of memory, then X is unable to do stuff because it's out of memory and starts receiving null pointers for memory allocation, and some of the X code doesn't check the return values of the memory allocation calls and so crashes.

So, the X crashes are a symptom rather than a root cause here. The real question is why is it running out of memory? Is it X? The kernel? Is it something in the test harness itself? Hard to guess based on the info at hand, but I think figuring that out is the next step.

[Mario Limonciello (superm1)]

Bryce:

To at least rule a few things out, i'm actually able to avoid the crash by running with 'nomodeset' on my kernel command line, so it is only happening in the Intel scenario when the intel driver is being used.

[Daniel Manrique (roadmr)]

Looks like the fix to bug 714829 takes care of this.