changing the default arches in import_pxe_files prevents maas-import-ephemerals from running

Bug #1240215 reported by Andres Rodriguez on 2013-10-15
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
MAAS
Critical
Andres Rodriguez
maas (Ubuntu)
Critical
Unassigned

Bug Description

After bug #1238376 was fixed, changing the import_pxe_files ARCHES to something different from default (all), prevents maas-import-ephemerals from running. This means that maas-import-ephemerals will not run at all. Setting back the ARCHES to default (disabled) in import_pxe_files will allow maas-import-ephemerals to run and download all the arches for the set RELEASE.

Related branches

Changed in maas:
status: New → Confirmed
importance: Undecided → Critical
Gavin Panella (allenap) wrote :

Does it emit a stack trace? What does it output?

Andres Rodriguez (andreserl) wrote :

no output, no stacktrace, nothing. Scott thinks we might be hitting [1] (but we might not)

https://bugs.launchpad.net/ubuntu/+source/simplestreams/+bug/1238227

Andres Rodriguez (andreserl) wrote :

So this seems to be the issue:

       # Any user specified filters such as arch~(amd64|i386) are in
        # addition to our selecting only tar.gz files. That's the only type
        # of file we know how to unpack.
        self.item_filters = item_filters or []
        self.item_filters.append('ftype=tar.gz')
        self.item_filters = filters.get_filters(self.item_filters)

MAAS has its arches as amd64/generic i386/generic (hence config file specifies ARCHES= "amd64/generic" and so on), while simple streams only handles filters such as "arch~(amd64|i386)", not considering the "/generic"

Julian Edwards (julian-edwards) wrote :

We can probably get rid of subarch now that ARM doesn't need it, perhaps?

Changed in maas:
status: Confirmed → Fix Committed
Changed in maas (Ubuntu):
status: New → Confirmed
importance: Undecided → Critical
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package maas - 1.4+bzr1693+dfsg-0ubuntu2

---------------
maas (1.4+bzr1693+dfsg-0ubuntu2) saucy; urgency=low

  * debian/patches:
    - 99_fix_wsgi_app_group_lp1237463.patch: Import wsgi into the %{GLOBAL}
      application group, to avoid bson encoding issues. (LP: #1237463)
    - 99_ephemeral_backward_compat_lp1238376.patch: Maintain import_ephemerals
      config compatibility to allow maas-import-ephemerals to inherit the
      config used for maas-import-pxe-files, otherwise it will always download
      all releases even when set to a particular one. (LP: #1238376)
    - 99_split_config_arch_rel_lp1238681.patch: arches/releases are a list
      of characters that need to be split. (LP: #1238681)
    - 99_handle_ephemeral_archs_correctly.patch: Allow maas-import-ephemerals
      to use arches correctly coming from the legacy config (LP: #1240215)
 -- Andres Rodriguez <email address hidden> Mon, 14 Oct 2013 13:10:21 -0400

Changed in maas (Ubuntu):
status: Confirmed → Fix Released
Chris Glass (tribaal) wrote :

This is still affecting users of the 1.4+bzr1693+dfsg-0ubuntu2 pacakge in Saucy.

Steps to reproduce:

- Install maas using the saucy server install CD.
- Edit /etc/maas/import_pxe_files -> set ARCHES to i.e. ARCHES="amd64/generic"
- Configure the rest of MaaS, click the "import boot images" in the UI
- PXE boot a machine

What happens:
The machine PXE boots, gets assigned an IP address by MaaS. The node gets stuck on "Trying to load: pxelinux.cfg/default" and finally reboots after a timeout triggers. This results in an eternal reboot loop.

What should be happening:
The machine PXE boots, gets assigned an IP address, and successfully downloads a bootable image from tftp, resuming normal operations.

Chris Glass (tribaal) wrote :

Further information:

Relevant stacktrace: https://pastebin.canonical.com/99705/

Raphaël Badin (rvb) wrote :

@tribaal: I think what you're seeing here is bug 1181334 (note the fact that the error you see mentions i386).

Can you try changing /etc/maas/import_pxe_files to set ARCHES to "i386/generic amd64/generic", re-run the import script and try again?

Chris Glass (tribaal) wrote :

Sorry, I used a private pastebin, here's the public equivalent: http://pastebin.ubuntu.com/6340916/

@rvb: Yeah that looks like what I'm seeing indeed. I'll give it a try and report back!

Chris Glass (tribaal) wrote :

@rvb: Yes, adding back the i386 architecture made the boot up work. I'll subscribe to bug 1181334 instead! Thanks for your help.

Changed in maas:
milestone: none → 14.04
Raphaël Badin (rvb) on 2014-04-03
Changed in maas:
assignee: nobody → Andres Rodriguez (andreserl)
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