Bug#655385: regression introduced in linux-2.6 2.6.32-46
Hi Christoph,
On 12-10-03 10:24 AM, Christoph Lechleitner wrote:
> Am 2012-10-03 16:07, schrieb Simon Deziel:
>> Hi,
>>
>> Since the kernel upgrade, all my Ubuntu Lucid VZ are broken. The
>> breakage manifests in various way but the more evident is the init
>> sequence missing some important parts.
>
> Lucid guests never worked for me.
An attached "openvz" upstart job is (and was always) required to have
the guest working. All our Ubuntu guests template are created using this
template generator in Python:
https://code.launchpad.net/~ubuntu-openvz-dev/openvz-tools/vz-utils It
takes care of creating an upstart job suitable to boot any Ubuntu guest
version.
>> Old kernel working to "vzctl enter" in a Lucid VZ:
>
> Which version exactly?
> As in:
> dpkg -p linux-image-2.6.32-5-openvz-amd64
# dpkg -p linux-image-2.6.32-5-openvz-amd64
Package: linux-image-2.6.32-5-openvz-amd64
Priority: optional
Section: kernel
Installed-Size: 98452
Maintainer: Debian Kernel Team <debian-kernel@lists.debian.org>
Architecture: amd64
Source: linux-2.6
Version: 2.6.32-46
Provides: linux-image, linux-image-2.6, linux-modules-2.6.32-5-openvz-amd64
Depends: module-init-tools, linux-base (>= 2.6.32-31), vzctl,
initramfs-tools (>= 0.55) | linux-initramfs-tool
Pre-Depends: debconf | debconf-2.0
Recommends: firmware-linux-free (>= 2.6.32)
Suggests: linux-doc-2.6.32, grub | lilo (>= 1:22.8-8.2~)
Breaks: initramfs-tools (<< 0.55), lilo (<< 1:22.8-8.2~)
Size: 28870306
Description: Linux 2.6.32 for 64-bit PCs, OpenVZ support
The Linux kernel 2.6.32 and modules for use on PCs with AMD64 or Intel 64
processors.
.
This kernel includes support for OpenVZ container-based virtualization.
.
This kernel also runs on a Xen hypervisor. It supports only unprivileged
(domU) operation.
>> New kernel failing to "vzctl enter" in a Lucid VZ:
>
> Which version exactly?
The kernel 2.6.32-46 breaks it. FYI, the "vzctl enter" is just a visible
sign of the breakage as clearly, upstart (or something else in the
guest) is not linking the new kernel but was fine with the old one
(2.6.32-45).
If that is useful, my own build of vzctl:
# apt-cache policy vzctl
vzctl:
Installed: 3.0.30.2-1~lucid1
Candidate: 3.0.30.2-1~lucid1
Version table:
*** 3.0.30.2-1~lucid1 0
500 http://ppa.launchpad.net/sdeziel/openvz/ubuntu/ lucid/main
Packages
500 http://ppa.launchpad.net/sdeziel/ppa/ubuntu/ lucid/main Packages
100 /var/lib/dpkg/status
>> # vzctl enter build-lucid
>> enter into CT 1000 failed
>> Unable to open pty: No such file or directory
>
> This is a common problem with Ubuntu guests, several solutions can be
> found via Google easily.
>
> I am quite sure that the proc-self-patch has nothing to do with this
> upstart/udev/ubuntu problem.
The pty issue is also another sign of the upstart/init breakage. I know
"Unable to open pty" is quite common and easily worked around but here
that's a different issue IMHO.
>> Is there anyone else affected by this too?
>
> Well, our hardy guests have no such issues.
Our Precise guests are working without problem too, just the Lucid ones
are broken.
Thanks,
Simon
# OpenVZ - Fix init sequence to have OpenVZ working with upstart
description "Fix OpenVZ"
start on startup
task
pre-start script
mount -t devpts devpts /dev/pts || true
mount -t tmpfs varrun /var/run || true
mount -t tmpfs varlock /var/lock || true
mkdir -p /var/run/network
cat /proc/mounts > /etc/mtab
touch /var/run/utmp
chmod 664 /var/run/utmp
chown root:utmp /var/run/utmp
if [ "$(find /etc/network/ -name upstart -type f)" ]; then
chmod -x /etc/network/*/upstart || true
fi
end script
script
start networking
initctl emit filesystem --no-wait
initctl emit local-filesystems --no-wait
initctl emit virtual-filesystems --no-wait
initctl emit net-device-up --no-wait || true
initctl emit net-device-up IFACE=lo --no-wait || true
initctl emit net-device-up IFACE=eth0 --no-wait || true
init 2
end script
Reply to: