[Bug 1818880] Re: Deadlock when detaching network interface
Hi, I've done some regression testing on qemu from mitaka-proposed, following the procedure from comment #6: $ dpkg -l | grep qemu ii ipxe-qemu 1.0.0+git-2013.c3d1e78-2ubuntu1.1all PXE boot firmware - ROM images for qemu ii qemu-block-extra:amd64 1:2.5+dfsg-5ubuntu10.36~cloud0 amd64extra block backend modules for qemu- system and qemu-utils ii qemu-kvm1:2.5+dfsg-5ubuntu10.36~cloud0 amd64QEMU Full virtualization ii qemu-system-common 1:2.5+dfsg-5ubuntu10.36~cloud0 amd64QEMU full system emulation binaries (common files) ii qemu-system-x86 1:2.5+dfsg-5ubuntu10.36~cloud0 amd64QEMU full system emulation binaries (x86) ii qemu-utils 1:2.5+dfsg-5ubuntu10.36~cloud0 amd64QEMU utilities $ /hotplug.sh xenial 52:54:00:b3:ef:bc Detach #1 Interface detached successfully Detach #2 Interface detached successfully ... Detach #2617 Interface detached successfully This was performed while iperf and stress-ng were running. The guest works correctly through and after the tests. Thanks, Heitor ** Tags removed: verification-mitaka-needed ** Tags added: verification-mitaka-done -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1818880 Title: Deadlock when detaching network interface To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1818880/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1818880] Re: Deadlock when detaching network interface
Hi, I've done some regression testing on qemu from ocata-proposed, following the procedure from comment #6: $ dpkg -l | grep qemu ii ipxe-qemu 1.0.0+git-20150424.a25a16d-1ubuntu1.2 all PXE boot firmware - ROM images for qemu ii qemu-block-extra:amd641:2.8+dfsg-3ubuntu2.9~cloud4 amd64extra block backend modules for qemu-system and qemu- utils ii qemu-kvm 1:2.8+dfsg-3ubuntu2.9~cloud4 amd64QEMU Full virtualization ii qemu-system-common1:2.8+dfsg-3ubuntu2.9~cloud4 amd64QEMU full system emulation binaries (common files) ii qemu-system-x86 1:2.8+dfsg-3ubuntu2.9~cloud4 amd64QEMU full system emulation binaries (x86) ii qemu-utils1:2.8+dfsg-3ubuntu2.9~cloud4 amd64QEMU utilities $ /hotplug.sh xenial 52:54:00:bb:23:77 Detach #1 Interface detached successfully Detach #2 Interface detached successfully ... Detach #2722 Interface detached successfully This was performed while iperf and stress-ng were running. The guest works correctly through and after the tests. Thanks, Heitor ** Tags removed: verification-ocata-needed ** Tags added: verification-ocata-done -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1818880 Title: Deadlock when detaching network interface To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1818880/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1821380] Re: HA-LVM can't parse vgchange_options with special characters
Confirmed fix for Xenial, according to test case: root@node1:~# pcs resource debug-start vg01 Operation start for vg01 (ocf:heartbeat:LVM) returned 0 > stdout: volume_list=["node1-vg","@tag1"] > stdout: Volume group "vg01" successfully changed > stdout: Volume group "vg01" successfully changed > stdout: volume_list=["node1-vg","@tag1"] > stderr: INFO: Activating volume group vg01 > stderr: INFO: Reading all physical volumes. This may take a while... Found > volume group "vg01" using metadata type lvm2 > stderr: INFO: Stripping tag, tag1 > stderr: INFO: New tag "pacemaker" added to vg01 > stderr: INFO: 1 logical volume(s) in volume group "vg01" now active root@node1:~# dpkg -l | grep resource-agents ii resource-agents 1:3.9.7-1ubuntu1 amd64Cluster Resource Agents After going through the setup as described in the description, resource activation succeeds without any changes in the heartbeat/LVM script. ** Tags removed: verification-needed verification-needed-xenial ** Tags added: verification-done verification-done-xenial -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1821380 Title: HA-LVM can't parse vgchange_options with special characters To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resource-agents/+bug/1821380/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1821343] Re: slapd process failure is not detected by systemd
I've been doing some research on how we could implement a proper systemd
unit file for slapd, and came up with interesting results.
There are a number of options that we can pass to the slapd service that will
give us lots of troubles on an "idiomatic" service file. To give some examples:
- The PID file can be directly obtained from /etc/default/slapd if set, or it
has to be parsed from /etc/ldap/slapd.d or /etc/ldap/slapd.conf. The /etc/ldap
files don't follow the /etc/default syntax, so we can't just pass them with
"EnvironmentFile=" in the systemd service. We would have to parse those files
as is currently done by the init script.
- slapd has the "-f" and "-F" flags that can be used to specify a config file or
directory, respectively. It does not accept both at the same time, but
SLAPD_CONF in /etc/default/slapd allows either a file or directory. The init
script will figure out which of those is set, and pass the correct flag
accordingly. I don't see a simple way of doing this in systemd without either
polluting the SLAPD_CONF option with the necessary flag, or delegating it to a
helper script which would check whether the option meant a file or a
directory.
- The slapd.conf file is used by other related tools (see slapd.conf(5)), which
prevents us from pulling some of the options to another centralized file
without also updating these tools
I hoped that the upstream package would have some insight on the proper
way of writing the service file, but unfortunately it seems that
upstream Openldap devs are very much against the idea of shipping them
(be they sysv-init or systemd files). There are some discussions on the
openldap lists, one of which deals specifically with adding systemd
support for slapd [0]. From that discussion, it's clear that upstream
openldap is not ready to provide the necessary systemd files out-of-the-
box, even when approached with relevant patches.
I also checked how CentOS implement their slapd.service file since they don't
seem to run into these problems. They don't use an autogenerated unit file, and
have a proper one instead [1]. From what I've checked, this is easier for them
for two reasons:
1) The CentOS configs for slapd are much simpler than what we have in
Debian/Ubuntu (their defaults don't include most of the options that we do)
2) They use helper scripts for the funky parsing we have in the sysv-init
script ("ExecStartPre=/usr/libexec/openldap/check-config.sh", which also
invokes some other helper scripts)
On Debian/Ubuntu, the autogenerated unit file for slapd uses the sysv-init
script as a "shim" to manage the service, which makes it possible to keep the
whole config-parsing insanity consistent between sysv-init and systemd.
It's not the most elegant solution, but for now I believe it makes sense to
include an override file for the "RemainAfterExit=" option until we have a
native systemd unit file for slapd (similar to what was done for apache2 in bug
1488962 mentioned by Ryan Tandy).
[0] https://www.openldap.org/its/index.cgi/Incoming?id=8707
[1] https://git.centos.org/blob/rpms!openldap.git/c7/SOURCES!slapd.service
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1821343
Title:
slapd process failure is not detected by systemd
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1821343/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1821343] Re: slapd process failure is not detected by systemd
** Bug watch added: Debian Bug tracker #926657 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926657 ** Also affects: openldap (Debian) via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926657 Importance: Unknown Status: Unknown ** Patch added: "lp1821343-disco.debdiff" https://bugs.launchpad.net/debian/+source/openldap/+bug/1821343/+attachment/5254240/+files/lp1821343-disco.debdiff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1821343 Title: slapd process failure is not detected by systemd To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1821343/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1821343] Re: slapd process failure is not detected by systemd
@slashd I don't think we need anything special for systemd in the
debian/{control,rules} files, since we're not shipping full systemd
support with this. The slapd service is still handled by systemd-sysv-
generator(8), so there's no service units that we need to include or
activate in dh_systemd rules.
To make sure things are working fine I went ahead and tested a package
upgrade with this debdiff:
ubuntu@disco:~$ dpkg -l | grep slapd
ii slapd 2.4.47+dfsg-3ubuntu1amd64
OpenLDAP server (slapd)
ubuntu@disco:~$ sudo apt-get --only-upgrade install slapd
ubuntu@disco:~$ dpkg -l | grep slapd
ii slapd 2.4.47+dfsg-3ubuntu2amd64
OpenLDAP server (slapd)
ubuntu@disco:~$ systemctl cat slapd
# /run/systemd/generator.late/slapd.service
# Automatically generated by systemd-sysv-generator
[Unit]
Documentation=man:systemd-sysv-generator(8)
SourcePath=/etc/init.d/slapd
Description=LSB: OpenLDAP standalone server (Lightweight Directory Access
Protocol)
Before=multi-user.target
Before=multi-user.target
Before=multi-user.target
Before=graphical.target
After=remote-fs.target
After=network-online.target
Wants=network-online.target
[Service]
Type=forking
Restart=no
TimeoutSec=5min
IgnoreSIGPIPE=no
KillMode=process
GuessMainPID=no
RemainAfterExit=yes
SuccessExitStatus=5 6
ExecStart=/etc/init.d/slapd start
ExecStop=/etc/init.d/slapd stop
# /usr/lib/systemd/system/slapd.service.d/slapd-remain-after-exit.conf
[Service]
Type=forking
RemainAfterExit=no
Thanks!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1821343
Title:
slapd process failure is not detected by systemd
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1821343/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1821380] Re: HA-LVM can't parse vgchange_options with special characters
** Changed in: resource-agents (Ubuntu Xenial) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1821380 Title: HA-LVM can't parse vgchange_options with special characters To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resource-agents/+bug/1821380/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1821255] Re: Restart policy "Always" doesn't work under certain circumstances
** Description changed:
- Iscsid restart fails when killed with a SIGTERM.
+ [Impact]
+ iscsid restart fails when killed with SIGTERM
- Conditions:
- Iscsid restart policy set to "Always" via a .conf file in
/etc/systemd/system/iscsid.service.d/, with the contents:
- [Service]
- Restart=always
+ [Description]
+ If systemd tries to execute a command that talks to iscsid via iscsid.socket,
it
+ can hang if iscsid is not running (or is in the process of being stopped).
This can
+ happen due to the current ExecStop= directive, which calls iscsiadm to kill
+ iscsid, and prevents the service from being restarted even when we set
+ Restart=always in the iscsid unit file.
- Steps to Reproduce:
- 1. Confirm iscsid is running, e.g.
- $ ps aux | grep iscsid
- or
- $ pgrep iscsid
+ The solution is to let systemd terminate iscsid by itself. The default action
+ when omitting the ExecStop directive is to send SIGTERM to the process group,
+ which is equivalent to invoking "iscsiadm -k" (the current ExecStop command).
- 2. Kill the pid(s) with SIGTERM, e.g.
- $ sudo kill -15
- or
- $ sudo pkill iscsid
+ [Test Case]
+ 1) Deploy a Disco VM e.g. with uvt-kvm
+ $ uvt-kvm create disco release=disco
- 3. Confirm that iscsid has not restarted
- $ systemctl status iscsid
+ 2) Run the deploy-tgt.sh script in the VM to setup an iSCSI target in the
+ localhost. The script will install tgt and open-iscsi, configure a 1G
+ file-backed iSCSI target, login and restart iscsid.service
+ ubuntu@disco:~$ ./deploy-tgt.sh
- This bug affects 18.04, but not 16.04. This hasn't been tested on 18.10
- or later.
+ 3) Kill iscsid with SIGTERM
+ ubuntu@disco:~$ sudo pkill iscsid
+
+ 4) Try to stop iscsid.service and check whether it hangs
+ ubuntu@disco:~$ sudo systemctl stop iscsid
+
+ If we remove the ExecStop= directive, it works as expected:
+ ubuntu@disco:~$ sudo systemctl stop iscsid
+ ubuntu@disco:~$
+ This also causes Restart=always to work as expected.
+
+ [Regression Potential]
+ This shouldn't introduce any regressions, since iscsiadm -k just sends SIGTERM
+ to iscsid's process group and that's equivalent to the default systemd
ExecStop
+ action. Nonetheless, changes will be tested with autopkgtests and different
+ iscsi scenarios.
** Also affects: open-iscsi (Ubuntu Disco)
Importance: High
Status: Triaged
** Also affects: open-iscsi (Ubuntu Cosmic)
Importance: Undecided
Status: New
** Changed in: open-iscsi (Ubuntu Bionic)
Status: Triaged => Confirmed
** Changed in: open-iscsi (Ubuntu Cosmic)
Status: New => Confirmed
** Changed in: open-iscsi (Ubuntu Disco)
Status: Triaged => Confirmed
** Changed in: open-iscsi (Ubuntu Cosmic)
Importance: Undecided => High
** Changed in: open-iscsi (Ubuntu Disco)
Assignee: (unassigned) => Heitor R. Alves de Siqueira (halves)
** Changed in: open-iscsi (Ubuntu Cosmic)
Assignee: (unassigned) => Heitor R. Alves de Siqueira (halves)
** Changed in: open-iscsi (Ubuntu Bionic)
Assignee: (unassigned) => Heitor R. Alves de Siqueira (halves)
** Attachment added: "deploy-tgt.sh"
https://bugs.launchpad.net/ubuntu/+source/open-iscsi/+bug/1821255/+attachment/5250279/+files/deploy-tgt.sh
** Description changed:
[Impact]
iscsid restart fails when killed with SIGTERM
[Description]
- If systemd tries to execute a command that talks to iscsid via iscsid.socket,
it
- can hang if iscsid is not running (or is in the process of being stopped).
This can
- happen due to the current ExecStop= directive, which calls iscsiadm to kill
- iscsid, and prevents the service from being restarted even when we set
- Restart=always in the iscsid unit file.
+ If systemd tries to execute a command that talks to iscsid via iscsid.socket,
it can hang if iscsid is not running (or is in the process of being stopped).
This can happen due to the current ExecStop= directive, which calls iscsiadm to
kill iscsid, and prevents the service from being restarted even when we set
Restart=always in the iscsid unit file.
The solution is to let systemd terminate iscsid by itself. The default action
when omitting the ExecStop directive is to send SIGTERM to the process group,
which is equivalent to invoking "iscsiadm -k" (the current ExecStop command).
[Test Case]
1) Deploy a Disco VM e.g. with uvt-kvm
- $ uvt-kvm create disco release=disco
+ $ uvt-kvm create disco release=disco
2) Run the deploy-tgt.sh script in the VM to setup an iSCSI target in the
localhost. The script will install tgt and open-iscsi, configure a 1G
file-backed iSCSI target, login and restart iscsid.service
- ubuntu@disco:~$ ./deploy-tgt.sh
+ ubuntu@disco:~$ ./deploy-tgt.sh
3) Kill iscsid with SIGTERM
- ubuntu@disco:~$ sudo pkill iscsid
+ ubuntu@disco:~$ sudo pkill iscsid
4) Try to stop iscsid.service and check whe
[Bug 1821255] Re: Restart policy "Always" doesn't work under certain circumstances
** Patch added: "lp1821255-bionic.debdiff" https://bugs.launchpad.net/ubuntu/+source/open-iscsi/+bug/1821255/+attachment/5250281/+files/lp1821255-bionic.debdiff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1821255 Title: Restart policy "Always" doesn't work under certain circumstances To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/open-iscsi/+bug/1821255/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1821255] Re: Restart policy "Always" doesn't work under certain circumstances
** Patch added: "lp1821255-cosmic.debdiff" https://bugs.launchpad.net/ubuntu/+source/open-iscsi/+bug/1821255/+attachment/5250282/+files/lp1821255-cosmic.debdiff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1821255 Title: Restart policy "Always" doesn't work under certain circumstances To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/open-iscsi/+bug/1821255/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1821255] Re: Restart policy "Always" doesn't work under certain circumstances
** Patch added: "lp1821255-disco.debdiff" https://bugs.launchpad.net/ubuntu/+source/open-iscsi/+bug/1821255/+attachment/5250283/+files/lp1821255-disco.debdiff ** Tags added: sts-sponsor -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1821255 Title: Restart policy "Always" doesn't work under certain circumstances To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/open-iscsi/+bug/1821255/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1821255] Re: Restart policy "Always" doesn't work under certain circumstances
I've updated the description with a simpler test case that doesn't require an override file, but this bug can also be verified with the Restart=always directive: ubuntu@disco:~$ cat /etc/systemd/system/iscsid.service.d/override.conf [Service] Restart=always ubuntu@disco:~$ sudo pkill iscsid ubuntu@disco:~$ sudo systemctl status iscsid ● iscsid.service - iSCSI initiator daemon (iscsid) Loaded: loaded (/lib/systemd/system/iscsid.service; disabled; vendor pre Drop-In: /etc/systemd/system/iscsid.service.d └─override.conf Active: inactive (dead) Docs: man:iscsid(8) ** Tags added: sts -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1821255 Title: Restart policy "Always" doesn't work under certain circumstances To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/open-iscsi/+bug/1821255/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1821255] Re: Restart policy "Always" doesn't work under certain circumstances
Hi Eric, Xenial does not exhibit this bug since it does not ship iscsid.socket. This is also the reason Debian is not affected, since they also don't have socket activation for iscsid. I did send a comment to the Debian bug that proposes changing iscsid to socket activation [0], just so they're aware of this issue. Thanks, Heitor [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900397 ** Bug watch added: Debian Bug tracker #900397 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900397 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1821255 Title: Restart policy "Always" doesn't work under certain circumstances To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/open-iscsi/+bug/1821255/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1818880] Re: Deadlock when detaching network interface
@@corey.bryant I've checked Pike and it has the fix included already, so I'm attaching a debdiff for Ocata only. @hopem About Trusty-Mitaka, it seems that it automatically pulled the patch from Xenial's release so it looks good too. ** Patch added: "lp1818880-ocata.debdiff" https://bugs.launchpad.net/cloud-archive/+bug/1818880/+attachment/5251719/+files/lp1818880-ocata.debdiff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1818880 Title: Deadlock when detaching network interface To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1818880/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1822821] [NEW] TSC clocksource not available in nested guests
Public bug reported: [Impact] * TSC clocksource not available in nested guests [Test Case] * Spin up a nested Xenial/Bionic guest and check for 'tsc' at /sys/devices/system/clocksource/clocksource0/available_clocksource [Regression Potential] * The regression potential is low. Upstream code still maintains this behaviour of skipping calibration on guests, and tsc code verifies if the frequency is known before registering the clocksource * Patches were verified against the above test case, and also tested with stress-ng in both nested and non-nested guest scenarios [Fix] * By applying the upstream commits [0] [1], we skip refined calibration and register TSC as a clocksource directly if its frequency is known (via MSR or CPUID) [0] For Xenial only - https://git.kernel.org/linus/47c95a46d0f [1] https://git.kernel.org/linus/e10f78050323 ** Affects: linux (Ubuntu) Importance: Undecided Status: Incomplete ** Affects: linux (Ubuntu Xenial) Importance: Medium Status: Confirmed ** Affects: linux (Ubuntu Bionic) Importance: Medium Status: Confirmed ** Tags: sts ** Also affects: linux (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: linux (Ubuntu Xenial) Status: New => Confirmed ** Changed in: linux (Ubuntu Bionic) Status: New => Confirmed ** Changed in: linux (Ubuntu Xenial) Importance: Undecided => Medium ** Changed in: linux (Ubuntu Bionic) Importance: Undecided => Medium ** Tags added: sts ** Description changed: [Impact] - * TSC clocksource not available in nested guests + * TSC clocksource not available in nested guests [Test Case] - * Spin up a nested Xenial/Bionic guest and check for 'tsc' at -/sys/devices/system/clocksource/clocksource0/available_clocksource + * Spin up a nested Xenial/Bionic guest and check for 'tsc' at + /sys/devices/system/clocksource/clocksource0/available_clocksource [Regression Potential] - * The regression potential is low. Upstream code still maintains this -behaviour of skipping calibration on guests, and tsc code verifies if -the frequency is known before registering the clocksource + * The regression potential is low. Upstream code still maintains this + behaviour of skipping calibration on guests, and tsc code verifies if + the frequency is known before registering the clocksource - * Patches were verified against the above test case, and also tested -with stress-ng in both nested and non-nested guest scenarios + * Patches were verified against the above test case, and also tested + with stress-ng in both nested and non-nested guest scenarios [Fix] - * By applying the upstream commits, we skip refined calibration and -register TSC as a clocksource directly if its frequency is known (via -MSR or CPUID) + * By applying the upstream commits [0] [1], we skip refined calibration and + register TSC as a clocksource directly if its frequency is known (via + MSR or CPUID) + + [0] For Xenial only - https://git.kernel.org/linus/47c95a46d0f + [1] https://git.kernel.org/linus/e10f78050323 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1822821 Title: TSC clocksource not available in nested guests To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1822821/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1822821] Re: TSC clocksource not available in nested guests
This is easily verifiable on both Xenial and Bionic guests from uvt-kvm. I've brought up both as nested instances, and TSC fails to show up as an available clocksource: == Xenial guest == $ uvt-kvm ssh bionic-l1 ubuntu@bionic-l1:~$ uvt-kvm ssh xenial-l2 ubuntu@xenial-l2:~$ uname -r 4.4.0-143-generic ubuntu@xenial-l2:~$ cat /sys/devices/system/clocksource/clocksource0/available_clocksource kvm-clock hpet acpi_pm ubuntu@xenial-l2:~$ dmesg | grep -i tsc [0.00] tsc: Detected 1997.676 MHz processor == Bionic guest == $ uvt-kvm ssh bionic-l1 ubuntu@bionic-l1:~$ uvt-kvm ssh bionic-l2 ubuntu@bionic-l2:~$ uname -r 4.15.0-46-generic ubuntu@bionic-l2:~$ cat /sys/devices/system/clocksource/clocksource0/available_clocksource kvm-clock hpet acpi_pm ubuntu@bionic-l2:~$ dmesg | grep -i tsc [0.052000] tsc: Detected 1997.676 MHz processor == >From what I've tested, it doesn't seem to matter which L1 kernel is running, since they usually have TSC available. This seems to be an issue only on nested guests. ** Description changed: [Impact] * TSC clocksource not available in nested guests [Test Case] * Spin up a nested Xenial/Bionic guest and check for 'tsc' at /sys/devices/system/clocksource/clocksource0/available_clocksource [Regression Potential] * The regression potential is low. Upstream code still maintains this behaviour of skipping calibration on guests, and tsc code verifies if the frequency is known before registering the clocksource * Patches were verified against the above test case, and also tested with stress-ng in both nested and non-nested guest scenarios [Fix] * By applying the upstream commits [0] [1], we skip refined calibration and register TSC as a clocksource directly if its frequency is known (via MSR or CPUID) + * Cosmic onwards (kernel 4.18+) are already fixed + [0] For Xenial only - https://git.kernel.org/linus/47c95a46d0f [1] https://git.kernel.org/linus/e10f78050323 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1822821 Title: TSC clocksource not available in nested guests To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1822821/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1822821] Re: TSC clocksource not available in nested guests
** Changed in: linux (Ubuntu) Status: Incomplete => Fix Released -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1822821 Title: TSC clocksource not available in nested guests To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1822821/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1822821] Re: TSC clocksource not available in nested guests
** Changed in: linux (Ubuntu Xenial) Assignee: (unassigned) => Heitor R. Alves de Siqueira (halves) ** Changed in: linux (Ubuntu Bionic) Assignee: (unassigned) => Heitor R. Alves de Siqueira (halves) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1822821 Title: TSC clocksource not available in nested guests To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1822821/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1822821] Re: TSC clocksource not available in nested guests
Patches submitted to kernel-team list: Xenial - https://lists.ubuntu.com/archives/kernel-team/2019-April/099810.html Bionic - https://lists.ubuntu.com/archives/kernel-team/2019-April/099813.html -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1822821 Title: TSC clocksource not available in nested guests To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1822821/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1821255] Re: Restart policy "Always" doesn't work under certain circumstances
Confirmed fix in bionic, according to test case: ubuntu@bionic:~$ ./deploy-tgt.sh ubuntu@bionic:~$ dpkg -l | grep open-iscsi ii open-iscsi2.0.874-5ubuntu2.7 amd64iSCSI initiator tools ubuntu@bionic:~$ sudo pkill iscsid ubuntu@bionic:~$ sudo systemctl stop iscsid Warning: Stopping iscsid.service, but it can still be activated by: iscsid.socket ubuntu@bionic:~$ The systemctl stop command doesn't hang anymore, and the service can be restarted normally. ** Tags removed: verification-needed-bionic ** Tags added: verification-done-bionic -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1821255 Title: Restart policy "Always" doesn't work under certain circumstances To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/open-iscsi/+bug/1821255/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1821255] Re: Restart policy "Always" doesn't work under certain circumstances
Confirmed fix in cosmic, according to test case: ubuntu@cosmic:~$ ./deploy-tgt.sh ubuntu@cosmic:~$ dpkg -l | grep open-iscsi ii open-iscsi 2.0.874-5ubuntu9.4 amd64 iSCSI initiator tools ubuntu@cosmic:~$ sudo pkill iscsid ubuntu@cosmic:~$ sudo systemctl stop iscsid Warning: Stopping iscsid.service, but it can still be activated by: iscsid.socket ubuntu@cosmic:~$ The systemctl stop command doesn't hang anymore, and the service can be restarted normally. ** Tags removed: verification-needed verification-needed-cosmic ** Tags added: verification-done-cosmic -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1821255 Title: Restart policy "Always" doesn't work under certain circumstances To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/open-iscsi/+bug/1821255/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1821380] Re: HA-LVM can't parse vgchange_options with special characters
** Patch added: "lp1821380-lvm-xenial.debdiff" https://bugs.launchpad.net/ubuntu/+source/resource-agents/+bug/1821380/+attachment/5252534/+files/lp1821380-lvm-xenial.debdiff ** Tags added: sts-sponsor -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1821380 Title: HA-LVM can't parse vgchange_options with special characters To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resource-agents/+bug/1821380/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1815501] Re: ixgbe: Kernel Oops when attempting to disable spoofchk in a non-existing VF
Tested on linux-generic 3.13.0.168.179 from trusty-proposed. Tried reproducing according to test case from description, and verified that ixgbe is fixed: # uname -r 3.13.0-168-generic # apt-cache madison linux-generic linux-generic | 3.13.0.168.179 | http://archive.ubuntu.com/ubuntu/trusty-proposed/main amd64 Packages # ip link set dev eth4 vf -1 spoofchk off RTNETLINK answers: Invalid argument dmesg is clean after spoofchk, and network connectivity continues operating as expected. ** Tags removed: verification-needed-trusty ** Tags added: verification-done-trusty -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1815501 Title: ixgbe: Kernel Oops when attempting to disable spoofchk in a non- existing VF To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1815501/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1819046] Re: Systemd unit file reads settings from wrong path
Tested on pacemaker 1.1.14-2ubuntu1.5 from xenial-proposed. Tried reproducing according to test case from description, and confirmed that pacemaker is fixed: # apt list pacemaker pacemaker/xenial-proposed,now 1.1.14-2ubuntu1.5 amd64 [installed] # echo "PCMK_logfile=/tmp/pacemaker.log" >> /etc/default/pacemaker # systemctl restart pacemaker.service # ls -l /tmp/pacemaker.log -rw-rw 1 hacluster haclient 13695 Mar 18 14:45 /tmp/pacemaker.log # head /tmp/pacemaker.log Set r/w permissions for uid=112, gid=116 on /tmp/pacemaker.log Mar 18 14:45:22 [7342] pacemaker pacemakerd: info: crm_log_init:Changed active directory to /var/lib/pacemaker/cores/root Mar 18 14:45:22 [7342] pacemaker pacemakerd: info: get_cluster_type: Detected an active 'corosync' cluster [...] ** Tags removed: verification-needed verification-needed-xenial ** Tags added: verification-done verification-done-xenial -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1819046 Title: Systemd unit file reads settings from wrong path To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1819046/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1818880] Re: Deadlock when detaching network interface
** Attachment added: "Helper script for continuous iperf tests in guest" https://bugs.launchpad.net/cloud-archive/+bug/1818880/+attachment/5248210/+files/iperf-retry.sh -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1818880 Title: Deadlock when detaching network interface To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1818880/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1818880] Re: Deadlock when detaching network interface
Hi, As this bug is very hard to trigger, I've been running some tests with qemu 1:2.5+dfsg-5ubuntu10.35 to see if we didn't regress or break anything with the new patch. My test setup is as follows: 1) Create new QEMU guest with uvt-kvm or virt-install # uvt-kvm create xenial release=xenial --cpu 8 2) Install iperf and latest stress-ng from git. Upstream stress-ng is desired to have a consistent load on each guest # apt install iperf # git clone git://kernel.ubuntu.com/cking/stress-ng # cd stress-ng # make clean # make 3) Start an iperf server instance on the host root@host:~# iperf -s 4) Stress the guest instance with the iperf-retry.sh script and stress-ng (run those commands in different screen windows) # ./stress-ng --cpu 4 --hdd 4 --io 4 --vm 4 # ./stress-ng --class network --all 2 # ./iperf-retry.sh 5) Attach and detach network adapter using the hotplug.sh script root@host:~# ./hotplug.sh xenial 52:54:00:19:7a:21 I've tested this with different guests, including Xenial, Bionic and Disco. Guest instances performed more than ~2000 hotplug cycles each: root@host:~# ./hotplug.sh xenial 52:54:00:19:7a:21 Detach #1 Interface detached successfully Detach #2 Interface detached successfully ... Detach #2168 Interface detached successfully The QEMU guests work correctly through and after the tests, and it doesn't look like we ran into any regressions due to the RCU patch. Thanks, Heitor ** Attachment added: "Helper script for network adapter attach/detach cycles" https://bugs.launchpad.net/cloud-archive/+bug/1818880/+attachment/5248209/+files/hotplug.sh -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1818880 Title: Deadlock when detaching network interface To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1818880/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1818880] Re: Deadlock when detaching network interface
** Tags removed: verification-needed verification-needed-xenial ** Tags added: verification-done verification-done-xenial -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1818880 Title: Deadlock when detaching network interface To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1818880/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1821343] [NEW] slapd process failure is not detected by systemd
Public bug reported:
[Impact]
Systemd service reports slapd as active, even though it may have failed
[Description]
The slapd package for OpenLDAP is shipped with a SysV-style init script
(/etc/init.d/slapd). Systemd automatically converts this to a systemd service
by generating the unit file using the systemd-sysv-generator(8) utility. The
generated unit file contains Type=forking and RemainAfterExit=yes directives.
If the slapd daemon process exits due to some failure (e.g., it receives
a SIGTERM or SIGKILL), the failure is not detected properly by systemd.
The service is still reported as active even though the child (daemon)
process has exited with a signal.
We can easily fix this by including a proper systemd service file for
slapd in the openldap package. Since the init.d script already does most
of the necessary work (parsing configs, setting up PID files, etc.), we
don't need anything complicated for the systemd unit file. Just making
sure that RemainAfterExit is set to "no" makes the systemd service
behave in the expected way.
[Test Case]
1) Deploy a disco container
$ lxc launch images:ubuntu/disco disco
2) Install slapd
ubuntu@disco:~$ sudo apt update && sudo apt install slapd -y
3) Verify that slapd is running with the auto-generated service
ubuntu@disco:~$ systemctl status slapd
● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory Access
Protocol)
Loaded: loaded (/etc/init.d/slapd; generated)
Active: active (running) since Fri 2019-03-22 11:51:22 UTC; 40min ago
Docs: man:systemd-sysv-generator(8)
Process: 1103 ExecStart=/etc/init.d/slapd start (code=exited,
status=0/SUCCESS)
Tasks: 3 (limit: 4915)
Memory: 712.6M
CGroup: /system.slice/slapd.service
└─1109 /usr/sbin/slapd -h ldap:/// ldapi:/// -g openldap -u openldap
-F /etc/ldap/slapd.d
4) SIGKILL the slapd process (PID is displayed in systemctl status output)
ubuntu@disco:~$ sudo kill -9 1109
5) Check if systemd service lists slapd as still active, even though it was
terminated
ubuntu@disco:~$ systemctl status slapd
● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory Access
Protocol)
Loaded: loaded (/etc/init.d/slapd; generated)
Active: active (exited) since Fri 2019-03-22 11:51:22 UTC; 42min ago
Docs: man:systemd-sysv-generator(8)
Process: 1103 ExecStart=/etc/init.d/slapd start (code=exited,
status=0/SUCCESS)
[Regression Potential]
The regression potential for this fix should be very low, if we keep the new
systemd unit file close to the one generated by systemd-sysv-generator(8). The
only significant change would be the RemainAfterExit directive, and this should
make the slapd service behave like a "normal" forking service. Nonetheless,
we'll perform scripted test runs to make sure no regressions arise.
** Affects: openldap (Ubuntu)
Importance: Medium
Assignee: Heitor R. Alves de Siqueira (halves)
Status: Confirmed
** Affects: openldap (Ubuntu Xenial)
Importance: Medium
Assignee: Heitor R. Alves de Siqueira (halves)
Status: Confirmed
** Affects: openldap (Ubuntu Bionic)
Importance: Medium
Assignee: Heitor R. Alves de Siqueira (halves)
Status: Confirmed
** Affects: openldap (Ubuntu Cosmic)
Importance: Medium
Assignee: Heitor R. Alves de Siqueira (halves)
Status: Confirmed
** Tags: sts
** Also affects: openldap (Ubuntu Cosmic)
Importance: Undecided
Status: New
** Also affects: openldap (Ubuntu Bionic)
Importance: Undecided
Status: New
** Also affects: openldap (Ubuntu Xenial)
Importance: Undecided
Status: New
** Changed in: openldap (Ubuntu Xenial)
Status: New => Confirmed
** Changed in: openldap (Ubuntu Bionic)
Status: New => Confirmed
** Changed in: openldap (Ubuntu Cosmic)
Status: New => Confirmed
** Changed in: openldap (Ubuntu Xenial)
Assignee: (unassigned) => Heitor R. Alves de Siqueira (halves)
** Changed in: openldap (Ubuntu Bionic)
Assignee: (unassigned) => Heitor R. Alves de Siqueira (halves)
** Changed in: openldap (Ubuntu Cosmic)
Assignee: (unassigned) => Heitor R. Alves de Siqueira (halves)
** Changed in: openldap (Ubuntu Xenial)
Importance: Undecided => Medium
** Changed in: openldap (Ubuntu Bionic)
Importance: Undecided => Medium
** Changed in: openldap (Ubuntu Cosmic)
Importance: Undecided => Medium
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1821343
Title:
slapd process failure is not detected by systemd
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1821343/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1821343] Re: slapd process failure is not detected by systemd
** Patch added: "debdiff for cosmic" https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1821343/+attachment/5248490/+files/lp1821343-cosmic.debdiff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1821343 Title: slapd process failure is not detected by systemd To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1821343/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1821343] Re: slapd process failure is not detected by systemd
** Patch added: "debdiff for disco" https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1821343/+attachment/5248489/+files/lp1821343-disco.debdiff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1821343 Title: slapd process failure is not detected by systemd To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1821343/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1821343] Re: slapd process failure is not detected by systemd
** Patch added: "debdiff for bionic" https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1821343/+attachment/5248492/+files/lp1821343-bionic.debdiff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1821343 Title: slapd process failure is not detected by systemd To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1821343/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1821343] Re: slapd process failure is not detected by systemd
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1821343 Title: slapd process failure is not detected by systemd To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1821343/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1821343] Re: slapd process failure is not detected by systemd
** Patch added: "debdiff for xenial" https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1821343/+attachment/5248493/+files/lp1821343-xenial.debdiff ** Tags added: sts-sponsor -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1821343 Title: slapd process failure is not detected by systemd To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1821343/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1821380] [NEW] HA-LVM can't parse vgchange_options with special characters
Public bug reported: [Impact] We can't manage LVM resources (e.g. through pcs) if the volume_list parameter has special characters [Description] The heartbeat/LVM script has the vgchange_options parameter that is used during LVM resource creation. The vgchange_options are set according to the /etc/lvm/lvm.conf file. If there are any special characters in the configuration, the heartbeat/LVM script will raise an error due to wrong configuration options. This is fixed upstream by "3949641f2fc7 quote vgchange options", but the fix is not included in Xenial. Upstream commit: https://github.com/ClusterLabs/resource- agents/commit/3949641f2fc7 $ git describe --contains 3949641f2fc7 v4.0.0rc1~98^2 $ rmadison resource-agents => resource-agents | 1:3.9.7-1| xenial | source, amd64, ... resource-agents | 1:4.1.0~rc1-1ubuntu1 | bionic | source, amd64, ... resource-agents | 1:4.1.1-2| cosmic | source, amd64, ... resource-agents | 1:4.2.0-1ubuntu1 | disco | source, amd64, ... [Test Case] 1) Deploy a Xenial VM (e.g. through uvt-kvm or virt-install) $ uvt-kvm create node1 release=xenial 2) Install pcs and resource-agents root@node1:~# apt update && apt install pcs resource-agents -y 3) Enable HA-LVM root@node1:~# lvmconf --enable-halvm --services --startstopservices 4) Add "volume_list" parameter to the activation section of /etc/lvm/lvm.conf root@node1:~# grep "volume_list =" /etc/lvm/lvm.conf volume_list = ["node1-vg", "@tag1"] 5) Create LVM vg/lv (we use a file-backed loop device for the vg) root@node1:~# vgcreate vg01 /dev/loop0 --addtag tag1 root@node1:~# lvcreate vg01 --addtag tag1 -L1G 6) Create an LVM resource with pcs root@node1:~# pcs resource create vg01 LVM volgrpname=vg01 exclusive=true --group Resource 7) Verify that LVM resource was created correctly root@node1:~# pcs resource debug-start vg01 Error performing operation: No such file or directory Operation start for vg01 (ocf:heartbeat:LVM) returned 2 > stdout: volume_list=["node1-vg","@tag1"] > stderr: /usr/lib/ocf/resource.d/heartbeat/LVM: 415: local: --config: bad variable name If we apply the upstream patch, the resource works as expected: root@node1:~# pcs resource debug-start vg01 Operation start for vg01 (ocf:heartbeat:LVM) returned 0 > stdout: volume_list=["node1-vg","@tag1"] > stdout: Volume group "vg01" successfully changed > stdout: Volume group "vg01" successfully changed > stdout: volume_list=["node1-vg","@tag1"] > stderr: INFO: Activating volume group vg01 > stderr: INFO: Reading all physical volumes. This may take a while... Found volume group "vg01" using metadata type lvm2 > stderr: INFO: Stripping tag, tag1 > stderr: INFO: New tag "pacemaker" added to vg01 > stderr: INFO: 1 logical volume(s) in volume group "vg01" now active root@node1:~# [Regression Potential] Since this is an upstream patch and it only adds quotes to the vgchange options, we shouldn't hit any regressions due to this. Nonetheless, this fix will be tested with different configuration options and autopkgtests. ** Affects: resource-agents (Ubuntu) Importance: Medium Status: Fix Released ** Affects: resource-agents (Ubuntu Xenial) Importance: Medium Assignee: Heitor R. Alves de Siqueira (halves) Status: New ** Tags: sts ** Also affects: resource-agents (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: resource-agents (Ubuntu Xenial) Importance: Undecided => Critical ** Changed in: resource-agents (Ubuntu Xenial) Importance: Critical => Medium ** Changed in: resource-agents (Ubuntu Xenial) Assignee: (unassigned) => Heitor R. Alves de Siqueira (halves) ** Description changed: [Impact] We can't manage LVM resources (e.g. through pcs) if the volume_list parameter has special characters + [Description] The heartbeat/LVM script has the vgchange_options parameter that is used during LVM resource creation. The vgchange_options are set according to the /etc/lvm/lvm.conf file. If there are any special characters in the configuration, the heartbeat/LVM script will raise an error due to wrong configuration options. This is fixed upstream by "3949641f2fc7 quote vgchange options", but the fix is not included in Xenial. Upstream commit: https://github.com/ClusterLabs/resource- agents/commit/3949641f2fc7 $ git describe --contains 3949641f2fc7 v4.0.0rc1~98^2 $ rmadison resource-agents => resource-agents | 1:3.9.7-1| xenial | source, amd64, ... -resource-agents | 1:4.1.0~rc1-1ubuntu1 | bionic | source, amd64, ... -
[Bug 1821343] Re: slapd process failure is not detected by systemd
The sysv init script does some funky parsing of configuration files that might give us some trouble in an independent service file. I'll check if we can't work around that and do away with the sysv init script altogether, otherwise we might as well go with the drop-in override since the new service wouldn't be much different from it. ** Patch removed: "debdiff for disco" https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1821343/+attachment/5248489/+files/lp1821343-disco.debdiff ** Patch removed: "debdiff for cosmic" https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1821343/+attachment/5248490/+files/lp1821343-cosmic.debdiff ** Patch removed: "debdiff for bionic" https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1821343/+attachment/5248492/+files/lp1821343-bionic.debdiff ** Patch removed: "debdiff for xenial" https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1821343/+attachment/5248493/+files/lp1821343-xenial.debdiff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1821343 Title: slapd process failure is not detected by systemd To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1821343/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1815129] Re: apt segfaults when generating cache file
Tested on apt-1.0.1ubuntu2.20 from trusty-proposed. Tried reproducing according to the test case from description, and verified that apt-cache does not crash: ubuntu@apt-stress:~/stress-ng$ dpkg -l | grep apt ii apt 1.0.1ubuntu2.20 (while having stress-ng running) ubuntu@apt-stress:~/stress-ng$ for i in `seq 1 1`;do apt-cache policy vsftpd;done E: Couldn't make mmap of 30021560 bytes - MMap-mmap (12: Cannot allocate memory) E: The package lists or status file could not be parsed or opened. ** Tags removed: verification-needed verification-needed-trusty ** Tags added: verification-done-trusty ** Tags added: verification-needed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1815129 Title: apt segfaults when generating cache file To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1815129/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1815129] Re: apt segfaults when generating cache file
There are two armhf autopkgtest regressions for apt-1.0.1ubuntu2.20, in tests for apt [0] and autopkgtest [1]. From the autopkgtest pages we can see that these regressions were introduced long before this SRU, so it seems like a long standing issue unrelated to this patch. [0] http://autopkgtest.ubuntu.com/packages/a/apt/trusty/armhf [1] http://autopkgtest.ubuntu.com/packages/a/autopkgtest/trusty/armhf -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1815129 Title: apt segfaults when generating cache file To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1815129/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1800562] Re: Replace "nousb" option in kdump command-line for the newer "usbcore.nousb"
** Description changed:
- Since kernel v4.5, the correct parameter to disable USB subsystem
- initialization is "usbcore.nousb" always (instead of "nousb" in case the
- subsystem is built-in). This was changed by commit 097a9ea0e48 ("usb:
- make "nousb" a clear module parameter").
+ [Impact]
+ Crash kernels come up with the usb subsystem enabled, even when it should be
disabled by default.
+
+
+ [Description]
+ Since kernel v4.5, the correct parameter to disable USB subsystem
initialization is "usbcore.nousb" always (instead of "nousb" in case the
subsystem is built-in). This was changed by commit 097a9ea0e48 ("usb: make
"nousb" a clear module parameter").
We need to take this into account in kdump-tools, or else we may boot
with USB in kdump even the command-line saying the opposite.
+
+ This affects Xenial onwards, since the system may be running an HWE or
+ other supported v4.5+ kernel.
+
+ [Test Case]
+ 1) Deploy a Disco VM e.g. with uvt-kvm
+ 2) Install the kdump-tools package
+ 3) Run `kdump-config test`and check for the 'usbcore.nousb' parameter:
+
+ $ kdump-config test
+ [...]
+ kexec command to be used:
+ /sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinuz-4.15.0-45-generic
root=LABEL=cloudimg-rootfs ro console=tty1 console=ttyS0 nr_cpus=1
systemd.unit=kdump-tools.service irqpoll nousb ata_piix.prefer_ms_hyperv=0"
/var/lib/kdump/vmlinuz
+
+ [Regression Potential]
+ The regression potential is very low, since it doesn't need any changes in
makedumpfile and we're only adding a parameter on the crashkernel cmdline.
+ According to kernel documentation [0], unknown parameters will be ignored if
they contain a dot (usbcore.nousb), so this change should have no impact on
v4.4 and earlier kernels.
+ Nonetheless, the fix will be tested with autopkgtests and normal kdump
use-case scenarios.
** Description changed:
[Impact]
Crash kernels come up with the usb subsystem enabled, even when it should be
disabled by default.
-
[Description]
Since kernel v4.5, the correct parameter to disable USB subsystem
initialization is "usbcore.nousb" always (instead of "nousb" in case the
subsystem is built-in). This was changed by commit 097a9ea0e48 ("usb: make
"nousb" a clear module parameter").
We need to take this into account in kdump-tools, or else we may boot
with USB in kdump even the command-line saying the opposite.
This affects Xenial onwards, since the system may be running an HWE or
other supported v4.5+ kernel.
[Test Case]
1) Deploy a Disco VM e.g. with uvt-kvm
2) Install the kdump-tools package
3) Run `kdump-config test`and check for the 'usbcore.nousb' parameter:
$ kdump-config test
[...]
kexec command to be used:
- /sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinuz-4.15.0-45-generic
root=LABEL=cloudimg-rootfs ro console=tty1 console=ttyS0 nr_cpus=1
systemd.unit=kdump-tools.service irqpoll nousb ata_piix.prefer_ms_hyperv=0"
/var/lib/kdump/vmlinuz
+ /sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinuz-4.15.0-45-generic
root=LABEL=cloudimg-rootfs ro console=tty1 console=ttyS0 nr_cpus=1
systemd.unit=kdump-tools.service irqpoll nousb ata_piix.prefer_ms_hyperv=0"
/var/lib/kdump/vmlinuz
[Regression Potential]
The regression potential is very low, since it doesn't need any changes in
makedumpfile and we're only adding a parameter on the crashkernel cmdline.
According to kernel documentation [0], unknown parameters will be ignored if
they contain a dot (usbcore.nousb), so this change should have no impact on
v4.4 and earlier kernels.
Nonetheless, the fix will be tested with autopkgtests and normal kdump
use-case scenarios.
+
+ [0] https://www.kernel.org/doc/Documentation/admin-guide/kernel-
+ parameters.rst
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1800562
Title:
Replace "nousb" option in kdump command-line for the newer
"usbcore.nousb"
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1800562/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1800566] Re: Make the reset_devices parameter default for kdump kernels
** Description changed: - Kernel has the "reset_devices" parameter that drivers can opt-in, and - perform special activity in case this parameter is parsed from command- - line. For example, in kdump kernels it hints the drivers that they - (maybe) are booting from a non-healthy condition and needs to issue some - reset to the adapter. Users currently (kernel v4.19) are: hpsa, ipr, - megaraid_sas, mpt3sas, smartpqi, xenbus. + [Impact] + Crash kernels do not advise some subsystems to perform a reset by default. + + [Description] + Kernel has the "reset_devices" parameter that drivers can opt-in, and perform special activity in case this parameter is parsed from command-line. For example, in kdump kernels it hints the drivers that they (maybe) are booting from a non-healthy condition and needs to issue some reset to the adapter. Users currently (kernel v4.19) are: hpsa, ipr, megaraid_sas, mpt3sas, smartpqi, xenbus. This should be enabled by default in the kdump config file to be added in the kdump kernel command-line for all versions. + + [Test Case] + 1) Deploy a Disco VM e.g. with uvt-kvm + 2) Install the kdump-tools package + 3) Run `kdump-config test`and check for the 'reset_devices' parameter: + + $ kdump-config test + [...] + kexec command to be used: + /sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinuz-4.15.0-45-generic root=LABEL=cloudimg-rootfs ro console=tty1 console=ttyS0 nr_cpus=1 systemd.unit=kdump-tools.service irqpoll nousb ata_piix.prefer_ms_hyperv=0" /var/lib/kdump/vmlinuz + + [Regression Potential] + The regression potential is very low, since it doesn't need any changes in makedumpfile code and we're only adding a parameter on the crashkernel cmdline. + The fix will be tested with autopkgtests and normal kdump use-case scenarios. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1800566 Title: Make the reset_devices parameter default for kdump kernels To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1800566/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1815501] Re: ixgbe: Kernel Oops when attempting to disable spoofchk in a non-existing VF
SRUv2 sent to kernel-team mailing list: https://lists.ubuntu.com/archives/kernel-team/2019-February/098451.htm -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1815501 Title: ixgbe: Kernel Oops when attempting to disable spoofchk in a non- existing VF To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1815501/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1800562] Re: Replace "nousb" option in kdump command-line for the newer "usbcore.nousb"
** Patch added: "debdiff for disco" https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1800562/+attachment/5239779/+files/disco_makedumpfile_1.6.5-1ubuntu2.debdiff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1800562 Title: Replace "nousb" option in kdump command-line for the newer "usbcore.nousb" To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1800562/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1800562] Re: Replace "nousb" option in kdump command-line for the newer "usbcore.nousb"
** Patch added: "debdiff for bionic" https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1800562/+attachment/5239781/+files/bionic_makedumpfile_1.6.3-2ubuntu2.debdiff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1800562 Title: Replace "nousb" option in kdump command-line for the newer "usbcore.nousb" To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1800562/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1800562] Re: Replace "nousb" option in kdump command-line for the newer "usbcore.nousb"
** Patch added: "debdiff for cosmic" https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1800562/+attachment/5239780/+files/cosmic_makedumpfile_1.6.4-2ubuntu2.debdiff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1800562 Title: Replace "nousb" option in kdump command-line for the newer "usbcore.nousb" To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1800562/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1800562] Re: Replace "nousb" option in kdump command-line for the newer "usbcore.nousb"
** Patch added: "debdiff for xenial" https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1800562/+attachment/5239782/+files/xenial_makedumpfile_1.6.3-2~16.04.1ubuntu1.debdiff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1800562 Title: Replace "nousb" option in kdump command-line for the newer "usbcore.nousb" To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1800562/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1800566] Re: Make the reset_devices parameter default for kdump kernels
Debdiffs for this bug were attached to LP#1800562 ** Description changed: [Impact] Crash kernels do not advise some subsystems to perform a reset by default. [Description] Kernel has the "reset_devices" parameter that drivers can opt-in, and perform special activity in case this parameter is parsed from command-line. For example, in kdump kernels it hints the drivers that they (maybe) are booting from a non-healthy condition and needs to issue some reset to the adapter. Users currently (kernel v4.19) are: hpsa, ipr, megaraid_sas, mpt3sas, smartpqi, xenbus. This should be enabled by default in the kdump config file to be added in the kdump kernel command-line for all versions. [Test Case] 1) Deploy a Disco VM e.g. with uvt-kvm 2) Install the kdump-tools package 3) Run `kdump-config test`and check for the 'reset_devices' parameter: $ kdump-config test - [...] + ... kexec command to be used: - /sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinuz-4.15.0-45-generic root=LABEL=cloudimg-rootfs ro console=tty1 console=ttyS0 nr_cpus=1 systemd.unit=kdump-tools.service irqpoll nousb ata_piix.prefer_ms_hyperv=0" /var/lib/kdump/vmlinuz + /sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinuz-4.15.0-45-generic root=LABEL=cloudimg-rootfs ro console=tty1 console=ttyS0 nr_cpus=1 systemd.unit=kdump-tools.service irqpoll nousb ata_piix.prefer_ms_hyperv=0" /var/lib/kdump/vmlinuz [Regression Potential] The regression potential is very low, since it doesn't need any changes in makedumpfile code and we're only adding a parameter on the crashkernel cmdline. The fix will be tested with autopkgtests and normal kdump use-case scenarios. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1800566 Title: Make the reset_devices parameter default for kdump kernels To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1800566/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1800562] Re: Replace "nousb" option in kdump command-line for the newer "usbcore.nousb"
** Description changed:
[Impact]
Crash kernels come up with the usb subsystem enabled, even when it should be
disabled by default.
[Description]
Since kernel v4.5, the correct parameter to disable USB subsystem
initialization is "usbcore.nousb" always (instead of "nousb" in case the
subsystem is built-in). This was changed by commit 097a9ea0e48 ("usb: make
"nousb" a clear module parameter").
We need to take this into account in kdump-tools, or else we may boot
with USB in kdump even the command-line saying the opposite.
This affects Xenial onwards, since the system may be running an HWE or
other supported v4.5+ kernel.
[Test Case]
1) Deploy a Disco VM e.g. with uvt-kvm
2) Install the kdump-tools package
3) Run `kdump-config test`and check for the 'usbcore.nousb' parameter:
$ kdump-config test
- [...]
+ ...
kexec command to be used:
/sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinuz-4.15.0-45-generic
root=LABEL=cloudimg-rootfs ro console=tty1 console=ttyS0 nr_cpus=1
systemd.unit=kdump-tools.service irqpoll nousb ata_piix.prefer_ms_hyperv=0"
/var/lib/kdump/vmlinuz
[Regression Potential]
The regression potential is very low, since it doesn't need any changes in
makedumpfile and we're only adding a parameter on the crashkernel cmdline.
According to kernel documentation [0], unknown parameters will be ignored if
they contain a dot (usbcore.nousb), so this change should have no impact on
v4.4 and earlier kernels.
Nonetheless, the fix will be tested with autopkgtests and normal kdump
use-case scenarios.
[0] https://www.kernel.org/doc/Documentation/admin-guide/kernel-
parameters.rst
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1800562
Title:
Replace "nousb" option in kdump command-line for the newer
"usbcore.nousb"
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1800562/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1800562] Re: Replace "nousb" option in kdump command-line for the newer "usbcore.nousb"
Thanks for bringing that up, Cascardo. That was one scenario we didn't consider, and you're right about it causing problems for users with encrypted systems. It does seem more sensible to just remove the 'nousb' option in this case, since this parameter has no effect in recent kernels. I'll respin the patches and change this LP to better reflect this. Thanks! -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1800562 Title: Replace "nousb" option in kdump command-line for the newer "usbcore.nousb" To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1800562/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1800562] Re: Replace "nousb" option in kdump command-line for the newer "usbcore.nousb"
** Patch removed: "debdiff for disco" https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1800562/+attachment/5239779/+files/disco_makedumpfile_1.6.5-1ubuntu2.debdiff ** Patch removed: "debdiff for cosmic" https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1800562/+attachment/5239780/+files/cosmic_makedumpfile_1.6.4-2ubuntu2.debdiff ** Patch removed: "debdiff for bionic" https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1800562/+attachment/5239781/+files/bionic_makedumpfile_1.6.3-2ubuntu2.debdiff ** Patch removed: "debdiff for xenial" https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1800562/+attachment/5239782/+files/xenial_makedumpfile_1.6.3-2~16.04.1ubuntu1.debdiff ** Summary changed: - Replace "nousb" option in kdump command-line for the newer "usbcore.nousb" + Remove obsolete "nousb" option in kdump command-line for newer kernels -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1800562 Title: Remove obsolete "nousb" option in kdump command-line for newer kernels To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1800562/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1800562] Re: Remove obsolete "nousb" option in kdump command-line for newer kernels
** Description changed:
[Impact]
- Crash kernels come up with the usb subsystem enabled, even when it should be
disabled by default.
+ Crash kernels include an obsolete "nousb" parameter by default, which can
cause confusion since it's been deprecated in newer kernel versions.
[Description]
Since kernel v4.5, the correct parameter to disable USB subsystem
initialization is "usbcore.nousb" always (instead of "nousb" in case the
subsystem is built-in). This was changed by commit 097a9ea0e48 ("usb: make
"nousb" a clear module parameter").
We need to take this into account in kdump-tools, or else we may boot
- with USB in kdump even the command-line saying the opposite.
+ with USB in kdump even the command-line appears to be saying the
+ opposite.
This affects Xenial onwards, since the system may be running an HWE or
other supported v4.5+ kernel.
[Test Case]
1) Deploy a Disco VM e.g. with uvt-kvm
2) Install the kdump-tools package
- 3) Run `kdump-config test`and check for the 'usbcore.nousb' parameter:
+ 3) Run `kdump-config test`and check for the 'nousb' parameter:
$ kdump-config test
...
kexec command to be used:
/sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinuz-4.15.0-45-generic
root=LABEL=cloudimg-rootfs ro console=tty1 console=ttyS0 nr_cpus=1
systemd.unit=kdump-tools.service irqpoll nousb ata_piix.prefer_ms_hyperv=0"
/var/lib/kdump/vmlinuz
[Regression Potential]
- The regression potential is very low, since it doesn't need any changes in
makedumpfile and we're only adding a parameter on the crashkernel cmdline.
- According to kernel documentation [0], unknown parameters will be ignored if
they contain a dot (usbcore.nousb), so this change should have no impact on
v4.4 and earlier kernels.
- Nonetheless, the fix will be tested with autopkgtests and normal kdump
use-case scenarios.
-
- [0] https://www.kernel.org/doc/Documentation/admin-guide/kernel-
- parameters.rst
+ The regression potential is extremely low, since it doesn't need any changes
in makedumpfile code and we're only removing an already ineffective parameter
from the crashkernel cmdline. Nonetheless, patches will be tested with
autopkgtests and normal kdump use-case scenarios.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1800562
Title:
Remove obsolete "nousb" option in kdump command-line for newer kernels
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1800562/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1818880] [NEW] Deadlock when detaching network interface
Public bug reported:
[Impact]
Qemu guests hang indefinitely
[Description]
When running a Qemu guest with VirtIO network interfaces, detaching an
interface that's currently being used can result in a deadlock. The guest
instance will hang and become unresponsive to commands, and the only option is
to kill -9 the instance.
The reason for this is a dealock between a monitor and an RCU thread, which
will fight over the BQL (qemu_global_mutex) and the critical RCU section locks.
The monitor thread will acquire the BQL for detaching the network interface,
and fire up a helper thread to deal with detaching the network adapter. That
new thread needs to wait on the RCU thread to complete the deletion, but the
RCU thread wants the BQL to commit its transactions.
This bug is already fixed upstream (73c6e4013b4c rcu: completely disable
pthread_atfork callbacks as soon as possible) and included for other series
(see below), so we don't need to backport it to Bionic onwards.
Upstream commit:
https://git.qemu.org/?p=qemu.git;a=commit;h=73c6e4013b4c
$ git describe --contains 73c6e4013b4c
v2.10.0-rc2~1^2~8
$ rmadison qemu
===> qemu | 1:2.5+dfsg-5ubuntu10.34 | xenial-updates/universe | amd64, ...
qemu | 1:2.11+dfsg-1ubuntu7| bionic/universe | amd64, ...
qemu | 1:2.12+dfsg-3ubuntu8| cosmic/universe | amd64, ...
qemu | 1:3.1+dfsg-2ubuntu2 | disco/universe| amd64, ...
[Test Case]
Being a racing condition, this is a tricky bug to reproduce consistently. We've
had reports of users running into this with OpenStack deployments and Windows
Server guests, and the scenario is usually like this:
1) Deploy a 16vCPU Windows Server 2012 R2 guest with a virtio network interface
2) Stress the network interface with e.g. Windows HLK test suite or similar
3) Repeatedly attach/detach the network adapter that's in use
It usually takes more than ~4000 attach/detach cycles to trigger the bug.
[Regression Potential]
Regressions for this might arise from the fact that the fix changes RCU lock
code. Since this patch has been upstream and in other series for a while, it's
unlikely that it would regressions in RCU code specifically. Other code that
makes use of the RCU locks (MMIO and some monitor events) will be thoroughly
tested for any regressions with autokpkgtest and scripted Qemu runs.
** Affects: qemu
Importance: Undecided
Status: Fix Released
** Affects: qemu (Ubuntu)
Importance: Undecided
Assignee: Heitor R. Alves de Siqueira (halves)
Status: Fix Released
** Affects: qemu (Ubuntu Xenial)
Importance: Undecided
Assignee: Heitor R. Alves de Siqueira (halves)
Status: Confirmed
** Affects: qemu (Ubuntu Bionic)
Importance: Undecided
Assignee: Heitor R. Alves de Siqueira (halves)
Status: Fix Released
** Affects: qemu (Ubuntu Cosmic)
Importance: Undecided
Assignee: Heitor R. Alves de Siqueira (halves)
Status: Fix Released
** Affects: qemu (Ubuntu Disco)
Importance: Undecided
Assignee: Heitor R. Alves de Siqueira (halves)
Status: Fix Released
** Tags: sts
** Changed in: qemu
Status: New => Confirmed
** Changed in: qemu
Status: Confirmed => Fix Released
** Also affects: qemu (Ubuntu)
Importance: Undecided
Status: New
** Changed in: qemu (Ubuntu)
Assignee: (unassigned) => Heitor R. Alves de Siqueira (halves)
** Changed in: qemu (Ubuntu)
Status: New => Confirmed
** Also affects: qemu (Ubuntu Cosmic)
Importance: Undecided
Status: New
** Also affects: qemu (Ubuntu Xenial)
Importance: Undecided
Status: New
** Also affects: qemu (Ubuntu Disco)
Importance: Undecided
Assignee: Heitor R. Alves de Siqueira (halves)
Status: Confirmed
** Also affects: qemu (Ubuntu Bionic)
Importance: Undecided
Status: New
** Changed in: qemu (Ubuntu Cosmic)
Assignee: (unassigned) => Heitor R. Alves de Siqueira (halves)
** Changed in: qemu (Ubuntu Bionic)
Assignee: (unassigned) => Heitor R. Alves de Siqueira (halves)
** Changed in: qemu (Ubuntu Xenial)
Assignee: (unassigned) => Heitor R. Alves de Siqueira (halves)
** Changed in: qemu (Ubuntu Disco)
Status: Confirmed => Fix Released
** Changed in: qemu (Ubuntu Cosmic)
Status: New => Fix Released
** Changed in: qemu (Ubuntu Bionic)
Status: New => Fix Released
** Changed in: qemu (Ubuntu Xenial)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1818880
Title:
Deadlock when detaching network interface
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1818880/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1818882] [NEW] Deadlock when detaching network interface
Public bug reported:
[Impact]
Qemu guests hang indefinitely
[Description]
When running a Qemu guest with VirtIO network interfaces, detaching an
interface that's currently being used can result in a deadlock. The guest
instance will hang and become unresponsive to commands, and the only option is
to kill -9 the instance.
The reason for this is a dealock between a monitor and an RCU thread, which
will fight over the BQL (qemu_global_mutex) and the critical RCU section locks.
The monitor thread will acquire the BQL for detaching the network interface,
and fire up a helper thread to deal with detaching the network adapter. That
new thread needs to wait on the RCU thread to complete the deletion, but the
RCU thread wants the BQL to commit its transactions.
This bug is already fixed upstream (73c6e4013b4c rcu: completely disable
pthread_atfork callbacks as soon as possible) and included for other series
(see below), so we don't need to backport it to Bionic onwards.
Upstream commit:
https://git.qemu.org/?p=qemu.git;a=commit;h=73c6e4013b4c
$ git describe --contains 73c6e4013b4c
v2.10.0-rc2~1^2~8
$ rmadison qemu
===> qemu | 1:2.5+dfsg-5ubuntu10.34 | xenial-updates/universe | amd64, ...
qemu | 1:2.11+dfsg-1ubuntu7 | bionic/universe | amd64, ...
qemu | 1:2.12+dfsg-3ubuntu8 | cosmic/universe | amd64, ...
qemu | 1:3.1+dfsg-2ubuntu2 | disco/universe | amd64, ...
[Test Case]
Being a racing condition, this is a tricky bug to reproduce consistently. We've
had reports of users running into this with OpenStack deployments and Windows
Server guests, and the scenario is usually like this:
1) Deploy a 16vCPU Windows Server 2012 R2 guest with a virtio network interface
2) Stress the network interface with e.g. Windows HLK test suite or similar
3) Repeatedly attach/detach the network adapter that's in use
It usually takes more than ~4000 attach/detach cycles to trigger the bug.
[Regression Potential]
Regressions for this might arise from the fact that the fix changes RCU lock
code. Since this patch has been upstream and in other series for a while, it's
unlikely that it would regressions in RCU code specifically. Other code that
makes use of the RCU locks (MMIO and some monitor events) will be thoroughly
tested for any regressions with autokpkgtest and scripted Qemu runs.
** Affects: qemu (Ubuntu)
Importance: Undecided
Assignee: Heitor R. Alves de Siqueira (halves)
Status: Invalid
** Changed in: qemu (Ubuntu)
Status: Confirmed => Invalid
** Tags removed: sts
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1818882
Title:
Deadlock when detaching network interface
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1818882/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1818882] Re: Deadlock when detaching network interface
Duplicate of #1818880 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1818882 Title: Deadlock when detaching network interface To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1818882/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1818880] Re: Deadlock when detaching network interface
** Also affects: cloud-archive Importance: Undecided Status: New ** Changed in: cloud-archive Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1818880 Title: Deadlock when detaching network interface To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1818880/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1818880] Re: Deadlock when detaching network interface
** Patch added: "Debdiff for xenial" https://bugs.launchpad.net/cloud-archive/+bug/1818880/+attachment/5244384/+files/xenial.debdiff ** Description changed: [Impact] Qemu guests hang indefinitely [Description] When running a Qemu guest with VirtIO network interfaces, detaching an interface that's currently being used can result in a deadlock. The guest instance will hang and become unresponsive to commands, and the only option is to kill -9 the instance. The reason for this is a dealock between a monitor and an RCU thread, which will fight over the BQL (qemu_global_mutex) and the critical RCU section locks. The monitor thread will acquire the BQL for detaching the network interface, and fire up a helper thread to deal with detaching the network adapter. That new thread needs to wait on the RCU thread to complete the deletion, but the RCU thread wants the BQL to commit its transactions. This bug is already fixed upstream (73c6e4013b4c rcu: completely disable pthread_atfork callbacks as soon as possible) and included for other series (see below), so we don't need to backport it to Bionic onwards. Upstream commit: https://git.qemu.org/?p=qemu.git;a=commit;h=73c6e4013b4c $ git describe --contains 73c6e4013b4c v2.10.0-rc2~1^2~8 $ rmadison qemu ===> qemu | 1:2.5+dfsg-5ubuntu10.34 | xenial-updates/universe | amd64, ... - qemu | 1:2.11+dfsg-1ubuntu7| bionic/universe | amd64, ... - qemu | 1:2.12+dfsg-3ubuntu8| cosmic/universe | amd64, ... - qemu | 1:3.1+dfsg-2ubuntu2 | disco/universe| amd64, ... + qemu | 1:2.11+dfsg-1ubuntu7| bionic/universe | amd64, ... + qemu | 1:2.12+dfsg-3ubuntu8| cosmic/universe | amd64, ... + qemu | 1:3.1+dfsg-2ubuntu2 | disco/universe| amd64, ... [Test Case] Being a racing condition, this is a tricky bug to reproduce consistently. We've had reports of users running into this with OpenStack deployments and Windows Server guests, and the scenario is usually like this: 1) Deploy a 16vCPU Windows Server 2012 R2 guest with a virtio network interface 2) Stress the network interface with e.g. Windows HLK test suite or similar 3) Repeatedly attach/detach the network adapter that's in use It usually takes more than ~4000 attach/detach cycles to trigger the bug. [Regression Potential] - Regressions for this might arise from the fact that the fix changes RCU lock code. Since this patch has been upstream and in other series for a while, it's unlikely that it would regressions in RCU code specifically. Other code that makes use of the RCU locks (MMIO and some monitor events) will be thoroughly tested for any regressions with autokpkgtest and scripted Qemu runs. + Regressions for this might arise from the fact that the fix changes RCU lock code. Since this patch has been upstream and in other series for a while, it's unlikely that it would regressions in RCU code specifically. Other code that makes use of the RCU locks (MMIO and some monitor events) will be thoroughly tested for any regressions with use-case scenarios and scripted runs. ** Tags added: sts-sponsor -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1818880 Title: Deadlock when detaching network interface To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1818880/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1819046] [NEW] Systemd unit file reads settings from wrong path
Public bug reported:
[Impact]
Systemd Unit file doesn't read any settings by default
[Description]
The unit file shipped with the Xenial pacemaker package tries to read
environment settings from /etc/sysconfig/ instead of /etc/default/. The result
is that settings defined in /etc/default/pacemaker are not effective.
Since the /etc/default/pacemaker file is created with default values when the
pacemaker package is installed, we should source that in the systemd unit file.
[Test Case]
1) Deploy a Xenial container:
$ lxc launch ubuntu:xenial pacemaker
2) Update container and install pacemaker:
root@pacemaker:~# apt update && apt install pacemaker -y
3) Check the systemd unit file for the "EnvironmentFile" option:
root@pacemaker:~# systemctl cat pacemaker | grep EnvironmentFile
EnvironmentFile=-/etc/sysconfig/pacemaker
EnvironmentFile=-/etc/sysconfig/sbd
[Regression Potential]
The regression potential for this should be very low, since the configuration
file is already being created by default and other systemd unit files are using
the /etc/default config. In case the file doesn't exist or the user removed it,
the "-" prefix will gracefully ignore the missing file according to the
systemd.exec manual [0].
Nonetheless, the new package will be tested with autopkgtests and the fix will
be validated in a reproduction environment.
[0] https://www.freedesktop.org/software/systemd/man/systemd.exec.html
** Affects: pacemaker (Ubuntu)
Importance: Undecided
Assignee: Heitor R. Alves de Siqueira (halves)
Status: Fix Released
** Affects: pacemaker (Ubuntu Xenial)
Importance: Undecided
Assignee: Heitor R. Alves de Siqueira (halves)
Status: Confirmed
** Tags: sts
** Also affects: pacemaker (Ubuntu Xenial)
Importance: Undecided
Status: New
** Changed in: pacemaker (Ubuntu Xenial)
Status: New => Confirmed
** Changed in: pacemaker (Ubuntu)
Status: Confirmed => Fix Released
** Changed in: pacemaker (Ubuntu Xenial)
Assignee: (unassigned) => Heitor R. Alves de Siqueira (halves)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1819046
Title:
Systemd unit file reads settings from wrong path
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1819046/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1819046] Re: Systemd unit file reads settings from wrong path
** Changed in: pacemaker (Ubuntu) Assignee: Heitor R. Alves de Siqueira (halves) => (unassigned) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1819046 Title: Systemd unit file reads settings from wrong path To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1819046/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1818880] Re: Deadlock when detaching network interface
** Changed in: qemu (Ubuntu Disco) Assignee: Heitor R. Alves de Siqueira (halves) => (unassigned) ** Changed in: qemu (Ubuntu Cosmic) Assignee: Heitor R. Alves de Siqueira (halves) => (unassigned) ** Changed in: qemu (Ubuntu Bionic) Assignee: Heitor R. Alves de Siqueira (halves) => (unassigned) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1818880 Title: Deadlock when detaching network interface To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1818880/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1819046] Re: Systemd unit file reads settings from wrong path
** Tags added: sts-sponsor ** Patch added: "Debdiff for xenial" https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1819046/+attachment/5244550/+files/xenial.debdiff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1819046 Title: Systemd unit file reads settings from wrong path To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1819046/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1819046] Re: Systemd unit file reads settings from wrong path
** Description changed: [Impact] Systemd Unit file doesn't read any settings by default [Description] The unit file shipped with the Xenial pacemaker package tries to read environment settings from /etc/sysconfig/ instead of /etc/default/. The result is that settings defined in /etc/default/pacemaker are not effective. Since the /etc/default/pacemaker file is created with default values when the pacemaker package is installed, we should source that in the systemd unit file. [Test Case] 1) Deploy a Xenial container: - $ lxc launch ubuntu:xenial pacemaker + $ lxc launch ubuntu:xenial pacemaker 2) Update container and install pacemaker: - root@pacemaker:~# apt update && apt install pacemaker -y - 3) Check the systemd unit file for the "EnvironmentFile" option: - root@pacemaker:~# systemctl cat pacemaker | grep EnvironmentFile - EnvironmentFile=-/etc/sysconfig/pacemaker - EnvironmentFile=-/etc/sysconfig/sbd + root@pacemaker:~# apt update && apt install pacemaker -y + 3) Change default pacemaker log location: + root@pacemaker:~# echo "PCMK_logfile=/tmp/pacemaker.log" >> /etc/default/pacemaker + 4) Restart pacemaker service and verify that log file exists: + root@pacemaker:~# systemctl restart pacemaker.service + root@pacemaker:~# ls -l /tmp/pacemaker.log + ls: cannot access '/tmp/pacemaker.log': No such file or directory + + After fixing the systemd unit, changes to /etc/default/pacemaker get picked up correctly: + root@pacemaker:~# ls -l /tmp/pacemaker.log + -rw-rw 1 hacluster haclient 27335 Mar 7 20:46 /tmp/pacemaker.log + [Regression Potential] The regression potential for this should be very low, since the configuration file is already being created by default and other systemd unit files are using the /etc/default config. In case the file doesn't exist or the user removed it, the "-" prefix will gracefully ignore the missing file according to the systemd.exec manual [0]. Nonetheless, the new package will be tested with autopkgtests and the fix will be validated in a reproduction environment. [0] https://www.freedesktop.org/software/systemd/man/systemd.exec.html -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1819046 Title: Systemd unit file reads settings from wrong path To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1819046/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1819046] Re: Systemd unit file reads settings from wrong path
Patch v2: Instead of adding the /etc/default location, change all /etc/sysconfig files to their /etc/default counterpart since the sysconfig folder does not exist in Debian based distros. ** Patch added: "Debdiff for xenial v2" https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1819046/+attachment/5244565/+files/xenial_v2.debdiff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1819046 Title: Systemd unit file reads settings from wrong path To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pacemaker/+bug/1819046/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1818880] Re: Deadlock when detaching network interface
Patch v2: Added missing DEP3 info and corrected pkg version ** Patch added: "Debdiff for xenial v2" https://bugs.launchpad.net/cloud-archive/+bug/1818880/+attachment/5244567/+files/xenial_v2.debdiff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1818880 Title: Deadlock when detaching network interface To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1818880/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1818880] Re: Deadlock when detaching network interface
** Patch removed: "Debdiff for xenial v2" https://bugs.launchpad.net/cloud-archive/+bug/1818880/+attachment/5244567/+files/xenial_v2.debdiff ** Patch added: "Correct debdiff for xenial v2" https://bugs.launchpad.net/cloud-archive/+bug/1818880/+attachment/5244568/+files/lp1818880-v2.debdiff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1818880 Title: Deadlock when detaching network interface To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1818880/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1815129] [NEW] apt segfaults when generating cache file
Public bug reported: [Impact] apt crashes (core dump) during cache creation [Description] When executing apt-cache several times on a memory constrained system, apt-cache can sometimes crash with a core dump file. This is related to mmap() failing allocations during cache generation, according to an upstream bug report (803417). There is an upstream patch for this bug (6789e01e do not segfault in cache generation on mmap failure) and it's included in the apt package for other series (see below), so we only need to backport it to Trusty. Upstream commit: https://salsa.debian.org/apt- team/apt/commit/6789e01e9370b3b7f65d52138c5657eaa712b4d1 $ git describe --contains 6789e01e9370 1.1_exp16~5 $ rmadison apt apt | 1.0.1ubuntu2| trusty | source, amd64, arm64, armhf, i386, powerpc, ppc64el apt | 1.0.1ubuntu2.19 | trusty-security | source, amd64, arm64, armhf, i386, powerpc, ppc64el apt | 1.0.1ubuntu2.19 | trusty-updates | source, amd64, arm64, armhf, i386, powerpc, ppc64el apt | 1.2.10ubuntu1 | xenial | source, amd64, arm64, armhf, i386, powerpc, ppc64el, s390x apt | 1.6.1 | bionic | source, amd64, arm64, armhf, i386, ppc64el, s390x apt | 1.7.0 | cosmic | source, amd64, arm64, armhf, i386, ppc64el, s390x apt | 1.8.0~rc2 | disco| source, amd64, arm64, armhf, i386, ppc64el, s390x [Test Case] Unfortunately, this issue is not easy to reproduce. It seems to trigger randomly when "apt-cache policy" is called on a system under memory pressure, triggering the failure path in the mmap() allocations. [Regression Potential] The regression potential for this should be low, as it's a change in the failure path for memory allocations. This shouldn't be triggered during normal usage, and we'll thoroughly test the patched package with autopkgtests and perform scripted runs in memory-constrained systems with stress-ng. We also have a confirmation from an impacted user that the upstream patch fixes their issue without further problems. ** Affects: apt (Ubuntu) Importance: Undecided Status: New ** Affects: apt (Ubuntu Trusty) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1815129 Title: apt segfaults when generating cache file To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1815129/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1815129] Re: apt segfaults when generating cache file
** Description changed: [Impact] apt crashes (core dump) during cache creation [Description] When executing apt-cache several times on a memory constrained system, apt-cache can sometimes crash with a core dump file. This is related to mmap() failing allocations during cache generation, according to an upstream bug report (803417). There is an upstream patch for this bug (6789e01e do not segfault in cache generation on mmap failure) and it's included in the apt package for other series (see below), so we only need to backport it to Trusty. Upstream commit: https://salsa.debian.org/apt- team/apt/commit/6789e01e9370b3b7f65d52138c5657eaa712b4d1 $ git describe --contains 6789e01e9370 1.1_exp16~5 $ rmadison apt - apt | 1.0.1ubuntu2| trusty | source, amd64, arm64, armhf, i386, powerpc, ppc64el - apt | 1.0.1ubuntu2.19 | trusty-security | source, amd64, arm64, armhf, i386, powerpc, ppc64el - apt | 1.0.1ubuntu2.19 | trusty-updates | source, amd64, arm64, armhf, i386, powerpc, ppc64el - apt | 1.2.10ubuntu1 | xenial | source, amd64, arm64, armhf, i386, powerpc, ppc64el, s390x - apt | 1.6.1 | bionic | source, amd64, arm64, armhf, i386, ppc64el, s390x - apt | 1.7.0 | cosmic | source, amd64, arm64, armhf, i386, ppc64el, s390x - apt | 1.8.0~rc2 | disco| source, amd64, arm64, armhf, i386, ppc64el, s390x - + apt | 1.0.1ubuntu2| trusty | source, ... + apt | 1.0.1ubuntu2.19 | trusty-security | source, ... + apt | 1.0.1ubuntu2.19 | trusty-updates | source, ... + apt | 1.2.10ubuntu1 | xenial | source, ... + apt | 1.6.1 | bionic | source, ... + apt | 1.7.0 | cosmic | source, ... + apt | 1.8.0~rc2 | disco| source, ... [Test Case] - Unfortunately, this issue is not easy to reproduce. It seems to trigger randomly when "apt-cache policy" is called on a system under memory pressure, triggering the failure path in the mmap() allocations. + 1) Deploy a Trusty (14.04 LTS) vm w/ 128M + 2) Fetch latest stress-ng src code + 2.1) git clone git://kernel.ubuntu.com/cking/stress-ng + 2.2) cd stress-ng + 2.3) make clean + 2.4) make + 3) Stress the mmap() with stress-ng + 3.1) ./stress-ng --brk 2 --mmap 5 --vm 1 --mmap-bytes 90% + 4) Disable swap (if any) + 4.1) swapoff -a + 5) for i in `seq 1 1`;do apt-cache policy vsftpd;done + ... + vsftpd: + Installed: (none) + Candidate: 3.0.2-1ubuntu2.14.04.1 + Version table: + 3.0.2-1ubuntu2.14.04.1 0 + 500 http://us.archive.ubuntu.com/ubuntu/ trusty-updates/main amd64 Packages + 3.0.2-1ubuntu2 0 + 500 http://us.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages + Segmentation fault (core dumped) + Segmentation fault (core dumped) + Segmentation fault (core dumped) + Segmentation fault (core dumped) + Segmentation fault (core dumped) + Segmentation fault (core dumped) + ... [Regression Potential] The regression potential for this should be low, as it's a change in the failure path for memory allocations. This shouldn't be triggered during normal usage, and we'll thoroughly test the patched package with autopkgtests and perform scripted runs in memory-constrained systems with stress-ng. We also have a confirmation from an impacted user that the upstream patch fixes their issue without further problems. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1815129 Title: apt segfaults when generating cache file To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1815129/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1815501] [NEW] ixgbe: Kernel Oops when attempting to disable spoofchk in a non-existing VF
[ 241.078994] [] ? __alloc_pages_nodemask+0x1a3/0xb90
[ 241.079393] [] ? security_capable+0x1e/0x20
[ 241.079733] [] ? ns_capable+0x29/0x50
[ 241.080027] [] rtnetlink_rcv_msg+0x98/0x250
[ 241.080381] [] ? __kmalloc_node_track_caller+0x58/0x2b0
[ 241.080802] [] ? __alloc_skb+0x7e/0x2b0
[ 241.081121] [] ? rtnetlink_rcv+0x30/0x30
[ 241.081464] [] netlink_rcv_skb+0xab/0xc0
[ 241.081792] [] rtnetlink_rcv+0x28/0x30
[ 241.082118] [] netlink_unicast+0xe0/0x1b0
[ 241.082455] [] netlink_sendmsg+0x30e/0x680
[ 241.082801] [] sock_sendmsg+0x91/0xc0
[ 241.099175] [] ? __mem_cgroup_commit_charge+0x156/0x3d0
[ 241.115633] [] ? move_addr_to_kernel.part.14+0x1e/0x60
[ 241.132150] [] ? move_addr_to_kernel+0x21/0x30
[ 241.148222] [] ___sys_sendmsg+0x389/0x3a0
[ 241.163907] [] ? sock_destroy_inode+0x2f/0x40
[ 241.179322] [] ? __do_page_fault+0x214/0x570
[ 241.194220] [] ? dput+0xad/0x190
[ 241.209158] [] ? mntput+0x24/0x40
[ 241.223576] [] ? __fput+0x181/0x260
[ 241.237701] [] __sys_sendmsg+0x42/0x80
[ 241.251846] [] SyS_sendmsg+0x12/0x20
[ 241.265579] [] system_call_fastpath+0x26/0x2b
[ 241.278978] Code: 8d 0c 06 83 e1 07 29 c1 48 63 c6 c1 fe 03 4c 8d 04 80 8d
34 b5 00 82 00 00 4e 8d 0c 40 48 8b 87 90 85 00 00 48 63 f6 49 c1 e1 03 <42> 88
54 08 52 48 89 f0 48 03 87 80 16 00 00 8b 00 41 ba 01 00
[ 241.306211] RIP [] ixgbe_ndo_set_vf_spoofchk+0x3c/0xc0
[ixgbe]
[ 241.319310] RSP
[ 241.332404] CR2: fffa
[ 241.345011] ---[ end trace a45b72690a7e13be ]---
[Regression Potential]
The regression potential is low, since the fix is a simple check to confirm the
VF exists before doing any operations. This check is already implemented in
other functions of the ixgbe driver, and only the spoofchk function is missing
it. Nonetheless, the patch was tested in an impacted system and confirmed to
resolve the kernel oops without further problems.
** Affects: linux (Ubuntu)
Importance: Undecided
Status: Fix Released
** Attachment added: "Full dmesg output until kernel oops"
https://bugs.launchpad.net/bugs/1815501/+attachment/5237733/+files/dmesg.out
** Changed in: linux (Ubuntu)
Status: New => Incomplete
** Changed in: linux (Ubuntu)
Status: Incomplete => New
** Changed in: linux (Ubuntu)
Status: New => Fix Released
** Changed in: linux (Ubuntu)
Assignee: Heitor R. Alves de Siqueira (halves) => (unassigned)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1815501
Title:
ixgbe: Kernel Oops when attempting to disable spoofchk in a non-
existing VF
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1815501/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1815501] Re: ixgbe: Kernel Oops when attempting to disable spoofchk in a non-existing VF
SRU request sent to kernel-team mailing list: https://lists.ubuntu.com/archives/kernel-team/2019-February/098444.html -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1815501 Title: ixgbe: Kernel Oops when attempting to disable spoofchk in a non- existing VF To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1815501/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
