We have Maverick running in Xen quite extensively. We use debootstrap
images with normal grub (not pvgrub), i.e. we are passing a full HD
image to Xen (and I know we aren't the only ones to do this). We do
however modify /etc/fstab etc., and aren't using -virtual (I think we
use -server) precisely
I don't suppose there's any chance of fixing this for Maverick as well?
I believe that this is the cause of the verification failure in bug
720558, and I think that any attempt to work around this in GRUB would
probably do more harm than good.
Comment #2 on this bug suggests that cloud-init
Scott Moser has explained to me why this is probably too invasive to fix
in Maverick (hardcoded device names in /etc/fstab). I think I have an
idea for how to work around this in Maverick's grub package by observing
that an earlier comment in this bug indicates that the xen-blkfront
/dev/sd*
cloud-init writes /etc/fstab entries with LABEL=, for root device.
for ephemeral devices other than swap, it adds 'nobootwait', so these devices
would not hang up boot if they changed names.
for swap devices (I just verified), mountall does not wait.
** Changed in: cloud-init (Ubuntu Natty)
I have tested this on Xen 3.3.1 in HVM mode and now correctly get
/dev/xvda etc.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to cloud-init in ubuntu.
https://bugs.launchpad.net/bugs/684875
Title:
Patch to Natty 2.6.37-virtual
Some notes on this which come up to me while looking at some other
issues. Currently the Natty images seem to contain two entries in
/etc/fstab that point to /dev/sd* devices. At first the entry for swap
was scaring me a bit as it did not have a nobootwait and my reboots were
not coming back. But
Further notes:
1. non-ubuntu specific: to get HVM devices to work on Xen pre
3.4.something, you need to use emulunplug=unnecessary or perhaps
emulunplug=unnecessary,all on the command line. Otherwise Xen's non-
support of PCI unplug means that failure to unplug the emulated devices
stops the HVM
I did a small test this morning with ami-e4c9388d:
IMAGE ami-e4c9388d
099720109477/ebs/ubuntu-images-testing/ubuntu-natty-daily-amd64-server-20110104
099720109477available public x86_64 machine aki-427d952b
ebs
BLOCKDEVICEMAPPING /dev/sda1
On Wed, 5 Jan 2011, Stefan Bader wrote:
This works with or without the xen_emul_unplug=unnecesarry switch
(expected as m1.large is not HVM). So we seem to be ok with just
reverting the patch. Though we should check whether we now need the
argument for our cluster instances.
If you've got a
I went ahead and asked it to be included in the next Natty kernel (I
assumed that we rather want it reverted and go on from there). This
should give at least something to look at on the sprint.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is
This bug was fixed in the package linux - 2.6.37-12.26
---
linux (2.6.37-12.26) natty; urgency=low
[ Andy Whitcroft ]
* rebase to v2.6.37-rc8
* [Config] armel -- reenable omap flavour
* [Config] disable CONFIG_MACH_OMAP3517EVM to fix FTBS on armel omap
* [Config] disable
Just want to make sure that it is ok (for the possible dependency in
cloud-init) to go forward and ask for the kernel patch to be reverted in
natty before actually doing so.
** Changed in: linux (Ubuntu Natty)
Assignee: (unassigned) = Stefan Bader (stefan-bader-canonical)
--
You received
Stefan, assuming the kernel boots, i'll deal with cloud-init fallout.
I think jjohansen had some issues with booting though.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to cloud-init in ubuntu.
https://bugs.launchpad.net/bugs/684875
So I have experimented with this a bit and so far I haven't gotten an
instance to boot without the patch. It should work, so I just need to
tinker with it more.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to cloud-init in ubuntu.
xen-devel thread is here:
http://www.gossamer-threads.com/lists/xen/devel/192003
I've been asked to point out there are really two problems:
1. If the emulated devices (i.e. the real sda) is not unplugged, there
is a device name clash. The emulated devices cannot be unplugged on xen
3.3
** Also affects: cloud-init (Ubuntu Natty)
Importance: Medium
Status: Triaged
** Also affects: linux (Ubuntu Natty)
Importance: High
Status: Confirmed
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to cloud-init in
** Tags added: kernel-series-unknown
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to cloud-init in ubuntu.
https://bugs.launchpad.net/bugs/684875
Title:
Patch to Natty 2.6.37-virtual breaks non-EC2 users
--
Ubuntu-server-bugs
My understanding is that the patch currently applies to all kernel variants, so
has the potential to cause problems for:
* Anyone running Xen versions pre 3.4
* Anyone running any version of Xen hoping for stable device naming between
Ubuntu kernels and any others (e.g. mainline, Debian , the
** Tags added: ec2-images
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to cloud-init in ubuntu.
https://bugs.launchpad.net/bugs/684875
Title:
Patch to Natty 2.6.37-virtual breaks non-EC2 users
--
Ubuntu-server-bugs mailing list
I think we can safely drop this now.
In EC2 for maverick and newer, we're booting with pv-grub, and specifying
root=LABEL=uec-rootfs . In the future, we possibly use root=UUID=... .
** Changed in: linux (Ubuntu)
Importance: Undecided = High
** Changed in: linux (Ubuntu)
Status: New
This change to the kernel may require a change in cloud-init to dal with
the metadata block device mapping. We already do something like this for
eucalyptus where we notice that the metadata service says 'sdX' but
devices are named 'vdX' (using virtio).
** Changed in: cloud-init (Ubuntu)
this hacked patch is in place because (for some reason unknown to me)
when not using pv-grub as the loader, EC2 specifies 'root=sda1' on the
kernel command line.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to cloud-init in ubuntu.
this hacked patch is in place because (for some reason unknown to me)
when not using pv-grub as the loader, EC2 specifies 'root=sda1' on the
kernel command line.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to cloud-init in ubuntu.
EC2 specifies 'root=sda1' on the kernel command line.
EC2 should fix that then, as it's plain wrong.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to cloud-init in ubuntu.
https://bugs.launchpad.net/bugs/684875
Title:
Patch to
Though a compromise solution would be to register as sda only if the
unplug of the original sda device succeeded / is going to be tried.
Otherwise it's just going to cause a kernel bug.
I think xen_unplug_emulated_devices() is called sufficiently early you
could choose the name when the driver is
25 matches
Mail list logo
