Blueprint changed by Stefan Bader:
Work items changed:
Work items:
[louis-bouchard] - kdump-tools needs to be MIR / file a bug: DONE
- [stefan-bader-canonical] - discuss linuxcrashdump changes on ubuntu-devel /
ubuntu-kernel: TODO
+ [stefan-bader-canonical] - discuss linuxcrashdump changes
Blueprint changed by Stefan Bader:
Work items changed:
Work items:
[serge-hallyn] Have virbr0 not be set to autostart if it's network is in use:
DONE
- [stefan-bader-canonical] watch for libxl patches for xen 4.2: TODO
+ [stefan-bader-canonical] watch for libxl patches for xen 4.2 (see
Blueprint changed by Stefan Bader:
Whiteboard changed:
User Stories:
Risks:
Test Plans:
The qrt libvirt testsuite is to be run before every package upload.
Release Note:
* Libvirt can now be used to launch and test UEFI based VMS.
* Libvirt-qemu can now be set up
Blueprint changed by Stefan Bader:
Work items changed:
Work items:
[lars-kurth] sort contributions pie chart by percentage: TODO
[dunlapg] Link to slides that were shown: DONE
[ijc] Ian and Adam discuss grub2 booting Xen first: TODO
[dunlapg] MaaS for installing Xen: TODO
- [stefan
Samantha, could you load this module ever before on that HW?
** Summary changed:
- missing kernel module ipmi_si module
+ Kernel module ipmi_si fails to load
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to ipmitool in Ubuntu.
Public bug reported:
In order to try transitioning from the specially patched EC2 kernels for Lucid,
we are aiming to have the virtual(server/generic-pae) kernels have the required
Xen drivers built-in. At some point the ec2 meta-package could pull people over
to the other kernels.
For that
Ah, I probably confused that with the mechanism used to find dom0 usable
kernel. In the end this does not need to be overly clever at all. I
suppose it should be enough just to sort kernels by version and name.
Preferring the ec2 kernel name if there are multiple kernels with the
same version.
Scott, what would you think about this. This isn't really a backport but
would seem to do what I was thinking about inside a Xen domU. That
should get verified against a cloud-init deployment somewhere else
(which uses grub-legacy-ec2, if this exists). The one part that could
affect other places
Yeah, the problem, I realised, is that in Lucid we got the linux-ec2
packages installed right now. The plan is to change the dependency of
the meta-package to change from linux-image-*-ec2 to linux-
image-*-virtual (which is a generic-pae or server in fact). The problem
is that ec2 kernels have a
I changed it from virt-manager to libvirt as this can be reproduced by
virsh - xen host. And would also remove the affects from virt-manager.
** Summary changed:
- Timeout connecting 12.04 virt-manager to libvirt 1.0.6-0ubuntu1 + xen in Saucy
+ Timeout connecting 12.04 libvirt to libvirt
Blueprint changed by Stefan Bader:
Work items changed:
Work items:
[ebiederm] Push fix for XFS and user namespaces: TODO
[serge-hallyn] Fix lxc-net to be nestable with no user interaction: DONE
[serge-hallyn] Write sysctl to disable unprivileged CLONE_NEWUSER: DONE
[serge-hallyn
Blueprint changed by Stefan Bader:
Work items changed:
Work items:
[ebiederm] Push fix for XFS and user namespaces: TODO
[serge-hallyn] Fix lxc-net to be nestable with no user interaction: DONE
[serge-hallyn] Write sysctl to disable unprivileged CLONE_NEWUSER: DONE
[serge-hallyn
This looks to be the third case we hit with the same symptom (and likely
for yet another reason). The complicating issue is that lxc containers
make use of net namespaces and if those are released, references to I
think the netdevice structures, are temporarily moved over to the
loopback device.
@Thilo, it seems that the discussion was about whether there should be a
better fix but there does not seem to be any confirmation about any real
problems found with either version. As of today only the patch as it was
queued has made it upstream. So this would be the change that would go
into
If you loock at comment #32 and comment #27, the patch got reverted in
natty because there was no one verifying the change. It also gives a
link that should tell how to get it reconsidered to go into natty. If
that is done, it will be in the lts backport automatically.
--
You received this bug
Blueprint changed by Stefan Bader:
Whiteboard changed:
Status: Not yet started
Work Items:
- [stefan-bader-canonical] Pull openvswitch (from dkms) into main kernel
modules: TODO
[serge-hallyn] test open openvswitch with qemu-kvm, document in features wiki
page: TODO
[serge-hallyn
Doh! I think I found out what it going on... The problem can be, as it
has been said before, reduced to attempting a NFS mount with:
mount -tnfs4 server:path mntpt
which will fail with a completely useless message of no such device. It
was also said that -tnfs does work. Now the interesting
@Steve, this seems actually already to be addressed. Unfortunately in a
way that is easy to get wrong. The nfs module would for example be
autoloaded when the idmapd gets started. And the /etc/default/nfs-common
comments clearly say it should be needed for v4. However one seems to be
able to get a
I am not sure whether mount.nfs4 ever did load the right module. At least it
does not do it back to Lucid and I have not checked farther back. It may be
that nfs once was built in and thus avoided all the issues. The modprobe call
happens in mount. Which takes the fstype as the module to load.
So as expected upstream was not too exited about a change to the kernel
module. In fact the answer was suggesting that using the fstype nfs4 is
rather deprecated. And I was observing that even using mount -tnfs ...
the resulting mount options which could be observed in cat
/proc/mounts were the
I carefully went through the various man pages again and found that
despite me missing those before, there are indications:
man nfs
...
The fstype field contains nfs. Use of the nfs4 fstype in
/etc/fstab is deprecated.
...
To mount using NFS version 4, use either the nfs file system
They are of course different. I just checked with a resent 2.6.2-37.81
generic i386 kernel. And here the module loads just fine. Note that you
had to load ipmi_devintf always to make ipmitool work. Please check
dmesg after the failed load as that normally shows more detailed errors.
--
You
Weirdly seems to skip some probing state.
@Asif, could you please do the following: boot back into the -36 kernel version
(which had ipmi working). Not sure whether it can simply be done via iKVM but
otherwise you could modify the set default=0 line in /boot/grub/grub.cfg to
=2 and reboot.
True, on my supermicro this would also be possible through the web
interface,
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to ipmitool in Ubuntu.
https://bugs.launchpad.net/bugs/916200
Title:
missing kernel module ipmi_si module
To
*** This bug is a duplicate of bug 662711 ***
https://bugs.launchpad.net/bugs/662711
This is actually fixed in Precise by a change to nfs-utils for bug
#662711. For that reason I'll mark the bug report here as a duplicate.
** Changed in: module-init-tools (Ubuntu)
Status: New =
Hm, when I look at /etc/init/cloud-init-local.conf and */cloud-init.conf
they seem to say start on mounted MOUNTPOINT=/. So I'd somehow expect
mountall to be finished with / at that point. Still the output of cloud-
init and mountall seem to intermix often. As if they are executed around
the same
Hm weird. I would have expected at least a rw open on the block device should
fail, let alone a ro (since fsck probably wants to modify the fs). Though I'd
need to check exactly what access mode mount -oro uses (maybe its some ro
exclusive). Actually it is not really a read-only open on the
Ok, / is non-sense as it is certainly mounted and also the failing fsck
is fot /mnt. But generally it looks like mountall and cloud-init running
concurrently and anything that opens the device may block a rw access
for the fsck. So any blkid could do that. The window is not very big but
who
Public bug reported:
The build system depends on a certain naming scheme of the rom images.
The basename of the rom file (e.g. rtl8139.rom - rtl8139) must be
defined in the drivers PCI_ROM or ISA_ROM makro. For the rtl8139 driver
this is correctly done:
PCI_ROM(0x10ec, 0x8139, rtl8139,
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to ipxe in Ubuntu.
https://bugs.launchpad.net/bugs/948323
Title:
Rom images for e1000 and ne2k missign vendor and device id
To manage notifications about this bug go to:
The bug, if to say so, is that for kvm there have been additional rom image
targets added. By the way the build system for ipxe works, I believe all the
required rom images have been build already by the makeall (whatever it is
called again). Just the names are different for some of them (for
Or actually modify the QEMUS line instead of removing things:
QEMUS = 8086100e ne pcnet32 rtl8139 virtio-net
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to ipxe in Ubuntu.
https://bugs.launchpad.net/bugs/948323
Title:
Rom images
This is how I would propose to do the fix. It keeps the target names for
kvm-ipxe but modifies the file names in the makefile and target name for
the links. I did it that way because to fix the Xen issue I modified the
xen package to look for the 8086100e.rom.
Before:
Serge, I had not directly thought of it because our discussion went
probably into some confusion when also talking about (bug 949028). But
it would make sense. It is not critical to get it into Ubuntu right now
as the Xen build has been fixed to use the alternative file name which
works.
--
You
Hm, thinking of this again, it does seem to me that the whole allqemu
target and special kvm-ipxe may be Ubuntu specific and neither in
upstream or Debian. Checking the latest Debian source to confirm this...
--
You received this bug notification because you are a member of Ubuntu
Server Team,
Ok, I think I confirmed this to be only in the Ubuntu version. Marc, I
believe you have been working on this. Maybe we could get the change
reviewed and loosely queued (without upload) to be picked up whenever
something serious (or the next release) come up?
--
You received this bug notification
On 29.05.2012 00:15, Ben Howard wrote:
Oh...
After cracking open a local copy of the image, it looks like linux-
image-virtual has gone away. We are assuming that linux-image-virtual is
going to be there.
Actually no. This may be a result of merging generic and virtual images together
as
I can see the same on most my reboots on a Atom based mini-server. An
educated guess would be that SIGHUP happens before squid3 actually has
set up its own sighandler for it. And the default is exit.
** Changed in: squid3 (Ubuntu)
Status: Incomplete = Confirmed
--
You received this bug
Blueprint changed by Stefan Bader:
Work items changed:
Work items:
[smoser] jump for joy: DONE
[rbasak] follow up on console log size limit implementation (ringbuffer): TODO
- [stefan-bader-canonical] confirm the xen and qemu prom naming is correct
after the debian merge back: TODO
without an other changes
and evaluate the situation after that.
I will attach diffs for the merge as I would do it. Please have a look.
Thanks.
** Affects: squid3 (Ubuntu)
Importance: Wishlist
Assignee: Stefan Bader (stefan-bader-canonical)
Status: In Progress
--
You received
** Patch added: ubuntu-merge.debdiff
https://bugs.launchpad.net/ubuntu/+source/squid3/+bug/1016560/+attachment/3200335/+files/ubuntu-merge.debdiff
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to squid3 in Ubuntu.
** Patch added: debian-merge.debdiff
https://bugs.launchpad.net/ubuntu/+source/squid3/+bug/1016560/+attachment/3200336/+files/debian-merge.debdiff
** Patch removed: ubuntu-merge.debdiff
** Patch added: ubuntu-merge.debdiff
https://bugs.launchpad.net/ubuntu/+source/squid3/+bug/1016560/+attachment/3200338/+files/ubuntu-merge.debdiff
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to squid3 in Ubuntu.
Realized that I forgot to update the release pocket. Adding an amended
debian-merge diff.
** Patch added: debian-merge-v2.debdiff
https://bugs.launchpad.net/ubuntu/+source/squid3/+bug/1016560/+attachment/3200355/+files/debian-merge-v2.debdiff
--
You received this bug notification because
Is this hardware that did work before or new hardware?
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to ipmitool in Ubuntu.
https://bugs.launchpad.net/bugs/1032724
Title:
Cannot access IPMI card
To manage notifications about this
Actually, second question: was ipmitool run as root, too? The /dev/ipmi0
file is only readable by root.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to ipmitool in Ubuntu.
https://bugs.launchpad.net/bugs/1032724
Title:
Cannot access
Ok, stupid question as it seems to be obvious from the login prompt,
sorry. Tried this on my machine and it did work, though.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to ipmitool in Ubuntu.
https://bugs.launchpad.net/bugs/1032724
One thing I saw in the dmesg: the io memory (0xca8) which the SMBIOS
returns is not registered/reserved before. On my machine there is a
reservation by one of the ACPI PNP devices (PNP0c02).
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed
So this seems to cause some errors later and no BMC in found, thus no
device /dev/ipmi0 is created.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to ipmitool in Ubuntu.
https://bugs.launchpad.net/bugs/1032724
Title:
Cannot access
I have not personally looked (because I have none and no access) on HP servers.
But talking to other people gave the impression that HP not automatically
allows IPMI access. Sounds like it would be some option one needs to buy. So
before asking for debug access, are we sure this should work
Blueprint changed by Stefan Bader:
Work items changed:
Work items:
[zulcss] merge latest upstream libvirt: DONE
[serge-hallyn] finish MIR of netcf bug 904014: DONE
[serge-hallyn] link libvirt against netcf: DONE
- [stefan-bader-canonical] look into transition from xend to libxl: TODO
** Changed in: libvirt (Ubuntu)
Status: Fix Released = Triaged
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to libvirt in Ubuntu.
https://bugs.launchpad.net/bugs/914788
Title:
libvirt expexts qemu-dm in wrong path for xen
To
Cannot remember but either it was not a problem or nobody really depends
on it. So as long as there isn't someone really in need I would not
touch Oneiric.
** Changed in: libvirt (Ubuntu Oneiric)
Status: Confirmed = Won't Fix
--
You received this bug notification because you are a member
Reading through comments again I am rather sure this should be in fixed
now.
** Changed in: linux (Ubuntu)
Status: Fix Committed = Fix Released
** Changed in: linux (Ubuntu)
Assignee: Stefan Bader (stefan-bader-canonical) = (unassigned)
--
You received this bug notification because
Blueprint changed by Stefan Bader:
Work items changed:
Work items:
[louis-bouchard] - kdump-tools needs to be MIR / file a bug: TODO
- [smb] - discuss linuxcrashdump changes on ubuntu-devel / ubuntu-kernel: TODO
- [smb] - linuxcrashdump changed to install kdump-tool (after discussion
Blueprint changed by Stefan Bader:
Work items changed:
Work items:
[lars-kurth] sort contributions pie chart by percentage: TODO
[dunlapg] Link to slides that were shown: DONE
[ijc] Ian and Adam discuss grub2 booting Xen first: TODO
[dunlapg] MaaS for installing Xen: TODO
[dunlapg
Blueprint changed by Stefan Bader:
Work items changed:
Work items:
[lars-kurth] sort contributions pie chart by percentage: TODO
[dunlapg] Link to slides that were shown: DONE
[ijc] Ian and Adam discuss grub2 booting Xen first: TODO
[dunlapg] MaaS for installing Xen: TODO
- [dunlapg
Blueprint changed by Stefan Bader:
Work items changed:
Work items:
[lars-kurth] sort contributions pie chart by percentage: TODO
[dunlapg] Link to slides that were shown: DONE
[ijc] Ian and Adam discuss grub2 booting Xen first: TODO
[dunlapg] MaaS for installing Xen: TODO
[stefan
I agree, the patch looks reasonable. Though it would be much preferable
to kindly ask the patch author about the upstream submission, and when
there is a commit in the upstream tree, think about SRUing it into (in
fact when asking, it would be best if the upstream submission had a cc:
I am currently discussing this upstream. My impression is that this may
be an intended change to get a sane way of naming the xvd devices when
the configuration may mix hd and sd naming. So there is a 4 device
offset done in the enumeration of xvd devices for disks named sd? in the
configuration.
Just as some additional background information while there is upstream
discussion going on. I am not sure how it will end as yesterday
responses rather made hope for getting things back and today there is
others rather wanting to preserve the current status.
The main argument is HVM as you can
** Changed in: linux (Ubuntu Oneiric)
Assignee: Canonical Kernel Team (canonical-kernel-team) = Stefan Bader
(stefan-bader-canonical)
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to cloud-init in Ubuntu.
https
As far as I can see the patch
commit 1aa8ceef0312a6aae7dd863a120a55f1637b361d
Author: Nikola Ciprich extmaill...@linuxbox.cz
Date: Wed Mar 9 23:36:51 2011 +0100
KVM: fix kvmclock regression due to missing clock update
commit 387b9f97750444728962b236987fbe8ee8cc4f8c moved
For Oneiric, this should be fixed already.
** Also affects: linux (Ubuntu Natty)
Importance: Undecided
Status: New
** Also affects: qemu-kvm (Ubuntu Natty)
Importance: Undecided
Status: New
** Changed in: qemu-kvm (Ubuntu Natty)
Status: New = Invalid
** Changed in:
in: linux (Ubuntu Natty)
Status: New = In Progress
** Changed in: linux (Ubuntu Natty)
Assignee: (unassigned) = Stefan Bader (stefan-bader-canonical)
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to qemu-kvm in Ubuntu.
https
** Description changed:
+ SRU Justification:
+
+ Impact: An upstream change in the kvm code in 2.6.37 causes regressions
+ running 32bit guest under 11.04 (Natty) KVM.
+
+ Fix: Cherry-picking a single upstream patch (which went into 2.6.39)
+ fixes the issue.
+
+ Testcase: Booting 32bit rhel
Thanks Greg. I have gone ahead and submitted the patch for SRU.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to qemu-kvm in Ubuntu.
https://bugs.launchpad.net/bugs/795717
Title:
32bit rhel and centos 5.(5|6) hangs on boot on natty
** Changed in: linux (Ubuntu Natty)
Status: In Progress = Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to qemu-kvm in Ubuntu.
https://bugs.launchpad.net/bugs/795717
Title:
32bit rhel and centos 5.(5|6) hangs on
Greg, could you check with the proposed kernel, too? Process requires it
and I don't have the setup ready. Would also help to ensure that the new
kernel brings no other problem. :) Thanks.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed
Note that the automatic statement of released is misleading. This
patch has been reverted as it was not verified and the kernel without
the change is now released.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to qemu-kvm in Ubuntu.
Blueprint changed by Stefan Bader:
Work items changed:
Work items:
[ebiederm] Push fix for XFS and user namespaces: TODO
[serge-hallyn] Fix lxc-net to be nestable with no user interaction: DONE
[serge-hallyn] Write sysctl to disable unprivileged CLONE_NEWUSER: DONE
[serge-hallyn
Blueprint changed by Stefan Bader:
Work items changed:
Work items:
[ebiederm] Push fix for XFS and user namespaces: TODO
[serge-hallyn] Fix lxc-net to be nestable with no user interaction: DONE
[serge-hallyn] Write sysctl to disable unprivileged CLONE_NEWUSER: DONE
[serge-hallyn
Blueprint changed by Stefan Bader:
Work items changed:
Work items:
[ebiederm] Push fix for XFS and user namespaces: TODO
[serge-hallyn] Fix lxc-net to be nestable with no user interaction: DONE
[serge-hallyn] Write sysctl to disable unprivileged CLONE_NEWUSER: DONE
[serge-hallyn
Serge mentioned today on IRC that this may be also a glibc issue, but I
am not sure what exactly he was looking at and why he thinks so.
Apparently ftracing (I guess the qemu process) and some partially
inlining clone function (those with .isra extention) were involved.
--
You received this bug
Before running prepare-testbed:
- create a directory in /mnt that user ubuntu can write to (say /mnt/adt)
- echo BASEDIR=/mnt/adt ~/.adtrc
autopkgtest should then use /mnt which has lots of space on medium
guests.
--
You received this bug notification because you are a member of Ubuntu
Server
I saw a similar crash when running the prepare script with a Saucy64
host, a Saucy32 1rst and Saucy32 2nd level guest. The 1rst level guest
cpu set to core2duo and I also had to replace the qemu-system-x86_64 by
qemu (which maps to the same arch). Otherwise the 2nd level guest was
not started at
Using a 64bit 1rst level guest seemed better on manual runs but running
in loops seemed to have locked up on the third run. Though completely
without any messages. I have to look into that next week. I need to run
again with qmp enabled. At least this allows to check for the
instruction pointer of
Trying to summarize my testing so far:
Host: saucy 64bit, 1rst level saucy 32bit, 2nd level saucy 32bit:
- 2nd level guest did not start when using qemu-system-x86_64:
- This may be some regression or feature, not sure, yet.
- Using qemu only (defaulting to same arch) the 2nd level guest
So host Q and 1rst 32 completed 35 runs and 1rst 64 completed 40.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to qemu-kvm in Ubuntu.
https://bugs.launchpad.net/bugs/1208455
Title:
general protection fault running apt-get inside
Actually for Saucy I would rather like to get Xen 4.3 uploaded instead.
** Changed in: xen (Ubuntu Saucy)
Status: In Progress = Won't Fix
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to xen in Ubuntu.
They can be even together. The -nographic removes any emulated graphics
card. I am not sure in detail how the cloud images work, but I believe
serial line as a console is always on. Depending on which release (in
that case I think it is the qemu user-space) the used setup would not
work even.
** Patch added: Xen-README.diff
https://bugs.launchpad.net/ubuntu/+source/xen/+bug/1218817/+attachment/3795024/+files/Xen-README.diff
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to xen in Ubuntu.
(Ubuntu)
Importance: High
Assignee: Stefan Bader (smb)
Status: New
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to xen in Ubuntu.
https://bugs.launchpad.net/bugs/1218817
Title:
[FFE] Update to Xen-4.3 in Saucy
To manage
I uploaded and build the new Xen package in my PPA (ppa:smb/xen):
https://launchpad.net/~smb/+archive/xen/+build/4880118/+files/buildlog_ubuntu-saucy-amd64.xen_4.3.0-0ubuntu3_UPLOADING.txt.gz
Several bugfixes were required in virt-install, libvirt and qemu and
already have been uploaded to Saucy and submitted upstream when
appropriate.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to xen in Ubuntu.
Blueprint changed by Stefan Bader:
Work items changed:
Work items:
Add a more recent version of XCP to the Ubuntu Archive: POSTPONED
Write XCP documentation and Openstack: POSTPONED
Test XCP and Openstack: POSTPONED
Write documenation on vmware and Openstack: POSTPONED
Work items
Since I have not heard anything back from Citrix, I did an attempt of
checking myself and found that even without any update to Xen the xen-
api/xcp state is ... highly improvable. The command-line examples in the
README.Debian of xcp-xapi more or less work (with the caveat that you
have to leave
** Description changed:
SRU Justification:
Impact: Upstream Xen has released a stable update to 4.2.2. Since Raring
and Saucy are based on 4.2 it would be gaining us bug fixes without
waiting for people to run into them. Like we do with upstream stable on
the kernel.
Fix:
As it seemed that starting a 64bit hypervisor (qemu-system-x86_64) from
a 32bit user-space running on another 64bit hypervisor has different
issues which seem to go back even further, I concentrated on bisecting
the case of host running 64bit user-space on a 64bit CPU and the first
level guest
Btw, James, this means there is a simple but not very helpful work-
around for Saucy: use AMD CPU based hosts. Did not check for 32bit user-
space on 1rst level but with 64bit and had no issues. Not very
surprising as the regression seems to be in the nested VMX code. But
also not very useful when
Hi Brian,
not formally yet as I wanted to write that down here as comments with
results. Need to see how much effort it will be to leverage some or more
of the regression testing that xen upstram does on the git repos. But
since I am travelling right now it will get delayed till next week.
--
Blueprint changed by Stefan Bader:
Work items changed:
Work items:
[serge-hallyn] (Dwight is pushing this, but has no lp id) Push fix for XFS
and user namespaces: DONE
[serge-hallyn] Fix lxc-net to be nestable with no user interaction: DONE
[serge-hallyn] Write sysctl to disable
Adding the test results as an attachment to keep the formatting sane.
Note on the one occasional failure of the security QRT run: one of the
tests for /proc/pid/maps turns out to be racy at least (I need to talk
to the security team about it). But failing or not failing is only
depending on
The newer version of the drbd8 utils offer a way to include backwards
compatible versions of drbdadm and drbdsetup. So it seemed possible to backport
that version. There were a few details to add but I think I got a version that
seems to work ok within 12.04/Precise and a 3.2 kernel and after
** Attachment added: drbd8-utils_8.4.3-0ubuntu0.12.04.1_i386.deb
https://bugs.launchpad.net/ubuntu/+source/drbd8/+bug/1185756/+attachment/3840757/+files/drbd8-utils_8.4.3-0ubuntu0.12.04.1_i386.deb
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is
** Attachment added: drbd8-utils_8.4.3-0ubuntu0.12.04.1_amd64.deb
https://bugs.launchpad.net/ubuntu/+source/drbd8/+bug/1185756/+attachment/3840756/+files/drbd8-utils_8.4.3-0ubuntu0.12.04.1_amd64.deb
--
You received this bug notification because you are a member of Ubuntu
Server Team, which
@Numérigraphe,
thanks for the quick testing. To answer the question from #12 first: The
version used by that package depends on the version of the kernel. So
just upgrading kernel to 3.8 (or later) and booting with that kernel
will cause the 8.4 utils part to be used. This unfortunately does some
So it seems the version displayed by the tools is coded to be that older
version. The code itself rather looks to be more recent. So I would
rather just tweak the version numbers.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to drbd8
** Attachment added: drbd8-utils_8.4.3-0ubuntu0.12.04.1_amd64.deb
https://bugs.launchpad.net/ubuntu/+source/drbd8/+bug/1185756/+attachment/3851297/+files/drbd8-utils_8.4.3-0ubuntu0.12.04.1_amd64.deb
--
You received this bug notification because you are a member of Ubuntu
Server Team, which
I re-uploaded the Raring debdiff and packages (sorry a bit unclean and
using the same version number again). The only change to the previous
version is the legacy tools version number being bumped.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is
1 - 100 of 346 matches
Mail list logo
