building vm image on text console causes gettys to stop respawning

Bug #392377 reported by Stuart Young on 2009-06-26
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Ubuntu Server papercuts
Medium
Soren Hansen
VMBuilder
Medium
Unassigned
debootstrap (Ubuntu)
Undecided
Unassigned

Bug Description

Release: Ubuntu 9.04/Jaunty
Arch: x86_64
Packages:
 python-vm-builder: 0.10-0ubuntu2
 debootstrap: 1.0.12
 console-setup: 1.28ubuntu8
 upstart: 0.3.9-8

Running vmbuilder on a text console to build a kvm based VM causes gettys to stop respawning. Each getty needs to be restarted using 'initctl start tty#' where # is the tty number. Some existing getty's seem to accept login but then try and respawn themselves after login if the login is successful before the user has logged out.

I suspect that this may not actually be a vmbuilder bug, but may be related to vmbuilder's use of debootstrap (and in turn interactions with upstart), and the setup of getty's within the vm image causing issues with the text console.

Notes:
 The version of Ubuntu that I am installing in the vm image is 9.04/Jaunty.
 I don't have X on this machine. Will test further with another machine (once again x86_64) that has X to see if I can replicate it when run from a shell while running X (eg: Xterm).
 Using vmbuilder --debug I have narrowed it down to somewhere around the install of console-setup, but I am not 100% sure of this.
 During the build process, the text console font changes at almost the same time that the getty's stop respawning, which seems to coincide with the configuration of the console-setup package by debootstrap.
 The command 'initctl events' shows no events being sent to respawn the gettys on logout, as compared to what usually happens prior to building the vm image using vmbuilder, or after manually restarting them.
 The vmbuilder process is being spawned using sudo (directly or using a shell created with 'sudo -i'), which in turn is being spawned by the initial user created at install time of the host system.

While test config files and command lines are available on request, I have been able to produce this with minimal vm builds using vmbuilder (eg: 'vmbuilder kvm ubuntu --part=test.part' and a simple partition file containing root & swap only).

If you have any test commands that I can try (eg: directly calling debootstrap the way vmbuilder does to isolate it to debootstrap, or even a way to reinstall individual packages in an image using chroot to try and replicate it), just let me know.

Related branches

Stuart Young (cef) wrote :

Update: Confirmed using a new machine that has X installed and a brand new install of vmbuilder (on same new machine) that when vmbuilder is run in an xterm that text consoles no longer respawn.

Note: In case it wasn't apparent previously, it's only during the build process this happens and only on the machine the build is taking place on. The vm images themselves are working and they work fine (without any issue) on the same machine (or even on a different machine).

Stuart Young (cef) wrote :

Update: This can be reproduced without the use of vmbuilder.

I have not as yet tracked down which command run by debootsrap causes the problem.

Running the following commands reproduce the same behaviour:

 mkdir /test-root
 debootstrap --arch=amd64 jaunty /test-root http://archive.ubuntu.com/ubuntu

affects: vm-builder (Ubuntu) → debootstrap (Ubuntu)
Stuart Young (cef) wrote :

Q: Is there any way I can add additional debugging to debootstrap (eg: pausing between installed packages, more verbose output, etc) so I can possibly track down where this is happening? I am aware that this may not even be a problem of debootstrap, but a problem caused by a package in the chroot created by debootstrap interacting with processes outside of the chroot.

As noted above, I am quite willing to do most of the diagnosis to find the crux of the issue.

Colin Watson (cjwatson) wrote :

I just uploaded debootstrap 1.0.20~jaunty1 to jaunty-backports. Can you reproduce this bug with this version? My suspicion is that this change will have fixed it:

  * For recent Ubuntu versions, move $TARGET/sbin/initctl aside in the same
    way we do start-stop-daemon, so that attempts to control Upstart jobs
    won't inadvertently affect jobs in the host system.

Sergey Svishchev (svs) wrote :

vmbuilder itself should also divert /sbin/initctl, since it may install packages that attempt to start daemons (ssh, for example).

Thierry Carrez (ttx) on 2010-02-11
Changed in server-papercuts:
importance: Undecided → Medium
status: New → Confirmed
Soren Hansen (soren) on 2010-02-22
Changed in vmbuilder:
importance: Undecided → Medium
status: New → Triaged
Soren Hansen (soren) wrote :

...and I've now added a quirk to VMBuilder identical to the one in debootstrap.

Changed in vmbuilder:
status: Triaged → Fix Committed
Soren Hansen (soren) on 2010-02-24
Changed in server-papercuts:
status: Confirmed → Fix Committed
Soren Hansen (soren) on 2010-02-24
Changed in vmbuilder:
status: Fix Committed → Fix Released
Stuart Young (cef) wrote :

I've since moved my test systems to later version of Ubuntu (both were jaunty, now one is lucid and the other is karmic) since this bug entry was created.

However, if testing any of this on lucid or karmic is worthwhile, let me know what needs testing and I'll get to it.

On Thu, Feb 25, 2010 at 01:54:31AM -0000, Stuart Young wrote:
> I've since moved my test systems to later version of Ubuntu (both were
> jaunty, now one is lucid and the other is karmic) since this bug entry
> was created.
>
> However, if testing any of this on lucid or karmic is worthwhile, let me
> know what needs testing and I'll get to it.

Testing on lucid would be much appreciated.

Thierry Carrez (ttx) on 2010-03-02
Changed in server-papercuts:
milestone: none → lucid-beta-1
status: Fix Committed → Fix Released
assignee: nobody → Soren Hansen (soren)
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers