[Touch-packages] [Bug 1931104] Re: Test of dogtag-pki is failing on s390x vs the nss v3.63 in impish-proposed
I tracked the problem down to the LTO optimizations that were enabled by
default in dpkg 1.20.9ubuntu1.
** Changed in: nss (Ubuntu)
Status: New => Triaged
** Tags added: lto
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to nss in Ubuntu.
https://bugs.launchpad.net/bugs/1931104
Title:
Test of dogtag-pki is failing on s390x vs the nss v3.63 in impish-
proposed
Status in nss package in Ubuntu:
Triaged
Bug description:
The test of dogtag-pki is failing on the nss 3.63 that is in impish proposed.
Example:
https://autopkgtest.ubuntu.com/results/autopkgtest-impish/impish/s390x/d/dogtag-pki/20210516_212719_e6522@/log.gz
Bad:
Installing CA into /var/lib/pki/pki-tomcat.
Installation failed: ('Connection aborted.', RemoteDisconnected('Remote end
closed connection without response'))
ERROR: ConnectionError: ('Connection aborted.', RemoteDisconnected('Remote
end closed connection without response'))
File "/usr/lib/python3/dist-packages/pki/server/pkispawn.py", line 575, in
main
scriptlet.spawn(deployer)
File
"/usr/lib/python3/dist-packages/pki/server/deployment/scriptlets/configuration.py",
line 995, in spawn
cert = deployer.setup_cert(client, tag)
File "/usr/lib/python3/dist-packages/pki/server/deployment/__init__.py",
line 355, in setup_cert
return client.setupCert(request)
File "/usr/lib/python3/dist-packages/pki/system.py", line 389, in setupCert
response = self.connection.post(
File "/usr/lib/python3/dist-packages/pki/client.py", line 55, in wrapper
return func(self, *args, **kwargs)
File "/usr/lib/python3/dist-packages/pki/client.py", line 293, in post
r = self.session.post(
File "/usr/lib/python3/dist-packages/requests/sessions.py", line 590, in
post
return self.request('POST', url, data=data, json=json, **kwargs)
File "/usr/lib/python3/dist-packages/requests/sessions.py", line 542, in
request
resp = self.send(prep, **send_kwargs)
File "/usr/lib/python3/dist-packages/requests/sessions.py", line 655, in
send
r = adapter.send(request, **kwargs)
File "/usr/lib/python3/dist-packages/requests/adapters.py", line 498, in
send
raise ConnectionError(err, request=request)
CA spawn failed:
Good:
nstalling CA into /var/lib/pki/pki-tomcat.
Notice: Trust flag u is set automatically if the private key is present.
/usr/lib/python3/dist-packages/urllib3/connection.py:455:
SubjectAltNameWarning: Certificate for i-dogtag has no `subjectAltName`,
falling back to check for a `commonName` for now. This feature is being removed
by major browsers and deprecated by RFC 2818. (See
https://github.com/urllib3/urllib3/issues/497 for details.)
warnings.warn(
==
INSTALLATION SUMMARY
==
...
The good test above was with:
ii libnss3:s390x2:3.61-1ubuntu2 s390xNetwork Security
Service libraries
ii 389-ds-base1.4.4.11-2 s390x389 Directory Server suite -
server
Worth to know, the good case test still fails later on with:
IOException: SocketException cannot write on socket: Failed to write to
socket: (-5938) Encountered end of file.
ERROR: CalledProcessError: Command '['pki', '-d',
'/etc/pki/pki-tomcat/alias', '-f', '/etc/pki/pki-tomcat/password.conf', '-U',
'https://i-dogtag:8443', 'securitydomain-join', '--session',
'4717921475119312283', '--type', 'TKS', '--hostname', 'i-dogtag',
'--unsecure-port', '8080', '--secure-port', '8443', 'TKS i-dogtag 8443']'
returned non-zero exit status 255.
File "/usr/lib/python3/dist-packages/pki/server/pkispawn.py", line 575, in
main
scriptlet.spawn(deployer)
File
"/usr/lib/python3/dist-packages/pki/server/deployment/scriptlets/configuration.py",
line 1038, in spawn
subsystem.join_security_domain(
File "/usr/lib/python3/dist-packages/pki/server/subsystem.py", line 1201,
in join_security_domain
subprocess.check_call(cmd)
File "/usr/lib/python3.9/subprocess.py", line 373, in check_call
raise CalledProcessError(retcode, cmd)
Installation failed: Command failed: pki -d /etc/pki/pki-tomcat/alias -f
/etc/pki/pki-tomcat/password.conf -U https://i-dogtag:8443 securitydomain-join
--session 4717921475119312283 --type TKS --hostname i-dogtag --unsecure-port
8080 --secure-port 8443 TKS i-dogtag 8443
Please check pkispawn logs in /var/log/pki/pki-tks-spawn.20210607093926.log
Well one issue at a time ... the current install issue first.
Since it worked with the nss in -release I was upgrading this to the new nss.
ii 389-ds-base1.4.4.11-2 s390x389 Directory Server suite -
server
ii libnss3:s390x 2:3.63-1ubuntu1 s390xNetwork Security Service
libraries
With t
[Touch-packages] [Bug 1934147] Re: systemd leaks abandoned session scopes
This systemd bug can be problematic for snapd as well, leading to the
sort of situation in https://bugs.launchpad.net/snapd/+bug/1928806,
where running snap commands frequently leads to many many many leftover
scopes like this
** Also affects: snapd
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/1934147
Title:
systemd leaks abandoned session scopes
Status in snapd:
New
Status in systemd:
New
Status in systemd package in Ubuntu:
In Progress
Status in systemd source package in Bionic:
Confirmed
Status in systemd source package in Focal:
In Progress
Status in systemd source package in Groovy:
In Progress
Status in systemd source package in Hirsute:
In Progress
Status in systemd source package in Impish:
In Progress
Bug description:
[impact]
systemd may leak sessions, leaving empty cgroups around as well as
abandoned session scopes.
[test case]
on a system where the user has a ssh key that allows noninteractive
login to localhost, and also has noninteractive sudo, run:
$ for i in {1..100}; do sudo -b -i -u ubuntu ssh localhost -- sleep 1;
done; for i in {1..20}; do echo 'Reloading...'; sudo systemctl daemon-
reload; done
check the sessions to see there have been leaked sessions:
$ loginctl list-sessions
SESSION UID USER SEAT TTY
1 1000 ubuntu ttyS0
350 1000 ubuntu
351 1000 ubuntu
360 1000 ubuntu
...
to verify the sessions were leaked, clear them out with:
$ echo '' | sudo tee
/sys/fs/cgroup/unified/user.slice/user-1000.slice/session-*.scope/cgroup.events
that should result in all the leaked sessions being cleaned up.
[regression potential]
issues during systemd pid1 reexec/reload, or issues while cleaning up
sessions, including leaking sessions/cgroups
[scope]
this is needed for all releases
upstream bug linked above, and upstream PR:
https://github.com/systemd/systemd/pull/20199
[original description]
On a system that is monitored via telegraf I found many abandoned
systemd session which I believe are created by a potential race where
systemd is reloading unit files and at the same time a user is
connecting to the system via ssh or is executing the su command.
The simple reproducer
$ for i in {1..100}; do sleep 0.2; ssh localhost sudo systemctl
daemon-reload & ssh localhost sleep 1 & done
Wait > 1 second
$ jobs -p | xargs --verbose --no-run-if-empty kill -KILL
To clean out STOPPED jobs and
$ systemctl status --all 2> /dev/null | grep --before-context 3
abandoned
will produce something similar to
│ ├─ 175 su - ubuntu
│ ├─ 178 -su
│ ├─62375 systemctl status --all
│ └─62376 grep --color=auto --before-context 3 abandoned
--
● session-273.scope - Session 273 of user ubuntu
Loaded: loaded (/run/systemd/transient/session-273.scope; transient)
Transient: yes
Active: active (abandoned) since Wed 2021-06-30 13:32:03 UTC; 4min 7s ago
--
● session-274.scope - Session 274 of user ubuntu
Loaded: loaded (/run/systemd/transient/session-274.scope; transient)
Transient: yes
Active: active (abandoned) since Wed 2021-06-30 13:32:03 UTC; 4min 7s ago
--
● session-30.scope - Session 30 of user ubuntu
Loaded: loaded (/run/systemd/transient/session-30.scope; transient)
Transient: yes
Active: active (abandoned) since Wed 2021-06-30 10:05:56 UTC; 3h 30min ago
--
● session-302.scope - Session 302 of user ubuntu
Loaded: loaded (/run/systemd/transient/session-302.scope; transient)
Transient: yes
Active: active (abandoned) since Wed 2021-06-30 13:32:04 UTC; 4min 6s ago
--
│ ├─ 175 su - ubuntu
│ ├─ 178 -su
│ ├─62375 systemctl status --all
│ └─62376 grep --color=auto --before-context 3 abandoned
The system in question is running Bionic, systemd-237-3ubuntu10.48
To manage notifications about this bug go to:
https://bugs.launchpad.net/snapd/+bug/1934147/+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 1934147] Re: systemd leaks abandoned session scopes
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: systemd (Ubuntu Bionic)
Status: New => Confirmed
--
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/1934147
Title:
systemd leaks abandoned session scopes
Status in snapd:
New
Status in systemd:
New
Status in systemd package in Ubuntu:
In Progress
Status in systemd source package in Bionic:
Confirmed
Status in systemd source package in Focal:
In Progress
Status in systemd source package in Groovy:
In Progress
Status in systemd source package in Hirsute:
In Progress
Status in systemd source package in Impish:
In Progress
Bug description:
[impact]
systemd may leak sessions, leaving empty cgroups around as well as
abandoned session scopes.
[test case]
on a system where the user has a ssh key that allows noninteractive
login to localhost, and also has noninteractive sudo, run:
$ for i in {1..100}; do sudo -b -i -u ubuntu ssh localhost -- sleep 1;
done; for i in {1..20}; do echo 'Reloading...'; sudo systemctl daemon-
reload; done
check the sessions to see there have been leaked sessions:
$ loginctl list-sessions
SESSION UID USER SEAT TTY
1 1000 ubuntu ttyS0
350 1000 ubuntu
351 1000 ubuntu
360 1000 ubuntu
...
to verify the sessions were leaked, clear them out with:
$ echo '' | sudo tee
/sys/fs/cgroup/unified/user.slice/user-1000.slice/session-*.scope/cgroup.events
that should result in all the leaked sessions being cleaned up.
[regression potential]
issues during systemd pid1 reexec/reload, or issues while cleaning up
sessions, including leaking sessions/cgroups
[scope]
this is needed for all releases
upstream bug linked above, and upstream PR:
https://github.com/systemd/systemd/pull/20199
[original description]
On a system that is monitored via telegraf I found many abandoned
systemd session which I believe are created by a potential race where
systemd is reloading unit files and at the same time a user is
connecting to the system via ssh or is executing the su command.
The simple reproducer
$ for i in {1..100}; do sleep 0.2; ssh localhost sudo systemctl
daemon-reload & ssh localhost sleep 1 & done
Wait > 1 second
$ jobs -p | xargs --verbose --no-run-if-empty kill -KILL
To clean out STOPPED jobs and
$ systemctl status --all 2> /dev/null | grep --before-context 3
abandoned
will produce something similar to
│ ├─ 175 su - ubuntu
│ ├─ 178 -su
│ ├─62375 systemctl status --all
│ └─62376 grep --color=auto --before-context 3 abandoned
--
● session-273.scope - Session 273 of user ubuntu
Loaded: loaded (/run/systemd/transient/session-273.scope; transient)
Transient: yes
Active: active (abandoned) since Wed 2021-06-30 13:32:03 UTC; 4min 7s ago
--
● session-274.scope - Session 274 of user ubuntu
Loaded: loaded (/run/systemd/transient/session-274.scope; transient)
Transient: yes
Active: active (abandoned) since Wed 2021-06-30 13:32:03 UTC; 4min 7s ago
--
● session-30.scope - Session 30 of user ubuntu
Loaded: loaded (/run/systemd/transient/session-30.scope; transient)
Transient: yes
Active: active (abandoned) since Wed 2021-06-30 10:05:56 UTC; 3h 30min ago
--
● session-302.scope - Session 302 of user ubuntu
Loaded: loaded (/run/systemd/transient/session-302.scope; transient)
Transient: yes
Active: active (abandoned) since Wed 2021-06-30 13:32:04 UTC; 4min 6s ago
--
│ ├─ 175 su - ubuntu
│ ├─ 178 -su
│ ├─62375 systemctl status --all
│ └─62376 grep --color=auto --before-context 3 abandoned
The system in question is running Bionic, systemd-237-3ubuntu10.48
To manage notifications about this bug go to:
https://bugs.launchpad.net/snapd/+bug/1934147/+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 1930738] Re: network configuration failed on reboot
** Description changed: + [impact] + + number of statically defined addresses for an interface in systemd- + networkd is limited + + [test case] + + Note: this only occurs in a container; this is not reproducable in a VM + or bare metal. + + Configure netplan with the attached yaml file (TBD: attach) + + enable debug for systemd-networkd + + reboot the system and check the journalctl output to see if any errors + were reported for systemd-networkd, e.g.: + + $ journalctl -b -u systemd-networkd | grep 'could not set' + Jul 23 13:16:52 lp1930738-b systemd-networkd[189]: eth0: could not set address: Connection timed out + ... + + Note that a restart of systemd-networkd may successfully complete + setting up all addresses, so the journal should be checked for errors + instead of only checking for configured addresses + + [regression potential] + + possible failure to correctly apply all statically defined interfaces + + [scope] + + this is needed in f and b + + this is fixed upstream with commits + 628f08b66d43d1947b03419409d817d28eb47321 and PR 16982 which are included + in v246 and later, so this is fixed in h and later + + [original description] + This issue was reported at https://github.com/systemd/systemd/issues/17012 **Used distribution** - > Ubuntu 20.04.1 LTS - + > Ubuntu 20.04.1 LTS **systemd version the issue has been seen with** > 245.4-4ubuntu3.2 **Issue details** I configured 255 IPv4 address (including primary IP) using netplan but when the server restart, it time out on configuring the interface. If I limit total IPv4 addresses to 181 or less, it works. But anything larger than 181 fails. Below are my configurations and error logs. **/etc/netplan/10-ens3.yaml** ``` network: - version: 2 - renderer: networkd - ethernets: - ens3: - dhcp4: no - addresses: - - 140.XX.XX.XX/23 - - 103.XXX.XX.1/24 - - 103.XXX.XX.2/24 - - CONTINUED IP ADDRESS UPTO BELOW ... - - 103.XXX.XX.254/24 - gateway4: 140.XX.XX.X - nameservers: - addresses: [1.1.1.1, 1.0.0.1] - routes: - - to: 169.254.0.0/16 - via: 140.XX.XX.X - metric: 100 + version: 2 + renderer: networkd + ethernets: + ens3: + dhcp4: no + addresses: + - 140.XX.XX.XX/23 + - 103.XXX.XX.1/24 + - 103.XXX.XX.2/24 + - CONTINUED IP ADDRESS UPTO BELOW ... + - 103.XXX.XX.254/24 + gateway4: 140.XX.XX.X + nameservers: + addresses: [1.1.1.1, 1.0.0.1] + routes: + - to: 169.254.0.0/16 + via: 140.XX.XX.X + metric: 100 ``` The above config works if I run `netplan apply` but when I reboot, it does not work. **networkctl** ``` - IDX LINK TYPE OPERATIONAL SETUP - 1 lo loopback carrier unmanaged - 2 ens3 etherroutablefailed + IDX LINK TYPE OPERATIONAL SETUP + 1 lo loopback carrier unmanaged + 2 ens3 etherroutablefailed 2 links listed. ``` **/etc/systemd/system/systemd-networkd.service.d/override.conf** ``` [Service] Environment=SYSTEMD_LOG_LEVEL=debug ``` **systemctl status systemd-networkd.service** ``` ● systemd-networkd.service - Network Service - Loaded: loaded (/lib/systemd/system/systemd-networkd.service; enabled-runtime; vendor preset: enabled) - Drop-In: /etc/systemd/system/systemd-networkd.service.d - └─override.conf - Active: active (running) since Thu 2020-09-10 19:46:58 UTC; 1min 36s ago -Docs: man:systemd-networkd.service(8) -Main PID: 346 (systemd-network) - Status: "Processing requests..." - Tasks: 1 (limit: 1074) - Memory: 3.8M - CGroup: /system.slice/systemd-networkd.service - └─346 /lib/systemd/systemd-networkd + Loaded: loaded (/lib/systemd/system/systemd-networkd.service; enabled-runtime; vendor preset: enabled) + Drop-In: /etc/systemd/system/systemd-networkd.service.d + └─override.conf + Active: active (running) since Thu 2020-09-10 19:46:58 UTC; 1min 36s ago + Docs: man:systemd-networkd.service(8) + Main PID: 346 (systemd-network) + Status: "Processing requests..." + Tasks: 1 (limit: 1074) + Memory: 3.8M + CGroup: /system.slice/systemd-networkd.service + └─346 /lib/systemd/systemd-networkd Sep 10 19:47:03 test-server systemd-networkd[346]: NDISC: Sent Router Solicitation, next solicitation in 7s Sep 10 19:47:11 test-server systemd-networkd[346]: NDISC: No RA received before link confirmation timeout Sep 10 19:47:11 test-server systemd-networkd[346]: NDISC: Invoking callback for 'timeout' event. Sep 10 19:47:11 test-server systemd-networkd[346]: NDISC: Sent Router Solicitation, next solicitation in 15s Sep 10 19:47:23 test-server systemd-networkd[346]: Assertion 'm->sealed' failed at src/libsystemd/sd-netlink/netlink-mes
[Touch-packages] [Bug 1931104] Re: Test of dogtag-pki is failing on s390x vs the nss v3.63 in impish-proposed
** Bug watch added: Mozilla Bugzilla #1721995
https://bugzilla.mozilla.org/show_bug.cgi?id=1721995
** Also affects: nss via
https://bugzilla.mozilla.org/show_bug.cgi?id=1721995
Importance: Unknown
Status: Unknown
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to nss in Ubuntu.
https://bugs.launchpad.net/bugs/1931104
Title:
Test of dogtag-pki is failing on s390x vs the nss v3.63 in impish-
proposed
Status in NSS:
Unknown
Status in nss package in Ubuntu:
Triaged
Bug description:
The test of dogtag-pki is failing on the nss 3.63 that is in impish proposed.
Example:
https://autopkgtest.ubuntu.com/results/autopkgtest-impish/impish/s390x/d/dogtag-pki/20210516_212719_e6522@/log.gz
Bad:
Installing CA into /var/lib/pki/pki-tomcat.
Installation failed: ('Connection aborted.', RemoteDisconnected('Remote end
closed connection without response'))
ERROR: ConnectionError: ('Connection aborted.', RemoteDisconnected('Remote
end closed connection without response'))
File "/usr/lib/python3/dist-packages/pki/server/pkispawn.py", line 575, in
main
scriptlet.spawn(deployer)
File
"/usr/lib/python3/dist-packages/pki/server/deployment/scriptlets/configuration.py",
line 995, in spawn
cert = deployer.setup_cert(client, tag)
File "/usr/lib/python3/dist-packages/pki/server/deployment/__init__.py",
line 355, in setup_cert
return client.setupCert(request)
File "/usr/lib/python3/dist-packages/pki/system.py", line 389, in setupCert
response = self.connection.post(
File "/usr/lib/python3/dist-packages/pki/client.py", line 55, in wrapper
return func(self, *args, **kwargs)
File "/usr/lib/python3/dist-packages/pki/client.py", line 293, in post
r = self.session.post(
File "/usr/lib/python3/dist-packages/requests/sessions.py", line 590, in
post
return self.request('POST', url, data=data, json=json, **kwargs)
File "/usr/lib/python3/dist-packages/requests/sessions.py", line 542, in
request
resp = self.send(prep, **send_kwargs)
File "/usr/lib/python3/dist-packages/requests/sessions.py", line 655, in
send
r = adapter.send(request, **kwargs)
File "/usr/lib/python3/dist-packages/requests/adapters.py", line 498, in
send
raise ConnectionError(err, request=request)
CA spawn failed:
Good:
nstalling CA into /var/lib/pki/pki-tomcat.
Notice: Trust flag u is set automatically if the private key is present.
/usr/lib/python3/dist-packages/urllib3/connection.py:455:
SubjectAltNameWarning: Certificate for i-dogtag has no `subjectAltName`,
falling back to check for a `commonName` for now. This feature is being removed
by major browsers and deprecated by RFC 2818. (See
https://github.com/urllib3/urllib3/issues/497 for details.)
warnings.warn(
==
INSTALLATION SUMMARY
==
...
The good test above was with:
ii libnss3:s390x2:3.61-1ubuntu2 s390xNetwork Security
Service libraries
ii 389-ds-base1.4.4.11-2 s390x389 Directory Server suite -
server
Worth to know, the good case test still fails later on with:
IOException: SocketException cannot write on socket: Failed to write to
socket: (-5938) Encountered end of file.
ERROR: CalledProcessError: Command '['pki', '-d',
'/etc/pki/pki-tomcat/alias', '-f', '/etc/pki/pki-tomcat/password.conf', '-U',
'https://i-dogtag:8443', 'securitydomain-join', '--session',
'4717921475119312283', '--type', 'TKS', '--hostname', 'i-dogtag',
'--unsecure-port', '8080', '--secure-port', '8443', 'TKS i-dogtag 8443']'
returned non-zero exit status 255.
File "/usr/lib/python3/dist-packages/pki/server/pkispawn.py", line 575, in
main
scriptlet.spawn(deployer)
File
"/usr/lib/python3/dist-packages/pki/server/deployment/scriptlets/configuration.py",
line 1038, in spawn
subsystem.join_security_domain(
File "/usr/lib/python3/dist-packages/pki/server/subsystem.py", line 1201,
in join_security_domain
subprocess.check_call(cmd)
File "/usr/lib/python3.9/subprocess.py", line 373, in check_call
raise CalledProcessError(retcode, cmd)
Installation failed: Command failed: pki -d /etc/pki/pki-tomcat/alias -f
/etc/pki/pki-tomcat/password.conf -U https://i-dogtag:8443 securitydomain-join
--session 4717921475119312283 --type TKS --hostname i-dogtag --unsecure-port
8080 --secure-port 8443 TKS i-dogtag 8443
Please check pkispawn logs in /var/log/pki/pki-tks-spawn.20210607093926.log
Well one issue at a time ... the current install issue first.
Since it worked with the nss in -release I was upgrading this to the new nss.
ii 389-ds-base1.4.4.11-2 s390x389 Directory Server suite -
server
ii libnss3:s390x 2:
[Touch-packages] [Bug 1931994] Re: [Ubuntu 20.04] OpenSSL bugs im s390x AES code
** Attachment removed: "Standalone C program from the upstream test case" https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1931994/+attachment/5512579/+files/evp_extra_test.c ** Attachment added: "Tiny test program" https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1931994/+attachment/5513212/+files/test.c -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1931994 Title: [Ubuntu 20.04] OpenSSL bugs im s390x AES code Status in Ubuntu on IBM z Systems: Triaged Status in openssl package in Ubuntu: New Status in openssl source package in Bionic: New Status in openssl source package in Focal: New Status in openssl source package in Groovy: New Status in openssl source package in Hirsute: New Status in openssl source package in Impish: New Bug description: Problem description: When passing a NULL key to reset AES EVC state, the state wouldn't be completely reset on s390x. https://github.com/openssl/openssl/pull/14900 Solution available here: https://github.com/openssl/openssl/commit/dc67210d909b5dd7a50f60a96f36f3f5a891b1c8 Should be applied to all distros where openssl 1.1.1 is included for consistency reason. -> 21.10, 20.04, 18.04. I think not needed for 16.04 anymore [Test plan] $ sudo apt install libssl-dev $ gcc test.c -o evc-test -lcrypto -lssl # See https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1931994/comments/2 for the test.c program $ ./evc-test && echo OK [Where problems could occur] This patch only touches s390x code paths, so there shouldn't be any regression on other architectures. However, on s390x this could reveal latent bugs by spreading a NULL key to new code paths. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1931994/+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 1931994] Standalone C program from the upstream test case
Default Comment by Bridge ** Attachment added: "Standalone C program from the upstream test case" https://bugs.launchpad.net/bugs/1931994/+attachment/5513213/+files/evp_extra_test.c -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1931994 Title: [Ubuntu 20.04] OpenSSL bugs im s390x AES code Status in Ubuntu on IBM z Systems: Triaged Status in openssl package in Ubuntu: New Status in openssl source package in Bionic: New Status in openssl source package in Focal: New Status in openssl source package in Groovy: New Status in openssl source package in Hirsute: New Status in openssl source package in Impish: New Bug description: Problem description: When passing a NULL key to reset AES EVC state, the state wouldn't be completely reset on s390x. https://github.com/openssl/openssl/pull/14900 Solution available here: https://github.com/openssl/openssl/commit/dc67210d909b5dd7a50f60a96f36f3f5a891b1c8 Should be applied to all distros where openssl 1.1.1 is included for consistency reason. -> 21.10, 20.04, 18.04. I think not needed for 16.04 anymore [Test plan] $ sudo apt install libssl-dev $ gcc test.c -o evc-test -lcrypto -lssl # See https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1931994/comments/2 for the test.c program $ ./evc-test && echo OK [Where problems could occur] This patch only touches s390x code paths, so there shouldn't be any regression on other architectures. However, on s390x this could reveal latent bugs by spreading a NULL key to new code paths. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1931994/+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 1931104] Re: Test of dogtag-pki is failing on s390x vs the nss v3.63 in impish-proposed
All of the above still applies to nss 3.68-1, for which I'm preparing a
merge right now.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to nss in Ubuntu.
https://bugs.launchpad.net/bugs/1931104
Title:
Test of dogtag-pki is failing on s390x vs the nss v3.63 in impish-
proposed
Status in NSS:
Unknown
Status in nss package in Ubuntu:
Triaged
Bug description:
The test of dogtag-pki is failing on the nss 3.63 that is in impish proposed.
Example:
https://autopkgtest.ubuntu.com/results/autopkgtest-impish/impish/s390x/d/dogtag-pki/20210516_212719_e6522@/log.gz
Bad:
Installing CA into /var/lib/pki/pki-tomcat.
Installation failed: ('Connection aborted.', RemoteDisconnected('Remote end
closed connection without response'))
ERROR: ConnectionError: ('Connection aborted.', RemoteDisconnected('Remote
end closed connection without response'))
File "/usr/lib/python3/dist-packages/pki/server/pkispawn.py", line 575, in
main
scriptlet.spawn(deployer)
File
"/usr/lib/python3/dist-packages/pki/server/deployment/scriptlets/configuration.py",
line 995, in spawn
cert = deployer.setup_cert(client, tag)
File "/usr/lib/python3/dist-packages/pki/server/deployment/__init__.py",
line 355, in setup_cert
return client.setupCert(request)
File "/usr/lib/python3/dist-packages/pki/system.py", line 389, in setupCert
response = self.connection.post(
File "/usr/lib/python3/dist-packages/pki/client.py", line 55, in wrapper
return func(self, *args, **kwargs)
File "/usr/lib/python3/dist-packages/pki/client.py", line 293, in post
r = self.session.post(
File "/usr/lib/python3/dist-packages/requests/sessions.py", line 590, in
post
return self.request('POST', url, data=data, json=json, **kwargs)
File "/usr/lib/python3/dist-packages/requests/sessions.py", line 542, in
request
resp = self.send(prep, **send_kwargs)
File "/usr/lib/python3/dist-packages/requests/sessions.py", line 655, in
send
r = adapter.send(request, **kwargs)
File "/usr/lib/python3/dist-packages/requests/adapters.py", line 498, in
send
raise ConnectionError(err, request=request)
CA spawn failed:
Good:
nstalling CA into /var/lib/pki/pki-tomcat.
Notice: Trust flag u is set automatically if the private key is present.
/usr/lib/python3/dist-packages/urllib3/connection.py:455:
SubjectAltNameWarning: Certificate for i-dogtag has no `subjectAltName`,
falling back to check for a `commonName` for now. This feature is being removed
by major browsers and deprecated by RFC 2818. (See
https://github.com/urllib3/urllib3/issues/497 for details.)
warnings.warn(
==
INSTALLATION SUMMARY
==
...
The good test above was with:
ii libnss3:s390x2:3.61-1ubuntu2 s390xNetwork Security
Service libraries
ii 389-ds-base1.4.4.11-2 s390x389 Directory Server suite -
server
Worth to know, the good case test still fails later on with:
IOException: SocketException cannot write on socket: Failed to write to
socket: (-5938) Encountered end of file.
ERROR: CalledProcessError: Command '['pki', '-d',
'/etc/pki/pki-tomcat/alias', '-f', '/etc/pki/pki-tomcat/password.conf', '-U',
'https://i-dogtag:8443', 'securitydomain-join', '--session',
'4717921475119312283', '--type', 'TKS', '--hostname', 'i-dogtag',
'--unsecure-port', '8080', '--secure-port', '8443', 'TKS i-dogtag 8443']'
returned non-zero exit status 255.
File "/usr/lib/python3/dist-packages/pki/server/pkispawn.py", line 575, in
main
scriptlet.spawn(deployer)
File
"/usr/lib/python3/dist-packages/pki/server/deployment/scriptlets/configuration.py",
line 1038, in spawn
subsystem.join_security_domain(
File "/usr/lib/python3/dist-packages/pki/server/subsystem.py", line 1201,
in join_security_domain
subprocess.check_call(cmd)
File "/usr/lib/python3.9/subprocess.py", line 373, in check_call
raise CalledProcessError(retcode, cmd)
Installation failed: Command failed: pki -d /etc/pki/pki-tomcat/alias -f
/etc/pki/pki-tomcat/password.conf -U https://i-dogtag:8443 securitydomain-join
--session 4717921475119312283 --type TKS --hostname i-dogtag --unsecure-port
8080 --secure-port 8443 TKS i-dogtag 8443
Please check pkispawn logs in /var/log/pki/pki-tks-spawn.20210607093926.log
Well one issue at a time ... the current install issue first.
Since it worked with the nss in -release I was upgrading this to the new nss.
ii 389-ds-base1.4.4.11-2 s390x389 Directory Server suite -
server
ii libnss3:s390x 2:3.63-1ubuntu1 s390xNetwork Security Service
libraries
With this the install fail is reprodicible.
So we can switch in/out bad c
[Touch-packages] [Bug 1931994] Re: [Ubuntu 20.04] OpenSSL bugs im s390x AES code
Updated description in preparation for SRU requests ** Description changed: Problem description: + + When passing a NULL key to reset AES EVC state, the state wouldn't be completely reset on s390x. https://github.com/openssl/openssl/pull/14900 - + Solution available here: https://github.com/openssl/openssl/commit/dc67210d909b5dd7a50f60a96f36f3f5a891b1c8 - Should be applied to all distros where openssl 1.1.1 is included for consistency reason. -> 21.10, 20.04, 18.04. I think not needed for 16.04 anymore + + [Test plan] + + $ sudo apt install libssl-dev + $ gcc test.c -o evc-test -lcrypto -lssl # See https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1931994/comments/2 for the test.c program + $ ./evc-test && echo OK + + [Where problems could occur] + + This patch only touches s390x code paths, so there shouldn't be any regression on other architectures. However, on s390x this could reveal + latent bugs by spreading a NULL key to new code paths. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1931994 Title: [Ubuntu 20.04] OpenSSL bugs im s390x AES code Status in Ubuntu on IBM z Systems: Triaged Status in openssl package in Ubuntu: New Status in openssl source package in Bionic: New Status in openssl source package in Focal: New Status in openssl source package in Groovy: New Status in openssl source package in Hirsute: New Status in openssl source package in Impish: New Bug description: Problem description: When passing a NULL key to reset AES EVC state, the state wouldn't be completely reset on s390x. https://github.com/openssl/openssl/pull/14900 Solution available here: https://github.com/openssl/openssl/commit/dc67210d909b5dd7a50f60a96f36f3f5a891b1c8 Should be applied to all distros where openssl 1.1.1 is included for consistency reason. -> 21.10, 20.04, 18.04. I think not needed for 16.04 anymore [Test plan] $ sudo apt install libssl-dev $ gcc test.c -o evc-test -lcrypto -lssl # See https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1931994/comments/2 for the test.c program $ ./evc-test && echo OK [Where problems could occur] This patch only touches s390x code paths, so there shouldn't be any regression on other architectures. However, on s390x this could reveal latent bugs by spreading a NULL key to new code paths. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1931994/+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 1930738] Re: network configuration failed on reboot
** Description changed:
[impact]
number of statically defined addresses for an interface in systemd-
networkd is limited
[test case]
Note: this only occurs in a container; this is not reproducable in a VM
or bare metal.
Configure netplan with the attached yaml file (TBD: attach)
enable debug for systemd-networkd
reboot the system and check the journalctl output to see if any errors
were reported for systemd-networkd, e.g.:
$ journalctl -b -u systemd-networkd | grep 'could not set'
Jul 23 13:16:52 lp1930738-b systemd-networkd[189]: eth0: could not set
address: Connection timed out
...
Note that a restart of systemd-networkd may successfully complete
setting up all addresses, so the journal should be checked for errors
instead of only checking for configured addresses
[regression potential]
possible failure to correctly apply all statically defined interfaces
[scope]
this is needed in f and b
this is fixed upstream with commits
628f08b66d43d1947b03419409d817d28eb47321 and PR 16982 which are included
in v246 and later, so this is fixed in h and later
+
+ [other info]
+
+ I elided upstream commit d31f33e3c9f6ea3bdc873ee52f4398edbec74527 as
+ that changes the udev-related behavior of networkd-manager inside a
+ container, which is not appropriate for SRU for this bug, as I don't see
+ any clear bug-related reason to change that behavior.
+
+ Additionally this requires the typo fix from commit
+ 4934ba2121d76229659939e19ab7d70a89446629
[original description]
This issue was reported at
https://github.com/systemd/systemd/issues/17012
**Used distribution**
> Ubuntu 20.04.1 LTS
**systemd version the issue has been seen with**
> 245.4-4ubuntu3.2
**Issue details**
I configured 255 IPv4 address (including primary IP) using netplan but when
the server restart, it time out on configuring the interface. If I limit total
IPv4 addresses to 181 or less, it works. But anything larger than 181 fails.
Below are my configurations and error logs.
**/etc/netplan/10-ens3.yaml**
```
network:
version: 2
renderer: networkd
ethernets:
ens3:
dhcp4: no
addresses:
- 140.XX.XX.XX/23
- 103.XXX.XX.1/24
- 103.XXX.XX.2/24
- CONTINUED IP ADDRESS UPTO BELOW ...
- 103.XXX.XX.254/24
gateway4: 140.XX.XX.X
nameservers:
addresses: [1.1.1.1, 1.0.0.1]
routes:
- to: 169.254.0.0/16
via: 140.XX.XX.X
metric: 100
```
The above config works if I run `netplan apply` but when I reboot, it does
not work.
**networkctl**
```
IDX LINK TYPE OPERATIONAL SETUP
1 lo loopback carrier unmanaged
2 ens3 etherroutablefailed
2 links listed.
```
**/etc/systemd/system/systemd-networkd.service.d/override.conf**
```
[Service]
Environment=SYSTEMD_LOG_LEVEL=debug
```
**systemctl status systemd-networkd.service**
```
● systemd-networkd.service - Network Service
Loaded: loaded (/lib/systemd/system/systemd-networkd.service;
enabled-runtime; vendor preset: enabled)
Drop-In: /etc/systemd/system/systemd-networkd.service.d
└─override.conf
Active: active (running) since Thu 2020-09-10 19:46:58 UTC; 1min 36s ago
Docs: man:systemd-networkd.service(8)
Main PID: 346 (systemd-network)
Status: "Processing requests..."
Tasks: 1 (limit: 1074)
Memory: 3.8M
CGroup: /system.slice/systemd-networkd.service
└─346 /lib/systemd/systemd-networkd
Sep 10 19:47:03 test-server systemd-networkd[346]: NDISC: Sent Router
Solicitation, next solicitation in 7s
Sep 10 19:47:11 test-server systemd-networkd[346]: NDISC: No RA received
before link confirmation timeout
Sep 10 19:47:11 test-server systemd-networkd[346]: NDISC: Invoking callback
for 'timeout' event.
Sep 10 19:47:11 test-server systemd-networkd[346]: NDISC: Sent Router
Solicitation, next solicitation in 15s
Sep 10 19:47:23 test-server systemd-networkd[346]: Assertion 'm->sealed'
failed at src/libsystemd/sd-netlink/netlink-message.c:582, function
netlink_message_read_internal(). Ignoring.
Sep 10 19:47:23 test-server systemd-networkd[346]: ens3: Could not set
address: Connection timed out
Sep 10 19:47:23 test-server systemd-networkd[346]: ens3: Failed
Sep 10 19:47:23 test-server systemd-networkd[346]: ens3: State changed:
configuring -> failed
Sep 10 19:47:23 test-server systemd-networkd[346]: Sent message type=signal
sender=n/a destination=n/a path=/org/freedesktop/network1/link/_32
interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=13
reply_cookie=0 signature=sa{sv}as error-name=n/a error-message=n/a
Sep 10 19:47:23 test-server systemd-networkd[346]: NDISC: Stopping IPv6
Router Solicitation client
```
** Changed in: systemd (Ubuntu Bionic)
[Touch-packages] [Bug 1937238] Re: systemd-time-wait-sync.service stuck in "activating" state after boot, blocks timers from starting
This is almost certainly because you don't have the systemd-timesyncd package installed, or you don't have the systemd-timesyncd service enabled. On a very quick glance, it seems the systemd-time-wait-sync service should have been bundled into the systemd-timesyncd package when it was split from the main systemd package, however I'll have to look closer to see if there is some reason it wasn't. ** Description changed: + [impact] + + systemd-time-wait-sync service never completes when systemd-timesyncd + package is not installed + + [test case] + + remove the systemd-timesyncd package and enable the systemd-time-wait- + sync service, and reboot. Check status of the service to see it's stuck + in 'activating' state, e.g.: + + ubuntu@lp1937238-f:~$ sudo systemctl status systemd-time-wait-sync.service + ● systemd-time-wait-sync.service - Wait Until Kernel Time Synchronized + Loaded: loaded (/lib/systemd/system/systemd-time-wait-sync.service; enabled; vendor preset: enabled) + Active: activating (start) since Fri 2021-07-23 15:32:12 UTC; 19s ago + + [regression potential] + + TBD + + [scope] + + this is needed in f and later + + the systemd-timesyncd package was split out from the main systemd + package starting in focal, so this problem exists in f and later + + the service doesn't exist in b, so this is not needed there + + [original description] + When I start my server running Ubuntu 20.04 the systemd-time-wait- sync.service is stuck in "activating" state. I noticed this because none of the systemd timer units triggered, because all the timers depend on systemd-time-wait-sync.service. Running "systemctl restart systemd-time- wait-sync.service" manually works around the problem. Some logs and command outputs: - raek@mizar:~$ lsb_release -rd Description:Ubuntu 20.04.2 LTS Release:20.04 - raek@mizar:~$ systemctl | grep systemd-time-wait-sync.service - systemd-time-wait-sync.service loaded activating start start Wait Until Kernel Time Synchronized - + systemd-time-wait-sync.service loaded activating start start Wait Until Kernel Time Synchronized raek@mizar:~$ systemctl status systemd-time-wait-sync.service ● systemd-time-wait-sync.service - Wait Until Kernel Time Synchronized - Loaded: loaded (/lib/systemd/system/systemd-time-wait-sync.service; enabled; vendor preset: enabled) - Active: activating (start) since Thu 2021-07-22 11:06:52 CEST; 27min ago -Docs: man:systemd-time-wait-sync.service(8) -Main PID: 514 (systemd-time-wa) - Tasks: 1 (limit: 9415) - Memory: 972.0K - CGroup: /system.slice/systemd-time-wait-sync.service - └─514 /lib/systemd/systemd-time-wait-sync + Loaded: loaded (/lib/systemd/system/systemd-time-wait-sync.service; enabled; vendor preset: enabled) + Active: activating (start) since Thu 2021-07-22 11:06:52 CEST; 27min ago + Docs: man:systemd-time-wait-sync.service(8) + Main PID: 514 (systemd-time-wa) + Tasks: 1 (limit: 9415) + Memory: 972.0K + CGroup: /system.slice/systemd-time-wait-sync.service + └─514 /lib/systemd/systemd-time-wait-sync Jul 22 11:06:52 mizar systemd-time-wait-sync[514]: adjtime state 5 status 40 time Thu 2021-07-22 09:06:52.216338 UTC Warning: journal has been rotated since unit was started, output may be incomplete. - raek@mizar:~$ journalctl -b -u systemd-time-wait-sync.service -- Logs begin at Wed 2020-07-08 16:34:13 CEST, end at Thu 2021-07-22 11:36:44 CEST. -- Jul 22 11:06:52 mizar systemd-time-wait-sync[514]: adjtime state 5 status 40 time Thu 2021-07-22 09:06:52.216338 UTC - raek@mizar:~$ dpkg -S /lib/systemd/system/systemd-time-wait-sync.service systemd: /lib/systemd/system/systemd-time-wait-sync.service - raek@mizar:~$ apt-cache policy systemd systemd: - Installed: 245.4-4ubuntu3.11 - Candidate: 245.4-4ubuntu3.11 - Version table: - *** 245.4-4ubuntu3.11 500 - 500 http://se.archive.ubuntu.com/ubuntu focal-security/main amd64 Packages - 100 /var/lib/dpkg/status - 245.4-4ubuntu3.10 500 - 500 http://se.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages - 245.4-4ubuntu3.8 400 - 400 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 Packages - 245.4-4ubuntu3 500 - 500 http://se.archive.ubuntu.com/ubuntu focal/main amd64 Packages + Installed: 245.4-4ubuntu3.11 + Candidate: 245.4-4ubuntu3.11 + Version table: + *** 245.4-4ubuntu3.11 500 + 500 http://se.archive.ubuntu.com/ubuntu focal-security/main amd64 Packages + 100 /var/lib/dpkg/status + 245.4-4ubuntu3.10 500 + 500 http://se.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages + 245.4-4ubuntu3.8 400
[Touch-packages] [Bug 1905285] Re: socket-activated sshd breaks on concurrent connections
** Description changed:
+ [Impact]
+
+ Users of the systemd socket activated ssh service may experience a race
+ condition that may lead an ssh instance to fail.
+
+ The race condition happens when, for a running socket activated ssh
+ service,
+
+ an instance A is started, creating the RuntimeDirectory for the service;
+ then
+
+ an instance B is started, relying on the RuntimeDirectory created for
+ instance A; then
+
+ instance A halts, causing the RuntimeDirectory to be deleted.
+
+ If, at this point, instance B has not chrooted into RuntimeDirectory
+ yet, then instance B will fail.
+
+ The proposed patch fixes the issue by preserving the RuntimeDirectory
+ after an instance A of the socket activated ssh service halts.
+
+ [Test Plan]
+
+ 1) Stop any running instances of ssh.
+ `systemctl stop ssh`
+
+ 2) Start the socket activated ssh service.
+ `systemctl start ssh.socket`
+
+ 3) Verify that no errors related to ssh were logged in /var/log/auth.log
+ `cat /var/log/auth.log | grep 'sshd.*fatal.*chroot.*No such file or
directory'`
+
+ 4) perform several ssh connections to the running server in a short time
span. ssh-keyscan may help here.
+ `ssh-keyscan localhost`
+
+ 5) Verify that errors related to ssh were logged in /var/log/auth.log
+ `cat /var/log/auth.log | grep 'sshd.*fatal.*chroot.*No such file or
directory'`
+
+ 6) Apply the proposed fix (make sure the socket activated service is
+ restarted)
+
+ 7) repead step (4), then verify that no new entries were appended to the
+ step (5) output
+
+ [Where problems could occur]
+
+ If the changes to the socket activated unit file are wrong, the socket
+ activated service may fail to start after the package upgrade. In this
+ case, we would need to instruct users to perform local changes to the
+ unit file with possible additional fixes while a new version of the
+ patch lands.
+
+ [Other Info]
+
+ This fix has been forwarded to Debian and accepted in
+ https://salsa.debian.org/ssh-team/openssh/-/merge_requests/12
+
+ [Original message]
+
This is mostly the same issue as https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=934663.
With the default configuration of openssh-server and systemd, sshd will
complain and crash when multiple connections are made and terminated in
a quick succession, e.g. with `ssh-keyscan`. It results in the following
errors in /var/log/auth.log:
```
Nov 22 20:53:34 {host} sshd[14567]: Unable to negotiate with {client} port
41460: no matching host key type found. Their offer:
sk-ecdsa-sha2-nistp...@openssh.com [preauth]
Nov 22 20:53:34 {host} sshd[14570]: fatal: chroot("/run/sshd"): No such file
or directory [preauth]
Nov 22 20:53:34 {host} sshd[14569]: fatal: chroot("/run/sshd"): No such file
or directory [preauth]
Nov 22 20:53:34 {host} sshd[14568]: fatal: chroot("/run/sshd"): No such file
or directory [preauth]
Nov 22 20:53:34 {host} sshd[14566]: fatal: chroot("/run/sshd"): No such file
or directory [preauth]
Nov 22 20:53:47 {host} sshd[14584]: Connection closed by {client} port 59312
[preauth]
Nov 22 20:53:47 {host} sshd[14586]: fatal: chroot("/run/sshd"): No such file
or directory [preauth]
Nov 22 20:53:48 {host} sshd[14585]: fatal: chroot("/run/sshd"): No such file
or directory [preauth]
```
as well as e.g. missing responses in ssh-keyscan:
```
$ ssh-keyscan -vvv {host}
debug2: fd 3 setting O_NONBLOCK
debug3: conalloc: oname {host} kt 2
debug2: fd 4 setting O_NONBLOCK
debug3: conalloc: oname {host} kt 4
debug2: fd 5 setting O_NONBLOCK
debug3: conalloc: oname {host} kt 8
debug2: fd 6 setting O_NONBLOCK
debug3: conalloc: oname {host} kt 32
debug2: fd 7 setting O_NONBLOCK
debug3: conalloc: oname {host} kt 64
debug1: match: OpenSSH_8.2p1 Ubuntu-4ubuntu0.1 pat OpenSSH* compat 0x0400
# {host}:22 SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.1
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms:
curve25519-sha256,curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256
debug2: host key algorithms: sk-ecdsa-sha2-nistp...@openssh.com
debug2: ciphers ctos:
chacha20-poly1...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com
debug2: ciphers stoc:
chacha20-poly1...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com
debug2: MACs ctos:
umac-64-...@openssh.com,umac-128-...@openssh.com,hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com,hmac-sha1-...@openssh.com,umac...@openssh.com,umac-...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc:
umac-64-...@openssh.com,umac-128-...@openssh.com,hmac-sha2-256-...@openssh.com,hmac
[Touch-packages] [Bug 1905285] Re: socket-activated sshd breaks on concurrent connections
** Merge proposal linked:
https://code.launchpad.net/~athos-ribeiro/ubuntu/+source/openssh/+git/openssh/+merge/406161
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1905285
Title:
socket-activated sshd breaks on concurrent connections
Status in openssh package in Ubuntu:
Fix Released
Status in openssh source package in Focal:
New
Bug description:
[Impact]
Users of the systemd socket activated ssh service may experience a
race condition that may lead an ssh instance to fail.
The race condition happens when, for a running socket activated ssh
service,
an instance A is started, creating the RuntimeDirectory for the
service; then
an instance B is started, relying on the RuntimeDirectory created for
instance A; then
instance A halts, causing the RuntimeDirectory to be deleted.
If, at this point, instance B has not chrooted into RuntimeDirectory
yet, then instance B will fail.
The proposed patch fixes the issue by preserving the RuntimeDirectory
after an instance A of the socket activated ssh service halts.
[Test Plan]
1) Stop any running instances of ssh.
`systemctl stop ssh`
2) Start the socket activated ssh service.
`systemctl start ssh.socket`
3) Verify that no errors related to ssh were logged in /var/log/auth.log
`cat /var/log/auth.log | grep 'sshd.*fatal.*chroot.*No such file or
directory'`
4) perform several ssh connections to the running server in a short time
span. ssh-keyscan may help here.
`ssh-keyscan localhost`
5) Verify that errors related to ssh were logged in /var/log/auth.log
`cat /var/log/auth.log | grep 'sshd.*fatal.*chroot.*No such file or
directory'`
6) Apply the proposed fix (make sure the socket activated service is
restarted)
7) repead step (4), then verify that no new entries were appended to
the step (5) output
[Where problems could occur]
If the changes to the socket activated unit file are wrong, the socket
activated service may fail to start after the package upgrade. In this
case, we would need to instruct users to perform local changes to the
unit file with possible additional fixes while a new version of the
patch lands.
[Other Info]
This fix has been forwarded to Debian and accepted in
https://salsa.debian.org/ssh-team/openssh/-/merge_requests/12
[Original message]
This is mostly the same issue as https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=934663.
With the default configuration of openssh-server and systemd, sshd
will complain and crash when multiple connections are made and
terminated in a quick succession, e.g. with `ssh-keyscan`. It results
in the following errors in /var/log/auth.log:
```
Nov 22 20:53:34 {host} sshd[14567]: Unable to negotiate with {client} port
41460: no matching host key type found. Their offer:
sk-ecdsa-sha2-nistp...@openssh.com [preauth]
Nov 22 20:53:34 {host} sshd[14570]: fatal: chroot("/run/sshd"): No such file
or directory [preauth]
Nov 22 20:53:34 {host} sshd[14569]: fatal: chroot("/run/sshd"): No such file
or directory [preauth]
Nov 22 20:53:34 {host} sshd[14568]: fatal: chroot("/run/sshd"): No such file
or directory [preauth]
Nov 22 20:53:34 {host} sshd[14566]: fatal: chroot("/run/sshd"): No such file
or directory [preauth]
Nov 22 20:53:47 {host} sshd[14584]: Connection closed by {client} port 59312
[preauth]
Nov 22 20:53:47 {host} sshd[14586]: fatal: chroot("/run/sshd"): No such file
or directory [preauth]
Nov 22 20:53:48 {host} sshd[14585]: fatal: chroot("/run/sshd"): No such file
or directory [preauth]
```
as well as e.g. missing responses in ssh-keyscan:
```
$ ssh-keyscan -vvv {host}
debug2: fd 3 setting O_NONBLOCK
debug3: conalloc: oname {host} kt 2
debug2: fd 4 setting O_NONBLOCK
debug3: conalloc: oname {host} kt 4
debug2: fd 5 setting O_NONBLOCK
debug3: conalloc: oname {host} kt 8
debug2: fd 6 setting O_NONBLOCK
debug3: conalloc: oname {host} kt 32
debug2: fd 7 setting O_NONBLOCK
debug3: conalloc: oname {host} kt 64
debug1: match: OpenSSH_8.2p1 Ubuntu-4ubuntu0.1 pat OpenSSH* compat 0x0400
# {host}:22 SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.1
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms:
curve25519-sha256,curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256
debug2: host key algorithms: sk-ecdsa-sha2-nistp...@openssh.com
debug2: ciphers ctos:
chacha20-poly1...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com
debug2: ciphers stoc:
chacha20-poly1...@openssh.com,aes128-c
[Touch-packages] [Bug 1931994] Re: [Ubuntu 20.04] OpenSSL bugs im s390x AES code
** Patch added: "Focal SRU debdiff" https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1931994/+attachment/5513254/+files/openssl_focal.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1931994 Title: [Ubuntu 20.04] OpenSSL bugs im s390x AES code Status in Ubuntu on IBM z Systems: Triaged Status in openssl package in Ubuntu: New Status in openssl source package in Bionic: New Status in openssl source package in Focal: New Status in openssl source package in Groovy: New Status in openssl source package in Hirsute: New Status in openssl source package in Impish: New Bug description: Problem description: When passing a NULL key to reset AES EVC state, the state wouldn't be completely reset on s390x. https://github.com/openssl/openssl/pull/14900 Solution available here: https://github.com/openssl/openssl/commit/dc67210d909b5dd7a50f60a96f36f3f5a891b1c8 Should be applied to all distros where openssl 1.1.1 is included for consistency reason. -> 21.10, 20.04, 18.04. I think not needed for 16.04 anymore [Test plan] $ sudo apt install libssl-dev $ gcc test.c -o evc-test -lcrypto -lssl # See https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1931994/comments/2 for the test.c program $ ./evc-test && echo OK [Where problems could occur] This patch only touches s390x code paths, so there shouldn't be any regression on other architectures. However, on s390x this could reveal latent bugs by spreading a NULL key to new code paths. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1931994/+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 1931994] Re: [Ubuntu 20.04] OpenSSL bugs im s390x AES code
-- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1931994 Title: [Ubuntu 20.04] OpenSSL bugs im s390x AES code Status in Ubuntu on IBM z Systems: Triaged Status in openssl package in Ubuntu: New Status in openssl source package in Bionic: New Status in openssl source package in Focal: New Status in openssl source package in Groovy: New Status in openssl source package in Hirsute: New Status in openssl source package in Impish: New Bug description: Problem description: When passing a NULL key to reset AES EVC state, the state wouldn't be completely reset on s390x. https://github.com/openssl/openssl/pull/14900 Solution available here: https://github.com/openssl/openssl/commit/dc67210d909b5dd7a50f60a96f36f3f5a891b1c8 Should be applied to all distros where openssl 1.1.1 is included for consistency reason. -> 21.10, 20.04, 18.04. I think not needed for 16.04 anymore [Test plan] $ sudo apt install libssl-dev $ gcc test.c -o evc-test -lcrypto -lssl # See https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1931994/comments/2 for the test.c program $ ./evc-test && echo OK [Where problems could occur] This patch only touches s390x code paths, so there shouldn't be any regression on other architectures. However, on s390x this could reveal latent bugs by spreading a NULL key to new code paths. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1931994/+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 1931994] Re: [Ubuntu 20.04] OpenSSL bugs im s390x AES code
** Patch added: "Bionic SRU debdiff" https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1931994/+attachment/5513255/+files/openssl_bionic.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1931994 Title: [Ubuntu 20.04] OpenSSL bugs im s390x AES code Status in Ubuntu on IBM z Systems: Triaged Status in openssl package in Ubuntu: New Status in openssl source package in Bionic: New Status in openssl source package in Focal: New Status in openssl source package in Groovy: New Status in openssl source package in Hirsute: New Status in openssl source package in Impish: New Bug description: Problem description: When passing a NULL key to reset AES EVC state, the state wouldn't be completely reset on s390x. https://github.com/openssl/openssl/pull/14900 Solution available here: https://github.com/openssl/openssl/commit/dc67210d909b5dd7a50f60a96f36f3f5a891b1c8 Should be applied to all distros where openssl 1.1.1 is included for consistency reason. -> 21.10, 20.04, 18.04. I think not needed for 16.04 anymore [Test plan] $ sudo apt install libssl-dev $ gcc test.c -o evc-test -lcrypto -lssl # See https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1931994/comments/2 for the test.c program $ ./evc-test && echo OK [Where problems could occur] This patch only touches s390x code paths, so there shouldn't be any regression on other architectures. However, on s390x this could reveal latent bugs by spreading a NULL key to new code paths. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1931994/+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 1931994] Re: [Ubuntu 20.04] OpenSSL bugs im s390x AES code
** Patch added: "Hirsute SRU debdiff" https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1931994/+attachment/5513256/+files/openssl_hirsute.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1931994 Title: [Ubuntu 20.04] OpenSSL bugs im s390x AES code Status in Ubuntu on IBM z Systems: Triaged Status in openssl package in Ubuntu: New Status in openssl source package in Bionic: New Status in openssl source package in Focal: New Status in openssl source package in Groovy: New Status in openssl source package in Hirsute: New Status in openssl source package in Impish: New Bug description: Problem description: When passing a NULL key to reset AES EVC state, the state wouldn't be completely reset on s390x. https://github.com/openssl/openssl/pull/14900 Solution available here: https://github.com/openssl/openssl/commit/dc67210d909b5dd7a50f60a96f36f3f5a891b1c8 Should be applied to all distros where openssl 1.1.1 is included for consistency reason. -> 21.10, 20.04, 18.04. I think not needed for 16.04 anymore [Test plan] $ sudo apt install libssl-dev $ gcc test.c -o evc-test -lcrypto -lssl # See https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1931994/comments/2 for the test.c program $ ./evc-test && echo OK [Where problems could occur] This patch only touches s390x code paths, so there shouldn't be any regression on other architectures. However, on s390x this could reveal latent bugs by spreading a NULL key to new code paths. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1931994/+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 1931994] Re: [Ubuntu 20.04] OpenSSL bugs im s390x AES code
** Patch added: "Impish debdiff" https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1931994/+attachment/5513257/+files/openssl_impish.debdiff ** Attachment removed: "Standalone C program from the upstream test case" https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1931994/+attachment/5513213/+files/evp_extra_test.c -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1931994 Title: [Ubuntu 20.04] OpenSSL bugs im s390x AES code Status in Ubuntu on IBM z Systems: Triaged Status in openssl package in Ubuntu: New Status in openssl source package in Bionic: New Status in openssl source package in Focal: New Status in openssl source package in Groovy: New Status in openssl source package in Hirsute: New Status in openssl source package in Impish: New Bug description: Problem description: When passing a NULL key to reset AES EVC state, the state wouldn't be completely reset on s390x. https://github.com/openssl/openssl/pull/14900 Solution available here: https://github.com/openssl/openssl/commit/dc67210d909b5dd7a50f60a96f36f3f5a891b1c8 Should be applied to all distros where openssl 1.1.1 is included for consistency reason. -> 21.10, 20.04, 18.04. I think not needed for 16.04 anymore [Test plan] $ sudo apt install libssl-dev $ gcc test.c -o evc-test -lcrypto -lssl # See https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1931994/comments/2 for the test.c program $ ./evc-test && echo OK [Where problems could occur] This patch only touches s390x code paths, so there shouldn't be any regression on other architectures. However, on s390x this could reveal latent bugs by spreading a NULL key to new code paths. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1931994/+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 1931994] Standalone C program from the upstream test case
Default Comment by Bridge ** Attachment added: "Standalone C program from the upstream test case" https://bugs.launchpad.net/bugs/1931994/+attachment/5513259/+files/evp_extra_test.c -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1931994 Title: [Ubuntu 20.04] OpenSSL bugs im s390x AES code Status in Ubuntu on IBM z Systems: Triaged Status in openssl package in Ubuntu: New Status in openssl source package in Bionic: New Status in openssl source package in Focal: New Status in openssl source package in Groovy: New Status in openssl source package in Hirsute: New Status in openssl source package in Impish: New Bug description: Problem description: When passing a NULL key to reset AES EVC state, the state wouldn't be completely reset on s390x. https://github.com/openssl/openssl/pull/14900 Solution available here: https://github.com/openssl/openssl/commit/dc67210d909b5dd7a50f60a96f36f3f5a891b1c8 Should be applied to all distros where openssl 1.1.1 is included for consistency reason. -> 21.10, 20.04, 18.04. I think not needed for 16.04 anymore [Test plan] $ sudo apt install libssl-dev $ gcc test.c -o evc-test -lcrypto -lssl # See https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1931994/comments/2 for the test.c program $ ./evc-test && echo OK [Where problems could occur] This patch only touches s390x code paths, so there shouldn't be any regression on other architectures. However, on s390x this could reveal latent bugs by spreading a NULL key to new code paths. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1931994/+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 1931104] Re: Test of dogtag-pki is failing on s390x due to LTO
MP for a merge from Debian which also disabled LTO via
DEB_BUILD_MAINT_OPTIONS=optimize=-lto:
https://code.launchpad.net/~paride/ubuntu/+source/nss/+git/nss/+merge/406163
** Summary changed:
- Test of dogtag-pki is failing on s390x vs the nss v3.63 in impish-proposed
+ Test of dogtag-pki is failing on s390x due to LTO
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to nss in Ubuntu.
https://bugs.launchpad.net/bugs/1931104
Title:
Test of dogtag-pki is failing on s390x due to LTO
Status in NSS:
Unknown
Status in nss package in Ubuntu:
Triaged
Bug description:
The test of dogtag-pki is failing on the nss 3.63 that is in impish proposed.
Example:
https://autopkgtest.ubuntu.com/results/autopkgtest-impish/impish/s390x/d/dogtag-pki/20210516_212719_e6522@/log.gz
Bad:
Installing CA into /var/lib/pki/pki-tomcat.
Installation failed: ('Connection aborted.', RemoteDisconnected('Remote end
closed connection without response'))
ERROR: ConnectionError: ('Connection aborted.', RemoteDisconnected('Remote
end closed connection without response'))
File "/usr/lib/python3/dist-packages/pki/server/pkispawn.py", line 575, in
main
scriptlet.spawn(deployer)
File
"/usr/lib/python3/dist-packages/pki/server/deployment/scriptlets/configuration.py",
line 995, in spawn
cert = deployer.setup_cert(client, tag)
File "/usr/lib/python3/dist-packages/pki/server/deployment/__init__.py",
line 355, in setup_cert
return client.setupCert(request)
File "/usr/lib/python3/dist-packages/pki/system.py", line 389, in setupCert
response = self.connection.post(
File "/usr/lib/python3/dist-packages/pki/client.py", line 55, in wrapper
return func(self, *args, **kwargs)
File "/usr/lib/python3/dist-packages/pki/client.py", line 293, in post
r = self.session.post(
File "/usr/lib/python3/dist-packages/requests/sessions.py", line 590, in
post
return self.request('POST', url, data=data, json=json, **kwargs)
File "/usr/lib/python3/dist-packages/requests/sessions.py", line 542, in
request
resp = self.send(prep, **send_kwargs)
File "/usr/lib/python3/dist-packages/requests/sessions.py", line 655, in
send
r = adapter.send(request, **kwargs)
File "/usr/lib/python3/dist-packages/requests/adapters.py", line 498, in
send
raise ConnectionError(err, request=request)
CA spawn failed:
Good:
nstalling CA into /var/lib/pki/pki-tomcat.
Notice: Trust flag u is set automatically if the private key is present.
/usr/lib/python3/dist-packages/urllib3/connection.py:455:
SubjectAltNameWarning: Certificate for i-dogtag has no `subjectAltName`,
falling back to check for a `commonName` for now. This feature is being removed
by major browsers and deprecated by RFC 2818. (See
https://github.com/urllib3/urllib3/issues/497 for details.)
warnings.warn(
==
INSTALLATION SUMMARY
==
...
The good test above was with:
ii libnss3:s390x2:3.61-1ubuntu2 s390xNetwork Security
Service libraries
ii 389-ds-base1.4.4.11-2 s390x389 Directory Server suite -
server
Worth to know, the good case test still fails later on with:
IOException: SocketException cannot write on socket: Failed to write to
socket: (-5938) Encountered end of file.
ERROR: CalledProcessError: Command '['pki', '-d',
'/etc/pki/pki-tomcat/alias', '-f', '/etc/pki/pki-tomcat/password.conf', '-U',
'https://i-dogtag:8443', 'securitydomain-join', '--session',
'4717921475119312283', '--type', 'TKS', '--hostname', 'i-dogtag',
'--unsecure-port', '8080', '--secure-port', '8443', 'TKS i-dogtag 8443']'
returned non-zero exit status 255.
File "/usr/lib/python3/dist-packages/pki/server/pkispawn.py", line 575, in
main
scriptlet.spawn(deployer)
File
"/usr/lib/python3/dist-packages/pki/server/deployment/scriptlets/configuration.py",
line 1038, in spawn
subsystem.join_security_domain(
File "/usr/lib/python3/dist-packages/pki/server/subsystem.py", line 1201,
in join_security_domain
subprocess.check_call(cmd)
File "/usr/lib/python3.9/subprocess.py", line 373, in check_call
raise CalledProcessError(retcode, cmd)
Installation failed: Command failed: pki -d /etc/pki/pki-tomcat/alias -f
/etc/pki/pki-tomcat/password.conf -U https://i-dogtag:8443 securitydomain-join
--session 4717921475119312283 --type TKS --hostname i-dogtag --unsecure-port
8080 --secure-port 8443 TKS i-dogtag 8443
Please check pkispawn logs in /var/log/pki/pki-tks-spawn.20210607093926.log
Well one issue at a time ... the current install issue first.
Since it worked with the nss in -release I was upgrading this to the new nss.
ii 389-ds-base1.4.4.11-2 s390x
[Touch-packages] [Bug 1937850] [NEW] the -L / --relative option breaks --accept-regex
Public bug reported: This code should in principle (per the docs) fetch a few *.pdf files: $ wget -r --level 1 --adjust-extension --relative --no-clobber --no-directories\ --domains=ncua.gov --accept-regex 'administrative-orders/.*.pdf'\ 'https://www.ncua.gov/regulation-supervision/enforcement-actions/administrative-orders?page=22&sort=year&dir=desc&sq=' But it misses all *.pdf files. When the --relative option is removed, the PDF files are downloaded. However, when you examine the tree-top HTML file, the links pointing to PDF files actually are relative. ** Affects: wget (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to wget in Ubuntu. https://bugs.launchpad.net/bugs/1937850 Title: the -L / --relative option breaks --accept-regex Status in wget package in Ubuntu: New Bug description: This code should in principle (per the docs) fetch a few *.pdf files: $ wget -r --level 1 --adjust-extension --relative --no-clobber --no-directories\ --domains=ncua.gov --accept-regex 'administrative-orders/.*.pdf'\ 'https://www.ncua.gov/regulation-supervision/enforcement-actions/administrative-orders?page=22&sort=year&dir=desc&sq=' But it misses all *.pdf files. When the --relative option is removed, the PDF files are downloaded. However, when you examine the tree-top HTML file, the links pointing to PDF files actually are relative. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/wget/+bug/1937850/+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 1934147] Re: systemd leaks abandoned session scopes
Also related:
https://bugs.launchpad.net/charm-etcd/+bug/1926185
--
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/1934147
Title:
systemd leaks abandoned session scopes
Status in snapd:
New
Status in systemd:
New
Status in systemd package in Ubuntu:
In Progress
Status in systemd source package in Bionic:
Confirmed
Status in systemd source package in Focal:
In Progress
Status in systemd source package in Groovy:
In Progress
Status in systemd source package in Hirsute:
In Progress
Status in systemd source package in Impish:
In Progress
Bug description:
[impact]
systemd may leak sessions, leaving empty cgroups around as well as
abandoned session scopes.
[test case]
on a system where the user has a ssh key that allows noninteractive
login to localhost, and also has noninteractive sudo, run:
$ for i in {1..100}; do sudo -b -i -u ubuntu ssh localhost -- sleep 1;
done; for i in {1..20}; do echo 'Reloading...'; sudo systemctl daemon-
reload; done
check the sessions to see there have been leaked sessions:
$ loginctl list-sessions
SESSION UID USER SEAT TTY
1 1000 ubuntu ttyS0
350 1000 ubuntu
351 1000 ubuntu
360 1000 ubuntu
...
to verify the sessions were leaked, clear them out with:
$ echo '' | sudo tee
/sys/fs/cgroup/unified/user.slice/user-1000.slice/session-*.scope/cgroup.events
that should result in all the leaked sessions being cleaned up.
[regression potential]
issues during systemd pid1 reexec/reload, or issues while cleaning up
sessions, including leaking sessions/cgroups
[scope]
this is needed for all releases
upstream bug linked above, and upstream PR:
https://github.com/systemd/systemd/pull/20199
[original description]
On a system that is monitored via telegraf I found many abandoned
systemd session which I believe are created by a potential race where
systemd is reloading unit files and at the same time a user is
connecting to the system via ssh or is executing the su command.
The simple reproducer
$ for i in {1..100}; do sleep 0.2; ssh localhost sudo systemctl
daemon-reload & ssh localhost sleep 1 & done
Wait > 1 second
$ jobs -p | xargs --verbose --no-run-if-empty kill -KILL
To clean out STOPPED jobs and
$ systemctl status --all 2> /dev/null | grep --before-context 3
abandoned
will produce something similar to
│ ├─ 175 su - ubuntu
│ ├─ 178 -su
│ ├─62375 systemctl status --all
│ └─62376 grep --color=auto --before-context 3 abandoned
--
● session-273.scope - Session 273 of user ubuntu
Loaded: loaded (/run/systemd/transient/session-273.scope; transient)
Transient: yes
Active: active (abandoned) since Wed 2021-06-30 13:32:03 UTC; 4min 7s ago
--
● session-274.scope - Session 274 of user ubuntu
Loaded: loaded (/run/systemd/transient/session-274.scope; transient)
Transient: yes
Active: active (abandoned) since Wed 2021-06-30 13:32:03 UTC; 4min 7s ago
--
● session-30.scope - Session 30 of user ubuntu
Loaded: loaded (/run/systemd/transient/session-30.scope; transient)
Transient: yes
Active: active (abandoned) since Wed 2021-06-30 10:05:56 UTC; 3h 30min ago
--
● session-302.scope - Session 302 of user ubuntu
Loaded: loaded (/run/systemd/transient/session-302.scope; transient)
Transient: yes
Active: active (abandoned) since Wed 2021-06-30 13:32:04 UTC; 4min 6s ago
--
│ ├─ 175 su - ubuntu
│ ├─ 178 -su
│ ├─62375 systemctl status --all
│ └─62376 grep --color=auto --before-context 3 abandoned
The system in question is running Bionic, systemd-237-3ubuntu10.48
To manage notifications about this bug go to:
https://bugs.launchpad.net/snapd/+bug/1934147/+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 1934286] Re: Update the ModemManager to 1.16.6-2 to support some modems in Focal and Hirsute releases.
Test Pass on WWAN Test: https://certification.canonical.com/hardware/202010-28324/submission/223136/ ACPI Stress Test: https://certification.canonical.com/hardware/202010-28324/submission/223167/ -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to modemmanager in Ubuntu. https://bugs.launchpad.net/bugs/1934286 Title: Update the ModemManager to 1.16.6-2 to support some modems in Focal and Hirsute releases. Status in OEM Priority Project: Confirmed Status in libmbim package in Ubuntu: Fix Released Status in libqmi package in Ubuntu: Fix Released Status in modemmanager package in Ubuntu: Fix Released Status in libmbim source package in Focal: Fix Committed Status in libqmi source package in Focal: Fix Committed Status in modemmanager source package in Focal: Fix Committed Status in libmbim source package in Hirsute: Fix Committed Status in libqmi source package in Hirsute: Fix Committed Status in modemmanager source package in Hirsute: Fix Committed Bug description: [Impact] Some IOT products use wireless modems which can be working only when recent versions of the ModemManager suite are used. The following 2 modems need the ModemManager suite to be upgraded: * Foxconn SDX55 T99W175 5G sub6 PCIE Modem * Quectel SDX24 EM160R-GL 4G LTE CAT16 PCIE Modem The main fix requested is to add the FCC unlock mechanism for Foxconn modems. * FCC unlock operation for Foxconn modems https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/534/commits * dms: new 'Foxconn Set FCC authentication' command https://gitlab.freedesktop.org/mobile-broadband/libqmi/-/merge_requests/254/commits The minimum versions of the ModemManager suite required to enable the support for the above 2 mentioned modems have been verified: (LP: #1928665) * ModemManager: 1.16.6 * libmbim: 1.24.8 * libqmi : 1.28.6 The ModemManager suite in the Impish release meets the requirements. [Test Plan] = How to Reproduce the Bug = Execute the following commands to list the modems detected by ModemManager in Hirsute and Focal releases: $ mmcli --list-modems No modems were found = Test Procedure = 1. Install the Ubuntu system on the tested hardware The following images will be used to verify the version of the ModemManager suite: * Impish: https://cdimage.ubuntu.com/daily-live/current/impish-desktop-amd64.iso * Hirsute: https://releases.ubuntu.com/21.04/ubuntu-21.04-desktop-amd64.iso * Focal: https://releases.ubuntu.com/focal/ubuntu-20.04.2.0-desktop-amd64.iso 2. Upgrade the kernel and driver ( for Foxconn and Quectel modem ) The kernel needs to get some patches from 5.13 and includes a back ported Quectel driver to support these 2 modems. We have prepared a kernel packages for testing: https://people.canonical.com/~mschiu77/lp1928665/v2/ 3. Install the ModemManager suite ( for Hirsute and Focal releases ) The ModemManager suite will be installed from the -proposed component: $ sudo apt update $ sudo apt install modemmanager $ sudo apt install libqmi-utils 4. Execute the following commands 4.1 Get the run-time environment $ uname -ar $ lsb_release -a $ mmcli -V $ qmicli -V 4.2 Check the status of the ModemManager service $ sudo systemctl status ModemManager.service 4.3 List the detected modems $ mmcli --list-modems 4.4 Check the modem’s status $ mmcli --modem 0 4.5 Install and execute Lenovo’s FCC unlock app ( for Quectel modem only ) $ sudo snap install --devmode --dangerous dpr-wwan_1.0-wwan- test_amd64.snap 4.6 Enable the detected modem $ sudo mmcli --modem 0 --enable 4.7 Check the modem’s status $ mmcli --modem 0 = Analyze the Tested Result = 1. Check if installed packages are working The result of test procedure 4.1 and 4.2 can be used to make sure the installed packages are working. If the Modemmanager.service is active(running), the packages are working. 2. Check if the supported modem can be detected The result of test procedure 4.3 can be used to see if the modem can be detected by ModemManager or not. The supported modems should be listed. 3. Check if the modem can be enabled If the modem can be enabled, the state of the modem in the test procedure 4.7 will be set to be registered. = Certification Validation = Additionally to the aforementioned test cases, the Certification Team will perform some coverage testing across supported devices to make sure the other modems still work as expected. [Where problems could occur] There is a risk that modems supported in the old versions of ModemManager suite may not be supported in the newer versions. [Other Info] We need to upgrade to these 3 packages (in Impish) at the same time: * ModemManager: 1.16.6 * libmbim: 1.24.8 * libqmi : 1.28.6 To support the mention
[Touch-packages] [Bug 1935850] Re: Dell XPS 17 (9710) PCI/internal sound card not detected
Wang Have a patch to test from intel. Attempting to compile doing the following: 1) Copy old config over to source 2) make oldconfig (Accept default changes) 3) make -j8 4) sudo make modules_install At this point I get this error: arch/x86/Makefile:148: CONFIG_X86_X32 enabled but no binutils support sed: can't read modules.order: No such file or directory make: *** [Makefile:1485: __modinst_pre] Error 2 I have made sure that binutils are install. Any input would be appropriated. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to alsa-driver in Ubuntu. https://bugs.launchpad.net/bugs/1935850 Title: Dell XPS 17 (9710) PCI/internal sound card not detected Status in alsa-driver package in Ubuntu: Confirmed Bug description: No audio/mic from internal speakers/build in microphone running Ubuntu 20.04, 20.10 or 21.04 . Can connect via USB headset and audio will work. Tried suggestions from Dell XPS 17 (9700) but this is the new model and fixes do not work. Currently running 21.04 with proposed. Have tried hirsute-proposed (5.11.0-24-generic) with no luck. ProblemType: Bug DistroRelease: Ubuntu 21.04 Package: alsa-base 1.0.25+dfsg-0ubuntu7 ProcVersionSignature: Ubuntu 5.11.0-24.25-generic 5.11.22 Uname: Linux 5.11.0-24-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu65.1 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: mblack 1698 F pulseaudio CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Mon Jul 12 11:21:27 2021 InstallationDate: Installed on 2021-07-07 (4 days ago) InstallationMedia: Ubuntu 21.04 "Hirsute Hippo" - Release amd64 (20210420) PackageArchitecture: all ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: alsa-driver Symptom: audio Title: PCI/internal sound card not detected UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 06/15/2021 dmi.bios.release: 1.2 dmi.bios.vendor: Dell Inc. dmi.bios.version: 1.2.0 dmi.board.name: 012MMP dmi.board.vendor: Dell Inc. dmi.board.version: A00 dmi.chassis.type: 10 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvr1.2.0:bd06/15/2021:br1.2:svnDellInc.:pnXPS179710:pvr:rvnDellInc.:rn012MMP:rvrA00:cvnDellInc.:ct10:cvr: dmi.product.family: XPS dmi.product.name: XPS 17 9710 dmi.product.sku: 0A5D dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1935850/+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 1927161] Re: dpkg-source: error: diff 'openssl/debian/patches/pr12272.patch' patches files multiple times; split the diff in multiple files or merge the hunks into a single one
I am quite surprised by this behaviour. Especially since, `quilt push -a; debuild -S` works find, unpacks fine, applies fine etc. Quite a weird limitation imho. Do you think this warrants an upstream dpkg bug report? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1927161 Title: dpkg-source: error: diff 'openssl/debian/patches/pr12272.patch' patches files multiple times; split the diff in multiple files or merge the hunks into a single one Status in openssl package in Ubuntu: Fix Released Status in openssl source package in Groovy: Fix Released Status in openssl source package in Hirsute: Fix Committed Status in openssl source package in Impish: Fix Released Bug description: [impact] openssl doesn't build source properly because of a badly-constructed patch [test case] $ pull-lp-source openssl groovy ... $ cd openssl-1.1.1f/ $ quilt pop -a ... $ dpkg-buildpackage -d -S dpkg-buildpackage: info: source package openssl dpkg-buildpackage: info: source version 1.1.1f-1ubuntu4.3 dpkg-buildpackage: info: source distribution groovy-security dpkg-buildpackage: info: source changed by Marc Deslauriers dpkg-source --before-build . dpkg-source: warning: can't parse dependency perl:native dpkg-source: error: diff 'openssl-1.1.1f/debian/patches/pr12272.patch' patches files multiple times; split the diff in multiple files or merge the hunks into a single one dpkg-buildpackage: error: dpkg-source --before-build . subprocess returned exit status 25 Test builds are available in the following ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp1927161-test [regression potential] any regression would likely cause a failed build or would affect the functionality that patch pr12272 was added for, which is adding support for Intel CET [scope] this is needed only for g and later this is caused by the bad patch 'pr12272.patch' which is only included in g/h/i, so this does not apply to f or earlier [other info] note that if the patches are applied, this bug is bypassed; i.e. if 'quilt pop -a' is removed from the test case above, the bug doesn't reproduce. this is only a problem when the patches aren't already applied and dpkg-buildpackage needs to call dpkg-source to apply the patches. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1927161/+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 1927161] Re: dpkg-source: error: diff 'openssl/debian/patches/pr12272.patch' patches files multiple times; split the diff in multiple files or merge the hunks into a single one
> I am quite surprised by this behaviour. I'm not, I hit it all the time with git-style multiple patches in one file. I always split them into multiple files now. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1927161 Title: dpkg-source: error: diff 'openssl/debian/patches/pr12272.patch' patches files multiple times; split the diff in multiple files or merge the hunks into a single one Status in openssl package in Ubuntu: Fix Released Status in openssl source package in Groovy: Fix Released Status in openssl source package in Hirsute: Fix Committed Status in openssl source package in Impish: Fix Released Bug description: [impact] openssl doesn't build source properly because of a badly-constructed patch [test case] $ pull-lp-source openssl groovy ... $ cd openssl-1.1.1f/ $ quilt pop -a ... $ dpkg-buildpackage -d -S dpkg-buildpackage: info: source package openssl dpkg-buildpackage: info: source version 1.1.1f-1ubuntu4.3 dpkg-buildpackage: info: source distribution groovy-security dpkg-buildpackage: info: source changed by Marc Deslauriers dpkg-source --before-build . dpkg-source: warning: can't parse dependency perl:native dpkg-source: error: diff 'openssl-1.1.1f/debian/patches/pr12272.patch' patches files multiple times; split the diff in multiple files or merge the hunks into a single one dpkg-buildpackage: error: dpkg-source --before-build . subprocess returned exit status 25 Test builds are available in the following ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp1927161-test [regression potential] any regression would likely cause a failed build or would affect the functionality that patch pr12272 was added for, which is adding support for Intel CET [scope] this is needed only for g and later this is caused by the bad patch 'pr12272.patch' which is only included in g/h/i, so this does not apply to f or earlier [other info] note that if the patches are applied, this bug is bypassed; i.e. if 'quilt pop -a' is removed from the test case above, the bug doesn't reproduce. this is only a problem when the patches aren't already applied and dpkg-buildpackage needs to call dpkg-source to apply the patches. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1927161/+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 1927161] Re: dpkg-source: error: diff 'openssl/debian/patches/pr12272.patch' patches files multiple times; split the diff in multiple files or merge the hunks into a single one
multiple patches shouldn't ever be cat'ed into a single file; that is awful. One patch file per actual patch. This fails because quilt allows fuzz, while dpkg-source doesn't, and it shouldn't. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1927161 Title: dpkg-source: error: diff 'openssl/debian/patches/pr12272.patch' patches files multiple times; split the diff in multiple files or merge the hunks into a single one Status in openssl package in Ubuntu: Fix Released Status in openssl source package in Groovy: Fix Released Status in openssl source package in Hirsute: Fix Committed Status in openssl source package in Impish: Fix Released Bug description: [impact] openssl doesn't build source properly because of a badly-constructed patch [test case] $ pull-lp-source openssl groovy ... $ cd openssl-1.1.1f/ $ quilt pop -a ... $ dpkg-buildpackage -d -S dpkg-buildpackage: info: source package openssl dpkg-buildpackage: info: source version 1.1.1f-1ubuntu4.3 dpkg-buildpackage: info: source distribution groovy-security dpkg-buildpackage: info: source changed by Marc Deslauriers dpkg-source --before-build . dpkg-source: warning: can't parse dependency perl:native dpkg-source: error: diff 'openssl-1.1.1f/debian/patches/pr12272.patch' patches files multiple times; split the diff in multiple files or merge the hunks into a single one dpkg-buildpackage: error: dpkg-source --before-build . subprocess returned exit status 25 Test builds are available in the following ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp1927161-test [regression potential] any regression would likely cause a failed build or would affect the functionality that patch pr12272 was added for, which is adding support for Intel CET [scope] this is needed only for g and later this is caused by the bad patch 'pr12272.patch' which is only included in g/h/i, so this does not apply to f or earlier [other info] note that if the patches are applied, this bug is bypassed; i.e. if 'quilt pop -a' is removed from the test case above, the bug doesn't reproduce. this is only a problem when the patches aren't already applied and dpkg-buildpackage needs to call dpkg-source to apply the patches. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1927161/+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 1937871] [NEW] [Galaxy Buds Live (F88A), Volume lower than it should be
Public bug reported: Galaxy Buds Live sound volume is lower than in other devices using non- linux operating systems. This however doesn't happen with the zen linux kernel where the volume is more acceptable. If I try to mitigate this with volumes level above 100 percent in pulse audio, the sound is distorted. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: alsa-base 1.0.25+dfsg-0ubuntu5 ProcVersionSignature: Ubuntu 5.13.0-1009.10-oem 5.13.0 Uname: Linux 5.13.0-1009-oem x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.11-0ubuntu27.18 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: gregassagraf 5248 F pulseaudio CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Fri Jul 23 16:09:14 2021 InstallationDate: Installed on 2021-07-19 (4 days ago) InstallationMedia: Ubuntu 20.04.2.0 LTS "Focal Fossa" - Release amd64 (20210209.1) PackageArchitecture: all SourcePackage: alsa-driver Symptom: audio Symptom_Card: Galaxy Buds Live (F88A) Symptom_Type: None of the above Title: [Galaxy Buds Live (F88A), playback] Playback problem UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 07/01/2021 dmi.bios.release: 1.6 dmi.bios.vendor: Dell Inc. dmi.bios.version: 1.6.0 dmi.board.name: 07N10G dmi.board.vendor: Dell Inc. dmi.board.version: A00 dmi.chassis.type: 10 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvr1.6.0:bd07/01/2021:br1.6:svnDellInc.:pnInspiron5402:pvr:sku0A01:rvnDellInc.:rn07N10G:rvrA00:cvnDellInc.:ct10:cvr: dmi.product.family: Inspiron dmi.product.name: Inspiron 5402 dmi.product.sku: 0A01 dmi.sys.vendor: Dell Inc. ** Affects: alsa-driver (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug focal third-party-packages -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to alsa-driver in Ubuntu. https://bugs.launchpad.net/bugs/1937871 Title: [Galaxy Buds Live (F88A), Volume lower than it should be Status in alsa-driver package in Ubuntu: New Bug description: Galaxy Buds Live sound volume is lower than in other devices using non-linux operating systems. This however doesn't happen with the zen linux kernel where the volume is more acceptable. If I try to mitigate this with volumes level above 100 percent in pulse audio, the sound is distorted. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: alsa-base 1.0.25+dfsg-0ubuntu5 ProcVersionSignature: Ubuntu 5.13.0-1009.10-oem 5.13.0 Uname: Linux 5.13.0-1009-oem x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.11-0ubuntu27.18 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: gregassagraf 5248 F pulseaudio CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Fri Jul 23 16:09:14 2021 InstallationDate: Installed on 2021-07-19 (4 days ago) InstallationMedia: Ubuntu 20.04.2.0 LTS "Focal Fossa" - Release amd64 (20210209.1) PackageArchitecture: all SourcePackage: alsa-driver Symptom: audio Symptom_Card: Galaxy Buds Live (F88A) Symptom_Type: None of the above Title: [Galaxy Buds Live (F88A), playback] Playback problem UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 07/01/2021 dmi.bios.release: 1.6 dmi.bios.vendor: Dell Inc. dmi.bios.version: 1.6.0 dmi.board.name: 07N10G dmi.board.vendor: Dell Inc. dmi.board.version: A00 dmi.chassis.type: 10 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvr1.6.0:bd07/01/2021:br1.6:svnDellInc.:pnInspiron5402:pvr:sku0A01:rvnDellInc.:rn07N10G:rvrA00:cvnDellInc.:ct10:cvr: dmi.product.family: Inspiron dmi.product.name: Inspiron 5402 dmi.product.sku: 0A01 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1937871/+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 1937874] [NEW] one --accept-regex expression negates another
Public bug reported: This command should theoretically fetch all PDFs on a page: $ wget -v -d -r --level 1 --adjust-extension --no-clobber --no-directories\ --accept-regex 'administrative-orders/.*/administrative-order-matter-'\ --accept-regex 'administrative-orders.*.pdf'\ --accept-regex 'administrative-orders.page[^&]*$'\ --directory-prefix=/tmp\ 'https://www.ncua.gov/regulation-supervision/enforcement-actions/administrative-orders?page=56' But it fails to grab any of them, giving the output: --- Deciding whether to enqueue "https://www.ncua.gov/files/administrative-orders/AO14-0241-R4.pdf";. https://www.ncua.gov/files/administrative-orders/AO14-0241-R4.pdf is excluded/not-included through regex. Decided NOT to load it. --- That's bogus. The workaround is to remove this option: --accept-regex 'administrative-orders.page[^&]*$' But that should not be necessary. Adding an --accept-* clause should never cause another --accept-* clause to become invalidated and it should not shrink the set of fetched files. ** Affects: wget (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to wget in Ubuntu. https://bugs.launchpad.net/bugs/1937874 Title: one --accept-regex expression negates another Status in wget package in Ubuntu: New Bug description: This command should theoretically fetch all PDFs on a page: $ wget -v -d -r --level 1 --adjust-extension --no-clobber --no-directories\ --accept-regex 'administrative-orders/.*/administrative-order-matter-'\ --accept-regex 'administrative-orders.*.pdf'\ --accept-regex 'administrative-orders.page[^&]*$'\ --directory-prefix=/tmp\ 'https://www.ncua.gov/regulation-supervision/enforcement-actions/administrative-orders?page=56' But it fails to grab any of them, giving the output: --- Deciding whether to enqueue "https://www.ncua.gov/files/administrative-orders/AO14-0241-R4.pdf";. https://www.ncua.gov/files/administrative-orders/AO14-0241-R4.pdf is excluded/not-included through regex. Decided NOT to load it. --- That's bogus. The workaround is to remove this option: --accept-regex 'administrative-orders.page[^&]*$' But that should not be necessary. Adding an --accept-* clause should never cause another --accept-* clause to become invalidated and it should not shrink the set of fetched files. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/wget/+bug/1937874/+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 1922477] Re: unattended-upgrade crashed with apt.cache.LockFailedException in __enter__(): Failed to lock directory /var/cache/apt/archives/: E:Could not get lock /var/cache/apt/
** Information type changed from Private to Public -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unattended-upgrades in Ubuntu. https://bugs.launchpad.net/bugs/1922477 Title: unattended-upgrade crashed with apt.cache.LockFailedException in __enter__(): Failed to lock directory /var/cache/apt/archives/: E:Could not get lock /var/cache/apt/archives/lock. It is held by process 26973 (apt-get) Status in unattended-upgrades package in Ubuntu: New Bug description: got this while installing latest update. ProblemType: Crash DistroRelease: Ubuntu 21.04 Package: unattended-upgrades 2.8 ProcVersionSignature: Ubuntu 5.11.0-1004.4-raspi 5.11.7 Uname: Linux 5.11.0-1004-raspi aarch64 ApportVersion: 2.20.11-0ubuntu61 Architecture: arm64 CasperMD5CheckResult: unknown Date: Fri Apr 2 17:42:45 2021 ExecutablePath: /usr/bin/unattended-upgrade ImageMediaBuild: 20201022 InterpreterPath: /usr/bin/python3.9 PackageArchitecture: all ProcCmdline: /usr/bin/python3 /usr/bin/unattended-upgrade ProcEnviron: LANGUAGE=en_GB:en PATH=(custom, no user) LANG=en_GB.UTF-8 Python3Details: /usr/bin/python3.9, Python 3.9.2, python3-minimal, 3.9.2-2 PythonArgs: ['/usr/bin/unattended-upgrade'] PythonDetails: N/A SourcePackage: unattended-upgrades Title: unattended-upgrade crashed with apt.cache.LockFailedException in __enter__(): Failed to lock directory /var/cache/apt/archives/: E:Could not get lock /var/cache/apt/archives/lock. It is held by process 26973 (apt-get) UpgradeStatus: Upgraded to hirsute on 2021-03-25 (9 days ago) UserGroups: N/A To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1922477/+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 1918046] Re: gdb-multiarch assert failure: *** stack smashing detected ***: terminated
** Information type changed from Private to Public -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gdb in Ubuntu. https://bugs.launchpad.net/bugs/1918046 Title: gdb-multiarch assert failure: *** stack smashing detected ***: terminated Status in gdb package in Ubuntu: New Bug description: Description: Ubuntu Hirsute Hippo (development branch) Release: 21.04 gdb-multiarch: Installed: 10.1-2ubuntu1 Candidate: 10.1-2ubuntu1 Version table: *** 10.1-2ubuntu1 500 500 http://gb.archive.ubuntu.com/ubuntu hirsute/universe amd64 Packages 100 /var/lib/dpkg/status I was not expecting this package to run as the crash happened after I reboot my laptop. I was using this package before reboot with eclipse IDE to debug a remote embedded target, but was not working as expected and was thinking to use arm-none-eabi-gdb instead which don't seem to be in the ubuntu repositories. ProblemType: Crash DistroRelease: Ubuntu 21.04 Package: gdb-multiarch 10.1-2ubuntu1 ProcVersionSignature: Ubuntu 5.10.0-14.15-generic 5.10.11 Uname: Linux 5.10.0-14-generic x86_64 ApportVersion: 2.20.11-0ubuntu59 Architecture: amd64 AssertionMessage: *** stack smashing detected ***: terminated CasperMD5CheckResult: unknown CrashCounter: 1 CurrentDesktop: ubuntu:GNOME Date: Sun Mar 7 02:13:19 2021 ExecutablePath: /usr/bin/gdb-multiarch InstallationDate: Installed on 2021-03-06 (0 days ago) InstallationMedia: Ubuntu 21.04 "Hirsute Hippo" - Alpha amd64 (20210123) ProcCmdline: gdb-multiarch --interpreter mi2 --nx -q --interpreter console -ex new-ui\ mi\ /dev/pts/1 -ex set\ pagination\ off -ex show\ version ProcEnviron: PATH=(custom, no user) LANGUAGE=en_GB:en SHELL=/bin/bash LANG=en_GB.UTF-8 XDG_RUNTIME_DIR= Signal: 6 SourcePackage: gdb StacktraceTop: __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7f975a625953 "*** %s ***: terminated\n") at ../sysdeps/posix/libc_fatal.c:155 __GI___fortify_fail (msg=msg@entry=0x7f975a62593b "stack smashing detected") at fortify_fail.c:26 __stack_chk_fail () at stack_chk_fail.c:24 ?? () ?? () Title: gdb-multiarch assert failure: *** stack smashing detected ***: terminated UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dialout dip lpadmin lxd plugdev sambashare sudo separator: To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1918046/+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 1937883] [NEW] ssh-agent Shielded Private Key Extraction
Public bug reported: Possible vulnerability with an active proof of concept that may well become a CVE. ssh-agent Shielded Private Key Extraction https://security.humanativaspa.it/openssh-ssh-agent-shielded-private- key-extraction-x86_64-linux/ ** Affects: openssh (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1937883 Title: ssh-agent Shielded Private Key Extraction Status in openssh package in Ubuntu: New Bug description: Possible vulnerability with an active proof of concept that may well become a CVE. ssh-agent Shielded Private Key Extraction https://security.humanativaspa.it/openssh-ssh-agent-shielded-private- key-extraction-x86_64-linux/ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1937883/+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
