[PKG-Openstack-devel] New version 1.3~deb8u1 of openstack-debian-images

Steve McIntyre steve at einval.com
Tue May 12 13:43:12 UTC 2015


Hi Thomas,

On Mon, May 11, 2015 at 10:25:29PM +0200, Thomas Goirand wrote:
>
>I have uploaded a new version 1.3~deb8u1 of openstack-debian-images
>to jessie-proposed-updates with the below changes:
>
>  * Backport of the version 1.3 from Sid to Jessie:
>    - Removed the tweak of /etc/modules, as acpiphp and pci_hotplug
>      aren't in the Jessie kernel: they are built not as module
>      (Closes: #783340).
>    - Also adds security repository if building an image for Jessie.
>      Previously, this was done only for Wheezy (Closes: #783480).
>    - Adds dbus + libpam-systemd when building a Jessie image, and
>      acpid + acpi-support-base when building a Wheezy image, so that
>      ACPI shutdown works by default (Closes: #783448).
>    - Adds nano as default when not using the --minimal flag
>      (Closes: #783341).
>
>The thing is, I'm not sure if, when you'll build the new image, the
>openstack-debian-images will be updated or not. It'd be too bad if
>the fixes would come for the 2nd point release instead of the 1st
>one, so I thought it'd be a good idea to let you know.

Good call. :-) The scripts I'm using automatically update before
building, but *might* not get the point release changes for the build
itself that way.

>Another thing. I've noticed a couple of times that the command
>"kpartx -d ${AMI_NAME}", at the end of the script line 412 (which
>removes the loopback device after the image is built), may fail, and
>as the script is using "set -e", it just stops there. I really did
>see it happening twice, and didn't find a way to reproduce it. This
>smells like a race condition.

Right. I've not seen it myself recently that I can recall, but kpartx
is very unreliable in my experience. I tend to prefer doing the
calculation of partition offsets myself and doing loopback mounts
using -o offset directly...

>I'm not so sure how to fix it, and thought that just adding a "sync"
>command would help. It's *that* bad because when that command is
>done, the image is already built, and only the final qcow2
>compression isn't done (plus obviously the removal of the loopback
>device), but it may be annoying for you if you're doing things after
>the build-openstack-debian-image script is ran.
>
>Your thoughts? Should I add a "sync" and just hope for the best?

Suck it and see. :-)

>Thanks again for your support and the inclusion of the image in the
>release,

No problem, glad to help!

I should also ask: do you have any suggestions for text to add as a
HEADER.html for the directory at

  http://cdimage.debian.org/cdimage/openstack/

? We've got some text for other directories like
http://cdimage.debian.org/cdimage/release/current/amd64/iso-cd/ if
you'd like an example...

-- 
Steve McIntyre, Cambridge, UK.                                steve at einval.com
"I can't ever sleep on planes ... call it irrational if you like, but I'm
 afraid I'll miss my stop" -- Vivek Dasmohapatra




More information about the Openstack-devel mailing list