The workaround is fine, but if you want more detailed description about the
underlying issues (there are more than one) see the Red Hat bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1026430
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is
Maybe you're right. I just followed the original patch.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to vm-builder in Ubuntu.
https://bugs.launchpad.net/bugs/1037607
Title:
vmbuilder completely fails on Quantal due to kernel pae
I also confirm the patch in #3 works.
However I'd suggest that rather than patching dapper.py, it would be
better to do modify the quantal.py subclass (if that's the first release
which requires /proc to be mounted). Otherwise you're going to change
the build behaviour for all previous releases
Public bug reported:
[ubuntu 14.04 amd64 on Mac Mini, fully up to date]
The virsh memtune function (see
ftp://libvirt.org/libvirt/virshcmdref/html/sect-memtune.html) completely
fails with LXC guests; it looks to be some sort of protocol/ABI problem.
$ virsh -c
Public bug reported:
(Sorry I'm not sure exactly what package to report this against - kernel
perhaps? libvirt is what I was using to replicate the problem)
Host platform: ubuntu 14.04 amd64, Mac Mini, 16GB RAM.
Short version: create an LXC domain with memtune swap_hard_limit set
in the XML:
Public bug reported:
Host: ubuntu 14.04 amd64, Mac mini 16GB.
* Prepare an Ubuntu 14.04 guest rootfs
* Define an LXC instance using libvirt XML (see below)
* virsh start -c lxc: domain
* virsh destroy -c lxc: domain
gives the following error:
$ virsh -c lxc: destroy gold-lxc-20140717
error:
Still in 14.04.
The other problem with the current directory containing temporary name
approach is that it does not properly map to any libvirt storage type
(either 'file' or 'directory'), and therefore cannot be managed properly
through virsh or virt-manager, e.g. you can't clone it.
--
You
Public bug reported:
[ubuntu 14.04]
Given the following config file:
/etc/nbd-server/config
[generic]
# If you want to run everything as root rather than the nbd user, you
# may either say root in the two following lines, or remove them
# altogether. Do not remove the [generic]
related (duplicate of?) #1287943
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to vm-builder in Ubuntu.
https://bugs.launchpad.net/bugs/1310653
Title:
python-vm-builder in Precise unable to build Trusty images
To manage
I see hang at Base system installed successfully too, building Trusty
VM under Precise 64-bit.
Last three lines of ps auxwww are:
root 20430 0.1 0.0 40060 9716 pts/2S+ 10:36 0:00
/usr/bin/python /usr/bin/vmbuilder kvm ubuntu --suite trusty --hostname trusty
--mem 512 --debug
There is a nasty race condition in the code, which is easily fixed:
--- /usr/share/pyshared/VMBuilder/util.py.orig 2010-06-10 17:20:58.0
+
+++ /usr/share/pyshared/VMBuilder/util.py 2014-06-19 10:57:09.723017475
+
@@ -108,9 +108,12 @@
mystdout =
I can replicate this issue with a standalone python script.
http://pastebin.com/vTREYc9n
It hangs at:
read stdout: 'I: Base system installed successfully.\n'
Furthermore, if I add a timeout to select and force it to read anyway, I
get an IOError:
read stdout: [Errno 11] Resource temporarily
FYI: the system I'm using has kernel 3.8.0-42-generic, i.e. it was
installed at the time when the raring enablement stack was active.
I can now reproduce with just a few lines:
---
import subprocess
args = ['/usr/sbin/debootstrap', '--arch=i386', 'trusty', '/tmp/tmpBQAxhc',
Argh. Scrub what I said about python. I can reproduce without python!
# /usr/sbin/debootstrap --arch=i386 trusty /tmp/tmpBQAxhc
http://archive.ubuntu.com/ubuntu | strace cat db.out
...
read(0, I: Configuring initramfs-tools., 32768) = 34
write(1, I: Configuring initramfs-tools., 34) = 34
OK, I found it.
During debootstrap run, a process udevd --daemon is started. It
persists when debootstrap gets to the end. If you kill it, the process
reading from debootstrap's stdout is able to terminate.
My guess is that stdout is being passed to that daemon, and it's holding
it open.
No
I have raised these:
Bug #1332155: debootstrap launches spurious udevd --daemon
Bug #1332165: udevd --daemon does not close stdout
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to vm-builder in Ubuntu.
The race condition in comment #17 is only true if mystdout.closed can
become True asynchronously before we have called mystdout.close(). I'm
not sure if there's any possibility of that.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to
I'm not sure if anyone has mentioned it yet, but the command syntax to
the drbdsetup command has changed totally between drbd8-utils 8.3 and
8.4
e.g. if you are using drbd-utils 8.3 then the command is
drbdsetup /dev/drbd0 show
if you are using drbd-utils 8.4 then the command is
drbdsetup show
Hmm, just to clarify: when using the drbd8-utils 8.4 package and the
kernel module 8.3, then drbdsetup execs the drbdsetup-83 compatibility
module which implements the old syntax, and will also if necessary swap
the first two arguments for forward compatibility
However there are some commands
Public bug reported:
Please backport python-vm-builder in Precise so that it can build Trusty
images.
In Trusty: python-vm-builder version 0.12.4+bzr489-0ubuntu2
$ ls /usr/lib/python2.7/dist-packages/VMBuilder/plugins/ubuntu/
dapper.py feisty.pycintrepid.py lucid.pyc precise.py
Just a note for early adopters to beware of:
https://ceph.com/releases/v0-78-released/
Please note that while it is possible to create and test erasure coded
pools in this release, the pools will not be usable when you upgrade to
v0.79 as the OSDMap encoding will subtlely change. Please do not
Also confirmed, this remains broken in 12.04
$ snmpwalk -v2c -c public storage3 hrStorageTable | grep
\\.34HOST-RESOURCES-MIB::hrStorageIndex.34 = INTEGER: 34
HOST-RESOURCES-MIB::hrStorageType.34 = OID:
HOST-RESOURCES-TYPES::hrStorageFixedDisk
HOST-RESOURCES-MIB::hrStorageDescr.34 = STRING:
Looking at the source of net-snmp-5.4.3~dfsg, it appears to make no
attempt to scale the block size to avoid 2^32 wrapping - see
agent/mibgroup/host/hr_storage.c, var_hrstore()
I have made a simple patch which fixes just this particular problem, so
should be suitable for backporting to LTS.
Once
Public bug reported:
Look at hrStorageSize.34 in the below table. Notice that:
(1) it's smaller than hrStorageUsed.34, so it can't possibly be right
(2) it's the same as the previous row, hrStorageSize.33
$ snmpwalk -c public -v2c hostname hrStorageTable
HOST-RESOURCES-MIB::hrStorageIndex.1 =
Looks like it could be related to this:
https://bugzilla.redhat.com/show_bug.cgi?id=654384
Apparently a newer snmpd would clamp this value to 2^31, and an even newer
snmpd would use a fake larger block size so as to be able to report on large
filesystems:
Still a problem in 10.04 LTS
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to freeradius in ubuntu.
https://bugs.launchpad.net/bugs/430732
Title:
radclient doesn't work
--
Ubuntu-server-bugs mailing list
26 matches
Mail list logo
