Bug#656792: linux-image-3.2.0-1-amd64: kernel does not boot since 3.1 under a (strange) Xen anymore
On Mon, 2012-01-30 at 19:24 +0100, Christoph Anton Mitterer wrote:
> > 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 .
If it exists then PV device will be called xvda not sda.
Also the PV device will not appear or load unless you allow the emulated
device to unplug.
If you do unplug then you won't get the emulated device discovered or
that driver loaded.
The two devices are mutually exclusive because it is dangerous for your
data to have two devices backing onto the same backend, especially since
that happens without guest kernel visibility.
> 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?
I don't know enough about how the initramfs loads modules to be able to
say for sure but I'm, pretty sure this will just work.
In a default initramfs-tools configuration and with LABEL/UUID/LVM based
root=[0] you should be able to flip between emulated and pv devices only
by adding and removing xen_emul_unplug from the command line (or
equivalently by adding or removing the xen platform pci device from the
guest configuration).
Ian.
[0] this is due to the sd vs xvd naming. if you use e.g. root=/dev/sdX
then that won't work.
--
Ian Campbell
"A complex system that works is invariably found to have evolved from a simple
system that worked."
-- John Gall, _Systemantics_
Reply to: