On Fri, 10 Nov 2006, Paul Wouters wrote:
[ ExecSum since it's a long post: xenU created from xenguest-isntall.py
has different initrd from dom0 though with the same version/build/rpmsig,
and rpm has a nasty bug]
Following up on myself, since i now know what happened:
> Loading ohci-hcd.ko module
> Loading ehci-hcd.ko module
> Loading jbd.ko module
> Loading ext3.ko module
> Loading scsi_mod.ko module
> SCSI subsystem initialized
Note the missing "Loading xenblk" which was visible in the boot of the guest
that was started with pygrub using a disk image created on the dom0 with
xenguest-install.py.
I decided to find out where it got loaded from. It couldn't be from
the filesystem, so it had to be initrd. But both were using the same
initrd? Well sort of. pygrub extracted one from the diskimage, and
I grabbed it from /boot on the dom0. What I found were two different
initrd files with the SAME build number. I copied it from xenU to dom0:
[root echelon boot]# ls -l initrd-2.6.18-1.2798.fc6*xen*
-rw------- 1 root root 2177639 Nov 10 00:00 initrd-2.6.18-1.2798.fc6xen.img-from-xenguest-install
-rw------- 1 root root 1522165 Oct 28 00:34 initrd-2.6.18-1.2798.fc6xen.img-from-dom0
The original date of the xenguest=install version before i copied it was: "Oct 28 16:37"
[root echelon boot]# md5sum initrd-2.6.18-1.2798.fc6*xen*
8b06aa9e364bd1ac5379e652095a4d3e initrd-2.6.18-1.2798.fc6xen.img-from-xenguest-install
6b591a095b5d4e55641d30c25702e272 initrd-2.6.18-1.2798.fc6xen.img-from-dom0
They both claim to come from the package kernel-xen-2.6.18-1.2798.fc6
Both the diskimage based xen's rpm -V, and the rpm -V on the dom0
claimed the package was not altered?
Checking the rpms, I find both as:
# rpm -qi kernel-xen-2.6.18-1.2798.fc6
Name : kernel-xen Relocations: (not relocatable)
Version : 2.6.18 Vendor: Red Hat, Inc.
Release : 1.2798.fc6 Build Date: Mon 16 Oct 2006 03:57:26 PM EDT
Install Date: Sat 28 Oct 2006 04:37:14 PM EDT Build Host: hs20-bc2-4.build.redhat.com
Group : System Environment/Kernel Source RPM: kernel-2.6.18-1.2798.fc6.src.rpm
Size : 46862330 License: GPLv2
So how can they both verify to the same version, with rpm -V not complaining,
while containing different initrd images, yet having the same build date?
Just to show what I did, so that I won't go insane:
[root echelon boot]# rpm -qf /boot/initrd-2.6.18-1.2798.fc6xen.img
kernel-xen-2.6.18-1.2798.fc6
[root echelon boot]# rpm -qa|grep kernel-xen
kernel-xen-devel-2.6.18-1.2798.fc6
kernel-xen-devel-2.6.18-1.2741.fc6
kernel-xen-2.6.18-1.2741.fc6
kernel-xen-2.6.18-1.2798.fc6
[root echelon boot]# ls -l /boot/initrd-2.6.18-1.2798.fc6*
-rw------- 1 root root 1521809 Oct 28 00:36 /boot/initrd-2.6.18-1.2798.fc6.img
-rw------- 1 root root 2177639 Nov 10 00:30 /boot/initrd-2.6.18-1.2798.fc6xen.img
-rw------- 1 root root 1522165 Oct 28 00:34 /boot/initrd-2.6.18-1.2798.fc6xen.img-broken
-rw------- 1 root root 2177639 Nov 10 00:28 /boot/initrd-2.6.18-1.2798.fc6xen.img-from-xenguest
[root echelon boot]# rpm -V kernel-xen-2.6.18-1.2798.fc6
[root echelon boot]# cp /boot/initrd-2.6.18-1.2798.fc6xen.img-broken /boot/initrd-2.6.18-1.2798.fc6xen.img
[root echelon boot]# ls -l /boot/initrd-2.6.18-1.2798.fc6*
-rw------- 1 root root 1521809 Oct 28 00:36 /boot/initrd-2.6.18-1.2798.fc6.img
-rw------- 1 root root 1522165 Nov 10 00:35 /boot/initrd-2.6.18-1.2798.fc6xen.img
-rw------- 1 root root 1522165 Oct 28 00:34 /boot/initrd-2.6.18-1.2798.fc6xen.img-broken
-rw------- 1 root root 2177639 Nov 10 00:28 /boot/initrd-2.6.18-1.2798.fc6xen.img-from-xenguest
[root echelon boot]# rpm -V kernel-xen-2.6.18-1.2798.fc6
[root echelon boot]#
So either rpm is broken in -qf mode, or it is broken in -V mode...
[root echelon boot]# rpm -qf /boot/initrd-2.6.18-1.2798.fc6xen.img
kernel-xen-2.6.18-1.2798.fc6
[root echelon boot]# rpm -ql kernel-xen-2.6.18-1.2798.fc6 |grep initrd
[root echelon boot]#
And as a test:
[root echelon boot]# rpm -qf /boot/initrd-2.6.18-1.2798.fc6xen.img-broken
file /boot/initrd-2.6.18-1.2798.fc6xen.img-broken is not owned by any package
I guess it is rpm -qf that is broken? Or some advanced "should never be visible"
magic is in use.
Replacing the dom0 version with the xenguest installed version fixed my
problem. The rootfs based xen now boots fine.
And this leads me to a final question. Why are the xen modules loaded
through initrd to begin with? kernel size can't be an issue, since all
hardware drivers are gone from the xenU - only the xen virtual drivers
are needed. Can't we just build that stuff inline, and save ourselves
a lot of trouble booting. It might not be the elegant CS theoretical
perfect solution, but it works in many more practical situations, like
this one with a voodoo initrd-2.6.18.-1.2798.fc6xen.img appearing.
Paul