UTAH provisioning failed with: UTAHProvisioningException: Failed to install client

Bug #1097151 reported by Jean-Baptiste Lallement on 2013-01-08
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Max Brustkern

Bug Description

Provisioning a physical system with UTAH fails from time to time with:
"ERROR: Failed to install client. Writing empty reports."

For example the log attached is the installation of Raring Ubuntu Desktop on Hardware:
+ ISO=/data/iso/ubuntu/daily-live/raring-desktop-i386-20121129.iso
+ run_utah_tests.py -m physical --name dx-autopilot-ati -i /data/iso/ubuntu/daily-live/raring-desktop-i386-20121129.iso -p resources/indicators-preseed.cfg master.run
2013-01-07 18:03:12,595 dx-autopilot-ati INFO: Running command through SSH: DEBIAN_FRONTEND=noninteractive; while (fuser /var/lib/dpkg/lock >/dev/null 2>&1); do echo "Waiting for dpkg lock to become available"; sleep 10; done ; gdebi -n -q /tmp/python-jsonschema_0.5-0~ppa1_all.deb
2013-01-07 18:03:13,994 dx-autopilot-ati WARNING: Return code: 1
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/utah/run.py", line 128, in run_tests
  File "/usr/lib/python2.7/dist-packages/utah/provisioning/provisioning.py", line 421, in installclient
    raise UTAHProvisioningException('Failed to install client\n')
UTAHProvisioningException: Failed to install client

2013-01-07 18:03:13,996 dx-autopilot-ati ERROR: Failed to install client. Writing empty reports.

This is blocking daily testing of Unity.

Jean-Baptiste Lallement (jibel) wrote :
Max Brustkern (nuclearbob) wrote :

I've recreated this issue in a UTAH-installed VM, but a manually installed VM worked fine. Something in the preseed we're using is resulting in a partially failed packaged installation. I'm trying to minimize the preseed involved to determine whether it's a dependency of UTAH or autopilot.

Max Brustkern (nuclearbob) wrote :

Installing this image on hardware with the default UTAH preseed appears to work fine. I think something in the preseed used for the autopilot job is causing a package installation problem. I'll continue to investigate and narrow it down.

Changed in utah:
importance: Undecided → High
status: New → Triaged
assignee: nobody → Max Brustkern (nuclearbob)
Max Brustkern (nuclearbob) wrote :

I ran this with the job's preseed and image and a default runlist on acer-veriton-03, and it worked as expected. I'm going to try the job's runlist as well.

Max Brustkern (nuclearbob) wrote :

I can't recreate this today. I think it was a problem with the packages on that image vs. the packages in the archive yesterday. Today, using that image and preseed, I've gotten good installs on acer-veriton-03 and dx-autopilot-ati. Please let me know if the issue recurs.

Changed in utah:
status: Triaged → Incomplete
Jean-Baptiste Lallement (jibel) wrote :

It actually not a problem with old images as I initially thought, it occurs with raring daily desktop images too:

Changed in utah:
status: Incomplete → Confirmed
summary: - UTAH failed to provision old images
+ UTAH provisioning failed with: UTAHProvisioningException: Failed to
+ install client
description: updated
Max Brustkern (nuclearbob) wrote :

I'll work on recreating this on the newer images.

Max Brustkern (nuclearbob) wrote :

My initial recreate attempt failed (the installation succeeded) but I found that additional lines were added to the preseed. I'm attempting to recreate again with the updated preseed on the same hardware instead of acer veriton 3.

Max Brustkern (nuclearbob) wrote :

My attempt to recreate this on the same hardware resulted in a successful install as well. I'm going to look into getting better visibility on these errors. Once we have that functionality integrated, I can work on getting a new stable version approved.

Note that the empty report generation was recently removed, so when reproducing
the bug, the traceback should be the same, but the error message won't be
printed anymore.

Changed in utah:
status: Confirmed → In Progress
tags: added: ue-desktop
Andy Doan (doanac) wrote :

this no longer seems to be an issue. Can we close this out?

I'm closing this report. I haven't seen this issue recently and strongly think that it was caused by the rc.local bug.

Changed in utah:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers