[Touch-packages] [Bug 2009502] Re: Enable /dev/sgx_vepc access for the group 'sgx'
Patch in question in Upstream is here [0]. [0] https://github.com/systemd/systemd/commit/b5d3138f9177bbc3505f42ba073d08d4f90b4888 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/2009502 Title: Enable /dev/sgx_vepc access for the group 'sgx' Status in systemd package in Ubuntu: New Bug description: [ Impact ] On systems where Intel SGX is available, access to a specific devide node (/dev/sgx_vepc) must be enforced, with a specific permission (0660) and group (sgx). This allows KVM-based virtual machines to use such feature (the SGX "enclaves") in a proper fashion. Without this, a manual udev rule needs to be created. [ Test Plan ] As the patch itself only tailors the permissions/group to the device node, in a system with Intel-SGX enabled, merely `ls -la` against the device node should show if the permissions and group are seen as expected. [ Where problems could occur ] N/A. This seems to be a very straightforward inclusion, very specific to access enablement to the SGX reserved memory used for hosting enclaves. [ Other Info ] N/A. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2009502/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2009502] [NEW] Enable /dev/sgx_vepc access for the group 'sgx'
Public bug reported: [ Impact ] On systems where Intel SGX is available, access to a specific devide node (/dev/sgx_vepc) must be enforced, with a specific permission (0660) and group (sgx). This allows KVM-based virtual machines to use such feature (the SGX "enclaves") in a proper fashion. Without this, a manual udev rule needs to be created. [ Test Plan ] As the patch itself only tailors the permissions/group to the device node, in a system with Intel-SGX enabled, merely `ls -la` against the device node should show if the permissions and group are seen as expected. [ Where problems could occur ] N/A. This seems to be a very straightforward inclusion, very specific to access enablement to the SGX reserved memory used for hosting enclaves. [ Other Info ] N/A. ** Affects: systemd (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/2009502 Title: Enable /dev/sgx_vepc access for the group 'sgx' Status in systemd package in Ubuntu: New Bug description: [ Impact ] On systems where Intel SGX is available, access to a specific devide node (/dev/sgx_vepc) must be enforced, with a specific permission (0660) and group (sgx). This allows KVM-based virtual machines to use such feature (the SGX "enclaves") in a proper fashion. Without this, a manual udev rule needs to be created. [ Test Plan ] As the patch itself only tailors the permissions/group to the device node, in a system with Intel-SGX enabled, merely `ls -la` against the device node should show if the permissions and group are seen as expected. [ Where problems could occur ] N/A. This seems to be a very straightforward inclusion, very specific to access enablement to the SGX reserved memory used for hosting enclaves. [ Other Info ] N/A. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2009502/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1972029] Re: dhclient overriding stub-resolv.conf file on Jammy
@vorlon, Upon installing the jammy-proposed version of the isc-dhcp-client on a Jammy instance (4.4.1-2.3ubuntu2.2), I am no longer able to reproduce the reported issue; running `dhclient` does not get the resolv.conf/stub-resolv.conf files overwritten. As of the reported regression, I did not find anything in the excuses page at all. Anyway, marking as complete from my side. Thanks! BR, pprincipeza ** Tags removed: verification-needed verification-needed-jammy ** Tags added: verification-done verification-done-jammy -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu. https://bugs.launchpad.net/bugs/1972029 Title: dhclient overriding stub-resolv.conf file on Jammy Status in isc-dhcp package in Ubuntu: Fix Released Status in isc-dhcp source package in Jammy: Fix Committed Status in isc-dhcp source package in Kinetic: Fix Released Bug description: [Issue] On Jammy, the stub-resolv.conf file on /run/systemd/resolve gets overwritten if dhclient is executed. While debugging this, I found the reference on LP#1889068 [0] of the move of `resolved` hook from dhclient-enter-hooks.d/ to dhclient-exit- hooks.d/, and this new hook [2] has no reference of make_resolv_conf() being called. [Reproducer] - I used a cloud-image based Jammy installation (uvt-kvm). Once in: $ cat /run/system/resolve/stub-resolv.conf And one will see: nameserver 127.0.0.53 options edns0 trust-ad search . Then: $ sudo dhclient $ cat /run/system/resolve/stub-resolv.conf You'll see the definition of the nameserver(s) in, and the stub IP address no longer there. To revert this, a `systemctl restart systemd-resolved` is needed. [Impact] This is an improper way to keep nameserver(s) in *resolv* files; the override of the file should never happen in these circumstances. [Extra] - As a minor test, I copied over the dhclient-enter-hooks.d/resolved file from a Focal installation to a Jammy one, and the problem _does not happen_ when such hook is in place. [ . . . ] Let me know if further clarification is needed to proceed. Thank you. BR, pprincipeza [0] https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1889068 [1] https://paste.ubuntu.com/p/bvqPZXZZ8w/ [2] https://paste.ubuntu.com/p/YQdG6z4WS7/ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1972029/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1972029] Re: dhclient overriding stub-resolv.conf file on Jammy
Hi, Lukas. Thank you very much for the reply, here. I tested the isc-dhcp-client in the mentioned PPA on a Kinetic uvt-kvm-based VM, and with it in place, I no longer see the stub-resolv.conf being overwritten whenever I run `sudo dhclient`. Indeed, I now see a `resolved-enter` enter-hook script disabling the make_resolv_conf() execution when sd-resolved is in. It works! Thanks again! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu. https://bugs.launchpad.net/bugs/1972029 Title: dhclient overriding stub-resolv.conf file on Jammy Status in isc-dhcp package in Ubuntu: Confirmed Status in isc-dhcp source package in Jammy: New Status in isc-dhcp source package in Kinetic: Confirmed Bug description: [Issue] On Jammy, the stub-resolv.conf file on /run/systemd/resolve gets overwritten if dhclient is executed. While debugging this, I found the reference on LP#1889068 [0] of the move of `resolved` hook from dhclient-enter-hooks.d/ to dhclient-exit- hooks.d/, and this new hook [2] has no reference of make_resolv_conf() being called. [Reproducer] - I used a cloud-image based Jammy installation (uvt-kvm). Once in: $ cat /run/system/resolve/stub-resolv.conf And one will see: nameserver 127.0.0.53 options edns0 trust-ad search . Then: $ sudo dhclient $ cat /run/system/resolve/stub-resolv.conf You'll see the definition of the nameserver(s) in, and the stub IP address no longer there. To revert this, a `systemctl restart systemd-resolved` is needed. [Impact] This is an improper way to keep nameserver(s) in *resolv* files; the override of the file should never happen in these circumstances. [Extra] - As a minor test, I copied over the dhclient-enter-hooks.d/resolved file from a Focal installation to a Jammy one, and the problem _does not happen_ when such hook is in place. [ . . . ] Let me know if further clarification is needed to proceed. Thank you. BR, pprincipeza [0] https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1889068 [1] https://paste.ubuntu.com/p/bvqPZXZZ8w/ [2] https://paste.ubuntu.com/p/YQdG6z4WS7/ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1972029/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1972029] [NEW] dhclient overriding stub-resolv.conf file on Jammy
Public bug reported: [Issue] On Jammy, the stub-resolv.conf file on /run/systemd/resolve gets overwritten if dhclient is executed. While debugging this, I found the reference on LP#1889068 [0] of the move of `resolved` hook from dhclient-enter-hooks.d/ to dhclient-exit- hooks.d/, and this new hook [2] has no reference of make_resolv_conf() being called. [Reproducer] - I used a cloud-image based Jammy installation (uvt-kvm). Once in: $ cat /run/system/resolve/stub-resolv.conf And one will see: nameserver 127.0.0.53 options edns0 trust-ad search . Then: $ sudo dhclient $ cat /run/system/resolve/stub-resolv.conf You'll see the definition of the nameserver(s) in, and the stub IP address no longer there. To revert this, a `systemctl restart systemd- resolved` is needed. [Impact] This is an improper way to keep nameserver(s) in *resolv* files; the override of the file should never happen in these circumstances. [Extra] - As a minor test, I copied over the dhclient-enter-hooks.d/resolved file from a Focal installation to a Jammy one, and the problem _does not happen_ when such hook is in place. [ . . . ] Let me know if further clarification is needed to proceed. Thank you. BR, pprincipeza [0] https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1889068 [1] https://paste.ubuntu.com/p/bvqPZXZZ8w/ [2] https://paste.ubuntu.com/p/YQdG6z4WS7/ ** Affects: isc-dhcp (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu. https://bugs.launchpad.net/bugs/1972029 Title: dhclient overriding stub-resolv.conf file on Jammy Status in isc-dhcp package in Ubuntu: New Bug description: [Issue] On Jammy, the stub-resolv.conf file on /run/systemd/resolve gets overwritten if dhclient is executed. While debugging this, I found the reference on LP#1889068 [0] of the move of `resolved` hook from dhclient-enter-hooks.d/ to dhclient-exit- hooks.d/, and this new hook [2] has no reference of make_resolv_conf() being called. [Reproducer] - I used a cloud-image based Jammy installation (uvt-kvm). Once in: $ cat /run/system/resolve/stub-resolv.conf And one will see: nameserver 127.0.0.53 options edns0 trust-ad search . Then: $ sudo dhclient $ cat /run/system/resolve/stub-resolv.conf You'll see the definition of the nameserver(s) in, and the stub IP address no longer there. To revert this, a `systemctl restart systemd-resolved` is needed. [Impact] This is an improper way to keep nameserver(s) in *resolv* files; the override of the file should never happen in these circumstances. [Extra] - As a minor test, I copied over the dhclient-enter-hooks.d/resolved file from a Focal installation to a Jammy one, and the problem _does not happen_ when such hook is in place. [ . . . ] Let me know if further clarification is needed to proceed. Thank you. BR, pprincipeza [0] https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1889068 [1] https://paste.ubuntu.com/p/bvqPZXZZ8w/ [2] https://paste.ubuntu.com/p/YQdG6z4WS7/ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1972029/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1871268] Re: Installation fails due to useless immediate configuration error when "Install Third-Party Drivers" is selected
Hi. Input from a customer: [ . . . ] I just tested a "do-release-upgrade" from bionic to focal and did not get any errors. I installed 18.04, installed the nvidia-driver-418 and enabled i386 arch. I then enable the bionic-proposed repo and did an update/dist-upgrade, rebooted, and did a do-release-upgrade with no errors. [ . . . ] Changing tags. Thanks! ** Tags removed: verification-needed-bionic ** Tags added: verification-done-bionic -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1871268 Title: Installation fails due to useless immediate configuration error when "Install Third-Party Drivers" is selected Status in Ubuntu CD Images: Fix Released Status in apt package in Ubuntu: Fix Released Status in apt source package in Bionic: Fix Committed Status in apt source package in Focal: Fix Released Status in apt source package in Groovy: Fix Released Status in apt package in Debian: Fix Released Bug description: [Impact] Installations that really succeeded would then fail because APT could not immediately configure a package. Which is a pointless way to fail at that point, because everything did work out anyway. We have two changes that help address this: * The first one stops immediately configuring multi-arch siblings (e.g. libc6:i386 when it's configuring libc6:amd64). This was not necessary, and caused all the libc6:i386 failures here. * The second change sort of also supersedes the first one: It just ignores any errors from immediate configuration, relying on the fact that it's checked and rectified at a later point if there are unconfigured packages (which is what made all those failures happen spuriously after having successfully installed everything). [Test case] We have one test case in EIPP format in the Debian bug 973305 which was only helped by the second change, not the first one. Run /usr/lib/apt/planners < eipp.log and check there are no errors. TODO: It's unclear if the APT from proposed installed in the live session will fix the installer, needs investigation, but would make a useful test case. [Regression potential] It's imaginable that we missed something somewhere and some path that checked for a set error doesn't check it anymore, and we report success when we hit an error, but it seems unlikely. Behavior of --simulate changes. This used to fail before as well, and will now only produce a warning. We don't believe that is a reason of concern. [Groovy SRU] The groovy SRU is a sync of the 2.1.11 micro release from Debian unstable which also incorporates changes to the documentation: A typo fix, replacing focal with groovy in examples, and minor Dutch manual pages translation updates. We do not have test cases for the documentation changes, and we do not consider there to be a huge regression potential. As long as they build, they should be readable - maybe some words are wrong in the translation, who knows. [Original bug report] Test Case 1. Install Ubuntu Desktop on hardware with an nVidia card and select to install 3rd party drivers 2. Proceed with installation The following error message is displayed in /var/log/syslog /plugininstall.py: Verifying downloads ... /plugininstall.py: Failed to find package object for /cdrom//pool/main/g/gcc-defaults/gcc_9.3.0-1ubuntu2_amd64.deb: "Version: '9.3.0-1ubuntu2' not found." /plugininstall.py: Failed to find package object for /cdrom//pool/main/libx/libxcrypt/libcrypt-dev_4.4.10-10ubuntu4_amd64.deb: "Version: '4.4.10-10ubuntu4' not found." /plugininstall.py: Failed to find package object for /cdrom//pool/main/g/gcc-defaults/g++_9.3.0-1ubuntu2_amd64.deb: "Version: '9.3.0-1ubuntu2' not found." /plugininstall.py: Failed to find package object for /cdrom//pool/main/z/zlib/zlib1g_1.2.11.dfsg-2ubuntu1_i386.deb: "Version: '1.2.11.dfsg-2ubuntu1' not found." /plugininstall.py: Failed to find package object for /cdrom//pool/main/libx/libxau/libxau6_1.0.9-0ubuntu1_i386.deb: "Version: '1.0.9-0ubuntu1' not found." /plugininstall.py: Failed to find package object for /cdrom//pool/main/libx/libxdmcp/libxdmcp6_1.1.3-0ubuntu1_i386.deb: "Version: '1.1.3-0ubuntu1' not found." /plugininstall.py: Failed to find package object for /cdrom//pool/main/libx/libx11/libx11-6_1.6.9-2ubuntu1_i386.deb: "Version: '1.6.9-2ubuntu1' not found." /plugininstall.py: Failed to find package object for /cdrom//pool/main/libx/libxext/libxext6_1.3.4-0ubuntu1_i386.deb: "Version: '1.3.4-0ubuntu1' not found." /plugininstall.py: Failed to find package object for /cdrom//pool/main/l/lm-sensors/libsensors5_3.6.0-2ubuntu1_i386.deb: "Version: '3.6.0-2ubuntu1' not found." /plugininstall.py: Failed to find package object for /cdrom//pool/main/libx/libx11/libx11-xcb1_1.6.9-2ubuntu1_i386.deb: "Version: '1.6.9-2ubuntu1' not found."
[Touch-packages] [Bug 1848330] Re: Installing auditd sometimes fails in post-inst
Hi, all.
I obtained feedback from one Canonical customer (with a Support Case
opened just for that), that hit the very same bug and, when testing the
package sitting in -proposed, didn't reproduce the issue anymore.
>From his own words:
"I wasn't able to recreate the auditd problem with the updated auditd
package from proposed. Once we have the release package we can test
that in the production environment."
Thanks!
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to audit in Ubuntu.
https://bugs.launchpad.net/bugs/1848330
Title:
Installing auditd sometimes fails in post-inst
Status in audit package in Ubuntu:
Fix Released
Status in audit source package in Bionic:
Fix Committed
Status in audit package in Debian:
New
Bug description:
[Impact]
Sometimes, auditd will get stuck when starting up, causing systemd to
kill it after a while since it (systemd) never got the start
notification.
Upstream troubleshooted this to be caused by calling a syslog()
function inside a signal handler.
[Test Case]
There is no reliable test case to reproduce the bug, other than trying the
fixed packages on an affected system where the hang occurs more frequently.
Basically:
sudo systemctl stop auditd
sudo systemctl start auditd
should work reliably. Do not run that in a tight loop, however, as
that will trigger a it's-restarting-too-frequently failure.
[Where problems could occur]
- if auditd fails to start, then the first fallback is syslog, and if that is
not picking up the audit messages, the last resort is the kernel buffer, which
can fill up. In the case it fills up, audit logs will be lost.
- it's possible to configure the audit system to panic() the machine
if audit messages are lost or otherwise not able to be recorded
(auditctl -f 2; default is 1 which is printk())
- the update restarts auditd as expected. Misconfiguration on very
very busy systems could mean that audit logs would be lost during the
brief moment the service is restarted. If that's the case, this update
would just be one more way to trigger it, but not be the root cause of
the problem
- similarly, as is usual with updates that restart services, it's
possible than an incorrect configuration for auditd is present, but
was never loaded before. The restart will load the config, and will
fail in such a case.
- this update removes a logging statement that occurs during startup:
("dispatcher %d reaped", pid)
It's unlikely, but possible, that some monitoring software could be
looking for that message in the logs. It won't be there anymore after
this update.
[Other Info]
The patch is committed upstream and part of the 2.8.5 release, which is
present in Focal and later.
The real fix for this bug is just dropping the audit_msg() call in the signal
handler code. But the original reporter of the bug, who is also who came up
with the fix (see https://bugzilla.redhat.com/show_bug.cgi?id=1587995#c4)
stated that with the 3 changes in the patch the startup hang didn't happen to
him anymore. Since this bug is difficult to reproduce elsewhere (either you
have it, or you don't), I chose to keep the 3 changes instead of just the
removal of the audit_msg() call.
[Original Description]
This happens sometimes when installing auditd on Ubuntu 18.04.2, most
installations work successfully, though. Re-running the install also
fixes the issue, but the failure breaks our automation. The log from
the failure looks like this:
# apt install auditd
...
Setting up auditd (1:2.8.2-1ubuntu1) ...
Created symlink /etc/systemd/system/multi-user.target.wants/auditd.service →
/lib/systemd/system/auditd.service.
Job for auditd.service failed because a timeout was exceeded.
See "systemctl status auditd.service" and "journalctl -xe" for details.
invoke-rc.d: initscript auditd, action "start" failed.
● auditd.service - Security Auditing Service
Loaded: loaded (/lib/systemd/system/auditd.service; enabled; vendor
preset: enabled)
Active: failed (Result: timeout) since Tue 2019-09-17 18:43:06 UTC; 11ms
ago
Docs: man:auditd(8)
https://github.com/linux-audit/audit-documentation
Process: 9702 ExecStart=/sbin/auditd (code=killed, signal=KILL)
Sep 17 18:40:06 compute-node21 systemd[1]: Starting Security Auditing
Service...
Sep 17 18:40:06 compute-node21 auditd[9703]: Started dispatcher:
/sbin/audispd pid: 9705
Sep 17 18:40:06 compute-node21 audispd[9705]: No plugins found, exiting
Sep 17 18:41:36 compute-node21 systemd[1]: auditd.service: Start operation
timed out. Terminating.
Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: State
'stop-sigterm' timed out. Killing.
Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Killing process
9702 (auditd) with signal SIGKILL.
Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service:
[Touch-packages] [Bug 1794478] Re: Automatic ipv4 not assigned to bond interface is manual ipv6 is assigned to it
Changed the status to New, since I was still able to reproduce the issue on Bionic, using the "patched" network-manager version. ** Changed in: network-manager (Ubuntu) Status: Fix Released => New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1794478 Title: Automatic ipv4 not assigned to bond interface is manual ipv6 is assigned to it Status in Ubuntu on IBM z Systems: Fix Released Status in network-manager package in Ubuntu: New Status in network-manager source package in Bionic: Fix Released Bug description: ---Problem Description--- Bond interface with automatic ipv4 mode and manual ipv6 mode fails to get automatic ipv4 assigned from dhcp server. ---uname output--- Linux NetworkTest 4.15.0-33-generic #36-Ubuntu SMP Wed Aug 15 13:42:17 UTC 2018 s390x s390x s390x GNU/Linux Machine Type = s390x ---Debugger--- A debugger is not configured ---Steps to Reproduce--- When user configures ipv4 as automatic and ipv6 as manual for bond interface automatic ipv4 is not getting assigned. Looks like dhcp client request for ipv4 is not done to dhcp server after maunal ipv6 is assigned quickly to bond interface This issue will not happen in below cases: 1)with ipv4 automatic and ipv6 manual configuration for ethernet or vlan interface. 2)with ipv4 automatic and ipv6 automatic configuration for bond interface 3)with ipv4 automatic and ipv6 disabled configuration for bond interface Configuration: Bond interface, ipv4 automatic mode and ipv6 automatic mode root@NetworkTest:/etc/NetworkManager/system-connections# cat test_bond [connection] id=test_bond uuid=63e54542-5135-47ac-a954-b861c3937be2 type=bond interface-name=test_bond permissions= timestamp=1537944121 [ethernet] mac-address-blacklist= [bond] downdelay=0 fail_over_mac=none miimon=100 mode=active-backup num_grat_arp=0 primary_reselect=always updelay=0 [ipv4] dns-search= method=auto [ipv6] addr-gen-mode=stable-privacy dns-search= method=auto From /var/log/syslog, we can see ip got assigned: Sep 26 06:26:26 NetworkTest dhclient[8663]: DHCPDISCOVER on test_bond to 255.255.255.255 port 67 interval 3 (xid=0x5e04bf1e) Sep 26 06:26:26 NetworkTest dhclient[8663]: DHCPREQUEST of 10.2.3.55 on test_bond to 255.255.255.255 port 67 (xid=0x5e04bf1e) Sep 26 06:26:26 NetworkTest dhclient[8663]: DHCPOFFER of 10.2.3.55 from 10.2.3.1 Sep 26 06:26:26 NetworkTest dhclient[8663]: DHCPACK of 10.2.3.55 from 10.2.3.1 root@NetworkTest:/etc/NetworkManager/system-connections# ip a s test_bond 28: test_bond: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 02:00:00:b3:b5:22 brd ff:ff:ff:ff:ff:ff inet 10.2.3.55/24 brd 10.2.3.255 scope global dynamic noprefixroute test_bond valid_lft 353sec preferred_lft 353sec inet6 fe80::ff:feb3:b522/64 scope link valid_lft forever preferred_lft forever +++ Bond interface, ipv4 automatic mode and ipv6 manual mode root@NetworkTest:/etc/NetworkManager/system-connections# cat test_bond [connection] id=test_bond uuid=3efb153a-a6e4-48fb-aa04-f0b8cb549bab type=bond interface-name=test_bond permissions= timestamp=1537943300 [ethernet] mac-address-blacklist= [bond] downdelay=0 fail_over_mac=none miimon=100 mode=active-backup num_grat_arp=0 primary_reselect=always updelay=0 [ipv4] dns-search= method=auto [ipv6] addr-gen-mode=stable-privacy address1=fe81::32a5:bc5f:287f:8db8/64 dns-search= method=manual No automatic ip assigned to ipv4 and no requests to dhcp server seen in /var/log/syslog root@NetworkTest:/etc/NetworkManager/system-connections# ip a s test_bond 29: test_bond: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 02:00:00:b3:b5:22 brd ff:ff:ff:ff:ff:ff inet6 fe81::32a5:bc5f:287f:8db8/64 scope link noprefixroute valid_lft forever preferred_lft forever ==> Correct LP-Package need to be assigned...! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1794478/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1794478] Re: Automatic ipv4 not assigned to bond interface is manual ipv6 is assigned to it
Hi, all. I'm afraid I'll need to reopen this bug. I was able to reproduce the issue on Bionic, using network-manager 1.10.6-2ubuntu1.2. However, when testing this on Eoan, using network- manager 1.20.4-2ubuntu2, I didn't reproduce the behaviour. The steps one takes to reproduce the issue, either on a s390 system or x86 (the issue is reproducible regardless of the platform) is: 1.) Create the bond interface with: nmcli conn add type bond con-name ifname ipv4.method disabled ipv6.method ignore 2.) Modify it to so set a manual IPv6 Address and auto-assign IPv4: nmcli c m bond.options " mode=active-backup, downdelay=0 , miimon=100 , updelay=0 , fail_over_mac=none , num_grat_arp=0 , primary_reselect=always " connection.interface-name ipv4.method auto ipv4.gateway "" ipv6.method manual 802-3-ethernet.mac-address "" ipv4.routes "" connection.id ipv6.never-default no ipv4.addresses "" ipv6.addresses 3.) Add the two slave ethernet devices, and change them with: nmcli c m connection.id connection .interface-name 802-3-ethernet.s390-subchannels 802-3-ethernet.s390-nettype qeth connection.autoconnect yes 802-3-ethernet.mac-address "" ipv4.method disabled ipv6.method ignore 802-3-ethernet.s390-options portno= ^ For repro steps on amd64 or ppc64, the s390-* parameters can be removed from the command. 4.) Add the two slave ethernet devices to the bond: nmcli c m 802-3-ethernet.mac-address "" connection.master connection.slave-type bond [ . . . ] You'll see that, on Bionic, the bond interface isn't assigned an IPv4 address. On Eoan, an IPv4 address is assigned as expected. I have reviewed network-manager's changelog [1], but I didn't find any smoking guns that could've solved the issue, hence the re-opening of the bug. Let me know if further evidence is needed to proceed. Thanks! [1] https://changelogs.ubuntu.com/changelogs/pool/main/n/network-manager /network-manager_1.20.4-2ubuntu2/changelog -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1794478 Title: Automatic ipv4 not assigned to bond interface is manual ipv6 is assigned to it Status in Ubuntu on IBM z Systems: Fix Released Status in network-manager package in Ubuntu: Fix Released Status in network-manager source package in Bionic: Fix Released Bug description: ---Problem Description--- Bond interface with automatic ipv4 mode and manual ipv6 mode fails to get automatic ipv4 assigned from dhcp server. ---uname output--- Linux NetworkTest 4.15.0-33-generic #36-Ubuntu SMP Wed Aug 15 13:42:17 UTC 2018 s390x s390x s390x GNU/Linux Machine Type = s390x ---Debugger--- A debugger is not configured ---Steps to Reproduce--- When user configures ipv4 as automatic and ipv6 as manual for bond interface automatic ipv4 is not getting assigned. Looks like dhcp client request for ipv4 is not done to dhcp server after maunal ipv6 is assigned quickly to bond interface This issue will not happen in below cases: 1)with ipv4 automatic and ipv6 manual configuration for ethernet or vlan interface. 2)with ipv4 automatic and ipv6 automatic configuration for bond interface 3)with ipv4 automatic and ipv6 disabled configuration for bond interface Configuration: Bond interface, ipv4 automatic mode and ipv6 automatic mode root@NetworkTest:/etc/NetworkManager/system-connections# cat test_bond [connection] id=test_bond uuid=63e54542-5135-47ac-a954-b861c3937be2 type=bond interface-name=test_bond permissions= timestamp=1537944121 [ethernet] mac-address-blacklist= [bond] downdelay=0 fail_over_mac=none miimon=100 mode=active-backup num_grat_arp=0 primary_reselect=always updelay=0 [ipv4] dns-search= method=auto [ipv6] addr-gen-mode=stable-privacy dns-search= method=auto From /var/log/syslog, we can see ip got assigned: Sep 26 06:26:26 NetworkTest dhclient[8663]: DHCPDISCOVER on test_bond to 255.255.255.255 port 67 interval 3 (xid=0x5e04bf1e) Sep 26 06:26:26 NetworkTest dhclient[8663]: DHCPREQUEST of 10.2.3.55 on test_bond to 255.255.255.255 port 67 (xid=0x5e04bf1e) Sep 26 06:26:26 NetworkTest dhclient[8663]: DHCPOFFER of 10.2.3.55 from 10.2.3.1 Sep 26 06:26:26 NetworkTest dhclient[8663]: DHCPACK of 10.2.3.55 from 10.2.3.1 root@NetworkTest:/etc/NetworkManager/system-connections# ip a s test_bond 28: test_bond: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 02:00:00:b3:b5:22 brd ff:ff:ff:ff:ff:ff inet 10.2.3.55/24 brd 10.2.3.255 scope global dynamic noprefixroute test_bond valid_lft 353sec preferred_lft 353sec inet6 fe80::ff:feb3:b522/64 scope link valid_lft forever preferred_lft forever +++ Bond
[Touch-packages] [Bug 1839329] [NEW] pgrep: Use POSIX _SC_ARG_MAX for maximum pgrep -f command line length
Public bug reported: [Impact] The pgrep -f and pkill -f commands are unable to find processes strings in processes which are beyond the 4096th character. This often happens with Java command lines with long classpaths on the command line. [Test Case] A quick test to reproduce this is to vi a file using a filename over 4k (e.g. vi $(seq 1 1250| paste -s -d'_')_foo.txt) and leave vi running; then try running pgrep -af 'foo.txt' to find it. [Potential Regression[ [Other Infos] This bug is a mirror of what has already been reported in GitLab, through the merge request #85 [1], and has been previously reported at the merge request #80 [2], with no response/reply. Let me know if further information is needed, at this point, to proceed. Thanks! [1] https://gitlab.com/procps-ng/procps/merge_requests/85 [2] https://gitlab.com/procps-ng/procps/merge_requests/80 ** Affects: procps (Ubuntu) Importance: Low Assignee: Eric Desrochers (slashd) Status: In Progress ** Affects: procps (Ubuntu Xenial) Importance: Undecided Status: New ** Affects: procps (Ubuntu Bionic) Importance: Undecided Status: New ** Affects: procps (Ubuntu Disco) Importance: Undecided Status: New ** Tags: sts -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to procps in Ubuntu. https://bugs.launchpad.net/bugs/1839329 Title: pgrep: Use POSIX _SC_ARG_MAX for maximum pgrep -f command line length Status in procps package in Ubuntu: In Progress Status in procps source package in Xenial: New Status in procps source package in Bionic: New Status in procps source package in Disco: New Bug description: [Impact] The pgrep -f and pkill -f commands are unable to find processes strings in processes which are beyond the 4096th character. This often happens with Java command lines with long classpaths on the command line. [Test Case] A quick test to reproduce this is to vi a file using a filename over 4k (e.g. vi $(seq 1 1250| paste -s -d'_')_foo.txt) and leave vi running; then try running pgrep -af 'foo.txt' to find it. [Potential Regression[ [Other Infos] This bug is a mirror of what has already been reported in GitLab, through the merge request #85 [1], and has been previously reported at the merge request #80 [2], with no response/reply. Let me know if further information is needed, at this point, to proceed. Thanks! [1] https://gitlab.com/procps-ng/procps/merge_requests/85 [2] https://gitlab.com/procps-ng/procps/merge_requests/80 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1839329/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
