[Touch-packages] [Bug 1988270] Re: AppArmor fails to start with Yoga UCA libvirt profile on Focal
apparmor is not provided in the Ubuntu Cloud Archive so we can remove that target from this bug as it is a little misleading. The fix has been released to Focal and Jammy hence why deploying Openstack Yoga on either of those (using focal-yoga uca or jammy-updates) gets you the fixed apparmor. Hope that makes sense. ** No longer affects: cloud-archive ** No longer affects: cloud-archive/antelope ** No longer affects: cloud-archive/yoga ** No longer affects: cloud-archive/zed ** Changed in: apparmor (Ubuntu Jammy) Status: Confirmed => Fix Released ** Changed in: apparmor (Ubuntu Focal) Status: Confirmed => Fix Committed ** Changed in: apparmor (Ubuntu Focal) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1988270 Title: AppArmor fails to start with Yoga UCA libvirt profile on Focal Status in apparmor package in Ubuntu: Invalid Status in apparmor source package in Focal: Fix Released Status in apparmor source package in Jammy: Fix Released Bug description: [ Impact ] AppArmor fails to start with yoga-focal uca libvirt profile [ Test Plan ] generate yoga-focal openstack instance juju ssh nova-compute/0 sudo systemctl restart apparmor journalctl -xe # Error message ct 04 15:55:32 juju-6d4862-apparmorbug-9 apparmor.systemd[94081]: AppArmor parser error for /etc/apparmor.d/usr.sbin.libvirtd in /etc/apparmor.d/usr.sbin.li> Oct 04 15:55:32 juju-6d4862-apparmorbug-9 apparmor.systemd[94082]: Skipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd Oct 04 15:55:32 juju-6d4862-apparmorbug-9 audit[94084]: AVC apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="u> Oct 04 15:55:32 juju-6d4862-apparmorbug-9 apparmor.systemd[94005]: Error: At least one profile failed to load [ Other Notes ] On a fully patched Ubuntu Focal with Yoga UCA enabled, after installation of libvirt-daemon-system, restarting apparmor would fail with error: Aug 31 07:40:52 ubuntu2004.localdomain apparmor.systemd[6335]: Restarting AppArmor Aug 31 07:40:52 ubuntu2004.localdomain apparmor.systemd[6335]: Reloading AppArmor profiles Aug 31 07:40:52 ubuntu2004.localdomain apparmor.systemd[6341]: Skipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd Aug 31 07:40:52 ubuntu2004.localdomain apparmor.systemd[6348]: AppArmor parser error for /etc/apparmor.d in /etc/apparmor.d/usr.sbin.libvirtd at line 29: Invalid capability bpf. Aug 31 07:40:52 ubuntu2004.localdomain apparmor.systemd[6413]: AppArmor parser error for /etc/apparmor.d/usr.sbin.libvirtd in /etc/apparmor.d/usr.sbin.libvirtd at line 29: Invalid capability bpf. Aug 31 07:40:52 ubuntu2004.localdomain apparmor.systemd[6418]: Skipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd Aug 31 07:40:52 ubuntu2004.localdomain apparmor.systemd[6335]: Error: At least one profile failed to load Aug 31 07:40:52 ubuntu2004.localdomain systemd[1]: apparmor.service: Main process exited, code=exited, status=1/FAILURE Aug 31 07:40:52 ubuntu2004.localdomain systemd[1]: apparmor.service: Failed with result 'exit-code'. Aug 31 07:40:52 ubuntu2004.localdomain systemd[1]: Failed to start Load AppArmor profiles. In addition to bpf, perfmon capability, which is also enabled in /etc/apparmor.d/usr.sbin.libvirtd profile, would lead to the same error. System information: root@ubuntu2004:~# uname -a Linux ubuntu2004.localdomain 5.4.0-125-generic #141-Ubuntu SMP Wed Aug 10 13:42:03 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux root@ubuntu2004:~# dpkg -l libvirt\* Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==-===--= ii libvirt-clients8.0.0-1ubuntu7.1~cloud0 amd64 Programs for the libvirt library ii libvirt-daemon 8.0.0-1ubuntu7.1~cloud0 amd64 Virtualization daemon ii libvirt-daemon-config-network 8.0.0-1ubuntu7.1~cloud0 all Libvirt daemon configuration files (default network) ii libvirt-daemon-config-nwfilter 8.0.0-1ubuntu7.1~cloud0 all Libvirt daemon configuration files (default network filters) un libvirt-daemon-driver-lxc (no description available) ii libvirt-daemon-driver-qemu 8.0.0-1ubuntu7.1~cloud0 amd64 Virtualization daemon QEMU connection driver un libvirt-daemon-driver-storage-gluster
[Touch-packages] [Bug 1988270] Re: AppArmor fails to start with Yoga UCA libvirt profile on Focal
oh and of course kinetic/zed too -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1988270 Title: AppArmor fails to start with Yoga UCA libvirt profile on Focal Status in Ubuntu Cloud Archive: Confirmed Status in Ubuntu Cloud Archive yoga series: New Status in Ubuntu Cloud Archive zed series: Confirmed Status in apparmor package in Ubuntu: Invalid Status in apparmor source package in Focal: New Status in apparmor source package in Jammy: New Bug description: [ Impact ] AppArmor fails to start with yoga-focal uca libvirt profile [ Test Plan ] generate yoga-focal openstack instance juju ssh nova-compute/0 sudo systemctl restart apparmor journalctl -xe # Error message ct 04 15:55:32 juju-6d4862-apparmorbug-9 apparmor.systemd[94081]: AppArmor parser error for /etc/apparmor.d/usr.sbin.libvirtd in /etc/apparmor.d/usr.sbin.li> Oct 04 15:55:32 juju-6d4862-apparmorbug-9 apparmor.systemd[94082]: Skipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd Oct 04 15:55:32 juju-6d4862-apparmorbug-9 audit[94084]: AVC apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="u> Oct 04 15:55:32 juju-6d4862-apparmorbug-9 apparmor.systemd[94005]: Error: At least one profile failed to load [ Other Notes ] On a fully patched Ubuntu Focal with Yoga UCA enabled, after installation of libvirt-daemon-system, restarting apparmor would fail with error: Aug 31 07:40:52 ubuntu2004.localdomain apparmor.systemd[6335]: Restarting AppArmor Aug 31 07:40:52 ubuntu2004.localdomain apparmor.systemd[6335]: Reloading AppArmor profiles Aug 31 07:40:52 ubuntu2004.localdomain apparmor.systemd[6341]: Skipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd Aug 31 07:40:52 ubuntu2004.localdomain apparmor.systemd[6348]: AppArmor parser error for /etc/apparmor.d in /etc/apparmor.d/usr.sbin.libvirtd at line 29: Invalid capability bpf. Aug 31 07:40:52 ubuntu2004.localdomain apparmor.systemd[6413]: AppArmor parser error for /etc/apparmor.d/usr.sbin.libvirtd in /etc/apparmor.d/usr.sbin.libvirtd at line 29: Invalid capability bpf. Aug 31 07:40:52 ubuntu2004.localdomain apparmor.systemd[6418]: Skipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd Aug 31 07:40:52 ubuntu2004.localdomain apparmor.systemd[6335]: Error: At least one profile failed to load Aug 31 07:40:52 ubuntu2004.localdomain systemd[1]: apparmor.service: Main process exited, code=exited, status=1/FAILURE Aug 31 07:40:52 ubuntu2004.localdomain systemd[1]: apparmor.service: Failed with result 'exit-code'. Aug 31 07:40:52 ubuntu2004.localdomain systemd[1]: Failed to start Load AppArmor profiles. In addition to bpf, perfmon capability, which is also enabled in /etc/apparmor.d/usr.sbin.libvirtd profile, would lead to the same error. System information: root@ubuntu2004:~# uname -a Linux ubuntu2004.localdomain 5.4.0-125-generic #141-Ubuntu SMP Wed Aug 10 13:42:03 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux root@ubuntu2004:~# dpkg -l libvirt\* Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==-===--= ii libvirt-clients8.0.0-1ubuntu7.1~cloud0 amd64 Programs for the libvirt library ii libvirt-daemon 8.0.0-1ubuntu7.1~cloud0 amd64 Virtualization daemon ii libvirt-daemon-config-network 8.0.0-1ubuntu7.1~cloud0 all Libvirt daemon configuration files (default network) ii libvirt-daemon-config-nwfilter 8.0.0-1ubuntu7.1~cloud0 all Libvirt daemon configuration files (default network filters) un libvirt-daemon-driver-lxc (no description available) ii libvirt-daemon-driver-qemu 8.0.0-1ubuntu7.1~cloud0 amd64 Virtualization daemon QEMU connection driver un libvirt-daemon-driver-storage-gluster (no description available) un libvirt-daemon-driver-storage-iscsi-direct (no description available) un libvirt-daemon-driver-storage-rbd (no description available) un libvirt-daemon-driver-storage-zfs (no description available) un libvirt-daemon-driver-vbox (no description available) un libvirt-daemon-driver-xen (no description available) ii
[Touch-packages] [Bug 1988270] Re: AppArmor fails to start with Yoga UCA libvirt profile on Focal
@hypothetical-lemon to get this into focal-yoga it will need to be fixed in Jammy first. As I understand it the problem is focal-specific to either the package needs to be selective on which config it applies based on series or perhaps the uca itself needs fixing to support this on focal. ** Also affects: apparmor (Ubuntu Jammy) Importance: Undecided Status: New ** Also affects: cloud-archive/yoga Importance: Undecided Status: New ** Also affects: cloud-archive/zed Importance: Undecided Assignee: Heather Lemon (hypothetical-lemon) Status: Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1988270 Title: AppArmor fails to start with Yoga UCA libvirt profile on Focal Status in Ubuntu Cloud Archive: Confirmed Status in Ubuntu Cloud Archive yoga series: New Status in Ubuntu Cloud Archive zed series: Confirmed Status in apparmor package in Ubuntu: Invalid Status in apparmor source package in Focal: New Status in apparmor source package in Jammy: New Bug description: [ Impact ] AppArmor fails to start with yoga-focal uca libvirt profile [ Test Plan ] generate yoga-focal openstack instance juju ssh nova-compute/0 sudo systemctl restart apparmor journalctl -xe # Error message ct 04 15:55:32 juju-6d4862-apparmorbug-9 apparmor.systemd[94081]: AppArmor parser error for /etc/apparmor.d/usr.sbin.libvirtd in /etc/apparmor.d/usr.sbin.li> Oct 04 15:55:32 juju-6d4862-apparmorbug-9 apparmor.systemd[94082]: Skipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd Oct 04 15:55:32 juju-6d4862-apparmorbug-9 audit[94084]: AVC apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="u> Oct 04 15:55:32 juju-6d4862-apparmorbug-9 apparmor.systemd[94005]: Error: At least one profile failed to load [ Other Notes ] On a fully patched Ubuntu Focal with Yoga UCA enabled, after installation of libvirt-daemon-system, restarting apparmor would fail with error: Aug 31 07:40:52 ubuntu2004.localdomain apparmor.systemd[6335]: Restarting AppArmor Aug 31 07:40:52 ubuntu2004.localdomain apparmor.systemd[6335]: Reloading AppArmor profiles Aug 31 07:40:52 ubuntu2004.localdomain apparmor.systemd[6341]: Skipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd Aug 31 07:40:52 ubuntu2004.localdomain apparmor.systemd[6348]: AppArmor parser error for /etc/apparmor.d in /etc/apparmor.d/usr.sbin.libvirtd at line 29: Invalid capability bpf. Aug 31 07:40:52 ubuntu2004.localdomain apparmor.systemd[6413]: AppArmor parser error for /etc/apparmor.d/usr.sbin.libvirtd in /etc/apparmor.d/usr.sbin.libvirtd at line 29: Invalid capability bpf. Aug 31 07:40:52 ubuntu2004.localdomain apparmor.systemd[6418]: Skipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd Aug 31 07:40:52 ubuntu2004.localdomain apparmor.systemd[6335]: Error: At least one profile failed to load Aug 31 07:40:52 ubuntu2004.localdomain systemd[1]: apparmor.service: Main process exited, code=exited, status=1/FAILURE Aug 31 07:40:52 ubuntu2004.localdomain systemd[1]: apparmor.service: Failed with result 'exit-code'. Aug 31 07:40:52 ubuntu2004.localdomain systemd[1]: Failed to start Load AppArmor profiles. In addition to bpf, perfmon capability, which is also enabled in /etc/apparmor.d/usr.sbin.libvirtd profile, would lead to the same error. System information: root@ubuntu2004:~# uname -a Linux ubuntu2004.localdomain 5.4.0-125-generic #141-Ubuntu SMP Wed Aug 10 13:42:03 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux root@ubuntu2004:~# dpkg -l libvirt\* Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==-===--= ii libvirt-clients8.0.0-1ubuntu7.1~cloud0 amd64 Programs for the libvirt library ii libvirt-daemon 8.0.0-1ubuntu7.1~cloud0 amd64 Virtualization daemon ii libvirt-daemon-config-network 8.0.0-1ubuntu7.1~cloud0 all Libvirt daemon configuration files (default network) ii libvirt-daemon-config-nwfilter 8.0.0-1ubuntu7.1~cloud0 all Libvirt daemon configuration files (default network filters) un libvirt-daemon-driver-lxc (no description available) ii libvirt-daemon-driver-qemu 8.0.0-1ubuntu7.1~cloud0 amd64 Virtualization daemon QEMU connection driver un libvirt-daemon-driver-storage-gluster
[Touch-packages] [Bug 1776622] Re: snapd updates on focal never finish installing. Can't install any other updates.
I can confirm i hit this with a fresh install of Focal Desktop today. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1776622 Title: snapd updates on focal never finish installing. Can't install any other updates. Status in snapd: Confirmed Status in snapd package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: snapd (2.33+18.10ubuntu3) cosmic never finishes installing. Can't install any other updates. The first time I gave up waiting and killed it. Then... $ sudo apt full-upgrade E: dpkg was interrupted, you must manually run 'sudo dpkg --configure -a' to correct the problem. $ sudo dpkg --configure -a Setting up snapd (2.33+18.10ubuntu3) ... snapd.snap-repair.service is a disabled or a static unit, not starting it. << never ends >> All the while the snap and snapd process use about 0.3% CPU (which is more than usual). WORKAROUND: sudo killall apt dpkg sudo dpkg -r snapd gnome-software-plugin-snap sudo apt update sudo apt full-upgrade --- ProblemType: Bug DistroRelease: Ubuntu 18.10 Package: snapd 2.33+18.10ubuntu3 ProcVersionSignature: Ubuntu 4.15.0-22.24-generic 4.15.17 Uname: Linux 4.15.0-22-generic x86_64 ApportVersion: 2.20.10-0ubuntu3 Architecture: amd64 Date: Wed Jun 13 16:49:20 2018 InstallationDate: Installed on 2018-05-26 (17 days ago) InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Alpha amd64 (20180525) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_AU.UTF-8 SHELL=/bin/bash SourcePackage: snapd UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1776622/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1815101] Re: [master] Restarting systemd-networkd breaks keepalived, heartbeat, corosync, pacemaker (interface aliases are restarted)
** Tags added: sts
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1815101
Title:
[master] Restarting systemd-networkd breaks keepalived, heartbeat,
corosync, pacemaker (interface aliases are restarted)
Status in Keepalived Charm:
New
Status in netplan:
Confirmed
Status in heartbeat package in Ubuntu:
Triaged
Status in keepalived package in Ubuntu:
In Progress
Status in systemd package in Ubuntu:
In Progress
Status in heartbeat source package in Bionic:
Triaged
Status in keepalived source package in Bionic:
Confirmed
Status in systemd source package in Bionic:
Confirmed
Status in heartbeat source package in Disco:
Triaged
Status in keepalived source package in Disco:
Confirmed
Status in systemd source package in Disco:
Confirmed
Status in heartbeat source package in Eoan:
Triaged
Status in keepalived source package in Eoan:
In Progress
Status in systemd source package in Eoan:
In Progress
Bug description:
Configure netplan for interfaces, for example (a working config with
IP addresses obfuscated)
network:
ethernets:
eth0:
addresses: [192.168.0.5/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth2:
addresses:
- 12.13.14.18/29
- 12.13.14.19/29
gateway4: 12.13.14.17
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth3:
addresses: [10.22.11.6/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth4:
addresses: [10.22.14.6/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth7:
addresses: [9.5.17.34/29]
dhcp4: false
optional: true
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
version: 2
Configure keepalived (again, a working config with IP addresses
obfuscated)
global_defs # Block id
{
notification_email {
sysadm...@blah.com
}
notification_email_from keepali...@system3.hq.blah.com
smtp_server 10.22.11.7 # IP
smtp_connect_timeout 30 # integer, seconds
router_id system3 # string identifying the machine,
# (doesn't have to be hostname).
vrrp_mcast_group4 224.0.0.18 # optional, default 224.0.0.18
vrrp_mcast_group6 ff02::12 # optional, default ff02::12
enable_traps # enable SNMP traps
}
vrrp_sync_group collection {
group {
wan
lan
phone
}
vrrp_instance wan {
state MASTER
interface eth2
virtual_router_id 77
priority 150
advert_int 1
smtp_alert
authentication {
auth_type PASS
auth_pass BlahBlah
}
virtual_ipaddress {
12.13.14.20
}
}
vrrp_instance lan {
state MASTER
interface eth3
virtual_router_id 78
priority 150
advert_int 1
smtp_alert
authentication {
auth_type PASS
auth_pass MoreBlah
}
virtual_ipaddress {
10.22.11.13/24
}
}
vrrp_instance phone {
state MASTER
interface eth4
virtual_router_id 79
priority 150
advert_int 1
smtp_alert
authentication {
auth_type PASS
auth_pass MostBlah
}
virtual_ipaddress {
10.22.14.3/24
}
}
At boot the affected interfaces have:
5: eth4: mtu 1500 qdisc mq state UP group
default qlen 1000
link/ether ab:cd:ef:90:c0:e3 brd ff:ff:ff:ff:ff:ff
inet 10.22.14.6/24 brd 10.22.14.255 scope global eth4
valid_lft forever preferred_lft forever
inet 10.22.14.3/24 scope global secondary eth4
valid_lft forever preferred_lft forever
inet6 fe80::ae1f:6bff:fe90:c0e3/64 scope link
valid_lft forever preferred_lft forever
7: eth3: mtu 1500 qdisc mq state UP group
default qlen 1000
[Touch-packages] [Bug 1815101] Re: [master] Restarting systemd-networkd breaks keepalived, heartbeat, corosync, pacemaker (interface aliases are restarted)
** Also affects: charm-keepalived
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1815101
Title:
[master] Restarting systemd-networkd breaks keepalived, heartbeat,
corosync, pacemaker (interface aliases are restarted)
Status in Keepalived Charm:
New
Status in netplan:
Confirmed
Status in heartbeat package in Ubuntu:
Triaged
Status in keepalived package in Ubuntu:
In Progress
Status in systemd package in Ubuntu:
In Progress
Status in heartbeat source package in Bionic:
Triaged
Status in keepalived source package in Bionic:
Confirmed
Status in systemd source package in Bionic:
Confirmed
Status in heartbeat source package in Disco:
Triaged
Status in keepalived source package in Disco:
Confirmed
Status in systemd source package in Disco:
Confirmed
Status in heartbeat source package in Eoan:
Triaged
Status in keepalived source package in Eoan:
In Progress
Status in systemd source package in Eoan:
In Progress
Bug description:
Configure netplan for interfaces, for example (a working config with
IP addresses obfuscated)
network:
ethernets:
eth0:
addresses: [192.168.0.5/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth2:
addresses:
- 12.13.14.18/29
- 12.13.14.19/29
gateway4: 12.13.14.17
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth3:
addresses: [10.22.11.6/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth4:
addresses: [10.22.14.6/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth7:
addresses: [9.5.17.34/29]
dhcp4: false
optional: true
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
version: 2
Configure keepalived (again, a working config with IP addresses
obfuscated)
global_defs # Block id
{
notification_email {
sysadm...@blah.com
}
notification_email_from keepali...@system3.hq.blah.com
smtp_server 10.22.11.7 # IP
smtp_connect_timeout 30 # integer, seconds
router_id system3 # string identifying the machine,
# (doesn't have to be hostname).
vrrp_mcast_group4 224.0.0.18 # optional, default 224.0.0.18
vrrp_mcast_group6 ff02::12 # optional, default ff02::12
enable_traps # enable SNMP traps
}
vrrp_sync_group collection {
group {
wan
lan
phone
}
vrrp_instance wan {
state MASTER
interface eth2
virtual_router_id 77
priority 150
advert_int 1
smtp_alert
authentication {
auth_type PASS
auth_pass BlahBlah
}
virtual_ipaddress {
12.13.14.20
}
}
vrrp_instance lan {
state MASTER
interface eth3
virtual_router_id 78
priority 150
advert_int 1
smtp_alert
authentication {
auth_type PASS
auth_pass MoreBlah
}
virtual_ipaddress {
10.22.11.13/24
}
}
vrrp_instance phone {
state MASTER
interface eth4
virtual_router_id 79
priority 150
advert_int 1
smtp_alert
authentication {
auth_type PASS
auth_pass MostBlah
}
virtual_ipaddress {
10.22.14.3/24
}
}
At boot the affected interfaces have:
5: eth4: mtu 1500 qdisc mq state UP group
default qlen 1000
link/ether ab:cd:ef:90:c0:e3 brd ff:ff:ff:ff:ff:ff
inet 10.22.14.6/24 brd 10.22.14.255 scope global eth4
valid_lft forever preferred_lft forever
inet 10.22.14.3/24 scope global secondary eth4
valid_lft forever preferred_lft forever
inet6 fe80::ae1f:6bff:fe90:c0e3/64 scope link
valid_lft forever preferred_lft forever
7: eth3: mtu
[Touch-packages] [Bug 1815101] Re: [master] Restarting systemd-networkd breaks keepalived, heartbeat, corosync, pacemaker (interface aliases are restarted)
Thanks Rafael/Christian,
I see that all those patches are in 243 and Eoan is currently on 242
(albeit -6 but i dont think any are already backported) so we'll need to
get this backported all the way down to Bionic.
max@power:~/git/systemd$ _c=( 7da377e 95355a2 db51778 c98d78d 1e49885 )
max@power:~/git/systemd$ for c in ${_c[@]}; do git tag --contains $c| egrep -v
"\-rc"; done| sort -u
v243
Do we have a feel for if/when the keepalived fix(es) will be
backportable to B (1.x) as well? Since those fixes already exist in
Discco (2.0.10) it might be easier to start with those?
I will add the charm-keepalived to this LP since it will need support
for the networkd/netplan fix once that is available.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1815101
Title:
[master] Restarting systemd-networkd breaks keepalived, heartbeat,
corosync, pacemaker (interface aliases are restarted)
Status in netplan:
Confirmed
Status in heartbeat package in Ubuntu:
Triaged
Status in keepalived package in Ubuntu:
In Progress
Status in systemd package in Ubuntu:
In Progress
Status in heartbeat source package in Bionic:
Triaged
Status in keepalived source package in Bionic:
Confirmed
Status in systemd source package in Bionic:
Confirmed
Status in heartbeat source package in Disco:
Triaged
Status in keepalived source package in Disco:
Confirmed
Status in systemd source package in Disco:
Confirmed
Status in heartbeat source package in Eoan:
Triaged
Status in keepalived source package in Eoan:
In Progress
Status in systemd source package in Eoan:
In Progress
Bug description:
Configure netplan for interfaces, for example (a working config with
IP addresses obfuscated)
network:
ethernets:
eth0:
addresses: [192.168.0.5/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth2:
addresses:
- 12.13.14.18/29
- 12.13.14.19/29
gateway4: 12.13.14.17
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth3:
addresses: [10.22.11.6/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth4:
addresses: [10.22.14.6/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth7:
addresses: [9.5.17.34/29]
dhcp4: false
optional: true
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
version: 2
Configure keepalived (again, a working config with IP addresses
obfuscated)
global_defs # Block id
{
notification_email {
sysadm...@blah.com
}
notification_email_from keepali...@system3.hq.blah.com
smtp_server 10.22.11.7 # IP
smtp_connect_timeout 30 # integer, seconds
router_id system3 # string identifying the machine,
# (doesn't have to be hostname).
vrrp_mcast_group4 224.0.0.18 # optional, default 224.0.0.18
vrrp_mcast_group6 ff02::12 # optional, default ff02::12
enable_traps # enable SNMP traps
}
vrrp_sync_group collection {
group {
wan
lan
phone
}
vrrp_instance wan {
state MASTER
interface eth2
virtual_router_id 77
priority 150
advert_int 1
smtp_alert
authentication {
auth_type PASS
auth_pass BlahBlah
}
virtual_ipaddress {
12.13.14.20
}
}
vrrp_instance lan {
state MASTER
interface eth3
virtual_router_id 78
priority 150
advert_int 1
smtp_alert
authentication {
auth_type PASS
auth_pass MoreBlah
}
virtual_ipaddress {
10.22.11.13/24
}
}
vrrp_instance phone {
state MASTER
interface eth4
virtual_router_id 79
priority 150
advert_int 1
smtp_alert
authentication {
auth_type PASS
[Touch-packages] [Bug 1819074] Re: Keepalived < 2.0.x in Ubuntu 18.04 LTS not compatible with systemd-networkd
Looks like this has been fixed in keepalived 2.x (detection of missing vip) - https://github.com/acassen/keepalived/issues/836 - but the patch is embedded with a whole load others that were merged at once so might be hard to backport. ** Bug watch added: github.com/acassen/keepalived/issues #836 https://github.com/acassen/keepalived/issues/836 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1819074 Title: Keepalived < 2.0.x in Ubuntu 18.04 LTS not compatible with systemd- networkd Status in keepalived package in Ubuntu: Fix Released Status in netplan.io package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in keepalived source package in Bionic: Triaged Status in netplan.io source package in Bionic: New Status in systemd source package in Bionic: New Bug description: Systemd-networkd clobbers VIPs placed by other daemons on any reconfiguration triggering systemd-networkd restart (netplan apply for example). Keepalived < version 2.0.x will not restore a VIP lost in this fashion, breaking high availability on Ubuntu 18.04 LTS. A backport for keepalived >= 2.0.x should fix the issue. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/keepalived/+bug/1819074/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1668771] Re: [SRU] systemd-resolved negative caching for extended period of time
** Tags removed: sts-sru-needed ** Tags added: sts-sru-done -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1668771 Title: [SRU] systemd-resolved negative caching for extended period of time Status in systemd: New Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Released Status in systemd source package in Disco: Fix Released Status in systemd source package in Eoan: Fix Released Bug description: [Impact] * If a DNS lookup returns SERVFAIL, systemd-resolved seems to cache the result for very long (infinity?). I have to restart systemd- resolved to have the negative caching purged. * After SERVFAIL DNS server issue has been resolved, chromium/firefox still returns DNS error despite host can correctly resolve the name. [Test Case] * If a lookup returns SERVFAIL systemd-resolved will cache the result for 30s (See 201d995), however, there are several use cases on which this condition is not acceptable (See #5552 comments) and the only workaround would be to disable cache entirely or flush it , which isn't optimal. * Configure /etc/systemd/resolved.conf as follows: Cache=yes (default) * Restart systemd-resolved (systemctl restart systemd- resolved.service) * Run a host/getent command against a entry that will return SERVFAIL and check the journalctl output to see that the reply gets served from cache. root@systemd-disco:/home/ubuntu# host www.no-record.cl Host www.montemar.cl not found: 2(SERVFAIL) root@systemd-disco:/home/ubuntu# journalctl -u systemd-resolved -n -- Logs begin at Fri 2019-07-12 18:09:42 UTC, end at Tue 2019-07-23 15:10:17 UTC. -- Jul 23 15:10:10 systemd-disco systemd-resolved[1282]: Transaction 6222 for on scope dns on ens3/* now complete with Jul 23 15:10:10 systemd-disco systemd-resolved[1282]: Sending response packet with id 61042 on interface 1/AF_INET. Jul 23 15:10:10 systemd-disco systemd-resolved[1282]: Freeing transaction 6222. Jul 23 15:10:17 systemd-disco systemd-resolved[1282]: Got DNS stub UDP query packet for id 53580 Jul 23 15:10:17 systemd-disco systemd-resolved[1282]: Looking up RR for www.no-record.cl IN A. Jul 23 15:10:17 systemd-disco systemd-resolved[1282]: RCODE SERVFAIL cache hit for www.no-record.cl IN A Jul 23 15:10:17 systemd-disco systemd-resolved[1282]: Transaction 58570 for < www.no-record.cl IN A> on scope dns on ens3/* now complete with scope dns on ens3/. Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Using feature level UDP for transaction 22382. Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Sending query packet with id 22382. Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Processing incoming packet on transaction 22382 (rcode=SERVFAIL). Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Server returned error: SERVFAIL Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Not caching negative entry for: www.metaklass.org IN A, cache mode set to no-negative Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Transaction 22382 for on scope dns on ens3/ now complete with from network (unsigned). Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Sending response packet with id 31060 on interface 1/AF_INET. The following patch https://github.com/systemd/systemd/pull/13047 implements the required changes. [Other Info] Note that systemd in Eoan is being upgraded to upstream 242, so I am not adding this to Eoan now, as I don't want to disturb the merge. If needed after the merge, I'll add to Eoan. To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1668771/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1695876] Re: German Documentation file displays incorrect CUPS version
** Tags removed: sts-sru-needed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1695876 Title: German Documentation file displays incorrect CUPS version Status in CUPS: Fix Released Status in cups package in Ubuntu: Fix Released Status in cups source package in Xenial: In Progress Bug description: The /doc/de/index.html.in file in the package source has an incorrect version number written into a header instead of using '@CUPS_VERSION@' to populate this file as in the other languages' version of the same file, seemingly resulting in /usr/share/cups/doc-root/de/index.html having the wrong version once CUPS is installed: ... CUPS 2.0.2 ... instead of: ... CUPS @CUPS_VERSION@ ... resulting in 'CUPS 2.0.2' instead of 2.1.3 being shown. To manage notifications about this bug go to: https://bugs.launchpad.net/cups/+bug/1695876/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1550983] Re: Fails to start with "Couldn't open libGL.so.1" (missing dependency?)
** Tags removed: sts-sru-needed ** Tags added: sts-sru-done -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gtk+3.0 in Ubuntu. https://bugs.launchpad.net/bugs/1550983 Title: Fails to start with "Couldn't open libGL.so.1" (missing dependency?) Status in One Hundred Papercuts: Confirmed Status in gtk+3.0 package in Ubuntu: Fix Released Status in gtk+3.0 source package in Xenial: Fix Released Status in gtk+3.0 source package in Yakkety: Fix Released Status in gtk+3.0 package in Debian: Fix Released Bug description: [Impact] There are some unlinked calls to libGL.so.1 undetected in the build process because of using libepoxy. Running an application that does not depend on libgl1 (directly or indirectly) may lead to aborting the process with an undefined reference to libGL.so.1. [Test Case] 1. Deploy a server / cloud image of Xenial or Yakkety. 2. Use a Windows or a Mac client with Cygwin/X and ssh -XY to Ubuntu machine. 3. sudo apt install firefox; firefox Expected result: firefox is launched on the client machine. Actual result: "Couldn't open libGL.so.1" message is printed. [Regression Potential] Minimal, it is an upstream change already released to zesty. It performs a runtime check for GL support and disables GLX function calls in case they're not available. [Other Info] Original bug description: virt-manager fails to start: $ virt-manager --debug --no-fork [Sun, 28 Feb 2016 19:18:22 virt-manager 7592] DEBUG (cli:256) Launched with command line: /usr/share/virt-manager/virt-manager --debug --no-fork [Sun, 28 Feb 2016 19:18:22 virt-manager 7592] DEBUG (virt-manager:143) virt-manager version: 1.3.2 [Sun, 28 Feb 2016 19:18:22 virt-manager 7592] DEBUG (virt-manager:144) virtManager import: Couldn't open libGL.so.1: libGL.so.1: cannot open shared object file: No such file or directory $ Installing the 'libgl1-mesa-glx' package resolves the issue. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: virt-manager 1:1.3.2-0ubuntu1 ProcVersionSignature: Ubuntu 4.4.0-8.23-generic 4.4.2 Uname: Linux 4.4.0-8-generic x86_64 ApportVersion: 2.20-0ubuntu3 Architecture: amd64 Date: Sun Feb 28 19:19:27 2016 InstallationDate: Installed on 2016-02-27 (0 days ago) InstallationMedia: Ubuntu-Server 16.04 LTS "Xenial Xerus" - Alpha amd64 (20160206) PackageArchitecture: all SourcePackage: virt-manager UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/hundredpapercuts/+bug/1550983/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1709670] Re: logrotate never recovers if the statefile is corrupted
** Tags removed: sts-sru-needed ** Tags added: sts-sru-done -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to logrotate in Ubuntu. https://bugs.launchpad.net/bugs/1709670 Title: logrotate never recovers if the statefile is corrupted Status in logrotate package in Ubuntu: Fix Released Status in logrotate source package in Trusty: Fix Released Status in logrotate source package in Xenial: Fix Released Status in logrotate source package in Zesty: Fix Released Status in logrotate source package in Artful: Fix Released Status in logrotate package in Debian: New Bug description: [Impact] logrotate never recovers if the statefile is corrupted unless you remove it or fix the corruption by hand. Impact scenarios : - System could eventually run out of disk space on a separate partition if mounted in "/var" or specifically "/var/log" or even worst if "/var/log" is on the same partition as "/" it could create even more damage if by any chance the partition is running out of free space. - System keep updating the same files over and over, creating large size logfiles. - ... [Test Case] - Install logrotate - Run "/etc/cron.daily/logrotate" ## The first logrotate run will generate the statefile "var/lib/logrotate/status" - Modify "/var/lib/logrotate/status" by removing the first line in order to corrupt the file - Re-run "/etc/cron.daily/logrotate" and one will get the following error : "error: bad top line in state file /var/lib/logrotate/status" every time you run logrotate Unless you remove the statefile and start again or fix the corruption by hand. * Additionally, I will run the /path_to_source/test/test script as a dogfooding that does ~72 tests. [Regression Potential] * Risk of potential regression is low, and IMHO couldn't be worst than the actual situation where logrotate simply doesn't recover from a corrupt statefile. * The current patch does recover (after verification) and has been through some upstream CI validation, community feedbacks, et al. * Additionally, I will run the /path_to_source/test/test script as a dogfooding that does ~72 tests. [Other Info] * Upstream commit: https://github.com/logrotate/logrotate/commit/b9d82003002c98370e4131a7e43c76afcd23306a * Upstream bug: https://github.com/logrotate/logrotate/issues/45 * Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871592 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/logrotate/+bug/1709670/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1727063] Re: Pacemaker package upgrades stop but fail to start pacemaker resulting in HA outage
Tested proposed package upgrade and works for me - http://pastebin.ubuntu.com/25815820/ -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to init-system-helpers in Ubuntu. https://bugs.launchpad.net/bugs/1727063 Title: Pacemaker package upgrades stop but fail to start pacemaker resulting in HA outage Status in OpenStack hacluster charm: Invalid Status in init-system-helpers package in Ubuntu: New Status in pacemaker package in Ubuntu: Fix Released Status in init-system-helpers source package in Xenial: New Status in pacemaker source package in Xenial: Triaged Status in init-system-helpers source package in Zesty: New Status in pacemaker source package in Zesty: Fix Released Status in init-system-helpers source package in Artful: New Status in pacemaker source package in Artful: Fix Released Status in init-system-helpers source package in Bionic: New Status in pacemaker source package in Bionic: Fix Released Bug description: [Impact] upgrades of the pacemaker package don't restart pacemaker after the package upgrade, resulting in down HA clusters. [Test Case] sudo apt install pacemaker sudo systemctl start pacemaker sudo dpkg-reconfigure pacemaker pacemaker daemons will not be restarted. [Regression Potential] Minimal, earlier and later versions provide the defaults in the lsb header. [Original Bug Report] We have found on our openstack charm-hacluster implementations that the pacemaker .deb packaging along with the upstream pacemaker configuration result in pacemaker stopping but not starting upon package upgrade (while attended or unattended). This was seen on three separate Xenial clouds. Both Mitaka and Ocata. The package upgrade today was to pacemaker 1.1.14-2ubuntu1.2. It appears that pacemaker.prerm stops the service using "invoke-rc.d pacemaker stop" and then the pacemaker.postinst attempts to start the service, but silently fails due to policy denial. It appears the policy check fails because /etc/rcX.d/S*pacemaker does not exist because /etc/init.d/pacemaker has no Default-Start or Default-Stop entries in the LSB init headers. (or rather, they are blank.) I have not checked whether this affects trusty environments. I'd suggest on systems that use systemd, the pacemaker.postinst script should check if the service is enabled and start it with systemctl commands rather than using the cross-platform compatible invoke-rc.d wrappers. Or upstream pacemaker should get default start/stop entries. Our default runlevel on cloud init built images appears to be 5 (graphical), so at least 5 should be present in /etc/init.d/pacemaker LSB init headers under Default-Start:. To manage notifications about this bug go to: https://bugs.launchpad.net/charm-hacluster/+bug/1727063/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1550983] Re: Fails to start with "Couldn't open libGL.so.1" (missing dependency?)
** Tags removed: sts-sru ** Tags added: sts-sru-needed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gtk+3.0 in Ubuntu. https://bugs.launchpad.net/bugs/1550983 Title: Fails to start with "Couldn't open libGL.so.1" (missing dependency?) Status in One Hundred Papercuts: Confirmed Status in gtk+3.0 package in Ubuntu: Fix Released Status in gtk+3.0 source package in Xenial: Fix Released Status in gtk+3.0 source package in Yakkety: Fix Released Status in gtk+3.0 package in Debian: Fix Released Bug description: [Impact] There are some unlinked calls to libGL.so.1 undetected in the build process because of using libepoxy. Running an application that does not depend on libgl1 (directly or indirectly) may lead to aborting the process with an undefined reference to libGL.so.1. [Test Case] 1. Deploy a server / cloud image of Xenial or Yakkety. 2. Use a Windows or a Mac client with Cygwin/X and ssh -XY to Ubuntu machine. 3. sudo apt install firefox; firefox Expected result: firefox is launched on the client machine. Actual result: "Couldn't open libGL.so.1" message is printed. [Regression Potential] Minimal, it is an upstream change already released to zesty. It performs a runtime check for GL support and disables GLX function calls in case they're not available. [Other Info] Original bug description: virt-manager fails to start: $ virt-manager --debug --no-fork [Sun, 28 Feb 2016 19:18:22 virt-manager 7592] DEBUG (cli:256) Launched with command line: /usr/share/virt-manager/virt-manager --debug --no-fork [Sun, 28 Feb 2016 19:18:22 virt-manager 7592] DEBUG (virt-manager:143) virt-manager version: 1.3.2 [Sun, 28 Feb 2016 19:18:22 virt-manager 7592] DEBUG (virt-manager:144) virtManager import: Couldn't open libGL.so.1: libGL.so.1: cannot open shared object file: No such file or directory $ Installing the 'libgl1-mesa-glx' package resolves the issue. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: virt-manager 1:1.3.2-0ubuntu1 ProcVersionSignature: Ubuntu 4.4.0-8.23-generic 4.4.2 Uname: Linux 4.4.0-8-generic x86_64 ApportVersion: 2.20-0ubuntu3 Architecture: amd64 Date: Sun Feb 28 19:19:27 2016 InstallationDate: Installed on 2016-02-27 (0 days ago) InstallationMedia: Ubuntu-Server 16.04 LTS "Xenial Xerus" - Alpha amd64 (20160206) PackageArchitecture: all SourcePackage: virt-manager UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/hundredpapercuts/+bug/1550983/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1089013] Re: clvm startup script requires cman
** Tags added: sts-sru -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lvm2 in Ubuntu. https://bugs.launchpad.net/bugs/1089013 Title: clvm startup script requires cman Status in lvm2 package in Ubuntu: Fix Released Status in lvm2 source package in Precise: Triaged Status in lvm2 source package in Trusty: Fix Committed Status in lvm2 source package in Wily: Fix Committed Status in lvm2 source package in Xenial: Fix Released Bug description: while clvm in precise can support corosync, init script won't start because issues a cman status command ProblemType: Bug DistroRelease: Ubuntu 12.04 Package: clvm 2.02.66-4ubuntu7.1 ProcVersionSignature: Ubuntu 3.2.0-23.36-generic 3.2.14 Uname: Linux 3.2.0-23-generic x86_64 ApportVersion: 2.0.1-0ubuntu5 Architecture: amd64 Date: Tue Dec 11 18:09:36 2012 InstallationMedia: Ubuntu-Server 12.04 LTS "Precise Pangolin" - Release amd64 (20120424.1) ProcEnviron: TERM=screen LANG=it_IT.UTF-8 SHELL=/bin/bash SourcePackage: lvm2 UpgradeStatus: No upgrade log present (probably fresh install) modified.conffile..etc.default.clvm: [modified] mtime.conffile..etc.default.clvm: 2012-12-11T16:45:40.149014 [Impact] * clvm daemon cannot start using provided init scripts [Test Case] * Install clvm package * Configure corosync * service clvm start - Fails to start due to cman dependency [Regression Potential] * None, already broken, though there is risk of other bugs being uncovered since this hasn't worked in quite awhile. [Other Info] * This is a change to the debian provided init script for clvm. Upstream debian still has the redhat-cluster package which contains the cman tool, as such this change is applicable to Ubuntu only since the redhat clustering suite is not available. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1089013/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1355813] Re: Interface MTU management across MAAS/juju
** Tags removed: cts ** Tags added: sts -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1355813 Title: Interface MTU management across MAAS/juju Status in juju-core: Fix Released Status in MAAS: Triaged Status in juju-core package in Ubuntu: Triaged Status in lxc package in Ubuntu: Invalid Bug description: Context: juju + MAAS deployed OpenStack environment, misc services deployed under LXC on the bootstrap node, interfaces configured for jumbo frames - note that I had to manually set the LXC container interfaces to mtu 9000 before the bridge would do the same. Action: Reboot one of the containers; MTU on br0 resets from 9000 -> 1500. This feels like more of a 'we need a better way to orchestrate MTU configuration across different services' so raising tasks for MAAS and Juju as well. ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: lxc 1.0.5-0ubuntu0.1 ProcVersionSignature: User Name 3.13.0-24.47-generic 3.13.9 Uname: Linux 3.13.0-24-generic x86_64 ApportVersion: 2.14.1-0ubuntu3.3 Architecture: amd64 Date: Tue Aug 12 13:26:00 2014 KernLog: SourcePackage: lxc UpgradeStatus: No upgrade log present (probably fresh install) defaults.conf: lxc.network.type = veth lxc.network.link = lxcbr0 lxc.network.flags = up lxc.network.hwaddr = 00:16:3e:xx:xx:xx lxcsyslog: To manage notifications about this bug go to: https://bugs.launchpad.net/juju-core/+bug/1355813/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1403955] Re: DHCP's Option interface-mtu 9000 is being ignored on bridge interface br0
** Tags removed: cts
** Tags added: sts
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu.
https://bugs.launchpad.net/bugs/1403955
Title:
DHCP's Option interface-mtu 9000 is being ignored on bridge
interface br0
Status in juju-core:
Triaged
Status in isc-dhcp package in Ubuntu:
Confirmed
Bug description:
In an env with jumbo frames enabled, and using MAAS as DHCP server,
the client receives the following IPv4 lease:
$ cat /var/lib/dhcp/dhclient.br0.leases
lease {
interface br0;
fixed-address 10.230.20.26;
filename pxelinux.0;
option subnet-mask 255.255.248.0;
option dhcp-lease-time 43200;
option routers 10.230.16.1;
option dhcp-message-type 5;
option dhcp-server-identifier 10.230.20.1;
option domain-name-servers 10.230.20.1;
option interface-mtu 9000;
option broadcast-address 10.230.23.255;
option domain-name ctsstack.qa.1ss;
renew 3 2014/12/17 16:48:15;
rebind 3 2014/12/17 21:52:09;
expire 3 2014/12/17 23:22:09;
}
The interfaces show the following config after boot:
$ ifconfig br0
br0 Link encap:Ethernet HWaddr a0:d3:c1:01:9d:58
inet addr:10.230.20.26 Bcast:10.230.23.255 Mask:255.255.248.0
inet6 addr: fe80::a2d3:c1ff:fe01:9d58/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:530530 errors:0 dropped:0 overruns:0 frame:0
TX packets:1591569 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:68713489 (68.7 MB) TX bytes:213710979 (213.7 MB)
$ ifconfig eth0
eth0 Link encap:Ethernet HWaddr a0:d3:c1:01:9d:58
inet6 addr: fe80::a2d3:c1ff:fe01:9d58/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:10539274 errors:0 dropped:3394 overruns:0 frame:454
TX packets:2627412 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2320560616 (2.3 GB) TX bytes:3562885157 (3.5 GB)
Interrupt:32
option interface-mtu 9000; from the lease file is being ignored by br0.
Could it be related to eth0 MTU size? If that's the case, shouldn't both
interfaces be updated?
Other info:
$ brctl show br0
bridge name bridge id STP enabled interfaces
br0 8000.a0d3c1019d58 no eth0
$ cat /etc/network/eth0.config
iface eth0 inet manual
auto br0
iface br0 inet dhcp
bridge_ports eth0
To manage notifications about this bug go to:
https://bugs.launchpad.net/juju-core/+bug/1403955/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists
** Changed in: lsb (Ubuntu Trusty) Assignee: Dimitri John Ledkov (xnox) = Hua Zhang (zhhuabj) ** Changed in: lsb (Ubuntu Trusty) Status: Confirmed = In Progress ** Tags added: sts -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lsb in Ubuntu. https://bugs.launchpad.net/bugs/1273462 Title: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists Status in lsb package in Ubuntu: Fix Released Status in mysql-5.5 package in Ubuntu: Invalid Status in upstart package in Ubuntu: Fix Released Status in lsb source package in Trusty: In Progress Status in mysql-5.5 source package in Trusty: Invalid Status in upstart source package in Trusty: Won't Fix Status in lsb source package in Utopic: Fix Released Status in mysql-5.5 source package in Utopic: Invalid Status in upstart source package in Utopic: Fix Released Status in upstart package in Debian: New Bug description: [ impact ] Previously, init.d scripts that were replaced by upstart jobs had upstart-job symlink as a redirect in-place, which directed users at using upstart commands. Despite the good intentions, that never actually taught people about the correct interfaces. Now with the advent of co-installability of multiple init systems, users may have systemd, upstart, and sysv-init all installed on users system and have init.d scripts / upstart jobs / systemd units all available. To avoid any daubt, we should support executing /etc/init.d/ scripts which may call into upstart, or into systemd, or actually execute the script in question depending on whether there is native configuration for that particular job and which init system we are running under. [ test case ] Invoking init.d script should invoke upstart commands, for example: $ /etc/init.d/ssh status ssh start/running, process 4620 $ /etc/init.d/ssh stop stop: Rejected send message, 1 matched rules; type=method_call, sender=:1.2469694 (uid=1000 pid=3908 comm=stop ssh ) interface=com.ubuntu.Upstart0_6.Job member=Stop error name=(unset) requested_reply=0 destination=com.ubuntu.Upstart (uid=0 pid=1 comm=/sbin/init) $ sudo /etc/init.d/ssh stop ssh stop/waiting $ sudo /etc/init.d/ssh start ssh start/running, process 5373 $ sudo /etc/init.d/ssh restart ssh stop/waiting ssh start/running, process 5405 Description:Ubuntu 13.10 Release:13.10 mysql-server-5.5: Installed: 5.5.35-0ubuntu0.13.10.1 Candidate: 5.5.35-0ubuntu0.13.10.1 Version table: *** 5.5.35-0ubuntu0.13.10.1 0 500 http://us-east-1.ec2.archive.ubuntu.com/ubuntu/ saucy-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu/ saucy-security/main amd64 Packages 100 /var/lib/dpkg/status 5.5.32-0ubuntu7 0 500 http://us-east-1.ec2.archive.ubuntu.com/ubuntu/ saucy/main amd64 Packages In Ubuntu 13.10, the Upstart job and the init.d script do not work properly. In previous versions, the init.d script was a symlink to the wrapper script around upstart (/lib/init/upstart-job). This conflict means that if the server was started using the init.d script, upstart does not recognize that the server is running and will attempt to start a second instance of mysqld. Also problematic is that if the upstart job is started using the service or start commands, the init.d script's stop function runs a mysql shutdown, but upstart simply restarts mysqld (because it's marked respawn in the upstart config). Description: Ubuntu 14.04 Release: 14.04 mysql: mysql-server-5.5.43-0ubuntu0.14.04.1 The problem in some setup was that the upgrade von 12.04 to 14.04 requres the adjustment of the InnoDB log size. Therefore the start of MySQL via upstart failed directly while the one via init started successfully and then failed as below. r...@webserver01.kurt..ref:~# status mysql mysql start/running, process 5866 r...@webserver01.kurt..ref:~# /etc/init.d/mysql stop * Stopping MySQL database server mysqld [ OK ] r...@webserver01.kurt..ref:~# status mysql mysql start/running, process 6101 r...@webserver01.kurt..ref:~# /etc/init.d/mysql status * /usr/bin/mysqladmin Ver 8.42 Distrib 5.5.43, for debian-linux-gnu on x86_64 Copyright (c) 2000, 2015, Oracle and/or its affiliates. All rights reserved. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. Server version5.5.43-0ubuntu0.14.04.1-log Protocol version 10 ConnectionLocalhost via UNIX socket UNIX socket /var/run/mysqld/mysqld.sock Uptime: 7 sec Threads: 1 Questions: 108 Slow queries: 0 Opens: 48 Flush tables: 1 Open tables: 41 Queries per second avg: 15.428 r...@webserver01.kurt..ref:~# stop mysql mysql stop/waiting
[Touch-packages] [Bug 1273462] Re: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists
** Patch added: trusty.debdiff https://bugs.launchpad.net/ubuntu/+source/lsb/+bug/1273462/+attachment/4428923/+files/trusty.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lsb in Ubuntu. https://bugs.launchpad.net/bugs/1273462 Title: Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists Status in lsb package in Ubuntu: Fix Released Status in mysql-5.5 package in Ubuntu: Invalid Status in upstart package in Ubuntu: Fix Released Status in lsb source package in Trusty: Confirmed Status in mysql-5.5 source package in Trusty: Invalid Status in upstart source package in Trusty: Won't Fix Status in lsb source package in Utopic: Fix Released Status in mysql-5.5 source package in Utopic: Invalid Status in upstart source package in Utopic: Fix Released Status in upstart package in Debian: New Bug description: [ impact ] Previously, init.d scripts that were replaced by upstart jobs had upstart-job symlink as a redirect in-place, which directed users at using upstart commands. Despite the good intentions, that never actually taught people about the correct interfaces. Now with the advent of co-installability of multiple init systems, users may have systemd, upstart, and sysv-init all installed on users system and have init.d scripts / upstart jobs / systemd units all available. To avoid any daubt, we should support executing /etc/init.d/ scripts which may call into upstart, or into systemd, or actually execute the script in question depending on whether there is native configuration for that particular job and which init system we are running under. [ test case ] Invoking init.d script should invoke upstart commands, for example: $ /etc/init.d/ssh status ssh start/running, process 4620 $ /etc/init.d/ssh stop stop: Rejected send message, 1 matched rules; type=method_call, sender=:1.2469694 (uid=1000 pid=3908 comm=stop ssh ) interface=com.ubuntu.Upstart0_6.Job member=Stop error name=(unset) requested_reply=0 destination=com.ubuntu.Upstart (uid=0 pid=1 comm=/sbin/init) $ sudo /etc/init.d/ssh stop ssh stop/waiting $ sudo /etc/init.d/ssh start ssh start/running, process 5373 $ sudo /etc/init.d/ssh restart ssh stop/waiting ssh start/running, process 5405 Description:Ubuntu 13.10 Release:13.10 mysql-server-5.5: Installed: 5.5.35-0ubuntu0.13.10.1 Candidate: 5.5.35-0ubuntu0.13.10.1 Version table: *** 5.5.35-0ubuntu0.13.10.1 0 500 http://us-east-1.ec2.archive.ubuntu.com/ubuntu/ saucy-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu/ saucy-security/main amd64 Packages 100 /var/lib/dpkg/status 5.5.32-0ubuntu7 0 500 http://us-east-1.ec2.archive.ubuntu.com/ubuntu/ saucy/main amd64 Packages In Ubuntu 13.10, the Upstart job and the init.d script do not work properly. In previous versions, the init.d script was a symlink to the wrapper script around upstart (/lib/init/upstart-job). This conflict means that if the server was started using the init.d script, upstart does not recognize that the server is running and will attempt to start a second instance of mysqld. Also problematic is that if the upstart job is started using the service or start commands, the init.d script's stop function runs a mysql shutdown, but upstart simply restarts mysqld (because it's marked respawn in the upstart config). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lsb/+bug/1273462/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1446767] Re: dhclient can fail if other nics are renamed
Yes, sorry for delay. We have been running repeated deployments with Trusty and this package and are no longer hitting the problems anymore. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu. https://bugs.launchpad.net/bugs/1446767 Title: dhclient can fail if other nics are renamed Status in isc-dhcp package in Ubuntu: Fix Released Status in isc-dhcp source package in Trusty: Fix Committed Status in isc-dhcp source package in Vivid: Fix Released Status in isc-dhcp source package in Wily: Fix Released Status in isc-dhcp package in Fedora: Unknown Bug description: === Begin SRU Information === [Impact] Systems that use dhcp for network config combined with network device re-naming can hit a race condition in dhclient which causes dhcp to fail. Any network device renaming could cause this, but the most likely scenario is boot with udev persistent naming in /etc/udev/rules.d/70-persistent-net.rules. This can be a fatal error when network devices that are required for proper function. [Test Case] To recreate the failure: * boot an ubuntu system with an interface that can dhcp * configure /etc/network/interfaces for dhcp on that interface $ grep eth0 /etc/network/interfaces auto eth0 iface eth0 inet dhcp * run attached 'nic-go-crazy' as root in one window/shell this will create by default 10 tuntap devices and repeatedly rename them. * run attached 'ifup-loop eth0' ifup-loop will exit failure if dhclient failed to bring the network up. With the fix provided, this will/should run indefinitely. [Regression Potential] Chance for regression here should be reasonably small. However, a very significant number of systems run dhclient, so any change has to be considered risky. One thing to note, is that Fedora has carried this patch for 3 years. Per getifaddrs(3): | The getifaddrs() function first appeared in glibc 2.3, but before glibc | 2.3.3, the implementation supported only IPv4 addresses; IPv6 support | was added in glibc 2.3.3. Support of address families other than IPv4 | is available only on kernels that support netlink. These versions are older than any supported Ubuntu release, so that should not be a problem. === End SRU Information === given 3 nics eth0, eth1, eth2 dhclient -1 -v -pf /run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases eth0 while that in its early phases, if eth1 is renamed a race condition can cause dhclient to exit failure. This can happen in real life when udev and persistent rules are used. Ie, in a system where eth0 is configured for 'auto' and dhcp and persistent rules cause renaming of devices during boot. I have set up recreate of that more complex system lp:~smoser/+junk/lp128 , but this recreate is simpler to catch. example, while running attached 'nic-go-crazy' on other nics, I try ifup eth1 $ sudo ifup eth1 sudo: unable to resolve host ubuntu Internet Systems Consortium DHCP Client 4.3.1 Copyright 2004-2014 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Error getting interface address for 'nic0317610'; No such device Error getting interface information. If you think you have received this message due to a bug rather than a configuration issue please read the section on submitting bugs on either our web page at www.isc.org or in the README file before submitting a bug. These pages explain the proper process and the information we find helpful for debugging.. exiting. Failed to bring up eth1. ProblemType: Bug DistroRelease: Ubuntu 15.04 Package: isc-dhcp-client 4.3.1-5ubuntu2 ProcVersionSignature: User Name 3.19.0-15.15-generic 3.19.3 Uname: Linux 3.19.0-15-generic x86_64 ApportVersion: 2.17.2-0ubuntu1 Architecture: amd64 Date: Tue Apr 21 16:35:10 2015 DhclientLeases: ProcEnviron: TERM=screen PATH=(custom, no user) XDG_RUNTIME_DIR=set LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: isc-dhcp UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1446767/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
