custom dd-tgz format images looked for in wrong path, so they don't work

Bug #1401241 reported by Daniel Manrique
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
MAAS
Fix Released
Critical
Blake Rouse
1.7
Fix Released
Critical
Blake Rouse

Bug Description

I applied the patch for bug https://bugs.launchpad.net/maas/+bug/1393953 to my existing MAAS installation which is at this version:

Installed: 1.7.0~rc3+bzr3299-0ubuntu1~trusty1

(to note, the patch in question is now in MAAS trunk at revno 3408)

After doing this, dd-tgz format images don't work. I uploaded the image like so:

maas roadmr boot-resources create name=kitty-t1 title='kitty test 1' architecture=amd64/generic content@=/home/roadmr/download/kitty-dd.tgz filetype=ddtgz

but when trying to deploy it to a node it seems to still be looking for the root-tgz (rather than root-dd) file:

--2014-12-10 19:42:05-- http://10.10.10.1/MAAS/static/images/custom/amd64/generic/kitty-t1/uploaded/root-tgz
Connecting to 10.10.10.1:80... connected.
HTTP request sent, awaiting response... 404 Not Found
2014-12-10 19:42:05 ERROR 404: Not Found.

I traced this to the fact that the method is missing a path component when it builds the path where it should look for the dd file. I see it looking for e.g.
/var/lib/maas/boot-resources/custom/amd64/generic/kitty-t1/uploaded/root-dd but the file is actually in
/var/lib/maas/boot-resources/current/custom/amd64/generic/kitty-t1/uploaded/root-dd (note extra "current" component).

I think simply adding the missing component to provisioningserver/drivers/osystem/custom.py in the get_xinstall_parameters method (the path variable definition) would fix things.

Related branches

Changed in maas:
status: New → In Progress
importance: Undecided → Critical
assignee: nobody → Blake Rouse (blake-rouse)
Changed in maas:
status: In Progress → Fix Committed
Changed in maas:
status: Fix Committed → Fix Released
Revision history for this message
Andres Rodriguez (andreserl) wrote :

This bug has been reported and fixed on upstream MAAS. However, provided that the bug was listed on the debian changelog, this appears as needing verification for pending SRU [1]. This bug did not affect current MAAS in Ubuntu, hence setting this to verification-done to unblock pending SRU.

[1]:http://people.canonical.com/~ubuntu-archive/pending-sru.html

tags: added: verification-done
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.