** Changed in: qemu
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1243287
Title:
[KVM/QEMU][ARM][SAUCY] fails to boot cloud-image due to host kvm fail
** Branch linked: lp:ubuntu/cloud-init
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1243287
Title:
[KVM/QEMU][ARM][SAUCY] fails to boot cloud-image due to host kvm fail
Status in QEMU:
Fix Comm
Manoj, the fix that Scott just put through should fix it. However, I've
gone ahead and put in a fix for the cloud image build process. I would
really like to see this fix though in dmidecode.
** Changed in: qemu
Assignee: (unassigned) => Ben Howard (utlemming)
** Changed in: qemu
Stat
I did send a patch for dmidecode to exit gracefully if there is no bios
or smbus before it did all the mmap() damage, but no one seemed
interested in that patch. I was told that upstream is working on a
different approach.
--
You received this bug notification because you are a member of qemu-
de
Is there something we can do for ARM32 cloud-images so that customers
who might download the image and try to deploy it will not see this
issue? Something like:
dpkg-divert --local --divert /path/dmidecode --rename --add /bin/true
--
You received this bug notification because you are a member of
"uname not i386 or x86_64" might be a better check -- restrict to the
archs where it actually works.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1243287
Title:
[KVM/QEMU][ARM][SAUCY] fails to boo
I just worked around this in cloud-init by disabling the smartOS datasource if
the uname arch is arm* or aarch*
http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/sources/DataSourceSmartOS.py
--
You received this bug notification because you are a member of qemu-
d
** Branch linked: lp:cloud-init
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1243287
Title:
[KVM/QEMU][ARM][SAUCY] fails to boot cloud-image due to host kvm fail
Status in QEMU:
Confirmed
Bug
The most recent mailing list discussion about the problem is here:
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-December/219176.html
It does not look likely that there will be a fix soon: it's complicated
(and the suggestion to inject a data abort has been rejected), and it
only affe
A workaround that we used was to rename dmidecode to /bin/true and .make
it persistent. dpkg-divert --local --divert /path/dmidecode --rename
--add /bin/true. But that is just a workaround, any code that maps()
/dev/mem can cause these crashes. Is there a fix for this in the horizon
?
--
You rec
I agree we should probably make KVM inject a data abort here. That
doesn't change the fact that a userspace program that looks in /dev/mem
without being 100% sure what hardware it is running on is really
dangerous and needs to be fixed.
--
You received this bug notification because you are a memb
Peter, the config option is called: CONFIG_STRICT_DEVMEM
And /dev/mem behaves differently between doing read() and doing mmap().
As Peter already hinted, the memory layout is different on native Midway (which
has DRAM starting at 0) and mach-virt/vexpress (which start at 128MB / 2GB
respectively
dmidecode itself should probably be checking at runtime what cpu
architecture it is running on so it can refuse to read /dev/mem on
systems which it doesn't know it understands.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://
Manoj, dmidecode seems highly x86-specific according to
http://www.nongnu.org/dmidecode/, so not running it on arm does seem a correct
solution for closing this bug. Suggest you assign it back to cloud-init to have
that fixed.
An alternative to checking for the command's presence would be checki
(1) If you are trying to mmap /dev/mem then you are going to be
accessing physical addresses. This is obviously totally board specific.
In particular the memory layout between a Midway system and a KVM
virtual machine is likely to be different (you don't say what QEMU
configuration you're using) so
** Changed in: qemu
Status: New => Confirmed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1243287
Title:
[KVM/QEMU][ARM][SAUCY] fails to boot cloud-image due to host kvm fail
Status in QEM
Ubuntu kernels use CONFIG_STRICT_MEM which prevents access to physical
mem other than BIOS and PCI region so that X or dmidecode tools can read
this info. On a native ARM system since there is no BIOS (yet) this
causes mmap() of /dev/mem to return a -1. But with KVM/QEMU emulating
ARM (mach virt) o
** Summary changed:
- [cloud-init][ARM][SAUCY] fails to boot cloud-image due to host kvm fail
+ [KVM/QEMU][ARM][SAUCY] fails to boot cloud-image due to host kvm fail
** Project changed: cloud-init => qemu
--
You received this bug notification because you are a member of qemu-
devel-ml, which is
18 matches
Mail list logo
