Re: [Xen-users] pv guest fails to start after 4.2 upgrade

[Travis Osterman <tosterman@xxxxxxxxx>]

On Tue, Feb 26, 2013 at 3:11 AM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> On Mon, 2013-02-25 at 22:47 +0000, Travis Osterman wrote:
>> >>> >> I also tried to take pvgrub out of the picture so I mounted the image
>> >>> >> and copied my initrd and kernel to the dom0 file system and updated my
>> >>> >> config with the appropriate ramdisk and kernel lines.
>> >>> >>
>> >>> >> Full output without pvgrub
>> >>> >> http://pastebin.com/c7VWWwXk
>> >>> >>
>> >>> >> Which dropped me in a shell asking for my root partition (progress).
>> >>>
>> >>> # cat /var/log/xen/qemu-dm-prime.log
>> >>> bind(unix:/var/run/xen/qmp-libxl-4): No such file or directory
>> >>> chardev: opening backend "socket" failed: No such file or directory
>> >>>
>> >>> # ls /var/run/xen*
>> >>> /var/run/xenconsoled.pid  /var/run/xenstored.pid
>> >>>
>> >>> /var/run/xenstored:
>> >>> socket  socket_ro
>> >>
>> >> Ah, you are missing the /var/run/xen/ directory so it is failing to
>> >> create the socket, if you create the directory does it work? Although
>> >> even if so it is obviously still a bug that libxl doesn't handle that
>> >> error...
>> >
>> > Ian,
>> >
>> > I can confirm the manually creating /var/run/xen fixes the problem.  I
>> > updated my bug report here
>> > https://bugs.gentoo.org/show_bug.cgi?id=459082
>> >
>> > Thank you for the help.
>> >
>>
>> Similar error not solved by the above on a domain using pygrub (pvgrub works)
>>
>> /var/log/xen/qemu-dm-domain.log
>> /var/tmp/portage/app-emulation/xen-tools-4.1.1-r6/work/xen-4.1.1/tools/ioemu-qemu-xen/hw/xen_blktap.
>> c:628: Init blktap pipes
>> Could not open /var/run/tap/qemu-read-2
>
> Do you have /var/run/tap ?
>
> I'm a bit surprised to see the qemu tap support getting activated, I
> didn't think it was used for anything there days.
>
> Ian.
>
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@xxxxxxxxxxxxx
> http://lists.xen.org/xen-users

I didn't have it, but created the directory as before.  That didn't
seem to fix things this time.  I'm not familar with tap but here are
the open tap libraries on my system currently.

# lsof | grep -i tap
xl         8451       root  mem       REG              253,0
30400    1462266 /usr/lib64/libblktapctl.so.1.0.0
xl         8451  8452 root  mem       REG              253,0
30400    1462266 /usr/lib64/libblktapctl.so.1.0.0
xl        18198       root  mem       REG              253,0
30400    1462266 /usr/lib64/libblktapctl.so.1.0.0
xl        18198 18199 root  mem       REG              253,0
30400    1462266 /usr/lib64/libblktapctl.so.1.0.0
qemu-dm   18580       root  mem       REG              253,0
18152    1462242 /usr/lib64/libblktap.so.3.0.0
qemu-dm   18580 18582 root  mem       REG              253,0
18152    1462242 /usr/lib64/libblktap.so.3.0.0
qemu-dm   18580 18583 root  mem       REG              253,0
18152    1462242 /usr/lib64/libblktap.so.3.0.0
xl        18671       root  mem       REG              253,0
30400    1462266 /usr/lib64/libblktapctl.so.1.0.0
xl        18671 18672 root  mem       REG              253,0
30400    1462266 /usr/lib64/libblktapctl.so.1.0.0

The 4.2 series of ebuilds really did a number on my setup (which had
been previously working in 4.1).  Here is the summary of changes I've
noticed with the upgrade:

pvgrub + file:/*.img: mkdir /var/run/xen does not get created so added
a script to /etc/local.d as workaround (fixes) and didn't need
/var/run/tap created

pygrub + file:/*.img:also seems to want /var/run/tap, after creating
that, still no xvda.  I didnt' get a chance to troubleshoot that any
further as I wasn't home last evening and wanted to leave the domain
up with /dev/loop

hvm + file:/*.img: a windows domain would no boot normally even after
the above directories were created
/var/log/*dm*.log
Using xvda for guest's hda
Strip off blktap sub-type prefix to /tank/xen/dev/winxp.img (drv 'aio')
Using file /tank/xen/dev/winxp.img in read-write mode

That looks like the disk was being loaded fine.  I was able to log in
via safe mode and found the gplpv drivers wouldn't load (which worked
fine in 4.1).

I'm getting around the pygrub and hvm currently by manually creating
/dev/loop devices and using phy:/dev/loop in my disk config line.

I'll try to give some more debug information later.  I'm not sure if
others are having problems but wish 4.2 hadn't been unmasked in
portage quite yet.

-- T

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users