[Pkg-libvirt-maintainers] Bug#578173: virtinst or libvirt loses contact with console during installation

IAN DELANEY johneed at hotmail.com
Sun Apr 18 00:35:10 UTC 2010


Package: virtinst
Version: 0.400.0-7
Severity: serious
Justification: 1


ok, the fiasco of installing in lenny continues.
Boot into xen, take a system such as hardy or karmic on cd or dvd, put it in the drive, invole virt-manager, invoke new vm bringing virtinst into play, use the provided wizzard screens and setup install of a new vm using the cd drive, begin an install of the new vm.

The problem WAS bug number 519809.  We've progressed from there, bringing in the backport versions of libvirt0 and libvirt-bin, version 0.7.6-1~bp.  Citing a late entry of that bug,

"can confirm - I backported libvirt 0.6.1-1 from squeeze to lenny.
The VNC console immediately works with virt-manager 0.6.0-6 after
passing the wizard for creating a new guest."

Well the reporter stopped at that point.
Continuing the install we find a separate new bug.
Initially, the install produces an effective vnc console.
Half way through the install, the vnc console faults, producing the error message along the lines,

TCP/IP error: Console lost contact or got disconnected from the console.

Selecting the Hardware tab of the console, the selection
Serial 0
initially reported Source path:/dev/pts0 (or 2)
Some how the packages changed their mind about what to allocate the console to under /dev.
Once faulted, it reads
Serial 0: Source path:/dev/pts/1,
a non existant char file!  So this is the cause of the bug.
The developer's place to fix it.

In addition, as an attempt to salvage the install, I got the vm to be saved, hoping to restore it from the point on reboot.  The save began to take place, then hangs, preventing the vm to be shutdown or paused, becomes frozen.  A reboot is required to acess the vm again.
Rationale, if a save can be made, at may be able to be restored on an existing /dev/pts/ file, and the install of the vm may perhaps then be completed.

My take on this, seeing the content of the bug number 519809, libvirt had to be fixed to get past this point.  The problem may again be libvirt, however, the nature of the problem is a missing char device file.  On beginning the install, the packages concerned call upon an existing /dev/pts file, then switch to a new one which need be created.  This suggests kernel involvement, or some feature that invokes udev to dynamically create a file with makedev or mknod.

I hope to see a reply to the bug in due course

-- System Information:
Debian Release: 5.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-1-xen-686 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages virtinst depends on:
ii  python                     2.5.2-3       An interactive high-level object-o
ii  python-libvirt             0.4.6-10      libvirt Python bindings
ii  python-libxml2             2.6.32.dfsg-5 Python bindings for the GNOME XML 
ii  python-support             0.8.4         automated rebuilding support for P
ii  python-urlgrabber          3.1.0-4       A high-level cross-protocol url-gr

Versions of packages virtinst recommends:
pn  qemu                          <none>     (no description available)
ii  virt-viewer                   0.0.3-2    Displaying the graphical console o

virtinst suggests no packages.

-- no debconf information





More information about the Pkg-libvirt-maintainers mailing list