[Bug 1511830] [NEW] apparmor denies VM startup when image is network mounted

Public bug reported: If I attempt to start a VM with one of its disk images on a libvirt managed NFS mount, it fails: Oct 30 15:30:56 athens kernel: [545232.917662] audit: type=1400 audit(1446233456.718:81): apparmor="DENIED" operation="sendmsg" profile="/usr/lib/libvirt/virt-aa-helper"

[Bug 1511840] [NEW] cannot apport-bug from IPv6-only network

Public bug reported: Attempting to report a bug using apport-bug from a machine without a legacy IP address fails: # apport-bug foopackage ... *** Uploading problem information The collected information is being sent to the bug tracking system. This might take a few minutes. *** Error:

[Bug 1492621] Re: Cannot start VMs without routable IPv4 address

Given that VNC does this as well, I traced the problem all the way back to getaddrinfo() behavior in libc. I believe this describes it: https://bugzilla.redhat.com/show_bug.cgi?id=721350 tl;dr: It ignores loopback when enumerating addresses per family. Workaround is to define the display as ::1,

[Bug 1492621] Re: Cannot start VMs without routable IPv4 address

Attaching typescript output of requested diagnostic commands. As OVS rather than Linux bridge is in use, I have included potentially relevant ovs-* command output. ** Attachment added: "1492621-diag.txt"

[Bug 1492621] Re: Cannot start VMs without routable IPv4 address

I don't have the 'kvm' command on this machine, but it definitely appears to be qemu related: kjotte@athens:~$ qemu-system-x86_64 -spice addr=127.0.0.1,port=5900 (/usr/bin/qemu-system-x86_64:1785): Spice-Warning **: reds.c:2330:reds_init_socket: getaddrinfo(127.0.0.1,5900): Address family for

[Bug 1492621] [NEW] Cannot start VMs without routable IPv4 address

Public bug reported: qemu will not start VMs using spice or vnc displays unless there is a routable IPv4 address on the machine, even though the error relates to 127.0.0.1 root@athens:~# ip addr 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default link/loopback

[Bug 1448254] Re: openvswitch systemd unit file ordering wrong

Looks we've been through this before with upstart: https://bugs.launchpad.net/ubuntu/+source/openvswitch/+bug/1084028 -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to openvswitch in Ubuntu. https://bugs.launchpad.net/bugs/1448254

[Bug 1448254] [NEW] openvswitch systemd unit file ordering wrong

Public bug reported: After upgrade to vivid, my system takes nearly 4 minutes to boot. This appears to be related to the new systemd unit ordering. [Unit] Description=Open vSwitch After=network.target openvswitch-nonetwork.service ... root@mystic:/lib/systemd/system# systemd-analyze blame |

[Bug 224665] Re: ntpd starts but does not contact peers

I have upgraded the machine I was experiencing this problem on from hardy to lucid. As such I probably won't be able to do much more in helping to fix. Maintainer may want to close with appropriate flags. -- ntpd starts but does not contact peers https://bugs.launchpad.net/bugs/224665 You

[Bug 224665] Re: ntpd starts but does not contact peers

@Forest: Ah, that makes sense. I am using a local bind9 as my resolver, which is most likely not alive by the time ntp is getting bounced by the network subsystem. Not sure if that makes this bug invalid since it is not really ntpd's fault. -- ntpd starts but does not contact peers

[Bug 236640] Re: iSCSI install fails under hardy

When I was testing I had forgotten that there had to be a local disk present for open-iscsi to get loaded. I retested this morning with a dummy hard disk in play and the install completed successfully. Thank you all for your hard work on this one! -- iSCSI install fails under hardy

[Bug 237460] Re: Root on iscsi is not supported

What needs to be done to make the open-iscsi-udeb load earlier in the install sequence so its block devices are available to disk-detect? Sounds like the initramfs problem is solved. As for blowing away the networking, one possible solution: if the installer knows what interface the initiator

[Bug 236640] Re: iSCSI install fails under hardy

I just acquired karmic-server-i386.iso from http://cdimage.ubuntu.com /ubuntu-server/daily/current/ and booted with the iscsi=true commandline option. I was not prompted for any iscsi information, nor is Configure iSCSI present in the installer main menu. -- iSCSI install fails under hardy

[Bug 236640] Re: iSCSI install fails under hardy

Steve, there was a response to comment 11 in comment 13. I can't seem to find where to get the daily build (my google-fu is weak today) I just tried the 9.04 server release CD with iscsi=true and was greeted with the dialog asking me to choose a module for my storage device. I grepped syslog

[Bug 236640] Re: iSCSI install fails under hardy

iscsi=true doesn't even seem to be parsed by the Jaunty alpha4 installer. -- iSCSI install fails under hardy https://bugs.launchpad.net/bugs/236640 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to open-iscsi in ubuntu. --

[Bug 236640] Re: iSCSI install fails under hardy

Any chance we'll see this in Jaunty? Jaunty+1? What is the timeline for this? -- iSCSI install fails under hardy https://bugs.launchpad.net/bugs/236640 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to open-iscsi in ubuntu. --

[Bug 236642] Re: unable to get iSCSI prompt without physical disk present in hardy-server

*** This bug is a duplicate of bug 237460 *** https://bugs.launchpad.net/bugs/237460 ** This bug has been marked a duplicate of bug 237460 Root on iscsi is not supported -- unable to get iSCSI prompt without physical disk present in hardy-server https://bugs.launchpad.net/bugs/236642 You