Hey... On Sat, 2012-01-28 at 20:53 +0000, Ben Hutchings wrote: Can you try again, in case you remember wrongly? > I tried,... setting it to "most" doesn't help. I assume it is not possible for you to interact with the shell that the > initramfs runs after failing to mount the root filesystem? > Unfortunately.... it always requires manual intervention by the ISP (yeah I know, this sucks). On Sat, 2012-01-28 at 22:48 +0000, Ian Campbell wrote: > One way to tell would be to add "xen_emul_unplug=never" to your kernel > command line to prevent this happening and see if it boots with > emulated devices ok. This did the trick :) *my hero* ;) I now even get a correctly detected Xen: Hypervisor detected: Xen HVM ... Booting paravirtualized kernel on Xen HVM > If this has happened then you > will see messages like: > Xen Platform PCI: I/O protocol version ... > ... > Blkfront and the Xen platform PCI driver have been compiled for this kernel: unplug emulated disks. > very early on. I cannot tell whether these occured _without_ "xen_emul_unplug=never"... but _with_ "xen_emul_unplug=never" (and the then booting kernel 3.2) it does not show up in dmesg. > If this turns out to be the case then I would recommend arranging for > the initramfs to contain the xen blkfront driver and removing that > option again so you end up using the PV drivers (which are much fast > than emulated). Well at least that module is not automatically loaded now (even outside the initramfs). And /sys/block/sda/device/driver is something like ../ ... ../bus/scsi/drivers/sd . So you think, just adding xen-blkfront to the initramfs, and removeing the parameter will work? Or do I have to explicitly modporbe it in the initramfs, given that it's apparently not auto-loaded? > This is normally already the case with the default > initramfs tools configuration. They're not included automatically.... Thanks to both of you for your help so far. Chris.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature