VMBuilder

execscript runs before many configuration steps

Bug #782007 reported by Chris R. Jones on 2011-05-13

This bug affects 2 people

	Status	Importance	Assigned to
VMBuilder	Fix Released	Low	Unassigned
vm-builder (Ubuntu)	Fix Released	Low	Unassigned
Natty	Won't Fix	Low	Unassigned

Bug Description

========================================================
SRU Justification
1. Impact: users cannot modify grub parameters or specify NFS automount to /etc/fstab with execscript
2. Bug addressed: the bug was addressed by delaying the call to execscripts
3. Patch: See the linked bzr tree.
4. TEST CASE: Use vmbuilder with an execscript adding NFS automount to /etc/fstab.
5. Regression potential: If there were cases where users depended on execscripts running earlier (which is unlikely), their installs would break.
========================================================

Hi all,
--exec scripts are currently run at the end of distro install, rather than
at the end of Hypervisor.install_os.

Because it runs so early, I've had trouble:
  Adding an NFS automount to /etc/fstab
  Adding options to GRUB to pass to my custom kernel
  Installing my own kernel package (I'd rather just use dpkg than setup
      a repo, etc.)

While some of these things can be done at firstboot, kernel and grub reconfiguration can't be done, making any kernel options critical for the first boot impossible.

Similarly, network reconfiguration is difficult as most of the network configuration is done after execscript is executed.

See original description

Tags:

Related branches

lp:~chris-rassalon/vmbuilder/execscript

Merged into lp:vmbuilder at revision 465

Serge Hallyn: Approve on 2011-05-17

lp:~vmbuilder-dev/vmbuilder/packaging

lp:ubuntu/oneiric/vm-builder

Revision history for this message

Chris R. Jones (chris-rassalon) wrote on 2011-05-13:

As a workaround for my own purpose, I've modified the execscript to be run later by just moving the call to self.callhooks('post_install') in Distro to self.distro.call_hooks('post_install) at the end of install_os, before unmount_partitions.
With that change, I seem to have much more control to achieve what I want with my execscript.

I'm a little new to launchpad, but I'll try to post a patch shortly to demonstrate the change.

Revision history for this message

Chris R. Jones (chris-rassalon) wrote on 2011-05-13:

Here's a patch to move the --execscript later after the kernel is install and just before the chroot is unmounted.

Revision history for this message

Chris R. Jones (chris-rassalon) wrote on 2011-05-13:

Move post_install hook later Edit (1.0 KiB, text/plain)

Oops, think I garbled that one - hope this one is better.

Chris R. Jones (chris-rassalon) on 2011-05-13

description:

updated

Revision history for this message

Serge Hallyn (serge-hallyn) wrote on 2011-05-13:

Can you think of any cases where moving it later might make it too late for what users mgiht want to do?

Revision history for this message

Chris R. Jones (chris-rassalon) wrote on 2011-05-13:

I don't think users could ever not be able to do something later -- they could practically manually re-install their chroot from scratch, to take the extreme case.

The danger is just that there are existing execscript users that currently depend on the order of things. It's certainly possible to come up with theoretical situations where someone *could* currently have scripts that depend on this ordering of things -- but I'm having trouble coming up with situations anyone really would want that behavior. I guess they would have to want to put something into place in the chroot filesystem that would influence the behavior of the installation of grub, the kernel, the network or mounts. But that seems like it would be pretty awkward -- those packages don't depend on pre-existing configuration, to my knowledge -- they just put their own configuration into place.

I don't see any reason why moving the execscript later would be a bad thing except for potentially breaking existing users. Adding a new second "--execscript2" hook could play it safe.. but that seems awkward to me.

Revision history for this message

Serge Hallyn (serge-hallyn) wrote on 2011-05-17:

'Potentially breaking existing users' is of course a very bad thing :) But I agree it doesn't seem likely.

Your patch has been pushed to oneiric. Which release were you hoping to use it in? I'll happily SRU it to natty, but am more leery about changing behavior for lucid.

Changed in vmbuilder:
status:	New → Confirmed
importance:	Undecided → Low

Revision history for this message

Chris R. Jones (chris-rassalon) wrote on 2011-05-17:

I'm fine with leaving it in oneiric, I don't personally have a need to get it in earlier. And given that there's a little risk of breaking someone I guess it's good to give it some time to settle.

Serge Hallyn (serge-hallyn) on 2011-05-19

Changed in vmbuilder:
status:	Confirmed → Fix Released

Serge Hallyn (serge-hallyn) on 2011-05-19

description:	updated
Changed in vm-builder (Ubuntu):
status:	New → Fix Released
importance:	Undecided → Low
Changed in vm-builder (Ubuntu Natty):
status:	New → Confirmed
importance:	Undecided → Low

Revision history for this message

Martin Pitt (pitti) wrote on 2011-05-30: Please test proposed package

Accepted vm-builder into natty-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!