On Sat, 2010-03-27 at 11:56 +0100, Josip Rodin wrote: > Hi, > > If I try to boot 2.6.32-4-xen-amd64 on a 2.6.26-2-xen-amd64 (lenny) dom0, > it gets stuck at: > > [ 0.120653] XENBUS: Device with no driver: device/vbd/769 > [ 0.120658] XENBUS: Device with no driver: device/vif/0 > [ 0.120663] XENBUS: Device with no driver: device/console/0 > [ 0.120679] /build/mattems-linux-2.6_2.6.32-10-amd64-Ff7Wwa/linux-2.6-2.6.32-10/debian/build/source_amd64_xen/drivers/rtc/hctosys.c: unable to open rtc device (rtc0) > [ 0.120822] Freeing unused kernel memory: 588k freed > [ 0.121088] Write protecting the kernel read-only data: 4264k > Loading, please wait... > Begin: Loading essential drivers ... done. > Begin: Running /scripts/init-premount ... FATAL: Error inserting fan (/lib/modules/2.6.32-4-xen-amd64/kernel/drivers/acpi/fan.ko): No such device > FATAL: Error inserting thermal (/lib/modules/2.6.32-4-xen-amd64/kernel/drivers/acpi/thermal.ko): No such device > [ 0.610445] blkfront: xvda1: barriers enabled > done. > Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. > Begin: Waiting for root file system ... xen-blkfront is a module in the pvops based 2.6.32-x-xen-amd64 where as it was statically linked in the non-pvops 2.6.26-x-xen-and64 images. This already happened in Lenny for 32 bit guests (sort of) since the -686-bigmem kernel (which supports Xen) also uses modules for the drivers. I think the change is generally a step in the right direction. Perhaps running mkinitramfs within the 2.6.26 environment causes the 2.6.32 initrd to not contain the correct module? (since it can't detect the requirement for the module because the current kernel has it statically linked?) This should be fixable with some configuration in the guest (e.g. add the modules to /etc/initramfs-tools/modules). Ian. -- Ian Campbell Not responsible for merchandise left over 30 days.
Attachment:
signature.asc
Description: This is a digitally signed message part