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
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
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
** 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
** 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
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
