i386 required to install amd64

Bug #1181334 reported by Scott Moser on 2013-05-17
This bug affects 10 people
Affects Status Importance Assigned to Milestone
Tycho Andersen
maas (Ubuntu)

Bug Description

A system I was working on had amd64 files for raring imported, but did not have i386.
That should be fine, since I'm only hoping to deploy to systems that are identified as amd64.

However, trying to allocate and the start a node results in pxe timeout and fallback to 'default' (which is enlistment) and then poweroff.
log shows:

2013-05-17 13:44:41-0400 [-] Starting factory <HTTPClientFactory: http://localhost/MAAS/api/1.0/pxeconfig/?cluster_uuid=9a4dbe50-1015-4fe1-92ab-d37c34052733&local=>
2013-05-17 13:44:41-0400 [HTTPPageGetter,client] Unhandled error in Deferred:
2013-05-17 13:44:41-0400 [HTTPPageGetter,client] Unhandled Error
    Traceback (most recent call last):
      File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 381, in callback
      File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 489, in _startRunCallbacks
      File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 576, in _runCallbacks
        current.result = callback(current.result, *args, **kw)
      File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 1127, in gotResult
        _inlineCallbacks(r, g, deferred)
    --- <exception caught here> ---
      File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 1069, in _inlineCallbacks
        result = result.throwExceptionIntoGenerator(g)
      File "/usr/lib/python2.7/dist-packages/twisted/python/failure.py", line 389, in throwExceptionIntoGenerator
        return g.throw(self.type, self.value, self.tb)
      File "/usr/lib/python2.7/dist-packages/tftp/protocol.py", line 67, in _startSession
        context, self.backend.get_reader, datagram.filename)
      File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 576, in _runCallbacks
        current.result = callback(current.result, *args, **kw)
      File "/usr/lib/python2.7/dist-packages/provisioningserver/tftp.py", line 171, in generate_config
        kernel_params=kernel_params, **params)
      File "/usr/lib/python2.7/dist-packages/provisioningserver/pxe/config.py", line 108, in render_pxe_config
        return template.substitute(namespace)
      File "/usr/lib/python2.7/dist-packages/tempita/__init__.py", line 173, in substitute
        result, defs, inherit = self._interpret(ns)
      File "/usr/lib/python2.7/dist-packages/tempita/__init__.py", line 184, in _interpret
        self._interpret_codes(self._parsed, ns, out=parts, defs=defs)
      File "/usr/lib/python2.7/dist-packages/tempita/__init__.py", line 212, in _interpret_codes
        self._interpret_code(item, ns, out, defs)
      File "/usr/lib/python2.7/dist-packages/tempita/__init__.py", line 235, in _interpret_code
        base = func(base)
      File "/usr/lib/python2.7/dist-packages/provisioningserver/pxe/config.py", line 100, in kernel_command
        return compose_kernel_command_line(params)
      File "/usr/lib/python2.7/dist-packages/provisioningserver/kernel_opts.py", line 176, in compose_kernel_command_line
        options += compose_purpose_opts(params)
      File "/usr/lib/python2.7/dist-packages/provisioningserver/kernel_opts.py", line 130, in compose_purpose_opts
        get_ephemeral_name(params.release, params.arch))
      File "/usr/lib/python2.7/dist-packages/provisioningserver/kernel_opts.py", line 107, in get_ephemeral_name
        "'maas-import-pxe-files'." % root)
    provisioningserver.kernel_opts.EphemeralImagesDirectoryNotFound: The directory containing the ephemeral images/info is missing (u'/var/lib/maas/ephemeral/raring/ephemeral/i386'). Make sure to run the script 'maas-import-pxe-files'.

ProblemType: Bug
DistroRelease: Ubuntu 13.04
Package: python-maas-provisioningserver 1.3+bzr1461+dfsg-0ubuntu2 [modified: usr/share/pyshared/provisioningserver/pxe/config.py usr/share/pyshared/provisioningserver/pxe/install_image.py]
ProcVersionSignature: Ubuntu 3.8.0-19.30-generic 3.8.8
Uname: Linux 3.8.0-19-generic x86_64
ApportVersion: 2.9.2-0ubuntu8
Architecture: amd64
Date: Fri May 17 13:48:55 2013
InstallationDate: Installed on 2011-11-16 (548 days ago)
InstallationMedia: Ubuntu-Server 11.10 "Oneiric Ocelot" - Release amd64 (20111011)
MarkForUpload: True
PackageArchitecture: all
 PATH=(custom, no user)
SourcePackage: maas
UpgradeStatus: Upgraded to raring on 2013-05-09 (8 days ago)

Related branches

Scott Moser (smoser) wrote :
Julian Edwards (julian-edwards) wrote :

Looking at the code path, it's either doing commissioning or xinstall. In this case, it should be using the architecture defined on the node itself. Are you sure it's set as amd64?

The only time i386 is required is when the client PXE implementation doesn't supply an arch and we fall back to i386.

Changed in maas:
status: New → Incomplete
Scott Moser (smoser) wrote :

node in this case was most definitely known to maas and set to amd64/generic.

On Monday 20 May 2013 12:58:13 you wrote:
> node in this case was most definitely known to maas and set to
> amd64/generic.

It might be something that broke recently then :(

I've been installing amd64 on my own nodes without downloading i386 images.
I'll try to re-create.

Robie Basak (racb) on 2013-05-23
Changed in maas (Ubuntu):
importance: Undecided → Medium
Julian Edwards (julian-edwards) wrote :

I re-created this. It's as simple as renaming /var/lib/maas/ephemeral/precise/ephemeral/i386/ to something else and then trying to enlist a node. The TFTP server then tracebacks as above.

Changed in maas:
status: Incomplete → Triaged
importance: Undecided → High
Julian Edwards (julian-edwards) wrote :

What this means is that the node's BIOS itself is not supplying an architecture on the TFTP request for a pxeconfig. MAAS needs to know what architecture it is so it can serve the right config, and if it's not supplied it defaults, not unreasonably, to i386.

Since there's a workaround (you could just symlink the directory) I'm marking this low priority for now. To fix it we could try all the x86 architectures before giving up I suppose.

Changed in maas:
importance: High → Low
Changed in maas (Ubuntu):
status: New → Confirmed
tags: added: provisioning
Raphaël Badin (rvb) wrote :

I think we should raise the priority on this bug and possibly fix it for 14.04. I expect a lot of users will want to use amd64 over i386. Being able to not download all the i386 images cuts a third of what maas-import-pxe-files downloads. This mean a significant gain in terms of space and speed of execution.

Changed in maas:
milestone: none → 14.04
Chris Glass (tribaal) wrote :

Can confirm, it would save us (the landscape team, but also other users I wager) a lot of time and disk space if we could only download amd64 images and use that successfully.

tags: added: landscape
Gavin Panella (allenap) wrote :

I think the fix here is fairly simple: in maasserver.api.pxeconfig(), when trying to boot a machine that we've not seen before, we should consult BootImages before automatically defaulting to i386.

Changed in maas:
status: Triaged → Fix Committed
Raphaël Badin (rvb) on 2013-11-22
Changed in maas:
assignee: nobody → Tycho Andersen (tycho-s)

Re-opening because someone has reported a duplicate bug (see bug 1278018)

Changed in maas:
status: Fix Committed → Triaged
importance: Low → High
Scott Moser (smoser) wrote :

"I think the fix here is fairly simple: in maasserver.api.pxeconfig(), when trying to boot a machine that we've not seen before, we should consult BootImages before automatically defaulting to i386."

I'd like ot suggest that the most effective way to solve this is to allow the user to set the default.
You're free to build in a default like:
 i386 if i386 is available else amd64

but I'd like to be able to explicitly set it.

Andreas Hasenack (ahasenack) wrote :

We also got hit by this with 1.4+bzr1693+dfsg-0ubuntu2.2~ctools0 on precise. Had to enable i386.

Scott Moser (smoser) wrote :

Just a note, bug 1273382 is related. Its my request to be able to set the default/fallback arch to amd64, so that i386 would never even be considered.

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

Other bug subscribers