[Touch-packages] [Bug 2045621] Re: Improve power consumption on Framework systems
Appreciate this everyone. I have multiple people beginning to test this today. I will be joining them next week. I have asked each to report back here. -- 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/2045621 Title: Improve power consumption on Framework systems Status in OEM Priority Project: In Progress Status in systemd package in Ubuntu: Fix Committed Status in systemd-hwe package in Ubuntu: Invalid Status in systemd source package in Jammy: Won't Fix Status in systemd-hwe source package in Jammy: Fix Committed Status in systemd source package in Lunar: Won't Fix Status in systemd-hwe source package in Lunar: Won't Fix Status in systemd source package in Mantic: Won't Fix Status in systemd-hwe source package in Mantic: Fix Committed Status in systemd source package in Noble: Fix Committed Status in systemd-hwe source package in Noble: Invalid Bug description: [ Impact ] * Framework systems that have DP or HDMI cards connected will have increased power consumption even when nothing is connected to DP or HDMI ports since the cards don't default to autosuspend. * Backporting upstream patch that adds rules in hwdb.d/60-autosuspend.hwdb for Framework's HDMI and DP extensions. [ Test Plan ] * DUT: Framework with DP and HDMI: $ lsusb | grep Framework Bus 007 Device 002: ID 32ac:0003 Framework DisplayPort Expansion Card Bus 001 Device 002: ID 32ac:0002 Framework HDMI Expansion Card 1. Autosuspend is not enabled before patch. Set to "on" in power/control $ cat /sys/devices/pci:00/:00:08.1/:c1:00.3/usb1/1-1/manufacturer Framework $ cat /sys/devices/pci:00/:00:08.1/:c1:00.3/usb1/1-1/power/control on $ cat /sys/devices/pci:00/:00:08.1/:c1:00.3/usb1/1-2/manufacturer Framework $ cat /sys/devices/pci:00/:00:08.1/:c1:00.3/usb1/1-2/power/control on 2. Install patch 3. Autosuspend is enabled for both extensions. Set to "auto" in power/control $ cat power/control auto [ Where problems could occur ] * During testing verified that both DP+HDMI display show good output after hot-plug, system suspend, and reboot. There might be some differences when hibernate and hotplug. [ Other Info ] * https://github.com/systemd/systemd/commit/9023630cb7025650aa4d01ee794b0bb68bfdf2c1 To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/2045621/+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 2045075] Re: Framework Laptop Expansion Card enabling auto suspend
** Tags added: systemd -- 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/2045075 Title: Framework Laptop Expansion Card enabling auto suspend Status in systemd package in Ubuntu: New Bug description: Framework provides expansion cards. For the HDMI and DisplayPort, these benefit power management via enabling auto suspend. Ubuntu 22.04.3 LTS 6.1.0-1026-oem systemd 249 (249.11-0ubuntu3.11) # # Framework # # HDMI Expansion Card usb:v32ACp0002* # DisplayPort Expansion Card usb:v32ACp0003* ID_AUTOSUSPEND=1 Commit in question: https://github.com/systemd/systemd/commit/9023630cb7025650aa4d01ee794b0bb68bfdf2c1 When looking at 60-autosuspend.hwdb for Ubuntu 22.04.3, we do not have the additional entry shown above available for HDMI and DisplayPort expansion cards. I'd like to see this added to 22.04 for future inclusion. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2045075/+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 2045075] [NEW] Framework Laptop Expansion Card enabling auto suspend
Public bug reported: Framework provides expansion cards. For the HDMI and DisplayPort, these benefit power management via enabling auto suspend. Ubuntu 22.04.3 LTS 6.1.0-1026-oem systemd 249 (249.11-0ubuntu3.11) # # Framework # # HDMI Expansion Card usb:v32ACp0002* # DisplayPort Expansion Card usb:v32ACp0003* ID_AUTOSUSPEND=1 Commit in question: https://github.com/systemd/systemd/commit/9023630cb7025650aa4d01ee794b0bb68bfdf2c1 When looking at 60-autosuspend.hwdb for Ubuntu 22.04.3, we do not have the additional entry shown above available for HDMI and DisplayPort expansion cards. I'd like to see this added to 22.04 for future inclusion. ** Affects: systemd (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/2045075 Title: Framework Laptop Expansion Card enabling auto suspend Status in systemd package in Ubuntu: New Bug description: Framework provides expansion cards. For the HDMI and DisplayPort, these benefit power management via enabling auto suspend. Ubuntu 22.04.3 LTS 6.1.0-1026-oem systemd 249 (249.11-0ubuntu3.11) # # Framework # # HDMI Expansion Card usb:v32ACp0002* # DisplayPort Expansion Card usb:v32ACp0003* ID_AUTOSUSPEND=1 Commit in question: https://github.com/systemd/systemd/commit/9023630cb7025650aa4d01ee794b0bb68bfdf2c1 When looking at 60-autosuspend.hwdb for Ubuntu 22.04.3, we do not have the additional entry shown above available for HDMI and DisplayPort expansion cards. I'd like to see this added to 22.04 for future inclusion. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2045075/+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 2019970] Re: OpenSSL 3.0.2 crash in Ubuntu 22.04.2 LTS
> if it's time to re-visit that practice of not updating through minor openssl versions; it's risky to try. As an upstream OpenSSL maintainer we try very hard to ensure that stable releases remain stable across patch releases. We only allow bug fixes (no new features etc) into our patch releases and always seek to ensure backwards compatibility. Of course every bug fix is ultimately a change of behaviour and sometimes end users rely on that buggy behaviour. Sometimes we get it wrong and inadvertently break something. I hope those are few and far between though. Ultimately if you fix bugs there will always be a residual risk that you break something somewhere. Hopefully the risk is small enough that it is acceptable. -- 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/2019970 Title: OpenSSL 3.0.2 crash in Ubuntu 22.04.2 LTS Status in openssl package in Ubuntu: Incomplete Bug description: Full bug report at https://github.com/openssl/openssl/issues/20981 No upstream impact: OpenSSL 3.0.9-dev does not contain the problem any more. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2019970/+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 2017401] [NEW] Unexpected / unwanted unattended-upgrades behaviour after kernel upgrade when Livepatch enabled
Public bug reported: Following the resolution for bug #1747499, after a kernel upgrade when Livepatch is enabled, the current behaviour in unattended-upgrades (2.3ubuntu0.2 and later) is not to touch /var/run/reboot-required so as not to confuse users with two separate messages calling for a restart in motd. This functionality is implemented in the script at /etc/kernel/postinst.d/unattended-upgrades. While this works as intended in terms of suppressing an extra message in motd, it defeats the ability of unattended-upgrades to restart automatically with the new kernel, which is reliant on /var/run/reboot- required being present. This is unexpected / unwanted behaviour in scenarios where a) Livepatch is being used to provide fast-response kernel patching; and b) Unattended-Upgrade::Automatic-Reboot is set to true, to enable automatic reboots during a regular maintenance window. In this case, without administrative intervention, the system could never boot into the new kernel even though it would be expected to, leaving Livepatch to do all the heavy lifting indefinitely, and unnecessarily. I believe this counts as a regression caused by the resolution to bug #1747499. It also has the potential to be a security threat if Livepatch doesn't work comprehensively for a particular kernel flaw, and an administrator is reliant on expected behaviour according to unattended- upgrades settings. Potential options for a fix that come to mind: 1. Revert to original behaviour in /etc/kernel/postinst.d/unattended-upgrades, and change the ***System restart required*** message to be less alarming or confusing when the cause is a kernel upgrade that's being patched by Livepatch. 2. Add an extra configuration setting (eg Unattended-Upgrade::Automatic-Reboot-After-Livepatch) that triggers a reboot when it's 'recommended' by Livepatch, not reliant on the presence of /var/run/reboot-required. 3. Add support in /etc/kernel/postinst.d/unattended-upgrades for an extra file somewhere. When present, /var/run/reboot-required is always touched, even if Livepatch is enabled. (This is my first time reporting a bug in this system, and I apologise if I haven't followed the usual descriptive format.) ** Affects: unattended-upgrades (Ubuntu) Importance: Undecided Status: New ** Tags: focal regression-update -- 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/2017401 Title: Unexpected / unwanted unattended-upgrades behaviour after kernel upgrade when Livepatch enabled Status in unattended-upgrades package in Ubuntu: New Bug description: Following the resolution for bug #1747499, after a kernel upgrade when Livepatch is enabled, the current behaviour in unattended-upgrades (2.3ubuntu0.2 and later) is not to touch /var/run/reboot-required so as not to confuse users with two separate messages calling for a restart in motd. This functionality is implemented in the script at /etc/kernel/postinst.d/unattended-upgrades. While this works as intended in terms of suppressing an extra message in motd, it defeats the ability of unattended-upgrades to restart automatically with the new kernel, which is reliant on /var/run/reboot-required being present. This is unexpected / unwanted behaviour in scenarios where a) Livepatch is being used to provide fast-response kernel patching; and b) Unattended-Upgrade::Automatic-Reboot is set to true, to enable automatic reboots during a regular maintenance window. In this case, without administrative intervention, the system could never boot into the new kernel even though it would be expected to, leaving Livepatch to do all the heavy lifting indefinitely, and unnecessarily. I believe this counts as a regression caused by the resolution to bug #1747499. It also has the potential to be a security threat if Livepatch doesn't work comprehensively for a particular kernel flaw, and an administrator is reliant on expected behaviour according to unattended-upgrades settings. Potential options for a fix that come to mind: 1. Revert to original behaviour in /etc/kernel/postinst.d/unattended-upgrades, and change the ***System restart required*** message to be less alarming or confusing when the cause is a kernel upgrade that's being patched by Livepatch. 2. Add an extra configuration setting (eg Unattended-Upgrade::Automatic-Reboot-After-Livepatch) that triggers a reboot when it's 'recommended' by Livepatch, not reliant on the presence of /var/run/reboot-required. 3. Add support in /etc/kernel/postinst.d/unattended-upgrades for an extra file somewhere. When present, /var/run/reboot-required is always touched, even if Livepatch is enabled. (This is my first time reporting a bug in this system, and I apologise if I haven't followed the usual descriptive format.) To manage notifications about
[Touch-packages] [Bug 2013545] Re: /usr/sbin/apt-add-repository will not function with IPv6 proxies called by address
On another reading of this, it looks like the issue may end up being in
dependency (and upstream package) httplib2. I'd like a sanity check on
that, and I'm willing to file tickets in other packages or upstream as
soon as I have cycles. I'm buried in the middle of another project
right now, but I wanted to get the issue documented for any other poor
souls running into it in the future.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to software-properties in
Ubuntu.
https://bugs.launchpad.net/bugs/2013545
Title:
/usr/sbin/apt-add-repository will not function with IPv6 proxies
called by address
Status in software-properties package in Ubuntu:
New
Bug description:
It appears that if one has an HTTP or HTTPS proxy called out
specifically by IPv6 address rather than hostname, it will fail.
Placing an entry in /etc/hosts, or the proxy into DNS (and calling by
hostname) will function.
failure steps:
1) set proxy environment variables
export http_proxy="http://[2001:db8:f00::2]:3128/;
export https_proxy="http://[2001:db8:f00::2]:3128/;
2) Attempt to add repository (in this case, a PPA):
apt-add-repository ppa:ansible/ansible
3) Enjoy the resulting stack trace:
Traceback (most recent call last):
File "/usr/bin/apt-add-repository", line 364, in
sys.exit(0 if addaptrepo.main() else 1)
File "/usr/bin/apt-add-repository", line 347, in main
shortcut = handler(source, **shortcut_params)
File "/usr/lib/python3/dist-packages/softwareproperties/shortcuts.py", line
40, in shortcut_handler
return handler(shortcut, **kwargs)
File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 82,
in __init__
if self.lpppa.publish_debug_symbols:
File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 120,
in lpppa
self._lpppa = self.lpteam.getPPAByName(name=self.ppaname)
File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 107,
in lpteam
self._lpteam = self.lp.people(self.teamname)
File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 98,
in lp
self._lp = login_func("%s.%s" % (self.__module__,
self.__class__.__name__),
File "/usr/lib/python3/dist-packages/launchpadlib/launchpad.py", line 494,
in login_anonymously
return cls(
File "/usr/lib/python3/dist-packages/launchpadlib/launchpad.py", line 230,
in __init__
super(Launchpad, self).__init__(
File "/usr/lib/python3/dist-packages/lazr/restfulclient/resource.py", line
472, in __init__
self._wadl = self._browser.get_wadl_application(self._root_uri)
File "/usr/lib/python3/dist-packages/lazr/restfulclient/_browser.py", line
447, in get_wadl_application
response, content = self._request(url, media_type=wadl_type)
File "/usr/lib/python3/dist-packages/lazr/restfulclient/_browser.py", line
389, in _request
response, content = self._request_and_retry(
File "/usr/lib/python3/dist-packages/lazr/restfulclient/_browser.py", line
359, in _request_and_retry
response, content = self._connection.request(
File "/usr/lib/python3/dist-packages/httplib2/__init__.py", line 1578, in
request
conn = self.connections[conn_key] = connection_type(
File "/usr/lib/python3/dist-packages/httplib2/__init__.py", line 1095, in
__init__
self.proxy_info = proxy_info("https")
File "/usr/lib/python3/dist-packages/httplib2/__init__.py", line 926, in
proxy_info_from_environment
return proxy_info_from_url(url, method, noproxy=None)
File "/usr/lib/python3/dist-packages/httplib2/__init__.py", line 950, in
proxy_info_from_url
port = int(port)
ValueError: invalid literal for int() with base 10: 'db8:f00::2]:3128'
Ubuntu Release:
# lsb_release -rd
Description: Ubuntu 22.04.2 LTS
Release: 22.04
Package version:
# apt-cache policy software-properties-common
software-properties-common:
Installed: 0.99.22.6
Candidate: 0.99.22.6
Version table:
*** 0.99.22.6 500
500 http://archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages
100 /var/lib/dpkg/status
0.99.22 500
500 http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/2013545/+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 2013545] [NEW] /usr/sbin/apt-add-repository will not function with IPv6 proxies called by address
Public bug reported:
It appears that if one has an HTTP or HTTPS proxy called out
specifically by IPv6 address rather than hostname, it will fail.
Placing an entry in /etc/hosts, or the proxy into DNS (and calling by
hostname) will function.
failure steps:
1) set proxy environment variables
export http_proxy="http://[2001:db8:f00::2]:3128/;
export https_proxy="http://[2001:db8:f00::2]:3128/;
2) Attempt to add repository (in this case, a PPA):
apt-add-repository ppa:ansible/ansible
3) Enjoy the resulting stack trace:
Traceback (most recent call last):
File "/usr/bin/apt-add-repository", line 364, in
sys.exit(0 if addaptrepo.main() else 1)
File "/usr/bin/apt-add-repository", line 347, in main
shortcut = handler(source, **shortcut_params)
File "/usr/lib/python3/dist-packages/softwareproperties/shortcuts.py", line
40, in shortcut_handler
return handler(shortcut, **kwargs)
File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 82, in
__init__
if self.lpppa.publish_debug_symbols:
File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 120, in
lpppa
self._lpppa = self.lpteam.getPPAByName(name=self.ppaname)
File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 107, in
lpteam
self._lpteam = self.lp.people(self.teamname)
File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 98, in
lp
self._lp = login_func("%s.%s" % (self.__module__, self.__class__.__name__),
File "/usr/lib/python3/dist-packages/launchpadlib/launchpad.py", line 494, in
login_anonymously
return cls(
File "/usr/lib/python3/dist-packages/launchpadlib/launchpad.py", line 230, in
__init__
super(Launchpad, self).__init__(
File "/usr/lib/python3/dist-packages/lazr/restfulclient/resource.py", line
472, in __init__
self._wadl = self._browser.get_wadl_application(self._root_uri)
File "/usr/lib/python3/dist-packages/lazr/restfulclient/_browser.py", line
447, in get_wadl_application
response, content = self._request(url, media_type=wadl_type)
File "/usr/lib/python3/dist-packages/lazr/restfulclient/_browser.py", line
389, in _request
response, content = self._request_and_retry(
File "/usr/lib/python3/dist-packages/lazr/restfulclient/_browser.py", line
359, in _request_and_retry
response, content = self._connection.request(
File "/usr/lib/python3/dist-packages/httplib2/__init__.py", line 1578, in
request
conn = self.connections[conn_key] = connection_type(
File "/usr/lib/python3/dist-packages/httplib2/__init__.py", line 1095, in
__init__
self.proxy_info = proxy_info("https")
File "/usr/lib/python3/dist-packages/httplib2/__init__.py", line 926, in
proxy_info_from_environment
return proxy_info_from_url(url, method, noproxy=None)
File "/usr/lib/python3/dist-packages/httplib2/__init__.py", line 950, in
proxy_info_from_url
port = int(port)
ValueError: invalid literal for int() with base 10: 'db8:f00::2]:3128'
Ubuntu Release:
# lsb_release -rd
Description:Ubuntu 22.04.2 LTS
Release:22.04
Package version:
# apt-cache policy software-properties-common
software-properties-common:
Installed: 0.99.22.6
Candidate: 0.99.22.6
Version table:
*** 0.99.22.6 500
500 http://archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages
100 /var/lib/dpkg/status
0.99.22 500
500 http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages
** Affects: software-properties (Ubuntu)
Importance: Undecided
Status: New
** Tags: ipv6 proxy
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to software-properties in
Ubuntu.
https://bugs.launchpad.net/bugs/2013545
Title:
/usr/sbin/apt-add-repository will not function with IPv6 proxies
called by address
Status in software-properties package in Ubuntu:
New
Bug description:
It appears that if one has an HTTP or HTTPS proxy called out
specifically by IPv6 address rather than hostname, it will fail.
Placing an entry in /etc/hosts, or the proxy into DNS (and calling by
hostname) will function.
failure steps:
1) set proxy environment variables
export http_proxy="http://[2001:db8:f00::2]:3128/;
export https_proxy="http://[2001:db8:f00::2]:3128/;
2) Attempt to add repository (in this case, a PPA):
apt-add-repository ppa:ansible/ansible
3) Enjoy the resulting stack trace:
Traceback (most recent call last):
File "/usr/bin/apt-add-repository", line 364, in
sys.exit(0 if addaptrepo.main() else 1)
File "/usr/bin/apt-add-repository", line 347, in main
shortcut = handler(source, **shortcut_params)
File "/usr/lib/python3/dist-packages/softwareproperties/shortcuts.py", line
40, in shortcut_handler
return handler(shortcut, **kwargs)
File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 82,
in __init__
if self.lpppa.publish_debug_symbols:
File
[Touch-packages] [Bug 1887655] Re: unattended-upgrades triggers reboot despite configuration
Confirming that we see this behaviour on Ubuntu 20.04 servers (reboots
happening even though `Unattended-Upgrade::Automatic-Reboot` is set to
false).
--
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/1887655
Title:
unattended-upgrades triggers reboot despite configuration
Status in unattended-upgrades package in Ubuntu:
Confirmed
Bug description:
I've been having problems with my Ubuntu machine suddenly rebooting
without any warning. To my knowledge Ubuntu Desktop is not supposed
to reboot without warning by default.
I believe this is being triggered by unattended-upgrades
unattended-upgrades 2.3 (amd64)
Ubuntu Desktop:
Description: Ubuntu 20.04 LTS
Release: 20.04
One pattern that emerges is that the reboot happens right after
unattended-upgrades completes successfully. There are multiple
examples in my /var/log/syslog, but all show "unattended-
upgrades.service: Succeeded." the same second everything begins to
shut down, with nothing for a minute or two prior. Example:
Jul 15 11:17:01 pc systemd[2065]: Starting Notification regarding a new
release of Ubuntu...
Jul 15 11:17:14 pc charon: 08[IKE] sending keep alive to 10.10.10.10[4500]
Jul 15 11:17:22 pc check-new-release-gtk[71843]:
/usr/lib/ubuntu-release-upgrader/check-new-release-gtk:30: PyGIWarning: Gtk was
imported without specifying a version first. Use gi.require_version('Gtk'
, '3.0') before import to ensure that the right version gets loaded.
Jul 15 11:17:22 pc check-new-release-gtk[71843]: from gi.repository import
Gtk
Jul 15 11:17:22 pc check-new-release-gtk[71843]: WARNING:root:timeout
reached, exiting
Jul 15 11:17:22 pc systemd[2065]: update-notifier-release.service: Succeeded.
Jul 15 11:17:22 pc systemd[2065]: Finished Notification regarding a new
release of Ubuntu.
Jul 15 11:17:48 pc mysql-workbench[33350]: gtk_tree_view_unref_tree_helper:
assertion 'node != NULL' failed
Jul 15 11:17:54 pc charon: 09[IKE] sending keep alive to 10.10.10.10[4500]
Jul 15 11:18:03 pc systemd[1]: unattended-upgrades.service: Succeeded.
Jul 15 11:18:03 pc systemd[1]: Stopping Session 3 of user philip.
Jul 15 11:18:03 pc systemd[1]: Removed slice
system-clean\x2dmount\x2dpoint.slice.
Jul 15 11:18:03 pc systemd[1]: Removed slice system-getty.slice.
Jul 15 11:18:03 pc systemd[1]: Removed slice system-modprobe.slice.
Jul 15 11:18:03 pc systemd[1]: Stopped target Block Device Preparation for
/dev/mapper/ubuntu.
Jul 15 11:18:03 pc systemd[2065]: Stopped target GNOME Wayland Session
(session: gnome).
From memory I've never edited the contents of /etc/apt/apt.conf.d/ and
the configuration for unattended upgrades claims to be default (NOT to
reboot):
$ grep -irnC4 reboot /etc/apt/apt.conf.d/
/etc/apt/apt.conf.d/50unattended-upgrades-88-// Do automatic removal of
unused packages after the upgrade
/etc/apt/apt.conf.d/50unattended-upgrades-89-// (equivalent to apt-get
autoremove)
/etc/apt/apt.conf.d/50unattended-upgrades-90-//Unattended-Upgrade::Remove-Unused-Dependencies
"false";
/etc/apt/apt.conf.d/50unattended-upgrades-91-
/etc/apt/apt.conf.d/50unattended-upgrades:92:// Automatically reboot *WITHOUT
CONFIRMATION* if
/etc/apt/apt.conf.d/50unattended-upgrades:93:// the file
/var/run/reboot-required is found after the upgrade
/etc/apt/apt.conf.d/50unattended-upgrades:94://Unattended-Upgrade::Automatic-Reboot
"false";
/etc/apt/apt.conf.d/50unattended-upgrades-95-
/etc/apt/apt.conf.d/50unattended-upgrades:96:// Automatically reboot even if
there are users currently logged in
/etc/apt/apt.conf.d/50unattended-upgrades:97:// when
Unattended-Upgrade::Automatic-Reboot is set to true
/etc/apt/apt.conf.d/50unattended-upgrades:98://Unattended-Upgrade::Automatic-Reboot-WithUsers
"true";
/etc/apt/apt.conf.d/50unattended-upgrades-99-
/etc/apt/apt.conf.d/50unattended-upgrades:100:// If automatic reboot is
enabled and needed, reboot at the specific
/etc/apt/apt.conf.d/50unattended-upgrades-101-// time instead of immediately
/etc/apt/apt.conf.d/50unattended-upgrades-102-// Default: "now"
/etc/apt/apt.conf.d/50unattended-upgrades:103://Unattended-Upgrade::Automatic-Reboot-Time
"02:00";
/etc/apt/apt.conf.d/50unattended-upgrades-104-
/etc/apt/apt.conf.d/50unattended-upgrades-105-// Use apt bandwidth limit
feature, this example limits the download
/etc/apt/apt.conf.d/50unattended-upgrades-106-// speed to 70kb/sec
/etc/apt/apt.conf.d/50unattended-upgrades-107-//Acquire::http::Dl-Limit "70";
journalctl -u unattended-upgrades
Jul 10 07:52:31 PC systemd[1]: Started Unattended Upgrades Shutdown.
Jul 14 10:03:03 PC systemd[1]: unattended-upgrades.service: Succeeded.
-- Reboot --
Jul 14 10:04:11 PC systemd[1]: Started Unattended Upgrades Shutdown.
Jul 15 11:18:03 PC systemd[1]:
[Touch-packages] [Bug 1977748] Re: Build Cairo with OpenGL support
Here is a link for cairo/egl: https://jan.newmarch.name/Wayland/Cairo/ -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cairo in Ubuntu. https://bugs.launchpad.net/bugs/1977748 Title: Build Cairo with OpenGL support Status in cairo package in Ubuntu: Triaged Bug description: Instructed by "ask a question" I tried to file a wayland-targeted bug, but apport-bug thinks I'm running Xorg. See https://answers.launchpad.net/ubuntu/+question/702075 PRETTY_NAME="Ubuntu 22.04 LTS" NAME="Ubuntu" VERSION_ID="22.04" VERSION="22.04 LTS (Jammy Jellyfish)" VERSION_CODENAME=jammy $ ps -ef | grep Xwayland xx 24931685 0 Jun04 ?00:05:36 /usr/bin/Xwayland :0 -rootless -noreset -accessx -core -auth /run/user/1001/.mutter-Xwaylandauth.5ZZYM1 -listen 4 -listen 5 -displayfd 6 -initfd 7 ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: xorg 1:7.7+23ubuntu2 ProcVersionSignature: Ubuntu 5.15.0-35.36-generic 5.15.35 Uname: Linux 5.15.0-35-generic x86_64 ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CasperMD5CheckResult: pass CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins' CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Mon Jun 6 06:40:48 2022 DistUpgraded: Fresh install DistroCodename: jammy DistroVariant: ubuntu ExtraDebuggingInterest: Yes GraphicsCard: Intel Corporation TigerLake-LP GT2 [Iris Xe Graphics] [8086:9a49] (rev 01) (prog-if 00 [VGA controller]) Subsystem: Dell TigerLake-LP GT2 [Iris Xe Graphics] [1028:0991] InstallationDate: Installed on 2021-10-02 (246 days ago) InstallationMedia: Ubuntu 21.04 "Hirsute Hippo" - Release amd64 (20210420) MachineType: Dell Inc. XPS 13 9310 ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-35-generic root=UUID=c737013a-1cc7-494f-a1b7-a6efce6f09f7 ro quiet splash vt.handoff=7 SourcePackage: xorg Symptom: display UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 03/17/2022 dmi.bios.release: 3.6 dmi.bios.vendor: Dell Inc. dmi.bios.version: 3.6.0 dmi.board.name: 0MK6WC dmi.board.vendor: Dell Inc. dmi.board.version: A00 dmi.chassis.type: 10 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvr3.6.0:bd03/17/2022:br3.6:svnDellInc.:pnXPS139310:pvr:rvnDellInc.:rn0MK6WC:rvrA00:cvnDellInc.:ct10:cvr:sku0991: dmi.product.family: XPS dmi.product.name: XPS 13 9310 dmi.product.sku: 0991 dmi.sys.vendor: Dell Inc. version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.110-1ubuntu1 version.libgl1-mesa-dri: libgl1-mesa-dri 22.0.1-1ubuntu2 version.libgl1-mesa-glx: libgl1-mesa-glx N/A version.xserver-xorg-core: xserver-xorg-core 2:21.1.3-2ubuntu2 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-2build3 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20210115-1 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.17-2build1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cairo/+bug/1977748/+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 1999086] [NEW] Livepatch attaches after a long time but indicates failure to attach to Ubuntu Advantage
Public bug reported: It seems that attaching to Ubuntu Advantage takes a long time. When I tried to attach using my token in the GUI, it repeatedly told me that I "failed to attach, try again". Finally I gave up and canceled out of the dialog, only to see that in the underlying UI for the Livepatch tab it was successfully attached already. It seems that it takes too long to attach and the token attach dialog gets stuck thinking it will never attach, when either 1.) it's just taking a while or 2.) it has already attached in the background but the dialog doesn't understand. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: software-properties-gtk 0.99.22.3 ProcVersionSignature: Ubuntu 5.15.0-56.62-generic 5.15.64 Uname: Linux 5.15.0-56-generic x86_64 NonfreeKernelModules: wl ApportVersion: 2.20.11-0ubuntu82.2 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Wed Dec 7 12:44:30 2022 InstallationDate: Installed on 2022-11-14 (23 days ago) InstallationMedia: Ubuntu 22.04.1 LTS "Jammy Jellyfish" - Release amd64 (20220809.1) PackageArchitecture: all ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/usr/bin/zsh SourcePackage: software-properties UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: software-properties (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug jammy -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to software-properties in Ubuntu. https://bugs.launchpad.net/bugs/1999086 Title: Livepatch attaches after a long time but indicates failure to attach to Ubuntu Advantage Status in software-properties package in Ubuntu: New Bug description: It seems that attaching to Ubuntu Advantage takes a long time. When I tried to attach using my token in the GUI, it repeatedly told me that I "failed to attach, try again". Finally I gave up and canceled out of the dialog, only to see that in the underlying UI for the Livepatch tab it was successfully attached already. It seems that it takes too long to attach and the token attach dialog gets stuck thinking it will never attach, when either 1.) it's just taking a while or 2.) it has already attached in the background but the dialog doesn't understand. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: software-properties-gtk 0.99.22.3 ProcVersionSignature: Ubuntu 5.15.0-56.62-generic 5.15.64 Uname: Linux 5.15.0-56-generic x86_64 NonfreeKernelModules: wl ApportVersion: 2.20.11-0ubuntu82.2 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Wed Dec 7 12:44:30 2022 InstallationDate: Installed on 2022-11-14 (23 days ago) InstallationMedia: Ubuntu 22.04.1 LTS "Jammy Jellyfish" - Release amd64 (20220809.1) PackageArchitecture: all ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/usr/bin/zsh SourcePackage: software-properties UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1999086/+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 1979032] [NEW] cpu_freq returns current value in GHz but min/max (fixed in 5.9.1)
Public bug reported: Can python-psutil be updated to 5.9.1? It fixes incorrect cpu_freq which affects s-tui. https://github.com/giampaolo/psutil/issues/2049 https://github.com/amanusk/s-tui/issues/186#issuecomment-1100639705 Thanks ** Affects: python-psutil (Ubuntu) Importance: Undecided Status: New ** Description changed: - Can python-psutil be updated to 5.9.1? It fixes incorrect cpu_freq which - affects s-tui. + Can python-psutil be updated to 5.9.1? It fixes incorrect cpu_freq which affects s-tui. + https://github.com/giampaolo/psutil/issues/2049 https://github.com/amanusk/s-tui/issues/186#issuecomment-1100639705 Thanks -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python-psutil in Ubuntu. https://bugs.launchpad.net/bugs/1979032 Title: cpu_freq returns current value in GHz but min/max (fixed in 5.9.1) Status in python-psutil package in Ubuntu: New Bug description: Can python-psutil be updated to 5.9.1? It fixes incorrect cpu_freq which affects s-tui. https://github.com/giampaolo/psutil/issues/2049 https://github.com/amanusk/s-tui/issues/186#issuecomment-1100639705 Thanks To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python-psutil/+bug/1979032/+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 1977748] Re: Build Cairo with OpenGL support
I was looking to run cairo on wayland. A web search led me to the EGL device. I'm guessing by buffer you mean IMAGE surface (after digging in the headers a bit). I am happy to try that. But I'm guessing at some point in the future peeps will want it. Thanks for digging in. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cairo in Ubuntu. https://bugs.launchpad.net/bugs/1977748 Title: Build Cairo with OpenGL support Status in cairo package in Ubuntu: Triaged Bug description: Instructed by "ask a question" I tried to file a wayland-targeted bug, but apport-bug thinks I'm running Xorg. See https://answers.launchpad.net/ubuntu/+question/702075 PRETTY_NAME="Ubuntu 22.04 LTS" NAME="Ubuntu" VERSION_ID="22.04" VERSION="22.04 LTS (Jammy Jellyfish)" VERSION_CODENAME=jammy $ ps -ef | grep Xwayland xx 24931685 0 Jun04 ?00:05:36 /usr/bin/Xwayland :0 -rootless -noreset -accessx -core -auth /run/user/1001/.mutter-Xwaylandauth.5ZZYM1 -listen 4 -listen 5 -displayfd 6 -initfd 7 ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: xorg 1:7.7+23ubuntu2 ProcVersionSignature: Ubuntu 5.15.0-35.36-generic 5.15.35 Uname: Linux 5.15.0-35-generic x86_64 ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CasperMD5CheckResult: pass CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins' CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Mon Jun 6 06:40:48 2022 DistUpgraded: Fresh install DistroCodename: jammy DistroVariant: ubuntu ExtraDebuggingInterest: Yes GraphicsCard: Intel Corporation TigerLake-LP GT2 [Iris Xe Graphics] [8086:9a49] (rev 01) (prog-if 00 [VGA controller]) Subsystem: Dell TigerLake-LP GT2 [Iris Xe Graphics] [1028:0991] InstallationDate: Installed on 2021-10-02 (246 days ago) InstallationMedia: Ubuntu 21.04 "Hirsute Hippo" - Release amd64 (20210420) MachineType: Dell Inc. XPS 13 9310 ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-35-generic root=UUID=c737013a-1cc7-494f-a1b7-a6efce6f09f7 ro quiet splash vt.handoff=7 SourcePackage: xorg Symptom: display UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 03/17/2022 dmi.bios.release: 3.6 dmi.bios.vendor: Dell Inc. dmi.bios.version: 3.6.0 dmi.board.name: 0MK6WC dmi.board.vendor: Dell Inc. dmi.board.version: A00 dmi.chassis.type: 10 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvr3.6.0:bd03/17/2022:br3.6:svnDellInc.:pnXPS139310:pvr:rvnDellInc.:rn0MK6WC:rvrA00:cvnDellInc.:ct10:cvr:sku0991: dmi.product.family: XPS dmi.product.name: XPS 13 9310 dmi.product.sku: 0991 dmi.sys.vendor: Dell Inc. version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.110-1ubuntu1 version.libgl1-mesa-dri: libgl1-mesa-dri 22.0.1-1ubuntu2 version.libgl1-mesa-glx: libgl1-mesa-glx N/A version.xserver-xorg-core: xserver-xorg-core 2:21.1.3-2ubuntu2 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-2build3 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20210115-1 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.17-2build1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cairo/+bug/1977748/+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 1937110] Re: dhcp option 121 & 249
I'll also add that installers for past LTS Ubuntu releases do work in our environment. I opened up the Focal initrd.gz we use for PXE based installs (I think it was from the mini.iso which I guess is now classified as a "Legacy Image", http://archive.ubuntu.com/ubuntu/dists/focal/main/installer- amd64/current/legacy-images/netboot/mini.iso). What I found is that it also is missing /etc/dhcp/dhclient-exit-hooks.d/rfc3442-classless-routes HOWEVER it has an older /sbin/dhclient-script that does NOT have the code that ignores "routers" option values when the RFC 3442 option 121 is present in the response. As a result it does configure the default route based on the DHCP "routers" value but ignores the RFC 3442 info. In our environment this means the routing is sub-optimal but networking still largely functions and thus Focal installation "works". The original poster reports trouble with Focal installer I don't know if the difference is because they use a different Focal .iso or because perhaps they strongly require the RFC 3442 routes for networking to function in their environment. My recollection regarding the changes in the newer dhclient-script is that it that ignoring the "routers" option if the client supports and uses the RFC 3442 routes option is the behavior specified in RFC 3442, that the behavior of the old version to sort-of merge the "routers" option and the RFC 3442 option 121 together was non-compliant. Though as it turns out if the "rfc3442-classless-routes" hook file is accidentally missing then that makes the behavior of the newer, more correct dhclient-script version worse. --Matt -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to busybox in Ubuntu. https://bugs.launchpad.net/bugs/1937110 Title: dhcp option 121 & 249 Status in subiquity: New Status in busybox package in Ubuntu: Confirmed Bug description: Hello, I'm running into issues with subiquity on a cloud provider. The cloud provider is using an on-link L3 gateway. His DHCP response looks like this: OPTION: 53 ( 1) DHCP message type 5 (DHCPACK) OPTION: 54 ( 4) Server identifier 172.31.1.1 OPTION: 51 ( 4) IP address leasetime 86400 (24h) OPTION: 1 ( 4) Subnet mask 255.255.255.255 OPTION: 3 ( 4) Routers 172.31.1.1 OPTION: 6 ( 12) DNS server OPTION: 121 ( 14) Classless Static Route20ac1f010100 ... ac1f0101 .. OPTION: 249 ( 14) MSFT - Classless route20ac1f010100 ... ac1f0101 .. Im booting the subiquity process with an patched ipxe (https://github.com/ipxe/ipxe/pull/104) like this: #!ipxe kernel .../vmlinuz initrd=initrd root=/dev/ram0 ramdisk_size=150 ip=dhcp url=https://cdimage.ubuntu.com/ubuntu-server/focal/daily-live/current/focal-live-server-amd64.iso autoinstall ds=nocloud-net;s=.../...-ad-78/ cloud-config-url=/dev/null initrd .../initrd boot initrd/vmlinuz is extracted right out of focal-live-server-amd64.iso Sadly subiquity is stuck with a broken network (because of missing dhcp option 121/249 support). It happens when its running the /init from the kernel right after kernel is booted, i guess even before the subiquity is started(?). After further debugging, it looks like the provided kernel 5.4.80 #90 Ubuntu, is using busybox 1.30.1-4ubuntu~6.3 which includes isc- dhclient-4.4.1 which is lacking the given options. Would be awesome if this could be fixed.. maybe just a simple busybox compile option? To manage notifications about this bug go to: https://bugs.launchpad.net/subiquity/+bug/1937110/+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 1937110] Re: dhcp option 121 & 249
The Ubuntu Jammy installer initrd is missing the /etc/dhcp/dhclient-
exit-hooks.d/rfc3442-classless-routes hook for dhclient. The
/sbin/dhclient-script included in the initrd assumes the hook is present
and if the "rfc3442_classless_static_routes" DHCP is sent by the DHCP
server it ignores the the "routers" DHCP option and defers to the
rfc3442 hook to setup the routing ...except that hook is missing so
ultimately no routing is configured if the rfc3442 option 121
("classless-static-routes" w/ ISC dhcpd) exists in the DHCP response.
This means networking doesn't function and we cannot install Ubuntu.
My colleague tested modifying the initrd by adding the
/etc/dhcp/dhclient-exit-hooks.d/rfc3442-classless-routes file and
reports that works.
--Matt
# from the initrd rescue shell
(initramfs) ls /etc/dhcp/dhclient-exit-hooks.d/rfc3442-classless-routes
ls: cannot access /etc/dhcp/dhclient-exit-hooks.d/rfc3442-classless-routes: No
such file or directory
# showing that the "routers" option is ignored if rfc3442 info is sent
(initramfs) grep -C1 classless /sbin/dhclient-script
# if we have $new_rfc3442_classless_static_routes then we have to
# ignore $new_routers entirely
if [ ! "$new_rfc3442_classless_static_routes" ]; then
# set if_metric if IF_METRIC is set or there's more than
one router
--
if [ -z "$new_routers" ] || ping -q -c 1 "${new_routers%% *}"; then
# if we have $new_rfc3442_classless_static_routes then we have to
# ignore $new_routers entirely
if [ ! "$new_rfc3442_classless_static_routes" ]; then
if [ -n "$alias_ip_address" ] &&
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to busybox in Ubuntu.
https://bugs.launchpad.net/bugs/1937110
Title:
dhcp option 121 & 249
Status in subiquity:
New
Status in busybox package in Ubuntu:
Confirmed
Bug description:
Hello,
I'm running into issues with subiquity on a cloud provider. The cloud
provider is using an on-link L3 gateway.
His DHCP response looks like this:
OPTION: 53 ( 1) DHCP message type 5 (DHCPACK)
OPTION: 54 ( 4) Server identifier 172.31.1.1
OPTION: 51 ( 4) IP address leasetime 86400 (24h)
OPTION: 1 ( 4) Subnet mask 255.255.255.255
OPTION: 3 ( 4) Routers 172.31.1.1
OPTION: 6 ( 12) DNS server
OPTION: 121 ( 14) Classless Static Route20ac1f010100 ...
ac1f0101 ..
OPTION: 249 ( 14) MSFT - Classless route20ac1f010100 ...
ac1f0101 ..
Im booting the subiquity process with an patched ipxe
(https://github.com/ipxe/ipxe/pull/104) like this:
#!ipxe
kernel .../vmlinuz initrd=initrd root=/dev/ram0 ramdisk_size=150 ip=dhcp
url=https://cdimage.ubuntu.com/ubuntu-server/focal/daily-live/current/focal-live-server-amd64.iso
autoinstall ds=nocloud-net;s=.../...-ad-78/ cloud-config-url=/dev/null
initrd .../initrd
boot
initrd/vmlinuz is extracted right out of focal-live-server-amd64.iso
Sadly subiquity is stuck with a broken network (because of missing
dhcp option 121/249 support). It happens when its running the /init
from the kernel right after kernel is booted, i guess even before the
subiquity is started(?).
After further debugging, it looks like the provided kernel 5.4.80 #90
Ubuntu, is using busybox 1.30.1-4ubuntu~6.3 which includes isc-
dhclient-4.4.1 which is lacking the given options.
Would be awesome if this could be fixed.. maybe just a simple busybox compile
option?
To manage notifications about this bug go to:
https://bugs.launchpad.net/subiquity/+bug/1937110/+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 1947588] Re: Infinite Loop in OpenSSL s_server
FYI, upstream have now also merged a fix in the 1.1.1 branch: https://github.com/openssl/openssl/commit/e04ba889594d84a8805f3d0caeadf0527470e508 If Ubuntu pulls in that patch I expect that this bug should be fixed by it. -- 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/1947588 Title: Infinite Loop in OpenSSL s_server Status in openssl package in Ubuntu: Confirmed Status in openssl source package in Focal: Confirmed Status in openssl source package in Impish: Confirmed Status in openssl source package in Jammy: Confirmed Bug description: Launching openssl s_server as follows: $ openssl s_server -nocert -psk 01020304 -dtls1 And using openssl s_client to connect to it like this: $ openssl s_client -dtls1 -psk 01020304 Results in s_server entering an infinite loop: Using default temp DH parameters ACCEPT ERROR 140247926990208:error:141FC044:SSL routines:tls_setup_handshake:internal error:../ssl/statem/statem_lib.c:109: ERROR 140247926990208:error:141FC044:SSL routines:tls_setup_handshake:internal error:../ssl/statem/statem_lib.c:109: ERROR ...and so on... I have confirmed that upstream OpenSSL does not have this issue in a default build of 1.1.1j or 1.1.1k. Upstream 1.1.1l has a different bug with these commands (https://github.com/openssl/openssl/issues/16707) and it was while working on the fix for that issue (https://github.com/openssl/openssl/pull/16838) that I noticed this problem in the Ubuntu packages. $ lsb_release -rd Description: Ubuntu 21.04 Release: 21.04 $ apt-cache policy openssl openssl: Installed: 1.1.1j-1ubuntu3.5 Candidate: 1.1.1j-1ubuntu3.5 Version table: *** 1.1.1j-1ubuntu3.5 500 500 http://gb.archive.ubuntu.com/ubuntu hirsute-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu hirsute-security/main amd64 Packages 100 /var/lib/dpkg/status 1.1.1j-1ubuntu3 500 500 http://gb.archive.ubuntu.com/ubuntu hirsute/main amd64 Packages $ openssl version -a OpenSSL 1.1.1j 16 Feb 2021 built on: Mon Aug 23 17:02:39 2021 UTC platform: debian-amd64 options: bn(64,64) rc4(16x,int) des(int) blowfish(ptr) compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 -ffile-prefix-map=/build/openssl-5U8yxE/openssl-1.1.1j=. -flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security -DOPENSSL_TLS_SECURITY_LEVEL=2 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2 OPENSSLDIR: "/usr/lib/ssl" ENGINESDIR: "/usr/lib/x86_64-linux-gnu/engines-1.1" Seeding source: os-specific To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1947588/+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 1947588] Re: Infinite Loop in OpenSSL s_server
FYI, upstream merged a fix for the underlying problem in OpenSSL 3.0: https://github.com/openssl/openssl/commit/8b63b174b00b0e8c5cefcea12989d90450e04b24 I expect a similar fix to be backported to 1.1.1 soon. Although the specific issue that this bug report is about doesn't impact upstream, I expect that any backported fix will also resolve this bug. -- 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/1947588 Title: Infinite Loop in OpenSSL s_server Status in openssl package in Ubuntu: Confirmed Status in openssl source package in Focal: Confirmed Status in openssl source package in Impish: Confirmed Status in openssl source package in Jammy: Confirmed Bug description: Launching openssl s_server as follows: $ openssl s_server -nocert -psk 01020304 -dtls1 And using openssl s_client to connect to it like this: $ openssl s_client -dtls1 -psk 01020304 Results in s_server entering an infinite loop: Using default temp DH parameters ACCEPT ERROR 140247926990208:error:141FC044:SSL routines:tls_setup_handshake:internal error:../ssl/statem/statem_lib.c:109: ERROR 140247926990208:error:141FC044:SSL routines:tls_setup_handshake:internal error:../ssl/statem/statem_lib.c:109: ERROR ...and so on... I have confirmed that upstream OpenSSL does not have this issue in a default build of 1.1.1j or 1.1.1k. Upstream 1.1.1l has a different bug with these commands (https://github.com/openssl/openssl/issues/16707) and it was while working on the fix for that issue (https://github.com/openssl/openssl/pull/16838) that I noticed this problem in the Ubuntu packages. $ lsb_release -rd Description: Ubuntu 21.04 Release: 21.04 $ apt-cache policy openssl openssl: Installed: 1.1.1j-1ubuntu3.5 Candidate: 1.1.1j-1ubuntu3.5 Version table: *** 1.1.1j-1ubuntu3.5 500 500 http://gb.archive.ubuntu.com/ubuntu hirsute-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu hirsute-security/main amd64 Packages 100 /var/lib/dpkg/status 1.1.1j-1ubuntu3 500 500 http://gb.archive.ubuntu.com/ubuntu hirsute/main amd64 Packages $ openssl version -a OpenSSL 1.1.1j 16 Feb 2021 built on: Mon Aug 23 17:02:39 2021 UTC platform: debian-amd64 options: bn(64,64) rc4(16x,int) des(int) blowfish(ptr) compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 -ffile-prefix-map=/build/openssl-5U8yxE/openssl-1.1.1j=. -flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security -DOPENSSL_TLS_SECURITY_LEVEL=2 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2 OPENSSLDIR: "/usr/lib/ssl" ENGINESDIR: "/usr/lib/x86_64-linux-gnu/engines-1.1" Seeding source: os-specific To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1947588/+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 1947588] Re: Infinite Loop in OpenSSL s_server
Thanks for your analysis. Based on your description I was able to find an instance of this bug that impacts an unmodified upstream OpenSSL directly. I've raised an issue for it here: https://github.com/openssl/openssl/issues/18047 That particular instance only impacts OpenSSL 3.0 - but its the same underlying cause as here. ** Bug watch added: github.com/openssl/openssl/issues #18047 https://github.com/openssl/openssl/issues/18047 -- 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/1947588 Title: Infinite Loop in OpenSSL s_server Status in openssl package in Ubuntu: Confirmed Status in openssl source package in Focal: Confirmed Status in openssl source package in Impish: Confirmed Status in openssl source package in Jammy: Confirmed Bug description: Launching openssl s_server as follows: $ openssl s_server -nocert -psk 01020304 -dtls1 And using openssl s_client to connect to it like this: $ openssl s_client -dtls1 -psk 01020304 Results in s_server entering an infinite loop: Using default temp DH parameters ACCEPT ERROR 140247926990208:error:141FC044:SSL routines:tls_setup_handshake:internal error:../ssl/statem/statem_lib.c:109: ERROR 140247926990208:error:141FC044:SSL routines:tls_setup_handshake:internal error:../ssl/statem/statem_lib.c:109: ERROR ...and so on... I have confirmed that upstream OpenSSL does not have this issue in a default build of 1.1.1j or 1.1.1k. Upstream 1.1.1l has a different bug with these commands (https://github.com/openssl/openssl/issues/16707) and it was while working on the fix for that issue (https://github.com/openssl/openssl/pull/16838) that I noticed this problem in the Ubuntu packages. $ lsb_release -rd Description: Ubuntu 21.04 Release: 21.04 $ apt-cache policy openssl openssl: Installed: 1.1.1j-1ubuntu3.5 Candidate: 1.1.1j-1ubuntu3.5 Version table: *** 1.1.1j-1ubuntu3.5 500 500 http://gb.archive.ubuntu.com/ubuntu hirsute-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu hirsute-security/main amd64 Packages 100 /var/lib/dpkg/status 1.1.1j-1ubuntu3 500 500 http://gb.archive.ubuntu.com/ubuntu hirsute/main amd64 Packages $ openssl version -a OpenSSL 1.1.1j 16 Feb 2021 built on: Mon Aug 23 17:02:39 2021 UTC platform: debian-amd64 options: bn(64,64) rc4(16x,int) des(int) blowfish(ptr) compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 -ffile-prefix-map=/build/openssl-5U8yxE/openssl-1.1.1j=. -flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security -DOPENSSL_TLS_SECURITY_LEVEL=2 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2 OPENSSLDIR: "/usr/lib/ssl" ENGINESDIR: "/usr/lib/x86_64-linux-gnu/engines-1.1" Seeding source: os-specific To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1947588/+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 1966800] [NEW] systemd locks up due to incorrect handling of time zone changes
Public bug reported: Recently on systems in Ireland, systemd became unresponsive due the change from GMT to Irish Standard Time. This is due to Ireland being unique in having their standard time during the summer, unlike most regions. Related to: https://bugzilla.redhat.com/show_bug.cgi?id=1941335 Fixed by: https://github.com/systemd/systemd-stable/commit/a8b66ca9af811148b67ee952ab32748f88b8bba3 ** Affects: systemd (Ubuntu) Importance: Undecided Status: Confirmed ** Affects: systemd (Fedora) Importance: Unknown Status: Unknown -- 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/1966800 Title: systemd locks up due to incorrect handling of time zone changes Status in systemd package in Ubuntu: Confirmed Status in systemd package in Fedora: Unknown Bug description: Recently on systems in Ireland, systemd became unresponsive due the change from GMT to Irish Standard Time. This is due to Ireland being unique in having their standard time during the summer, unlike most regions. Related to: https://bugzilla.redhat.com/show_bug.cgi?id=1941335 Fixed by: https://github.com/systemd/systemd-stable/commit/a8b66ca9af811148b67ee952ab32748f88b8bba3 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1966800/+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 1964506] [NEW] Ping: checks payloads incorrectly, ignores all mismatch replies
Public bug reported: Problematic commit reverted upstream causing incorrect behavior in Ubuntu Focal. Discussion: https://github.com/iputils/iputils/issues/320 Fix: https://github.com/iputils/iputils/pull/321 Release: https://github.com/iputils/iputils/releases/tag/20210722 Could this patch be added for a Focal update please? 1) Ubuntu 20.04.3 LTS 2) 3:20190709-3 3) focal$ ping -c 1 -s 1200 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 1200(1228) bytes of data. --- 8.8.8.8 ping statistics --- 1 packets transmitted, 0 received, 100% packet loss, time 0ms 4) xenial$ ping -c 1 -s 1200 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 1200(1228) bytes of data. 76 bytes from 8.8.8.8: icmp_seq=1 ttl=61 (truncated) --- 8.8.8.8 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.284/0.284/0.284/0.000 ms ** Affects: iputils (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iputils in Ubuntu. https://bugs.launchpad.net/bugs/1964506 Title: Ping: checks payloads incorrectly, ignores all mismatch replies Status in iputils package in Ubuntu: New Bug description: Problematic commit reverted upstream causing incorrect behavior in Ubuntu Focal. Discussion: https://github.com/iputils/iputils/issues/320 Fix: https://github.com/iputils/iputils/pull/321 Release: https://github.com/iputils/iputils/releases/tag/20210722 Could this patch be added for a Focal update please? 1) Ubuntu 20.04.3 LTS 2) 3:20190709-3 3) focal$ ping -c 1 -s 1200 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 1200(1228) bytes of data. --- 8.8.8.8 ping statistics --- 1 packets transmitted, 0 received, 100% packet loss, time 0ms 4) xenial$ ping -c 1 -s 1200 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 1200(1228) bytes of data. 76 bytes from 8.8.8.8: icmp_seq=1 ttl=61 (truncated) --- 8.8.8.8 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.284/0.284/0.284/0.000 ms To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iputils/+bug/1964506/+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 1956275] [NEW] apt autoremove uninstalls nvidia graphics card drivers
Public bug reported: Hardware information: Razer Blade 15 mid 2019, RTX2060 OS Kubuntu 21.10 command ran: apt autoremove What I expected to happen: Unnecessary packages are removed by autoremove What happened: GPU drivers are removed, preventing graphical interfaces from being used apt logs: Start-Date: 2022-01-03 18:34:51 Commandline: apt autoremove Requested-By: matt (1000) Remove: libnvidia-common-470:amd64 (470.86-0ubuntu0.21.10.1), libxnvctrl0:amd64 (470.57.01-0ubuntu3), libnvidia-fbc1-470:amd64 (470.86-0ubuntu0.21.10.1), libnvidia-fbc1-470:i386 (470.86-0ubuntu0.21.10.1), libnvidia-gl-470:amd64 (470.86-0ubuntu0.21.10.1), libnvidia-gl-470:i386 (470.86-0ubuntu0.21.10.1), libnvidia-extra-470:amd64 (470.86-0ubuntu0.21.10.1), nvidia-compute-utils-470:amd64 (470.86-0ubuntu0.21.10.1), libnvidia-encode-470:amd64 (470.86-0ubuntu0.21.10.1), libnvidia-encode-470:i386 (470.86-0ubuntu0.21.10.1), nvidia-utils-470:amd64 (470.86-0ubuntu0.21.10.1), xserver-xorg-video-nvidia-470:amd64 (470.86-0ubuntu0.21.10.1), libnvidia-ifr1-470:amd64 (470.86-0ubuntu0.21.10.1), libnvidia-ifr1-470:i386 (470.86-0ubuntu0.21.10.1), libsdl-ttf2.0-0:amd64 (2.0.11-6), libnvidia-decode-470:amd64 (470.86-0ubuntu0.21.10.1), libnvidia-decode-470:i386 (470.86-0ubuntu0.21.10.1), screen-resolution-extra:amd64 (0.18.1), nvidia-settings:amd64 (470.57.01-0ubuntu3), lynx-common:amd64 (2.9.0dev.6-3), libnvidia-cfg1-470:amd64 (470.86-0ubuntu0.21.10.1), nvidia-kernel-source-470:amd64 (470.86-0ubuntu0.21.10.1), libnvidia-compute-470:i386 (470.86-0ubuntu0.21.10.1) ProblemType: Bug DistroRelease: Ubuntu 21.10 Package: apt 2.3.9 ProcVersionSignature: Ubuntu 5.13.0-22.22-generic 5.13.19 Uname: Linux 5.13.0-22-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu71 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: KDE Date: Mon Jan 3 21:11:15 2022 InstallationDate: Installed on 2021-12-26 (9 days ago) InstallationMedia: Kubuntu 21.10 "Impish Indri" - Release amd64 (20211012) ProcEnviron: PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/zsh SourcePackage: apt UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: apt (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug impish -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1956275 Title: apt autoremove uninstalls nvidia graphics card drivers Status in apt package in Ubuntu: New Bug description: Hardware information: Razer Blade 15 mid 2019, RTX2060 OS Kubuntu 21.10 command ran: apt autoremove What I expected to happen: Unnecessary packages are removed by autoremove What happened: GPU drivers are removed, preventing graphical interfaces from being used apt logs: Start-Date: 2022-01-03 18:34:51 Commandline: apt autoremove Requested-By: matt (1000) Remove: libnvidia-common-470:amd64 (470.86-0ubuntu0.21.10.1), libxnvctrl0:amd64 (470.57.01-0ubuntu3), libnvidia-fbc1-470:amd64 (470.86-0ubuntu0.21.10.1), libnvidia-fbc1-470:i386 (470.86-0ubuntu0.21.10.1), libnvidia-gl-470:amd64 (470.86-0ubuntu0.21.10.1), libnvidia-gl-470:i386 (470.86-0ubuntu0.21.10.1), libnvidia-extra-470:amd64 (470.86-0ubuntu0.21.10.1), nvidia-compute-utils-470:amd64 (470.86-0ubuntu0.21.10.1), libnvidia-encode-470:amd64 (470.86-0ubuntu0.21.10.1), libnvidia-encode-470:i386 (470.86-0ubuntu0.21.10.1), nvidia-utils-470:amd64 (470.86-0ubuntu0.21.10.1), xserver-xorg-video-nvidia-470:amd64 (470.86-0ubuntu0.21.10.1), libnvidia-ifr1-470:amd64 (470.86-0ubuntu0.21.10.1), libnvidia-ifr1-470:i386 (470.86-0ubuntu0.21.10.1), libsdl-ttf2.0-0:amd64 (2.0.11-6), libnvidia-decode-470:amd64 (470.86-0ubuntu0.21.10.1), libnvidia-decode-470:i386 (470.86-0ubuntu0.21.10.1), screen-resolution-extra:amd64 (0.18.1), nvidia-settings:amd64 (470.57.01-0ubuntu3), lynx-common:amd64 (2.9.0dev.6-3), libnvidia-cfg1-470:amd64 (470.86-0ubuntu0.21.10.1), nvidia-kernel-source-470:amd64 (470.86-0ubuntu0.21.10.1), libnvidia-compute-470:i386 (470.86-0ubuntu0.21.10.1) ProblemType: Bug DistroRelease: Ubuntu 21.10 Package: apt 2.3.9 ProcVersionSignature: Ubuntu 5.13.0-22.22-generic 5.13.19 Uname: Linux 5.13.0-22-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu71 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: KDE Date: Mon Jan 3 21:11:15 2022 InstallationDate: Installed on 2021-12-26 (9 days ago) InstallationMedia: Kubuntu 21.10 "Impish Indri" - Release amd64 (20211012) ProcEnviron: PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/zsh SourcePackage: apt UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1956275/+subscriptions --
[Touch-packages] [Bug 1947588] [NEW] Infinite Loop in OpenSSL s_server
Public bug reported: Launching openssl s_server as follows: $ openssl s_server -nocert -psk 01020304 -dtls1 And using openssl s_client to connect to it like this: $ openssl s_client -dtls1 -psk 01020304 Results in s_server entering an infinite loop: Using default temp DH parameters ACCEPT ERROR 140247926990208:error:141FC044:SSL routines:tls_setup_handshake:internal error:../ssl/statem/statem_lib.c:109: ERROR 140247926990208:error:141FC044:SSL routines:tls_setup_handshake:internal error:../ssl/statem/statem_lib.c:109: ERROR ...and so on... I have confirmed that upstream OpenSSL does not have this issue in a default build of 1.1.1j or 1.1.1k. Upstream 1.1.1l has a different bug with these commands (https://github.com/openssl/openssl/issues/16707) and it was while working on the fix for that issue (https://github.com/openssl/openssl/pull/16838) that I noticed this problem in the Ubuntu packages. $ lsb_release -rd Description:Ubuntu 21.04 Release:21.04 $ apt-cache policy openssl openssl: Installed: 1.1.1j-1ubuntu3.5 Candidate: 1.1.1j-1ubuntu3.5 Version table: *** 1.1.1j-1ubuntu3.5 500 500 http://gb.archive.ubuntu.com/ubuntu hirsute-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu hirsute-security/main amd64 Packages 100 /var/lib/dpkg/status 1.1.1j-1ubuntu3 500 500 http://gb.archive.ubuntu.com/ubuntu hirsute/main amd64 Packages $ openssl version -a OpenSSL 1.1.1j 16 Feb 2021 built on: Mon Aug 23 17:02:39 2021 UTC platform: debian-amd64 options: bn(64,64) rc4(16x,int) des(int) blowfish(ptr) compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 -ffile-prefix-map=/build/openssl-5U8yxE/openssl-1.1.1j=. -flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security -DOPENSSL_TLS_SECURITY_LEVEL=2 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2 OPENSSLDIR: "/usr/lib/ssl" ENGINESDIR: "/usr/lib/x86_64-linux-gnu/engines-1.1" Seeding source: os-specific ** Affects: openssl (Ubuntu) Importance: Undecided Status: New -- 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/1947588 Title: Infinite Loop in OpenSSL s_server Status in openssl package in Ubuntu: New Bug description: Launching openssl s_server as follows: $ openssl s_server -nocert -psk 01020304 -dtls1 And using openssl s_client to connect to it like this: $ openssl s_client -dtls1 -psk 01020304 Results in s_server entering an infinite loop: Using default temp DH parameters ACCEPT ERROR 140247926990208:error:141FC044:SSL routines:tls_setup_handshake:internal error:../ssl/statem/statem_lib.c:109: ERROR 140247926990208:error:141FC044:SSL routines:tls_setup_handshake:internal error:../ssl/statem/statem_lib.c:109: ERROR ...and so on... I have confirmed that upstream OpenSSL does not have this issue in a default build of 1.1.1j or 1.1.1k. Upstream 1.1.1l has a different bug with these commands (https://github.com/openssl/openssl/issues/16707) and it was while working on the fix for that issue (https://github.com/openssl/openssl/pull/16838) that I noticed this problem in the Ubuntu packages. $ lsb_release -rd Description: Ubuntu 21.04 Release: 21.04 $ apt-cache policy openssl openssl: Installed: 1.1.1j-1ubuntu3.5 Candidate: 1.1.1j-1ubuntu3.5 Version table: *** 1.1.1j-1ubuntu3.5 500 500 http://gb.archive.ubuntu.com/ubuntu hirsute-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu hirsute-security/main amd64 Packages 100 /var/lib/dpkg/status 1.1.1j-1ubuntu3 500 500 http://gb.archive.ubuntu.com/ubuntu hirsute/main amd64 Packages $ openssl version -a OpenSSL 1.1.1j 16 Feb 2021 built on: Mon Aug 23 17:02:39 2021 UTC platform: debian-amd64 options: bn(64,64) rc4(16x,int) des(int) blowfish(ptr) compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 -ffile-prefix-map=/build/openssl-5U8yxE/openssl-1.1.1j=. -flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security -DOPENSSL_TLS_SECURITY_LEVEL=2 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2 OPENSSLDIR: "/usr/lib/ssl"
[Touch-packages] [Bug 1946293] [NEW] Update slapd to include db directory in debconf
Public bug reported: Add the olcDbDirectory value as a debconf setting, so the directory may be relocated. This is especially helpful when building a container to run slapd with multiple ldap databases using one or more volumes. ** Affects: openldap (Ubuntu) Importance: Undecided Status: New ** Tags: feature ** Project changed: launchpad => openldap ** Project changed: openldap => openldap (Ubuntu) ** Description changed: Add the olcDbDirectory value as a debconf setting, so the directory may be relocated. This is especially helpful when building a container to - run slapd. + run slapd with multiple ldap databases using one or more volumes. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openldap in Ubuntu. https://bugs.launchpad.net/bugs/1946293 Title: Update slapd to include db directory in debconf Status in openldap package in Ubuntu: New Bug description: Add the olcDbDirectory value as a debconf setting, so the directory may be relocated. This is especially helpful when building a container to run slapd with multiple ldap databases using one or more volumes. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1946293/+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 1944481] Re: Distrust "DST Root CA X3"
@jsing You may well be correct that the server was incorrectly configured, unfortunately it was a Windows server managed by a third party and I don't know precisely how it was set up. Given that the cert in question was issued on 9th September 2021 I suspect it was a misconfiguration of their intermediate cert they were sending. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ca-certificates in Ubuntu. https://bugs.launchpad.net/bugs/1944481 Title: Distrust "DST Root CA X3" Status in ca-certificates package in Ubuntu: Fix Committed Status in ca-certificates source package in Trusty: Fix Released Status in ca-certificates source package in Xenial: Fix Released Status in ca-certificates source package in Bionic: Fix Released Status in ca-certificates source package in Focal: Fix Released Status in ca-certificates source package in Hirsute: Fix Released Status in ca-certificates source package in Impish: Fix Committed Bug description: [Impact] * ca-certificates trusts the letsencrypt CA certificate "ISRG Root X1" * ca-certificates also trusts the CA certificate "DST Root CA X3" which cross-signs letencrypt CA * "DST Root CA X3" is about to expire, however it has issued an updated cross-signature to letsencrypt beyond its own expiry * This causes issues with older implementations of openssl & gnutls that reject such chains when offered to clients by servers. * We have provided fixes for openssl in xenial and gnutls in bionic/xenial, however trusty systems remain affected. Also any self built old copies of openssl/gnutls remain suspeptible to this expiry. * One solution is to blacklist the "DST Root CA X3" from the ca-certificates package as described at https://blog.devgenius.io/rhel-centos-7-fix-for-lets-encrypt-change-8af2de587fe4 - connectivity to sites chained to "DST Root CA X3" will be unaffected, and servers that chain to both "ISRG Root X1" and "DST Root CA X3" should start to work unmodified. * This is similar to how this was handled for AddTrust before "* mozilla/blacklist.txt: blacklist expired AddTrust External Root CA." [Test Plan] * Install old/current ca-certificates faketime wget curl libcurl3-gnutls # faketime 2021-10-01 wget https://pskov.surgut.co.uk --2021-10-01 00:00:00-- https://pskov.surgut.co.uk/ Resolving pskov.surgut.co.uk (pskov.surgut.co.uk)... 2a01:4f8:c17:3dd8::1, 49.12.37.5 Connecting to pskov.surgut.co.uk (pskov.surgut.co.uk)|2a01:4f8:c17:3dd8::1|:443... connected. ERROR: cannot verify pskov.surgut.co.uk's certificate, issued by '/C=US/O=Let\'s Encrypt/CN=R3': Issued certificate has expired. To connect to pskov.surgut.co.uk insecurely, use `--no-check-certificate'. # LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4 faketime 2021-10-01 curl https://pskov.surgut.co.uk >/dev/null % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- 0 curl: (60) SSL certificate problem: certificate has expired * Install new ca-certificates package # faketime 2021-10-01 wget https://pskov.surgut.co.uk --2021-10-01 00:00:00-- https://pskov.surgut.co.uk/ Resolving pskov.surgut.co.uk (pskov.surgut.co.uk)... 2a01:4f8:c17:3dd8::1, 49.12.37.5 Connecting to pskov.surgut.co.uk (pskov.surgut.co.uk)|2a01:4f8:c17:3dd8::1|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 612 [text/html] Saving to: 'index.html.3' 100%[>] 612 --.-K/s in 0s 2021-10-01 00:00:00 (71.7 MB/s) - 'index.html.3' saved [612/612] LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4 faketime 2021-10-01 curl https://pskov.surgut.co.uk >/dev/null % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 612 100 6120 0 5794 0 --:--:-- --:--:-- --:--:-- 5828 Download is successful. [Where problems could occur] * Connectivity to "DST Root CA X3" websites only, even under faketime set to dates prior to 30th of September 2021 will not work, as "DST Root CA X3" certificate is no longer installed. users should locally install and enable that CA certificate, or allow dangerous unverified connectivity to websites using expired CA certs. [Other Info] * Related openssl and gnutls28 bugs are https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1928989 and https://bugs.launchpad.net/ubuntu/+source/gnutls28/+bug/1928648 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/1944481/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to :
[Touch-packages] [Bug 1944481] Re: Distrust "DST Root CA X3"
I ran into an SSL verification issue today, caused by this change. It seems that some older LetsEncrypt clients have still recently been issuing valid certificates signed by the DST Root CA X3 root. These certificates would have otherwise continued to work normally until the root expired (September 30th 2021), but have been distrusted early due to this change. (Indeed the certificate in question in my case was still trusted by the latest Chrome etc.) The best fix is to make sure the ACME client is up-to-date and re-issue the certificates under the new root cert. Posting for awareness - surprised I'm the first! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ca-certificates in Ubuntu. https://bugs.launchpad.net/bugs/1944481 Title: Distrust "DST Root CA X3" Status in ca-certificates package in Ubuntu: Fix Committed Status in ca-certificates source package in Trusty: Fix Released Status in ca-certificates source package in Xenial: Fix Released Status in ca-certificates source package in Bionic: Fix Released Status in ca-certificates source package in Focal: Fix Released Status in ca-certificates source package in Hirsute: Fix Released Status in ca-certificates source package in Impish: Fix Committed Bug description: [Impact] * ca-certificates trusts the letsencrypt CA certificate "ISRG Root X1" * ca-certificates also trusts the CA certificate "DST Root CA X3" which cross-signs letencrypt CA * "DST Root CA X3" is about to expire, however it has issued an updated cross-signature to letsencrypt beyond its own expiry * This causes issues with older implementations of openssl & gnutls that reject such chains when offered to clients by servers. * We have provided fixes for openssl in xenial and gnutls in bionic/xenial, however trusty systems remain affected. Also any self built old copies of openssl/gnutls remain suspeptible to this expiry. * One solution is to blacklist the "DST Root CA X3" from the ca-certificates package as described at https://blog.devgenius.io/rhel-centos-7-fix-for-lets-encrypt-change-8af2de587fe4 - connectivity to sites chained to "DST Root CA X3" will be unaffected, and servers that chain to both "ISRG Root X1" and "DST Root CA X3" should start to work unmodified. * This is similar to how this was handled for AddTrust before "* mozilla/blacklist.txt: blacklist expired AddTrust External Root CA." [Test Plan] * Install old/current ca-certificates faketime wget curl libcurl3-gnutls # faketime 2021-10-01 wget https://pskov.surgut.co.uk --2021-10-01 00:00:00-- https://pskov.surgut.co.uk/ Resolving pskov.surgut.co.uk (pskov.surgut.co.uk)... 2a01:4f8:c17:3dd8::1, 49.12.37.5 Connecting to pskov.surgut.co.uk (pskov.surgut.co.uk)|2a01:4f8:c17:3dd8::1|:443... connected. ERROR: cannot verify pskov.surgut.co.uk's certificate, issued by '/C=US/O=Let\'s Encrypt/CN=R3': Issued certificate has expired. To connect to pskov.surgut.co.uk insecurely, use `--no-check-certificate'. # LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4 faketime 2021-10-01 curl https://pskov.surgut.co.uk >/dev/null % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- 0 curl: (60) SSL certificate problem: certificate has expired * Install new ca-certificates package # faketime 2021-10-01 wget https://pskov.surgut.co.uk --2021-10-01 00:00:00-- https://pskov.surgut.co.uk/ Resolving pskov.surgut.co.uk (pskov.surgut.co.uk)... 2a01:4f8:c17:3dd8::1, 49.12.37.5 Connecting to pskov.surgut.co.uk (pskov.surgut.co.uk)|2a01:4f8:c17:3dd8::1|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 612 [text/html] Saving to: 'index.html.3' 100%[>] 612 --.-K/s in 0s 2021-10-01 00:00:00 (71.7 MB/s) - 'index.html.3' saved [612/612] LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4 faketime 2021-10-01 curl https://pskov.surgut.co.uk >/dev/null % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 612 100 6120 0 5794 0 --:--:-- --:--:-- --:--:-- 5828 Download is successful. [Where problems could occur] * Connectivity to "DST Root CA X3" websites only, even under faketime set to dates prior to 30th of September 2021 will not work, as "DST Root CA X3" certificate is no longer installed. users should locally install and enable that CA certificate, or allow dangerous unverified connectivity to websites using expired CA certs. [Other Info] * Related openssl and gnutls28 bugs are
[Touch-packages] [Bug 1916485] Re: test -x fails inside shell scripts in containers
According to https://stackoverflow.com/questions/66319610/gpg-error-in- ubuntu-21-04-after-second-apt-get-update-during-docker-build, this bug fix is supposed to fix the issue of getting the following error when running "apt-get update" in an Ubuntu 21.04 container: "W: GPG error: http://ports.ubuntu.com/ubuntu-ports hirsute InRelease: gpgv, gpgv2 or gpgv1 required for verification, but neither seems installed". I was running into this error when attempting to build my Dockerfiles based on arm64v8/ubuntu:21.04 and arm32v7/ubuntu:21.04. After upgrading my runc version to 1.0.1, the error went away but only for arm64v8/ubuntu:21.04. The Dockerfile based on arm32v7/ubuntu:21.04 still encountered the error. In both cases, I am running the build on an AArch64 device, so it's using emulation for the arm32v7/ubuntu:21.04 scenario. It would appear that it's still broken for that scenario? The repro is very simple, just run the following command on an AArch64 device: "docker run --rm arm32v7/ubuntu:21.04 apt-get update". It will output the following: Unable to find image 'arm32v7/ubuntu:21.04' locally 21.04: Pulling from arm32v7/ubuntu 48989deb32eb: Pulling fs layer 48989deb32eb: Verifying Checksum 48989deb32eb: Download complete 48989deb32eb: Pull complete Digest: sha256:b61c1421a092dd4ffc0b14a6b683513d775d5daa275598c74cd34090a0424a19 Status: Downloaded newer image for arm32v7/ubuntu:21.04 WARNING: The requested image's platform (linux/arm/v7) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested WARNING: apt does not have a stable CLI interface. Use with caution in scripts. Get:1 http://ports.ubuntu.com/ubuntu-ports hirsute InRelease [269 kB] Get:2 http://ports.ubuntu.com/ubuntu-ports hirsute-updates InRelease [115 kB] Err:1 http://ports.ubuntu.com/ubuntu-ports hirsute InRelease gpgv, gpgv2 or gpgv1 required for verification, but neither seems installed Get:3 http://ports.ubuntu.com/ubuntu-ports hirsute-backports InRelease [101 kB] Err:2 http://ports.ubuntu.com/ubuntu-ports hirsute-updates InRelease gpgv, gpgv2 or gpgv1 required for verification, but neither seems installed Get:4 http://ports.ubuntu.com/ubuntu-ports hirsute-security InRelease [110 kB] Err:3 http://ports.ubuntu.com/ubuntu-ports hirsute-backports InRelease gpgv, gpgv2 or gpgv1 required for verification, but neither seems installed Err:4 http://ports.ubuntu.com/ubuntu-ports hirsute-security InRelease gpgv, gpgv2 or gpgv1 required for verification, but neither seems installed Reading package lists... W: GPG error: http://ports.ubuntu.com/ubuntu-ports hirsute InRelease: gpgv, gpgv2 or gpgv1 required for verification, but neither seems installed E: The repository 'http://ports.ubuntu.com/ubuntu-ports hirsute InRelease' is not signed. W: GPG error: http://ports.ubuntu.com/ubuntu-ports hirsute-updates InRelease: gpgv, gpgv2 or gpgv1 required for verification, but neither seems installed E: The repository 'http://ports.ubuntu.com/ubuntu-ports hirsute-updates InRelease' is not signed. W: GPG error: http://ports.ubuntu.com/ubuntu-ports hirsute-backports InRelease: gpgv, gpgv2 or gpgv1 required for verification, but neither seems installed E: The repository 'http://ports.ubuntu.com/ubuntu-ports hirsute-backports InRelease' is not signed. W: GPG error: http://ports.ubuntu.com/ubuntu-ports hirsute-security InRelease: gpgv, gpgv2 or gpgv1 required for verification, but neither seems installed E: The repository 'http://ports.ubuntu.com/ubuntu-ports hirsute-security InRelease' is not signed. Here's the docker version info for the host machine: Client: Version: 20.10.7 API version: 1.41 Go version:go1.16.4 Git commit:f0df35096d5f5e6b559b42c7fde6c65a2909f7c5 Built: Sat Sep 11 15:09:09 2021 OS/Arch: linux/arm64 Context: default Experimental: true Server: Docker Engine - Community Engine: Version: 20.10.8 API version: 1.41 (minimum version 1.12) Go version: go1.16.6 Git commit: 75249d8 Built:Fri Jul 30 19:53:13 2021 OS/Arch: linux/arm64 Experimental: false containerd: Version: 1.4.9 GitCommit:e25210fe30a0a703442421b0f60afac609f950a3 runc: Version: 1.0.1 GitCommit:v1.0.1-0-g4144b63 docker-init: Version: 0.19.0 GitCommit:de40ad0 -- 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/1916485 Title: test -x fails inside shell scripts in containers Status in Ubuntu on IBM z Systems: New Status in docker.io package in Ubuntu: Invalid Status in glibc package in Ubuntu: Opinion Status in libseccomp package in Ubuntu: Fix Committed Status in runc package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in docker.io source package in
[Touch-packages] [Bug 1934545] Re: package initramfs-tools 0.130ubuntu3.12 failed to install/upgrade: installed initramfs-tools package post-installation script subprocess returned error exit status 1
After this report, it automatically ran something like dpkg --configure --pending, which succeeded in running the lilo update. The only thing it didn't do was run autoremove to remove the outdated libraries and stuff. Rebooted into the new kernel via lilo successfully as well. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1934545 Title: package initramfs-tools 0.130ubuntu3.12 failed to install/upgrade: installed initramfs-tools package post-installation script subprocess returned error exit status 1 Status in initramfs-tools package in Ubuntu: New Bug description: Upgrading from 16.04 to 18.04 on an old server that still has to use lilo. ProblemType: Package DistroRelease: Ubuntu 18.04 Package: initramfs-tools 0.130ubuntu3.12 ProcVersionSignature: Ubuntu 4.4.0-210.242-generic 4.4.262 Uname: Linux 4.4.0-210-generic i686 ApportVersion: 2.20.9-0ubuntu7.24 Architecture: i386 Date: Fri Jul 2 16:35:42 2021 ErrorMessage: installed initramfs-tools package post-installation script subprocess returned error exit status 1 InstallationDate: Installed on 2010-06-08 (4042 days ago) InstallationMedia: Ubuntu-Server 10.04 LTS "Lucid Lynx" - Release i386 (20100427) PackageArchitecture: all Python3Details: /usr/bin/python3.6, Python 3.6.9, python3-minimal, 3.6.7-1~18.04 PythonDetails: /usr/bin/python2.7, Python 2.7.17, python-minimal, 2.7.15~rc1-1 RelatedPackageVersions: dpkg 1.19.0.5ubuntu2.3 apt 1.6.14 SourcePackage: initramfs-tools Title: package initramfs-tools 0.130ubuntu3.12 failed to install/upgrade: installed initramfs-tools package post-installation script subprocess returned error exit status 1 UpgradeStatus: Upgraded to bionic on 2021-07-02 (0 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1934545/+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 1934545] [NEW] package initramfs-tools 0.130ubuntu3.12 failed to install/upgrade: installed initramfs-tools package post-installation script subprocess returned error exit status
Public bug reported: Upgrading from 16.04 to 18.04 on an old server that still has to use lilo. ProblemType: Package DistroRelease: Ubuntu 18.04 Package: initramfs-tools 0.130ubuntu3.12 ProcVersionSignature: Ubuntu 4.4.0-210.242-generic 4.4.262 Uname: Linux 4.4.0-210-generic i686 ApportVersion: 2.20.9-0ubuntu7.24 Architecture: i386 Date: Fri Jul 2 16:35:42 2021 ErrorMessage: installed initramfs-tools package post-installation script subprocess returned error exit status 1 InstallationDate: Installed on 2010-06-08 (4042 days ago) InstallationMedia: Ubuntu-Server 10.04 LTS "Lucid Lynx" - Release i386 (20100427) PackageArchitecture: all Python3Details: /usr/bin/python3.6, Python 3.6.9, python3-minimal, 3.6.7-1~18.04 PythonDetails: /usr/bin/python2.7, Python 2.7.17, python-minimal, 2.7.15~rc1-1 RelatedPackageVersions: dpkg 1.19.0.5ubuntu2.3 apt 1.6.14 SourcePackage: initramfs-tools Title: package initramfs-tools 0.130ubuntu3.12 failed to install/upgrade: installed initramfs-tools package post-installation script subprocess returned error exit status 1 UpgradeStatus: Upgraded to bionic on 2021-07-02 (0 days ago) ** Affects: initramfs-tools (Ubuntu) Importance: Undecided Status: New ** Tags: apport-package bionic i386 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1934545 Title: package initramfs-tools 0.130ubuntu3.12 failed to install/upgrade: installed initramfs-tools package post-installation script subprocess returned error exit status 1 Status in initramfs-tools package in Ubuntu: New Bug description: Upgrading from 16.04 to 18.04 on an old server that still has to use lilo. ProblemType: Package DistroRelease: Ubuntu 18.04 Package: initramfs-tools 0.130ubuntu3.12 ProcVersionSignature: Ubuntu 4.4.0-210.242-generic 4.4.262 Uname: Linux 4.4.0-210-generic i686 ApportVersion: 2.20.9-0ubuntu7.24 Architecture: i386 Date: Fri Jul 2 16:35:42 2021 ErrorMessage: installed initramfs-tools package post-installation script subprocess returned error exit status 1 InstallationDate: Installed on 2010-06-08 (4042 days ago) InstallationMedia: Ubuntu-Server 10.04 LTS "Lucid Lynx" - Release i386 (20100427) PackageArchitecture: all Python3Details: /usr/bin/python3.6, Python 3.6.9, python3-minimal, 3.6.7-1~18.04 PythonDetails: /usr/bin/python2.7, Python 2.7.17, python-minimal, 2.7.15~rc1-1 RelatedPackageVersions: dpkg 1.19.0.5ubuntu2.3 apt 1.6.14 SourcePackage: initramfs-tools Title: package initramfs-tools 0.130ubuntu3.12 failed to install/upgrade: installed initramfs-tools package post-installation script subprocess returned error exit status 1 UpgradeStatus: Upgraded to bionic on 2021-07-02 (0 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1934545/+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 1904638] Re: Xbox Series X|S controller doesn't work and Xbox icon still blinks after pairing
I can pair successfully if I enable LE Privacy: sudo btmgmt power off sudo btmgmt privacy on sudo btmgmt power on -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1904638 Title: Xbox Series X|S controller doesn't work and Xbox icon still blinks after pairing Status in bluez package in Ubuntu: Confirmed Status in linux package in Ubuntu: Confirmed Bug description: I have Xbox Series X|S controller and the Xbox icon still blinks after the successful pairing. I'm using Ubuntu 20.10 updated with BlueZ latest release. I'm following this bug closely and I can provide any information you need and do any tests you want. mhalano@glados:~$ lsb_release -rd Description: Ubuntu 20.10 Release: 20.10 mhalano@glados:~$ apt policy bluez bluez: Installed: 5.55-0ubuntu1.1 Candidate: 5.55-0ubuntu1.1 Version table: *** 5.55-0ubuntu1.1 500 500 http://br.archive.ubuntu.com/ubuntu groovy-proposed/main amd64 Packages 100 /var/lib/dpkg/status 5.55-0ubuntu1 500 500 http://br.archive.ubuntu.com/ubuntu groovy/main amd64 Packages --- ProblemType: Bug ApportVersion: 2.20.11-0ubuntu50.2 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME DistroRelease: Ubuntu 20.10 InstallationDate: Installed on 2020-10-23 (25 days ago) InstallationMedia: Ubuntu 20.10 "Groovy Gorilla" - Release amd64 (20201022) InterestingModules: rfcomm bnep btusb bluetooth MachineType: Dell Inc. Inspiron 5590 NonfreeKernelModules: nvidia_modeset nvidia Package: linux PackageArchitecture: amd64 ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.8.0-30-generic root=UUID=1e3484bb-be3c-4f5d-be22-044d9df06a4a ro quiet splash vt.handoff=7 ProcVersionSignature: Ubuntu 5.8.0-30.32-generic 5.8.17 Tags: groovy package-from-proposed Uname: Linux 5.8.0-30-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin lxd plugdev sambashare sudo _MarkForUpload: True dmi.bios.date: 08/13/2020 dmi.bios.release: 1.11 dmi.bios.vendor: Dell Inc. dmi.bios.version: 1.11.0 dmi.board.name: 0XRXN9 dmi.board.vendor: Dell Inc. dmi.board.version: A04 dmi.chassis.type: 10 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvr1.11.0:bd08/13/2020:br1.11:svnDellInc.:pnInspiron5590:pvr:rvnDellInc.:rn0XRXN9:rvrA04:cvnDellInc.:ct10:cvr: dmi.product.family: Inspiron dmi.product.name: Inspiron 5590 dmi.product.sku: 0957 dmi.sys.vendor: Dell Inc. hciconfig: hci0:Type: Primary Bus: USB BD Address: 14:F6:D8:6A:A3:F0 ACL MTU: 1021:4 SCO MTU: 96:6 UP RUNNING PSCAN ISCAN RX bytes:5307486 acl:57516 sco:0 events:78636 errors:0 TX bytes:18701 acl:357 sco:0 commands:841 errors:0 mtime.conffile..etc.bluetooth.main.conf: 2020-11-04T10:53:00.842656 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1904638/+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 1900905] [NEW] package initramfs-tools 0.136ubuntu6.3 failed to install/upgrade: »installiertes initramfs-tools-Skript des Paketes post-installation«-Unterprozess gab den Fehlerw
Public bug reported: do-release-upgrade from 18.04 LTS to 20.04 LTS results in this error ProblemType: Package DistroRelease: Ubuntu 20.04 Package: initramfs-tools 0.136ubuntu6.3 ProcVersionSignature: Ubuntu 4.15.0-122.124-generic 4.15.18 Uname: Linux 4.15.0-122-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.10 Architecture: amd64 CasperMD5CheckResult: skip Date: Wed Oct 21 23:15:14 2020 ErrorMessage: »installiertes initramfs-tools-Skript des Paketes post-installation«-Unterprozess gab den Fehlerwert 1 zurück InstallationDate: Installed on 2015-02-06 (2084 days ago) InstallationMedia: Ubuntu-Server 14.04.1 LTS "Trusty Tahr" - Release amd64 (20140722.3) PackageArchitecture: all Python3Details: /usr/bin/python3.8, Python 3.8.5, python3-minimal, 3.8.2-0ubuntu2 PythonDetails: /usr/bin/python2.7, Python 2.7.18, python-is-python2, 2.7.17-4 RelatedPackageVersions: dpkg 1.19.7ubuntu3 apt 2.0.2ubuntu0.1 SourcePackage: initramfs-tools Title: package initramfs-tools 0.136ubuntu6.3 failed to install/upgrade: »installiertes initramfs-tools-Skript des Paketes post-installation«-Unterprozess gab den Fehlerwert 1 zurück UpgradeStatus: Upgraded to focal on 2020-10-21 (0 days ago) ** Affects: initramfs-tools (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-package focal -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1900905 Title: package initramfs-tools 0.136ubuntu6.3 failed to install/upgrade: »installiertes initramfs-tools-Skript des Paketes post- installation«-Unterprozess gab den Fehlerwert 1 zurück Status in initramfs-tools package in Ubuntu: New Bug description: do-release-upgrade from 18.04 LTS to 20.04 LTS results in this error ProblemType: Package DistroRelease: Ubuntu 20.04 Package: initramfs-tools 0.136ubuntu6.3 ProcVersionSignature: Ubuntu 4.15.0-122.124-generic 4.15.18 Uname: Linux 4.15.0-122-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.10 Architecture: amd64 CasperMD5CheckResult: skip Date: Wed Oct 21 23:15:14 2020 ErrorMessage: »installiertes initramfs-tools-Skript des Paketes post-installation«-Unterprozess gab den Fehlerwert 1 zurück InstallationDate: Installed on 2015-02-06 (2084 days ago) InstallationMedia: Ubuntu-Server 14.04.1 LTS "Trusty Tahr" - Release amd64 (20140722.3) PackageArchitecture: all Python3Details: /usr/bin/python3.8, Python 3.8.5, python3-minimal, 3.8.2-0ubuntu2 PythonDetails: /usr/bin/python2.7, Python 2.7.18, python-is-python2, 2.7.17-4 RelatedPackageVersions: dpkg 1.19.7ubuntu3 apt 2.0.2ubuntu0.1 SourcePackage: initramfs-tools Title: package initramfs-tools 0.136ubuntu6.3 failed to install/upgrade: »installiertes initramfs-tools-Skript des Paketes post-installation«-Unterprozess gab den Fehlerwert 1 zurück UpgradeStatus: Upgraded to focal on 2020-10-21 (0 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1900905/+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 1877633] Re: libseccomp 2.4.3 (and 2.4.2) is not correctly resolving (at least) the getrlimit syscall on arm64
I don't see the updated applied to the ARM architecture. The versions of arm64 and armhf at https://packages.ubuntu.com/focal/libseccomp-dev still show 2.4.3-1ubuntu1. What's the story on that? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libseccomp in Ubuntu. https://bugs.launchpad.net/bugs/1877633 Title: libseccomp 2.4.3 (and 2.4.2) is not correctly resolving (at least) the getrlimit syscall on arm64 Status in libseccomp package in Ubuntu: Fix Released Status in libseccomp source package in Focal: Fix Released Status in libseccomp source package in Groovy: Fix Released Bug description: This was reported via the snapcraft forum[1]: On bionic amd64, libseccomp 2.4.1-0ubuntu0.18.04.2 $ lsb_release -d Description: Ubuntu 18.04.4 LTS $ scmp_sys_resolver -a aarch64 163 getrlimit $ scmp_sys_resolver -a aarch64 getrlimit 163 focal amd64, libseccomp 2.4.3-1ubuntu1 -- *__BROKEN__* $ lsb_release -d Description: Ubuntu 20.04 LTS $ scmp_sys_resolver -a aarch64 163 UNKNOWN $ scmp_sys_resolver -a aarch64 getrlimit -10180 [1]https://forum.snapcraft.io/t/getrlimit-blocked-by-seccomp-on-focal- arm64/17237/8 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1877633/+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 1874567] [NEW] Secondary (rotated) monitor configuration is not applied correctly in gnome settings
Public bug reported: I have two monitors, with the secondary one rotated in a portrait orientation. Using the nvidia 440 drivers, the orientation is not applied when configuring in gnome settings (the displays go blank for a second, and then reappear in landscape orientation). Using nvidia settings, I can set the monitor rotation and offset correctly, however these settings do not persist on next boot (even when selecting to save to xorg.conf). When using the nouveau drivers, the orientation is applied correctly in gnome settings, and is persisted. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: xorg 1:7.7+19ubuntu14 ProcVersionSignature: Ubuntu 5.4.0-26.30-generic 5.4.30 Uname: Linux 5.4.0-26-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia .proc.driver.nvidia.gpus..01.00.0: Error: [Errno 21] Is a directory: '/proc/driver/nvidia/gpus/:01:00.0' .proc.driver.nvidia.registry: Binary: "" .proc.driver.nvidia.suspend: suspend hibernate resume .proc.driver.nvidia.suspend_depth: default modeset uvm .proc.driver.nvidia.version: NVRM version: NVIDIA UNIX x86_64 Kernel Module 440.64 Fri Feb 21 01:17:26 UTC 2020 GCC version: gcc version 9.3.0 (Ubuntu 9.3.0-10ubuntu2) ApportVersion: 2.20.11-0ubuntu27 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CasperMD5CheckResult: skip CompositorRunning: None CurrentDesktop: GNOME Date: Fri Apr 24 08:30:41 2020 DistUpgraded: 2020-04-20 18:27:13,972 DEBUG Running PostInstallScript: './xorg_fix_proprietary.py' DistroCodename: focal DistroVariant: ubuntu DkmsStatus: nvidia, 440.64, 5.4.0-26-generic, x86_64: installed ExtraDebuggingInterest: Yes GraphicsCard: NVIDIA Corporation GK106 [GeForce GTX 660] [10de:11c0] (rev a1) (prog-if 00 [VGA controller]) Subsystem: Micro-Star International Co., Ltd. [MSI] GK106 [GeForce GTX 660] [1462:2871] InstallationDate: Installed on 2018-05-01 (723 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) MachineType: Shuttle Inc. SZ77 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_AU.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-26-generic root=UUID=d2c17cee-7c37-429f-9cbb-9484a159f182 ro quiet splash vt.handoff=7 SourcePackage: xorg Symptom: display UpgradeStatus: Upgraded to focal on 2020-04-20 (3 days ago) dmi.bios.date: 10/13/2014 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 1.13 dmi.board.asset.tag: To be filled by O.E.M. dmi.board.name: FZ77 dmi.board.vendor: Shuttle Inc. dmi.board.version: 1.0 dmi.chassis.asset.tag: To Be Filled By O.E.M. dmi.chassis.type: 3 dmi.chassis.vendor: To Be Filled By O.E.M. dmi.chassis.version: To Be Filled By O.E.M. dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr1.13:bd10/13/2014:svnShuttleInc.:pnSZ77:pvr1.0:rvnShuttleInc.:rnFZ77:rvr1.0:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.: dmi.product.family: To be filled by O.E.M. dmi.product.name: SZ77 dmi.product.sku: To be filled by O.E.M. dmi.product.version: 1.0 dmi.sys.vendor: Shuttle Inc. version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.101-2 version.libgl1-mesa-dri: libgl1-mesa-dri 20.0.4-2ubuntu1 version.libgl1-mesa-glx: libgl1-mesa-glx N/A version.nvidia-graphics-drivers: nvidia-graphics-drivers-* N/A version.xserver-xorg-core: xserver-xorg-core 2:1.20.8-2ubuntu2 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20200226-1 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1 ** Affects: xorg (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug focal nvidia ubuntu -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to xorg in Ubuntu. https://bugs.launchpad.net/bugs/1874567 Title: Secondary (rotated) monitor configuration is not applied correctly in gnome settings Status in xorg package in Ubuntu: New Bug description: I have two monitors, with the secondary one rotated in a portrait orientation. Using the nvidia 440 drivers, the orientation is not applied when configuring in gnome settings (the displays go blank for a second, and then reappear in landscape orientation). Using nvidia settings, I can set the monitor rotation and offset correctly, however these settings do not persist on next boot (even when selecting to save to xorg.conf). When using the nouveau drivers, the orientation is applied correctly in gnome settings, and is persisted. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: xorg 1:7.7+19ubuntu14 ProcVersionSignature: Ubuntu 5.4.0-26.30-generic 5.4.30 Uname: Linux 5.4.0-26-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia .proc.driver.nvidia.gpus..01.00.0: Error: [Errno 21] Is a directory:
[Touch-packages] [Bug 1874567] Re: Secondary (rotated) monitor configuration is not applied correctly in gnome settings
** Attachment added: "Screenshot from 2020-04-24 08-37-43.png" https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1874567/+attachment/5358812/+files/Screenshot%20from%202020-04-24%2008-37-43.png -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to xorg in Ubuntu. https://bugs.launchpad.net/bugs/1874567 Title: Secondary (rotated) monitor configuration is not applied correctly in gnome settings Status in xorg package in Ubuntu: New Bug description: I have two monitors, with the secondary one rotated in a portrait orientation. Using the nvidia 440 drivers, the orientation is not applied when configuring in gnome settings (the displays go blank for a second, and then reappear in landscape orientation). Using nvidia settings, I can set the monitor rotation and offset correctly, however these settings do not persist on next boot (even when selecting to save to xorg.conf). When using the nouveau drivers, the orientation is applied correctly in gnome settings, and is persisted. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: xorg 1:7.7+19ubuntu14 ProcVersionSignature: Ubuntu 5.4.0-26.30-generic 5.4.30 Uname: Linux 5.4.0-26-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia .proc.driver.nvidia.gpus..01.00.0: Error: [Errno 21] Is a directory: '/proc/driver/nvidia/gpus/:01:00.0' .proc.driver.nvidia.registry: Binary: "" .proc.driver.nvidia.suspend: suspend hibernate resume .proc.driver.nvidia.suspend_depth: default modeset uvm .proc.driver.nvidia.version: NVRM version: NVIDIA UNIX x86_64 Kernel Module 440.64 Fri Feb 21 01:17:26 UTC 2020 GCC version: gcc version 9.3.0 (Ubuntu 9.3.0-10ubuntu2) ApportVersion: 2.20.11-0ubuntu27 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CasperMD5CheckResult: skip CompositorRunning: None CurrentDesktop: GNOME Date: Fri Apr 24 08:30:41 2020 DistUpgraded: 2020-04-20 18:27:13,972 DEBUG Running PostInstallScript: './xorg_fix_proprietary.py' DistroCodename: focal DistroVariant: ubuntu DkmsStatus: nvidia, 440.64, 5.4.0-26-generic, x86_64: installed ExtraDebuggingInterest: Yes GraphicsCard: NVIDIA Corporation GK106 [GeForce GTX 660] [10de:11c0] (rev a1) (prog-if 00 [VGA controller]) Subsystem: Micro-Star International Co., Ltd. [MSI] GK106 [GeForce GTX 660] [1462:2871] InstallationDate: Installed on 2018-05-01 (723 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) MachineType: Shuttle Inc. SZ77 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_AU.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-26-generic root=UUID=d2c17cee-7c37-429f-9cbb-9484a159f182 ro quiet splash vt.handoff=7 SourcePackage: xorg Symptom: display UpgradeStatus: Upgraded to focal on 2020-04-20 (3 days ago) dmi.bios.date: 10/13/2014 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 1.13 dmi.board.asset.tag: To be filled by O.E.M. dmi.board.name: FZ77 dmi.board.vendor: Shuttle Inc. dmi.board.version: 1.0 dmi.chassis.asset.tag: To Be Filled By O.E.M. dmi.chassis.type: 3 dmi.chassis.vendor: To Be Filled By O.E.M. dmi.chassis.version: To Be Filled By O.E.M. dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr1.13:bd10/13/2014:svnShuttleInc.:pnSZ77:pvr1.0:rvnShuttleInc.:rnFZ77:rvr1.0:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.: dmi.product.family: To be filled by O.E.M. dmi.product.name: SZ77 dmi.product.sku: To be filled by O.E.M. dmi.product.version: 1.0 dmi.sys.vendor: Shuttle Inc. version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.101-2 version.libgl1-mesa-dri: libgl1-mesa-dri 20.0.4-2ubuntu1 version.libgl1-mesa-glx: libgl1-mesa-glx N/A version.nvidia-graphics-drivers: nvidia-graphics-drivers-* N/A version.xserver-xorg-core: xserver-xorg-core 2:1.20.8-2ubuntu2 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20200226-1 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1874567/+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 1872778] Re: update-crypto-policies not affecting Gnome Online Accounts
The following worked for me: see https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/1866974/comments/8 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnome-online-accounts in Ubuntu. https://bugs.launchpad.net/bugs/1872778 Title: update-crypto-policies not affecting Gnome Online Accounts Status in gnome-online-accounts package in Ubuntu: Incomplete Status in gnutls28 package in Ubuntu: Confirmed Bug description: -crypto-policies 20190816git-1 -gnome-online-accounts 3.36.0-1ubuntu1 Changing between DEFAULT, LEGACY, and EMPTY has no affect on attempts to connect to accounts through Online Accounts. Changing to LEGACY or EMPTY should at least change the following error: Error performing TLS handshake: The Diffie-Hellman prime sent by the server is not acceptable (not long enough). Under either LEGACY or EMPTY the (not long enough) error is nonsensical. The persistence of the incorrect error message could imply that gnome-online-accounts is not respecting settings made by crypto-policies. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-online-accounts/+bug/1872778/+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 1866974] Re: The Diffie-Hellman prime sent by the server is not acceptable
*** This bug is a duplicate of bug 1872778 *** https://bugs.launchpad.net/bugs/1872778 Thank you Simon Déziel! That worked for me too. I was all set to give up on ubuntu 20 because having a working evolution-ews is a deal-breaker for me. I wonder why the linked duplicate thread does not also contain your fix. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnome-online-accounts in Ubuntu. https://bugs.launchpad.net/bugs/1866974 Title: The Diffie-Hellman prime sent by the server is not acceptable Status in evolution package in Ubuntu: Confirmed Status in gnome-online-accounts package in Ubuntu: New Bug description: I can no longer connect to my ISP mail server. Works in previous version 19.10 "The reported error was “Failed to get capabilities: Error performing TLS handshake: The Diffie-Hellman prime sent by the server is not acceptable (not long enough).”." I've tried finding a workaround but so far no luck. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: evolution 3.35.92-1 ProcVersionSignature: Ubuntu 5.4.0-18.22-generic 5.4.24 Uname: Linux 5.4.0-18-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu20 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Wed Mar 11 11:07:01 2020 InstallationDate: Installed on 2020-03-03 (7 days ago) InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Alpha amd64 (20200303) SourcePackage: evolution UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/1866974/+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 1858152] Re: fstrim.service no longer trims /home partition
I can confirm this bug. Viewing systemd logs on my system showed the weekly TRIM of /home stopped around the end of October 2019 as reported by Jeffery. This bug was filed upstream (https://github.com/karelzak/util- linux/issues/824) and will affect users with /home on a separate partition. It was patched with the following one-line commit c64d452b3eb85fe55e238144082247b05cc143ea: -ProtectHome=yes +ProtectHome=read-only ** Bug watch added: github.com/karelzak/util-linux/issues #824 https://github.com/karelzak/util-linux/issues/824 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to util-linux in Ubuntu. https://bugs.launchpad.net/bugs/1858152 Title: fstrim.service no longer trims /home partition Status in util-linux package in Ubuntu: Confirmed Bug description: When I was running disco, fstrim.service would trim all of my partitions: Oct 21 00:00:18 computer systemd[1]: Starting Discard unused blocks on filesystems from /etc/fstab... Oct 21 00:00:37 computer fstrim[9588]: /home: 25 GiB (26797150208 bytes) trimmed on /dev/mapper/ubuntu--vg-home Oct 21 00:00:37 computer fstrim[9588]: /boot: 805.4 MiB (844546048 bytes) trimmed on /dev/sda5 Oct 21 00:00:37 computer fstrim[9588]: /: 5.5 GiB (5929816064 bytes) trimmed on /dev/mapper/ubuntu--vg-root Oct 21 00:00:37 computer systemd[1]: fstrim.service: Succeeded. Oct 21 00:00:37 computer systemd[1]: Started Discard unused blocks on filesystems from /etc/fstab. After upgrading to eoan, my /home partition is no longer trimmed: Oct 28 00:00:21 computer systemd[1]: Starting Discard unused blocks on filesystems from /etc/fstab... Oct 28 00:00:32 computer fstrim[24667]: /boot: 781.1 MiB (819011584 bytes) trimmed on /dev/sda5 Oct 28 00:00:32 computer fstrim[24667]: /: 7.2 GiB (7696994304 bytes) trimmed on /dev/mapper/ubuntu--vg-root Oct 28 00:00:32 computer systemd[1]: fstrim.service: Succeeded. Oct 28 00:00:32 computer systemd[1]: Started Discard unused blocks on filesystems from /etc/fstab. Checking the unit file (/lib/systemd/system/fstrim.service), I noticed there is a "ProtectHome=yes" option. Removing this option caused my /home partition to be trimmed once again. I believe the "ProtectSystem=strict" option may also cause partitions in non-standard partition schemes to be skipped by fstrim.service (although I have not tested this). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1858152/+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 1814262] Re: Wired interface gets impossibly high metric 20100
This bug persists. It may be a regression associated with 5.0.0.37. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to procps in Ubuntu. https://bugs.launchpad.net/bugs/1814262 Title: Wired interface gets impossibly high metric 20100 Status in procps package in Ubuntu: Fix Released Bug description: Actually this might be a heisenbug. I've had an issue with this all morning since network-manager got an update this morning, but just now *while this bug was being submitted* it decided to correct itself. What I was getting was, on a machine (Dell XPS 13 9370) with WiFi and a (Caldigit) Thunderbolt 3 dock with an ethernet port: After the network-manager update I noticed everything was slower than I was used to, and in gnome-shell the network icon showing was the WiFi one, not the wired one. Looking at the output of route, or route -n for simplicity, I would see this: rachel@rainbow:~$ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 0.0.0.0 192.168.1.254 0.0.0.0 UG60000 wlp2s0 0.0.0.0 192.168.1.254 0.0.0.0 UG20100 00 enp63s0 169.254.0.0 0.0.0.0 255.255.0.0 U 1000 00 wlp2s0 192.168.1.0 0.0.0.0 255.255.255.0 U 10000 enp63s0 192.168.1.0 0.0.0.0 255.255.255.0 U 60000 wlp2s0 So the metric on the default route on enp63s0 had 20,000 mysteriously added to it, which would obviously make it extremely low-priority. The system was choosing the wifi connection instead, which isn't that great in my office, hence observable slowness. Now, this morning, this seemed to be the sticky situation. It didn't show any sign of changing, whatever I did, after restarts of network- manager, undock/redock, reboots, etc. I could change it manually with ifmetric (and it would work), but that was about it. I would have reported the bug then, but I had to go out. When I got back I plugged in and initially saw the same thing again (that's where the above snippet was pasted from). But *while* the ubuntu-bug network-manager command was running, I noticed the gnome-shell network icon switch to wired, checked again, and saw: rachel@rainbow:~$ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 0.0.0.0 192.168.1.254 0.0.0.0 UG10000 enp63s0 0.0.0.0 192.168.1.254 0.0.0.0 UG20600 00 wlp2s0 169.254.0.0 0.0.0.0 255.255.0.0 U 1000 00 wlp2s0 192.168.1.0 0.0.0.0 255.255.255.0 U 10000 enp63s0 192.168.1.0 0.0.0.0 255.255.255.0 U 60000 wlp2s0 So now the wifi connection has 20,000 added to it, which may still be wrong? But I wouldn't otherwise have noticed it because the system is again *behaving* as expected. This all seemed to happen after the network-manager upgrade (from 1.12.6-0ubuntu4 to 1.15.2-0ubuntu1) this morning. I can't say if these metric+20,000 values were present before then, because I didn't have any cause to go looking at it, it always just worked. Could it be some issue with how the newer network-manager, or one of its associated packages, is figuring out the metrics on new connections? Like it's running some new heuristic to determine which one should really be the preferred? If it's like it was just now, when it fixed itself after a minute or so, that's not really a problem, but if it's like it was this morning when it just seemed to be stuck with the ethernet connection at 20100, it is. ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: network-manager 1.15.2-0ubuntu1 ProcVersionSignature: Ubuntu 4.18.0-13.14-generic 4.18.17 Uname: Linux 4.18.0-13-generic x86_64 ApportVersion: 2.20.10-0ubuntu19 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Fri Feb 1 13:15:06 2019 IfupdownConfig: # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback InstallationDate: Installed on 2018-09-11 (142 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214) IpRoute: default via 192.168.1.254 dev wlp2s0 proto dhcp metric 600 default via 192.168.1.254 dev enp63s0 proto dhcp metric 20100 169.254.0.0/16 dev wlp2s0 scope link metric 1000 192.168.1.0/24 dev enp63s0 proto kernel scope link src 192.168.1.106 metric 100 192.168.1.0/24 dev wlp2s0 proto kernel scope link src 192.168.1.101 metric 600 NetworkManager.state: [main] NetworkingEnabled=true WirelessEnabled=true WWANEnabled=true RfKill: 1: phy0: Wireless LAN Soft blocked: no Hard blocked: no SourcePackage: network-manager
[Touch-packages] [Bug 1718658] Re: ecryptfs-mount-private fails to initialize ecryptfs keys
I just upgraded from 16.04 to 18.04 and I'm seeing the same/similar issue. I have the same messages in the log, and I have an encrypted home folder. When I *first* try to log in after a reboot, I get bounced back to the login screen. It then logs in on the second attempt (so far - but this makes me nervous). None of the fixes above have worked for me so far. -- 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/1718658 Title: ecryptfs-mount-private fails to initialize ecryptfs keys Status in ecryptfs-utils package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: ecryptfs-mount-private fails to mount the ecryptfs after the 1st reboot after creating the ecryptfs by ecryptfs-setup-private. After the unsucessful attempt dmesg contains: [ 1265.695388] Could not find key with description: [] [ 1265.695393] process_request_key_err: No key [ 1265.695394] Could not find valid key in user session keyring for sig specified in mount option: [] [ 1265.695395] One or more global auth toks could not properly register; rc = [-2] [ 1265.695396] Error parsing options; rc = [-2] Note: The correct key ID has been replaced in the "". I also accidentally found an workaround - just running ecrytpfs- manager and then the ecryptfs-mount-private (it does not ask for password for the second time and mounts the ecryptfs correctly): host:~$ ecryptfs-manager eCryptfs key management menu --- 1. Add passphrase key to keyring 2. Add public key to keyring 3. Generate new public/private keypair 4. Exit Make selection: 4 host:~$ ls Private/ Access-Your-Private-Data.desktop README.txt host:~$ ecryptfs-mount-private host:~$ ls Private/ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1718658/+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 1849405] Re: Repeated keypresses from bluetooth keyboard
I've now been using an Xorg session rather than Wayland and haven't seen the repeated keys issue. I do get some very nasty screen tearing when scrolling (e.g. websites) on Xorg however, so ideally I'd like to continue using Wayland. Does that mean that this is likely a mutter bug, rather than bluez? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1849405 Title: Repeated keypresses from bluetooth keyboard Status in bluez package in Ubuntu: Incomplete Status in mutter package in Ubuntu: Incomplete Bug description: I have a Microsoft Surface bluetooth keyboard, and semi-frequently (e.g. around every 10-15mins) end up with repeated keypresses being made (e.g. apppt get update). This seems to happen when the machine is under slight stress, or when a new notification pops up in gnome, so it could be related to wayland possibly - but even if wayland or other processes are causing stress, I should imagine the bluetooth hid driver should not cause repeated key presses. Please let me know if you require further information about my environment, it's difficult to know where to begin with determining which process is the root cause of this. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: bluez 5.48-0ubuntu3.2 ProcVersionSignature: Ubuntu 5.0.0-32.34~18.04.2-generic 5.0.21 Uname: Linux 5.0.0-32-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.7 Architecture: amd64 Date: Wed Oct 23 09:38:20 2019 InterestingModules: rfcomm bnep btusb bluetooth MachineType: Dell Inc. Latitude 7480 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=en_AU.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.0.0-32-generic root=/dev/mapper/sarasota--kf--vg-root ro quiet splash vt.handoff=1 SourcePackage: bluez UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 07/04/2019 dmi.bios.vendor: Dell Inc. dmi.bios.version: 1.15.1 dmi.board.name: 00F6D3 dmi.board.vendor: Dell Inc. dmi.board.version: A00 dmi.chassis.type: 10 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvr1.15.1:bd07/04/2019:svnDellInc.:pnLatitude7480:pvr:rvnDellInc.:rn00F6D3:rvrA00:cvnDellInc.:ct10:cvr: dmi.product.family: Latitude dmi.product.name: Latitude 7480 dmi.product.sku: 07A0 dmi.sys.vendor: Dell Inc. hciconfig: hci0:Type: Primary Bus: USB BD Address: F8:63:3F:E9:51:8C ACL MTU: 1021:4 SCO MTU: 96:6 UP RUNNING PSCAN RX bytes:1658613 acl:66750 sco:0 events:15708 errors:0 TX bytes:605292 acl:98 sco:0 commands:2484 errors:0 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1849405/+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 1849405] [NEW] Repeated keypresses from bluetooth keyboard
Public bug reported: I have a Microsoft Surface bluetooth keyboard, and semi-frequently (e.g. around every 10-15mins) end up with repeated keypresses being made (e.g. apppt get update). This seems to happen when the machine is under slight stress, or when a new notification pops up in gnome, so it could be related to wayland possibly - but even if wayland or other processes are causing stress, I should imagine the bluetooth hid driver should not cause repeated key presses. Please let me know if you require further information about my environment, it's difficult to know where to begin with determining which process is the root cause of this. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: bluez 5.48-0ubuntu3.2 ProcVersionSignature: Ubuntu 5.0.0-32.34~18.04.2-generic 5.0.21 Uname: Linux 5.0.0-32-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.7 Architecture: amd64 Date: Wed Oct 23 09:38:20 2019 InterestingModules: rfcomm bnep btusb bluetooth MachineType: Dell Inc. Latitude 7480 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=en_AU.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.0.0-32-generic root=/dev/mapper/sarasota--kf--vg-root ro quiet splash vt.handoff=1 SourcePackage: bluez UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 07/04/2019 dmi.bios.vendor: Dell Inc. dmi.bios.version: 1.15.1 dmi.board.name: 00F6D3 dmi.board.vendor: Dell Inc. dmi.board.version: A00 dmi.chassis.type: 10 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvr1.15.1:bd07/04/2019:svnDellInc.:pnLatitude7480:pvr:rvnDellInc.:rn00F6D3:rvrA00:cvnDellInc.:ct10:cvr: dmi.product.family: Latitude dmi.product.name: Latitude 7480 dmi.product.sku: 07A0 dmi.sys.vendor: Dell Inc. hciconfig: hci0: Type: Primary Bus: USB BD Address: F8:63:3F:E9:51:8C ACL MTU: 1021:4 SCO MTU: 96:6 UP RUNNING PSCAN RX bytes:1658613 acl:66750 sco:0 events:15708 errors:0 TX bytes:605292 acl:98 sco:0 commands:2484 errors:0 ** Affects: bluez (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug bionic -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1849405 Title: Repeated keypresses from bluetooth keyboard Status in bluez package in Ubuntu: New Bug description: I have a Microsoft Surface bluetooth keyboard, and semi-frequently (e.g. around every 10-15mins) end up with repeated keypresses being made (e.g. apppt get update). This seems to happen when the machine is under slight stress, or when a new notification pops up in gnome, so it could be related to wayland possibly - but even if wayland or other processes are causing stress, I should imagine the bluetooth hid driver should not cause repeated key presses. Please let me know if you require further information about my environment, it's difficult to know where to begin with determining which process is the root cause of this. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: bluez 5.48-0ubuntu3.2 ProcVersionSignature: Ubuntu 5.0.0-32.34~18.04.2-generic 5.0.21 Uname: Linux 5.0.0-32-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.7 Architecture: amd64 Date: Wed Oct 23 09:38:20 2019 InterestingModules: rfcomm bnep btusb bluetooth MachineType: Dell Inc. Latitude 7480 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=en_AU.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.0.0-32-generic root=/dev/mapper/sarasota--kf--vg-root ro quiet splash vt.handoff=1 SourcePackage: bluez UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 07/04/2019 dmi.bios.vendor: Dell Inc. dmi.bios.version: 1.15.1 dmi.board.name: 00F6D3 dmi.board.vendor: Dell Inc. dmi.board.version: A00 dmi.chassis.type: 10 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvr1.15.1:bd07/04/2019:svnDellInc.:pnLatitude7480:pvr:rvnDellInc.:rn00F6D3:rvrA00:cvnDellInc.:ct10:cvr: dmi.product.family: Latitude dmi.product.name: Latitude 7480 dmi.product.sku: 07A0 dmi.sys.vendor: Dell Inc. hciconfig: hci0:Type: Primary Bus: USB BD Address: F8:63:3F:E9:51:8C ACL MTU: 1021:4 SCO MTU: 96:6 UP RUNNING PSCAN RX bytes:1658613 acl:66750 sco:0 events:15708 errors:0 TX bytes:605292 acl:98 sco:0 commands:2484 errors:0 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1849405/+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 1839856] [NEW] Screen resolution on external monitor won't go above 2560 x 1080
Public bug reported: I have an external monitor capable of 3440 x 1440. I am using a Thinkpad T480s. Up until about 2 weeks ago, I could set the resolution of the monitor to 3440 x 1440 just fine. Now when I try, the screen goes black and I have to revert to a lower resolution. The highest it will go now is 2560 x 1080. Lower resolutions work fine as well. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: xorg 1:7.7+19ubuntu7.1 ProcVersionSignature: Ubuntu 5.0.0-23.24~18.04.1-generic 5.0.15 Uname: Linux 5.0.0-23-generic x86_64 .tmp.unity_support_test.0: ApportVersion: 2.20.9-0ubuntu7.7 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins' CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Mon Aug 12 08:56:25 2019 DistUpgraded: Fresh install DistroCodename: bionic DistroVariant: ubuntu DkmsStatus: acpi-call, 1.1.0, 4.18.0-25-generic, x86_64: installed acpi-call, 1.1.0, 5.0.0-23-generic, x86_64: installed ExtraDebuggingInterest: Yes, including running git bisection searches GraphicsCard: Intel Corporation UHD Graphics 620 [8086:5917] (rev 07) (prog-if 00 [VGA controller]) Subsystem: Lenovo UHD Graphics 620 [17aa:2258] InstallationDate: Installed on 2019-02-19 (173 days ago) InstallationMedia: Ubuntu 18.04.2 LTS "Bionic Beaver" - Release amd64 (20190210) MachineType: LENOVO 20L7S01200 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.0.0-23-generic root=UUID=471b6634-e334-44c7-b898-080ab93327e0 ro quiet splash vt.handoff=1 SourcePackage: xorg Symptom: display UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 02/19/2019 dmi.bios.vendor: LENOVO dmi.bios.version: N22ET53W (1.30 ) dmi.board.asset.tag: Not Available dmi.board.name: 20L7S01200 dmi.board.vendor: LENOVO dmi.board.version: SDK0J40709 WIN dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.modalias: dmi:bvnLENOVO:bvrN22ET53W(1.30):bd02/19/2019:svnLENOVO:pn20L7S01200:pvrThinkPadT480s:rvnLENOVO:rn20L7S01200:rvrSDK0J40709WIN:cvnLENOVO:ct10:cvrNone: dmi.product.family: ThinkPad T480s dmi.product.name: 20L7S01200 dmi.product.sku: LENOVO_MT_20L7_BU_Think_FM_ThinkPad T480s dmi.product.version: ThinkPad T480s dmi.sys.vendor: LENOVO version.compiz: compiz 1:0.9.13.1+18.04.20180302-0ubuntu1 version.libdrm2: libdrm2 2.4.97-1ubuntu1~18.04.1 version.libgl1-mesa-dri: libgl1-mesa-dri 19.0.2-1ubuntu1.1~18.04.2 version.libgl1-mesa-glx: libgl1-mesa-glx 19.0.2-1ubuntu1.1~18.04.2 version.xserver-xorg-core: xserver-xorg-core N/A version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati N/A version.xserver-xorg-video-intel: xserver-xorg-video-intel N/A version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau N/A ** Affects: xorg (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug bionic resolution ubuntu -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to xorg in Ubuntu. https://bugs.launchpad.net/bugs/1839856 Title: Screen resolution on external monitor won't go above 2560 x 1080 Status in xorg package in Ubuntu: New Bug description: I have an external monitor capable of 3440 x 1440. I am using a Thinkpad T480s. Up until about 2 weeks ago, I could set the resolution of the monitor to 3440 x 1440 just fine. Now when I try, the screen goes black and I have to revert to a lower resolution. The highest it will go now is 2560 x 1080. Lower resolutions work fine as well. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: xorg 1:7.7+19ubuntu7.1 ProcVersionSignature: Ubuntu 5.0.0-23.24~18.04.1-generic 5.0.15 Uname: Linux 5.0.0-23-generic x86_64 .tmp.unity_support_test.0: ApportVersion: 2.20.9-0ubuntu7.7 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins' CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Mon Aug 12 08:56:25 2019 DistUpgraded: Fresh install DistroCodename: bionic DistroVariant: ubuntu DkmsStatus: acpi-call, 1.1.0, 4.18.0-25-generic, x86_64: installed acpi-call, 1.1.0, 5.0.0-23-generic, x86_64: installed ExtraDebuggingInterest: Yes, including running git bisection searches GraphicsCard: Intel Corporation UHD Graphics 620 [8086:5917] (rev 07) (prog-if 00 [VGA controller]) Subsystem: Lenovo UHD Graphics 620 [17aa:2258] InstallationDate: Installed on 2019-02-19 (173 days ago) InstallationMedia: Ubuntu 18.04.2 LTS "Bionic Beaver" - Release amd64 (20190210) MachineType: LENOVO 20L7S01200 ProcEnviron: TERM=xterm-256color PATH=(custom, no
[Touch-packages] [Bug 1748839] Re: Problem to connect to WPA2/PEAP WIFI - gnome-shell
Nothing helpful in this post but can confirm this issue still exists in 19.04. :( -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1748839 Title: Problem to connect to WPA2/PEAP WIFI - gnome-shell Status in network-manager package in Ubuntu: Confirmed Bug description: This problem is also happened on my desktop. After upgrading OS from Ubuntu 16.04 to Ubuntu 18.04.1 LTS, my PC could not connect and authenticate on WiFi with WPA2/PEAP/MSCHAPv2/no CA certificate/true username and password. I tried to solve the problem following URL link; however, it could not help me also. https://askubuntu.com/questions/279762/how-to-connect-to-wpa2-peap-mschapv2-enterprise-wifi-networks-that-dont-use-a-c My PC is HP Compaq Pro 4300, CPU: Intel® Core™ i3-3220 CPU @ 3.30GHz × 4, OS: Ubuntu 18.04.1 (64-bit). root@joe-UBTPC:/root # lspci 00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor DRAM Controller (rev 09) 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller (rev 09) 00:16.0 Communication controller: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 (rev 04) 00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 (rev 05) 00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller (rev 05) 00:1c.0 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 1 (rev b5) 00:1c.1 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 2 (rev b5) 00:1c.2 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 3 (rev b5) 00:1c.3 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 4 (rev b5) 00:1c.4 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 5 (rev b5) 00:1c.5 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 6 (rev b5) 00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 (rev 05) 00:1f.0 ISA bridge: Intel Corporation H61 Express Chipset Family LPC Controller (rev 05) 00:1f.2 SATA controller: Intel Corporation 6 Series/C200 Series Chipset Family SATA AHCI Controller (rev 05) 00:1f.3 SMBus: Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller (rev 05) 03:00.0 Network controller: Ralink corp. RT5392 PCIe Wireless Network Adapter 06:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 07) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1748839/+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 1824806] Re: Network stops working after systemd update
Dan, thanks for the comment. I will test this evening and let you know. Sorry for the delay! -- 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/1824806 Title: Network stops working after systemd update Status in systemd package in Ubuntu: Confirmed Bug description: I have four 18.04 servers that are regularly updated and have a bond/bridge configured via netplan. Every so often the interfaces themselves will have "speed changed to 0" and the server will be unresponsive over network. The servers are still usable via the console, though. I think I can confidently associate it with systemd updates. If I'm manually updating the servers, e.g., `apt dist- upgrade`, and there's a system update... the ssh session becomes unresponsive when updating systemd, timing of automatic security updates seems to coincide with it happening as well. Rebooting fixes the issue until the next systemd update. I've included some log excerpts and one of my netplan configs below. Thanks! syslog: `Apr 9 06:39:01 stn-vm-host dnsmasq[2557]: using nameserver 127.0.0.53#53 Apr 9 06:39:01 stn-vm-host systemd-networkd[13409]: enp4s0f3: Lost carrier Apr 9 06:39:01 stn-vm-host systemd-networkd[13409]: enp4s0f3: IPv6 successfully disabled Apr 9 06:39:01 stn-vm-host dnsmasq[2557]: reading /etc/resolv.conf Apr 9 06:39:01 stn-vm-host dnsmasq[2557]: using nameserver 127.0.0.53#53 Apr 9 06:39:01 stn-vm-host kernel: [1058497.661292] igb :04:00.3 enp4s0f3: speed changed to 0 for port enp4s0f3 Apr 9 06:39:01 stn-vm-host systemd-networkd[13409]: enp4s0f2: Lost carrier Apr 9 06:39:01 stn-vm-host systemd-networkd[13409]: enp4s0f2: IPv6 successfully disabled Apr 9 06:39:01 stn-vm-host dnsmasq[2557]: reading /etc/resolv.conf Apr 9 06:39:01 stn-vm-host systemd[1]: Started Network Time Synchronization. Apr 9 06:39:01 stn-vm-host systemd[1]: Stopped Flush Journal to Persistent Storage. Apr 9 06:39:01 stn-vm-host systemd[1]: Stopping Flush Journal to Persistent Storage... Apr 9 06:39:01 stn-vm-host kernel: [1058497.732487] systemd[1]: Stopping Journal Service... Apr 9 06:39:01 stn-vm-host kernel: [1058497.732903] systemd-journald[672]: Received SIGTERM from PID 1 (systemd). Apr 9 06:39:01 stn-vm-host kernel: [1058497.823634] igb :04:00.2 enp4s0f2: speed changed to 0 for port enp4s0f2 Apr 9 06:39:01 stn-vm-host kernel: [1058497.833718] systemd[1]: Stopped Journal Service. Apr 9 06:39:01 stn-vm-host kernel: [1058497.837652] systemd[1]: Starting Journal Service... Apr 9 06:39:01 stn-vm-host systemd-networkd[13409]: enp4s0f1: Lost carrier Apr 9 06:39:01 stn-vm-host dnsmasq[2557]: using nameserver 127.0.0.53#53 Apr 9 06:39:01 stn-vm-host systemd-networkd[13409]: enp4s0f1: IPv6 successfully disabled Apr 9 06:39:01 stn-vm-host dnsmasq[2557]: reading /etc/resolv.conf Apr 9 06:39:01 stn-vm-host dnsmasq[2557]: using nameserver 127.0.0.53#53 Apr 9 06:39:01 stn-vm-host dnsmasq[2557]: reading /etc/resolv.conf Apr 9 06:39:01 stn-vm-host systemd[1]: Starting Flush Journal to Persistent Storage... Apr 9 06:39:01 stn-vm-host kernel: [1058497.912976] systemd[1]: Started Journal Service. Apr 9 06:39:01 stn-vm-host systemd[1]: Started Flush Journal to Persistent Storage. Apr 9 06:39:01 stn-vm-host dnsmasq[2557]: using nameserver 127.0.0.53#53 Apr 9 06:39:01 stn-vm-host kernel: [1058497.971223] igb :04:00.1 enp4s0f1: speed changed to 0 for port enp4s0f1 Apr 9 06:39:01 stn-vm-host systemd-networkd[13409]: enp4s0f0: Lost carrier Apr 9 06:39:01 stn-vm-host systemd-networkd[13409]: enp4s0f0: IPv6 successfully disabled Apr 9 06:39:01 stn-vm-host dnsmasq[2557]: reading /etc/resolv.conf Apr 9 06:39:01 stn-vm-host dnsmasq[2557]: using nameserver 127.0.0.53#53 Apr 9 06:39:01 stn-vm-host kernel: [1058498.109063] igb :04:00.0 enp4s0f0: speed changed to 0 for port enp4s0f0 Apr 9 06:39:01 stn-vm-host systemd-networkd[13409]: bond0: Gained carrier Apr 9 06:39:01 stn-vm-host systemd-networkd[13409]: bond0: Configured Apr 9 06:39:01 stn-vm-host systemd-networkd[13409]: br0: Configured` Apt history, noting the systemd update just before the interfaces when down `Start-Date: 2019-04-09 06:38:55 Commandline: /usr/bin/unattended-upgrade Upgrade: libsystemd0:amd64 (237-3ubuntu10.15, 237-3ubuntu10.19), libpam-systemd:amd64 (237-3ubuntu10.15, 237-3ubuntu10.19), systemd:amd64 (237-3ubuntu10.15, 237-3ubuntu10.19), libnss-systemd:amd64 (237-3ubuntu10.15, 237-3ubuntu10.19) End-Date: 2019-04-09 06:39:06` The netplan config on this server: `network: ethernets: enp4s0f0: addresses: [] dhcp4: false dhcp6: false enp4s0f1: addresses: [] dhcp4: false
[Touch-packages] [Bug 1824806] [NEW] Network stops working after systemd update
Public bug reported: I have four 18.04 servers that are regularly updated and have a bond/bridge configured via netplan. Every so often the interfaces themselves will have "speed changed to 0" and the server will be unresponsive over network. The servers are still usable via the console, though. I think I can confidently associate it with systemd updates. If I'm manually updating the servers, e.g., `apt dist-upgrade`, and there's a system update... the ssh session becomes unresponsive when updating systemd, timing of automatic security updates seems to coincide with it happening as well. Rebooting fixes the issue until the next systemd update. I've included some log excerpts and one of my netplan configs below. Thanks! syslog: `Apr 9 06:39:01 stn-vm-host dnsmasq[2557]: using nameserver 127.0.0.53#53 Apr 9 06:39:01 stn-vm-host systemd-networkd[13409]: enp4s0f3: Lost carrier Apr 9 06:39:01 stn-vm-host systemd-networkd[13409]: enp4s0f3: IPv6 successfully disabled Apr 9 06:39:01 stn-vm-host dnsmasq[2557]: reading /etc/resolv.conf Apr 9 06:39:01 stn-vm-host dnsmasq[2557]: using nameserver 127.0.0.53#53 Apr 9 06:39:01 stn-vm-host kernel: [1058497.661292] igb :04:00.3 enp4s0f3: speed changed to 0 for port enp4s0f3 Apr 9 06:39:01 stn-vm-host systemd-networkd[13409]: enp4s0f2: Lost carrier Apr 9 06:39:01 stn-vm-host systemd-networkd[13409]: enp4s0f2: IPv6 successfully disabled Apr 9 06:39:01 stn-vm-host dnsmasq[2557]: reading /etc/resolv.conf Apr 9 06:39:01 stn-vm-host systemd[1]: Started Network Time Synchronization. Apr 9 06:39:01 stn-vm-host systemd[1]: Stopped Flush Journal to Persistent Storage. Apr 9 06:39:01 stn-vm-host systemd[1]: Stopping Flush Journal to Persistent Storage... Apr 9 06:39:01 stn-vm-host kernel: [1058497.732487] systemd[1]: Stopping Journal Service... Apr 9 06:39:01 stn-vm-host kernel: [1058497.732903] systemd-journald[672]: Received SIGTERM from PID 1 (systemd). Apr 9 06:39:01 stn-vm-host kernel: [1058497.823634] igb :04:00.2 enp4s0f2: speed changed to 0 for port enp4s0f2 Apr 9 06:39:01 stn-vm-host kernel: [1058497.833718] systemd[1]: Stopped Journal Service. Apr 9 06:39:01 stn-vm-host kernel: [1058497.837652] systemd[1]: Starting Journal Service... Apr 9 06:39:01 stn-vm-host systemd-networkd[13409]: enp4s0f1: Lost carrier Apr 9 06:39:01 stn-vm-host dnsmasq[2557]: using nameserver 127.0.0.53#53 Apr 9 06:39:01 stn-vm-host systemd-networkd[13409]: enp4s0f1: IPv6 successfully disabled Apr 9 06:39:01 stn-vm-host dnsmasq[2557]: reading /etc/resolv.conf Apr 9 06:39:01 stn-vm-host dnsmasq[2557]: using nameserver 127.0.0.53#53 Apr 9 06:39:01 stn-vm-host dnsmasq[2557]: reading /etc/resolv.conf Apr 9 06:39:01 stn-vm-host systemd[1]: Starting Flush Journal to Persistent Storage... Apr 9 06:39:01 stn-vm-host kernel: [1058497.912976] systemd[1]: Started Journal Service. Apr 9 06:39:01 stn-vm-host systemd[1]: Started Flush Journal to Persistent Storage. Apr 9 06:39:01 stn-vm-host dnsmasq[2557]: using nameserver 127.0.0.53#53 Apr 9 06:39:01 stn-vm-host kernel: [1058497.971223] igb :04:00.1 enp4s0f1: speed changed to 0 for port enp4s0f1 Apr 9 06:39:01 stn-vm-host systemd-networkd[13409]: enp4s0f0: Lost carrier Apr 9 06:39:01 stn-vm-host systemd-networkd[13409]: enp4s0f0: IPv6 successfully disabled Apr 9 06:39:01 stn-vm-host dnsmasq[2557]: reading /etc/resolv.conf Apr 9 06:39:01 stn-vm-host dnsmasq[2557]: using nameserver 127.0.0.53#53 Apr 9 06:39:01 stn-vm-host kernel: [1058498.109063] igb :04:00.0 enp4s0f0: speed changed to 0 for port enp4s0f0 Apr 9 06:39:01 stn-vm-host systemd-networkd[13409]: bond0: Gained carrier Apr 9 06:39:01 stn-vm-host systemd-networkd[13409]: bond0: Configured Apr 9 06:39:01 stn-vm-host systemd-networkd[13409]: br0: Configured` Apt history, noting the systemd update just before the interfaces when down `Start-Date: 2019-04-09 06:38:55 Commandline: /usr/bin/unattended-upgrade Upgrade: libsystemd0:amd64 (237-3ubuntu10.15, 237-3ubuntu10.19), libpam-systemd:amd64 (237-3ubuntu10.15, 237-3ubuntu10.19), systemd:amd64 (237-3ubuntu10.15, 237-3ubuntu10.19), libnss-systemd:amd64 (237-3ubuntu10.15, 237-3ubuntu10.19) End-Date: 2019-04-09 06:39:06` The netplan config on this server: `network: ethernets: enp4s0f0: addresses: [] dhcp4: false dhcp6: false enp4s0f1: addresses: [] dhcp4: false dhcp6: false enp4s0f2: addresses: [] dhcp4: false dhcp6: false enp4s0f3: addresses: [] dhcp4: false dhcp6: false bonds: bond0: dhcp4: false dhcp6: false interfaces: - enp4s0f0
[Touch-packages] [Bug 1822416] Re: resolve: do not hit CNAME or DNAME entry in NODATA cache
I stopped using resolve because of this bug so unfortunately, I can't say whether or not that error appeared in the log at the same time. -- 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/1822416 Title: resolve: do not hit CNAME or DNAME entry in NODATA cache Status in systemd package in Ubuntu: New Bug description: The question: DNS A record lookups fail to resolve due to cached CNAME NODATA lookups ... https://askubuntu.com/questions/1063462/18-04-server-systemd-resolve- returns-cached-cname-nodata-for-a-lookup Upstream at Github: Systemd issue 998 - Cached cname NODATA returned for A lookup ... https://github.com/systemd/systemd/issues/9833 Please patch ... https://github.com/systemd/systemd/commit/3740146a4cbd99883af79e375ee4836206dcea4e To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1822416/+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 1811580] Re: systemd fails to start sshd at reboot
Okay. I guess I would have expected that if there was a dependency on a specific kernel version, that I wouldn't be able to install a package that wasn't compatible and breaks the system by installing a security update. It would be preferable to be informed there is a security update but that I can't install it because I am running an out of date kernel...then I know I am insecure and that the kernel is the issue. But I guess that is a topic for the package management guys. The error message from systemd-tmpfiles about too many symlinks isn't particularly helpful either since in this case the problem (apparently) has nothing to do with symlinks but rather filesystem apis in the old kernel (I guess?). Yes of course I can contact the hosting provider and ask them to provide an updated kernel and the likely result may be that I just have to use an alternate provider if I want this to work. Perhaps I should anyway since the hosting provider having such old kernels isn't a good sign. I also saw this comment: https://github.com/systemd/systemd/commit/6a89d671dfdd92c0b1b703d7fcb5b0551cafb570 For now I have worked around this issue by just updating the paths to point to /run instead of /var/run so systemd-tmpfiles doesn't barf on the symlinks. sed -i -e 's;/var/run;/run;g' /usr/lib/tmpfiles.d/*.conf -- 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/1811580 Title: systemd fails to start sshd at reboot Status in systemd package in Ubuntu: Incomplete Bug description: So far reported issues turned out to be: - obsolete/buggy/vulnerable 3rd party provided kernels - bad permissions on / Please ensure / is owned by root:root. Please ensure you are running up to date kernels. === Ubuntu 16.04.5, systemd 229-4ubuntu21.15 The latest systemd update has somehow changed the method it uses to start 'ssh.service' i.e. 'sshd'. systemd fails to start sshd if /etc/ssh/sshd_config contains "UsePrivilegeSeparation yes" and /var/run/sshd/ does not already exist. Being as this is the default, virtually EVERY Ubuntu 16.04 server in the world has UsePrivilegeSeparation set to yes. Furthermore, at the time when the user performs 'apt upgrade' and receives the newest version of systemd, /var/run/sshd/ already exists, so sshd successfully reloads for as long as the server doesn't get rebooted. BUT, as soon as the server is rebooted for any reason, /var/run/sshd/ gets cleaned away, and sshd fails to start, causing the remote user to be completely locked out of his system. This is a MAJOR issue for millions of VPS servers worldwide, as they are all about to get locked out of their servers and potentially lose data. The next reboot is a ticking time bomb waiting to spring. The bomb can be defused by implicitly setting 'UsePrivilegeSeparation no' in /etc/ssh/sshd_config, however unsuspecting administrators are bound to be caught out by the millions. I got caught by it in the middle of setting up a new server yesterday, and it took a whole day to find the source. The appropriate fix would be to ensure that systemd can successfully 'start ssh.service' even when 'UsePrivilegeSeparation yes' is set. systemd needs to test that /var/run/sshd/ exists before starting sshd, just as the init.d script for sshd does. openssl could also be patched so that UsePrivilegeSeparation is no longer enabled by default, however that is not going to solve the problem for millions of pre- existing config files. Only an update to openssl to force-override that flag to 'no' would solve the problem. Thus systemd still needs to be responsible for ensuring that it inits sshd properly by ensuring that /var/run/sshd/ exists before it sends the 'start' command. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1811580/+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 1811580] Re: systemd fails to start sshd at reboot
Same situation. Ubuntu 16.04 openvz vps image of unknown origin. Minimized image, ran security updates and rebooted. openssh server failed to start due to systemd-tmpfiles failing with Failed to validate path /var/run/sshd: Too many levels of symbolic links Which then causes ssh server to fail to start with error: Missing privilege separation directory: /var/run/sshd # # pre breaking update # # uname -a Linux NJ01 2.6.32-openvz-042stab120.18-amd64 #1 SMP Fri Jan 13 10:33:34 MSK 2017 x86_64 x86_64 x86_64 GNU/Linux # cat /usr/lib/tmpfiles.d/sshd.conf d /var/run/sshd 0755 root root # systemd-tmpfiles --version systemd 229 +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN # systemd-tmpfiles --create /usr/lib/tmpfiles.d/sshd.conf # # success # ls -ld / drwxr-xr-x 23 root root 4096 Feb 26 09:35 / # ls -ld /var drwxr-xr-x 12 root root 4096 Nov 26 2016 /var # ls -ld /var/run lrwxrwxrwx 1 root root 4 Nov 26 2016 /var/run -> /run # ls -ld /var/run/sshd drwxr-xr-x 2 root root 40 Feb 26 09:35 /var/run/sshd # apt-cache policy systemd systemd: Installed: 229-4ubuntu12 Candidate: 229-4ubuntu12 Version table: *** 229-4ubuntu12 100 100 /var/lib/dpkg/status #---BREAKING UPDATE START apt-get update # "minimize" the system export DEBIAN_FRONTEND=noninteractive apt-get --assume-yes install aptitude ubuntu-minimal aptitude --assume-yes markauto '~i!?name(ubuntu-minimal~|linux-generic~|openssh-server~|systemd)' aptitude --assume-yes purge '~c' # apply security updates apt-get --assume-yes install unattended-upgrades unattended-upgrade # reboot shutdown -r now #---BREAKING UPDATE END # post update (pre-reboot). # apt-cache policy systemd systemd: Installed: 229-4ubuntu21.16 Candidate: 229-4ubuntu21.16 Version table: *** 229-4ubuntu21.16 500 500 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu xenial-security/main amd64 Packages 100 /var/lib/dpkg/status 229-4ubuntu4 500 500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages # ls -ld / drwxr-xr-x 23 root root 4096 Feb 26 09:03 / # ls -ld /var drwxr-xr-x 12 root root 4096 Nov 26 2016 /var # ls -ld /var/run lrwxrwxrwx 1 root root 4 Nov 26 2016 /var/run -> /run # ls -ld /var/run/sshd drwxr-xr-x 2 root root 40 Feb 26 09:03 /var/run/sshd # systemd-tmpfiles --version systemd 229 +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN # systemd-tmpfiles --create /usr/lib/tmpfiles.d/sshd.conf Failed to validate path /var/run/sshd: Too many levels of symbolic links Anyway, root cause seems to be this systemd-tmpfiles error. Tmpfile gets purged at reboot and doesn't get recreated. Seems pretty major that applying security updates would lock you out of your server. If I didn't happen to have a serial console with this particular VPS provider (some others I use don't provide one)...I would have no idea what was going on. I get this might be due to weird openvz image or older kernel...but these ubuntu openvz images are very common. -- 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/1811580 Title: systemd fails to start sshd at reboot Status in systemd package in Ubuntu: Incomplete Bug description: So far reported issues turned out to be: - obsolete/buggy/vulnerable 3rd party provided kernels - bad permissions on / Please ensure / is owned by root:root. Please ensure you are running up to date kernels. === Ubuntu 16.04.5, systemd 229-4ubuntu21.15 The latest systemd update has somehow changed the method it uses to start 'ssh.service' i.e. 'sshd'. systemd fails to start sshd if /etc/ssh/sshd_config contains "UsePrivilegeSeparation yes" and /var/run/sshd/ does not already exist. Being as this is the default, virtually EVERY Ubuntu 16.04 server in the world has UsePrivilegeSeparation set to yes. Furthermore, at the time when the user performs 'apt upgrade' and receives the newest version of systemd, /var/run/sshd/ already exists, so sshd successfully reloads for as long as the server doesn't get rebooted. BUT, as soon as the server is rebooted for any reason, /var/run/sshd/ gets cleaned away, and sshd fails to start, causing the remote user to be completely locked out of his system. This is a MAJOR issue for millions of VPS servers worldwide, as they are all about to get locked out of their servers and potentially lose data. The next reboot is a ticking time bomb waiting to spring. The bomb can be defused by implicitly setting 'UsePrivilegeSeparation no' in /etc/ssh/sshd_config, however unsuspecting administrators are bound to be caught out by the millions. I got
[Touch-packages] [Bug 1804611] Re: systemd-networkd is stuck in 'configuring' with DHCP and no default route
I'm seeing the same behavior with Ubuntu 18.04.2 running in a VMware virtual machine. When networking for the VM is set to "Host-only", it takes two extra minutes to boot while waiting for systemd-networkd-wait- online.service to fail. $ lsb_release -rd Description:Ubuntu 18.04.2 LTS Release:18.04 $ apt-cache policy systemd systemd: Installed: 237-3ubuntu10.13 Candidate: 237-3ubuntu10.13 Version table: *** 237-3ubuntu10.13 500 500 http://us.archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages 100 /var/lib/dpkg/status 237-3ubuntu10 500 500 http://us.archive.ubuntu.com/ubuntu bionic/main amd64 Packages -- 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/1804611 Title: systemd-networkd is stuck in 'configuring' with DHCP and no default route Status in systemd package in Ubuntu: Confirmed Bug description: In our network setup systemd-networkd fails to configure everything correctly. Our systems have two NIC which are configured via DHCP. One NIC is in a service network without a default route. With this setup we get systemd-networkd-wait-online.service failing after timeout and the service NIC stuck in 'configuring'. Besides that, everything is working as expected. Our config: # lsb_release -rd Description:Ubuntu 18.04.1 LTS Release:18.04 # apt-cache policy systemd systemd: Installiert: 237-3ubuntu10.9 Installationskandidat: 237-3ubuntu10.9 Versionstabelle: *** 237-3ubuntu10.9 500 500 http://de.archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages 100 /var/lib/dpkg/status 237-3ubuntu10 500 500 http://de.archive.ubuntu.com/ubuntu bionic/main amd64 Package # cat /etc/systemd/network/ens160.network [Match] Name=ens160 [Network] DHCP=ipv4 [DHCP] UseMTU=true RouteMetric=100 ClientIdentifier=mac # cat /etc/systemd/network/ens192.network [Match] Name=ens192 [Network] DHCP=ipv4 [DHCP] UseMTU=true RouteMetric=100 ClientIdentifier=mac UseRoutes=false UseDNS=false networkctl status -a ● 1: lo Link File: n/a Network File: n/a Type: loopback State: carrier (unmanaged) Address: 127.0.0.1 ::1 ● 2: ens160 Link File: n/a Network File: /etc/systemd/network/ens160.network Type: ether State: routable (configured) Path: pci-:03:00.0 Vendor: VMware Model: VMXNET3 Ethernet Controller HW Address: 00:50:56:a4:98:4c (VMware, Inc.) Address: 10.22.0.30 fe80::250:56ff:fea4:984c Gateway: 10.22.200.254 (Hewlett Packard Enterprise) DNS: 10.22.0.2 Search Domains: xxx ● 3: ens192 Link File: n/a Network File: /etc/systemd/network/ens192.network Type: ether State: routable (configuring) Path: pci-:0b:00.0 Vendor: VMware Model: VMXNET3 Ethernet Controller HW Address: 00:50:56:a4:c0:42 (VMware, Inc.) Address: 10.23.0.30 fe80::250:56ff:fea4:c042 Search Domains: This also happens in other configurations, which are more complex as soon as I add the service NIC which has no default route. systemd 239 from ubuntu 16.10 works fine. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1804611/+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 1807262] Re: stein unit tests fail with sqlalchemy.exc.NoSuchTableError: migration_tmp
** Changed in: sqlalchemy-migrate Status: New => In Progress ** Changed in: sqlalchemy-migrate Assignee: (unassigned) => Corey Bryant (corey.bryant) ** Changed in: sqlalchemy-migrate Importance: Undecided => High -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to sqlite3 in Ubuntu. https://bugs.launchpad.net/bugs/1807262 Title: stein unit tests fail with sqlalchemy.exc.NoSuchTableError: migration_tmp Status in sqlalchemy-migrate: In Progress Status in cinder package in Ubuntu: Fix Released Status in migrate package in Ubuntu: Fix Released Status in nova package in Ubuntu: Fix Released Status in sqlite3 package in Ubuntu: Invalid Bug description: Several tests that use sqlite fail with: "sqlalchemy.exc.NoSuchTableError: migration_tmp". I'm currently hitting this with nova and cinder packages in disco. Note this started sometime after 11/19 when nova 2:19.0.0~b1~git2018111953.3e756ff674-0ubuntu1 was uploaded (and built successfully at the time). After doing some digging this appears to occur with libsqlite3-0 3.26.0-1 but does not occur with libsqlite3-0 3.25.3-1. Here are some more details on that, shown by running a failing unit test from the cinder package: https://paste.ubuntu.com/p/hsnQFQD572/ Update: The test in the paste above also works successfully with libsqlite3-0 3.25.3-2. To manage notifications about this bug go to: https://bugs.launchpad.net/sqlalchemy-migrate/+bug/1807262/+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 1726856] Re: ufw does not start automatically at boot
** Attachment added: "ufw.tar.gz" https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1726856/+attachment/5222404/+files/ufw.tar.gz -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1726856 Title: ufw does not start automatically at boot Status in ufw: Incomplete Status in ufw package in Ubuntu: Incomplete Status in ufw source package in Xenial: Incomplete Status in ufw source package in Bionic: Incomplete Status in ufw source package in Cosmic: Incomplete Status in ufw source package in Disco: Incomplete Bug description: Whenever I boot into 17.10 ufw is always inactive, even though /etc/ufw/ufw.conf has this: # Set to yes to start on boot. If setting this remotely, be sure to add a rule # to allow your remote connection before starting ufw. Eg: 'ufw allow 22/tcp' ENABLED=yes ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: ufw 0.35-5 ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4 Uname: Linux 4.13.0-16-generic x86_64 ApportVersion: 2.20.7-0ubuntu3 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Tue Oct 24 13:56:40 2017 InstallationDate: Installed on 2015-04-01 (936 days ago) InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 (20140722.2) PackageArchitecture: all SourcePackage: ufw UpgradeStatus: Upgraded to artful on 2017-10-24 (0 days ago) mtime.conffile..etc.default.ufw: 2015-06-17T22:01:02.089170 To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/1726856/+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 1726856] Re: ufw does not start automatically at boot
** Attachment added: "dpkg.list" https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1726856/+attachment/5222403/+files/dpkg.list -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1726856 Title: ufw does not start automatically at boot Status in ufw: Incomplete Status in ufw package in Ubuntu: Incomplete Status in ufw source package in Xenial: Incomplete Status in ufw source package in Bionic: Incomplete Status in ufw source package in Cosmic: Incomplete Status in ufw source package in Disco: Incomplete Bug description: Whenever I boot into 17.10 ufw is always inactive, even though /etc/ufw/ufw.conf has this: # Set to yes to start on boot. If setting this remotely, be sure to add a rule # to allow your remote connection before starting ufw. Eg: 'ufw allow 22/tcp' ENABLED=yes ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: ufw 0.35-5 ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4 Uname: Linux 4.13.0-16-generic x86_64 ApportVersion: 2.20.7-0ubuntu3 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Tue Oct 24 13:56:40 2017 InstallationDate: Installed on 2015-04-01 (936 days ago) InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 (20140722.2) PackageArchitecture: all SourcePackage: ufw UpgradeStatus: Upgraded to artful on 2017-10-24 (0 days ago) mtime.conffile..etc.default.ufw: 2015-06-17T22:01:02.089170 To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/1726856/+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 1726856] Re: ufw does not start automatically at boot
** Attachment added: "ufw.raw" https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1726856/+attachment/5222405/+files/ufw.raw -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1726856 Title: ufw does not start automatically at boot Status in ufw: Incomplete Status in ufw package in Ubuntu: Incomplete Status in ufw source package in Xenial: Incomplete Status in ufw source package in Bionic: Incomplete Status in ufw source package in Cosmic: Incomplete Status in ufw source package in Disco: Incomplete Bug description: Whenever I boot into 17.10 ufw is always inactive, even though /etc/ufw/ufw.conf has this: # Set to yes to start on boot. If setting this remotely, be sure to add a rule # to allow your remote connection before starting ufw. Eg: 'ufw allow 22/tcp' ENABLED=yes ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: ufw 0.35-5 ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4 Uname: Linux 4.13.0-16-generic x86_64 ApportVersion: 2.20.7-0ubuntu3 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Tue Oct 24 13:56:40 2017 InstallationDate: Installed on 2015-04-01 (936 days ago) InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 (20140722.2) PackageArchitecture: all SourcePackage: ufw UpgradeStatus: Upgraded to artful on 2017-10-24 (0 days ago) mtime.conffile..etc.default.ufw: 2015-06-17T22:01:02.089170 To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/1726856/+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 1726856] Re: ufw does not start automatically at boot
I rebooted and confirmed that ufw still reports itself as inactive. Attached are the requested files. Note: I only included the last 25000 lines from journal.full - otherwise I would have to upload 250Mb! ** Attachment added: "journal.full" https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1726856/+attachment/5222402/+files/journal.full -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1726856 Title: ufw does not start automatically at boot Status in ufw: Incomplete Status in ufw package in Ubuntu: Incomplete Status in ufw source package in Xenial: Incomplete Status in ufw source package in Bionic: Incomplete Status in ufw source package in Cosmic: Incomplete Status in ufw source package in Disco: Incomplete Bug description: Whenever I boot into 17.10 ufw is always inactive, even though /etc/ufw/ufw.conf has this: # Set to yes to start on boot. If setting this remotely, be sure to add a rule # to allow your remote connection before starting ufw. Eg: 'ufw allow 22/tcp' ENABLED=yes ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: ufw 0.35-5 ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4 Uname: Linux 4.13.0-16-generic x86_64 ApportVersion: 2.20.7-0ubuntu3 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Tue Oct 24 13:56:40 2017 InstallationDate: Installed on 2015-04-01 (936 days ago) InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 (20140722.2) PackageArchitecture: all SourcePackage: ufw UpgradeStatus: Upgraded to artful on 2017-10-24 (0 days ago) mtime.conffile..etc.default.ufw: 2015-06-17T22:01:02.089170 To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/1726856/+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 1726856] Re: ufw does not start automatically at boot
I made the change to /lib/ufw/ufw-init as requested and confirmed that after reboot I was still hitting the issue (Ubuntu 18.04.1 LTS): $ sudo ufw status Status: inactive Attached is the requested journalctl output. ** Attachment added: "journalctl.log" https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1726856/+attachment/551/+files/journalctl.log -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1726856 Title: ufw does not start automatically at boot Status in ufw: Incomplete Status in ufw package in Ubuntu: New Status in ufw source package in Xenial: New Status in ufw source package in Bionic: New Status in ufw source package in Cosmic: New Bug description: Whenever I boot into 17.10 ufw is always inactive, even though /etc/ufw/ufw.conf has this: # Set to yes to start on boot. If setting this remotely, be sure to add a rule # to allow your remote connection before starting ufw. Eg: 'ufw allow 22/tcp' ENABLED=yes ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: ufw 0.35-5 ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4 Uname: Linux 4.13.0-16-generic x86_64 ApportVersion: 2.20.7-0ubuntu3 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Tue Oct 24 13:56:40 2017 InstallationDate: Installed on 2015-04-01 (936 days ago) InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 (20140722.2) PackageArchitecture: all SourcePackage: ufw UpgradeStatus: Upgraded to artful on 2017-10-24 (0 days ago) mtime.conffile..etc.default.ufw: 2015-06-17T22:01:02.089170 To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/1726856/+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 1807057] [NEW] Systemd passes a relative path to the unit-file for mariadb.service, which breaks apparmor.
Public bug reported: Ubuntu's systemd implementation is passing a relative path for the sytemd-notify socket 'run/systemd/notify' into the environment of the mariadb.service unit-file. This breaks apparmor, since apparmor profile rules require an absolute path '/run/systemd/notify rw,'. Please fix this so I can enforce an apparmor profile with mariadb. Nota Bene: the mysql-sever package doesn't have this problem. As far as i can tell, this is because that package doesn't interact with the systemd-notify socket, but I could be wrong. I spoke with some patrons of #systemd on irc.freenode.net who claim this is a bug in Ubuntu's systemd implementation, stating that it shouldn't pass a relative path to the /run/systemd/notify socket. Thanks for your maintenance. Systemd sucks but apparmor is cool. Since your distro integrates both of these technologies, please fix this bug. Thank you, Matt Rush OSCP, OSCE ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: systemd 237-3ubuntu10.4 ProcVersionSignature: Ubuntu 4.15.0-1025.25-aws 4.15.18 Uname: Linux 4.15.0-1025-aws x86_64 ApportVersion: 2.20.9-0ubuntu7.4 Architecture: amd64 Date: Wed Dec 5 17:35:09 2018 Ec2AMI: ami-0ac019f4fcb7cb7e6 Ec2AMIManifest: (unknown) Ec2AvailabilityZone: us-east-1b Ec2InstanceType: t2.medium Ec2Kernel: unavailable Ec2Ramdisk: unavailable Lsusb: Error: command ['lsusb'] failed with exit code 1: MachineType: Xen HVM domU ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-1025-aws root=UUID=bbf64c6d-bc15-4ae0-aa4c-608fd9820d95 ro console=tty1 console=ttyS0 nvme.io_timeout=4294967295 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 08/24/2006 dmi.bios.vendor: Xen dmi.bios.version: 4.2.amazon dmi.chassis.type: 1 dmi.chassis.vendor: Xen dmi.modalias: dmi:bvnXen:bvr4.2.amazon:bd08/24/2006:svnXen:pnHVMdomU:pvr4.2.amazon:cvnXen:ct1:cvr: dmi.product.name: HVM domU dmi.product.version: 4.2.amazon dmi.sys.vendor: Xen ** Affects: systemd (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug bionic ec2-images -- 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/1807057 Title: Systemd passes a relative path to the unit-file for mariadb.service, which breaks apparmor. Status in systemd package in Ubuntu: New Bug description: Ubuntu's systemd implementation is passing a relative path for the sytemd-notify socket 'run/systemd/notify' into the environment of the mariadb.service unit-file. This breaks apparmor, since apparmor profile rules require an absolute path '/run/systemd/notify rw,'. Please fix this so I can enforce an apparmor profile with mariadb. Nota Bene: the mysql-sever package doesn't have this problem. As far as i can tell, this is because that package doesn't interact with the systemd-notify socket, but I could be wrong. I spoke with some patrons of #systemd on irc.freenode.net who claim this is a bug in Ubuntu's systemd implementation, stating that it shouldn't pass a relative path to the /run/systemd/notify socket. Thanks for your maintenance. Systemd sucks but apparmor is cool. Since your distro integrates both of these technologies, please fix this bug. Thank you, Matt Rush OSCP, OSCE ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: systemd 237-3ubuntu10.4 ProcVersionSignature: Ubuntu 4.15.0-1025.25-aws 4.15.18 Uname: Linux 4.15.0-1025-aws x86_64 ApportVersion: 2.20.9-0ubuntu7.4 Architecture: amd64 Date: Wed Dec 5 17:35:09 2018 Ec2AMI: ami-0ac019f4fcb7cb7e6 Ec2AMIManifest: (unknown) Ec2AvailabilityZone: us-east-1b Ec2InstanceType: t2.medium Ec2Kernel: unavailable Ec2Ramdisk: unavailable Lsusb: Error: command ['lsusb'] failed with exit code 1: MachineType: Xen HVM domU ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-1025-aws root=UUID=bbf64c6d-bc15-4ae0-aa4c-608fd9820d95 ro console=tty1 console=ttyS0 nvme.io_timeout=4294967295 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 08/24/2006 dmi.bios.vendor: Xen dmi.bios.version: 4.2.amazon dmi.chassis.type: 1 dmi.chassis.vendor: Xen dmi.modalias: dmi:bvnXen:bvr4.2.amazon:bd08/24/2006:svnXen:pnHVMdomU:pvr4.2.amazon:cvnXen:ct1:cvr: dmi.product.name: HVM domU dmi.product.version: 4.2.amazon dmi.sys.vendor: Xen To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1807057/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https
[Touch-packages] [Bug 1797386] Re: [SRU] OpenSSL 1.1.1 to 18.04 LTS
Thank you very much, Dimitri -- I am interested in this also. I tested that PPA on a test web server running nginx, uwsgi, uwsgi- plugin-python3, Django 1.11(.16), and a Python 3.6 'pyvenv' virtual environment using 'psycopg2' to connect to a PostgreSQL 10 server via the pre-built Python wheel for 'psycopg2_binary' version 2.7.5. I could immediately connect to nginx over TLS 1.3 without any problems, and the Qualys SSL Labs scan also reported that all was well with TLS 1.3. However, the web app under uwsgi crashed (segfaulted) on any request, with a stack trace at https://pastebin.com/DLGiuKfR I was relatively surprised that the 'psycopg2_binary' Python wheel seemed to bundle its own version of libssl-8bb9b3dd.so.1.0.2o -- and it looks like there's some incompatibility with this build of Python and OpenSSL 1.1.1. I removed this Python package and installed 'psycopg2' instead, and saw the same behavior. I was able to fix this by reinstalling psycopg2 from source with 'pip install --no-binary=":all:" psycopg2', and now everything works well with the web app. I'm not sure how much of a problem this is at this stage, or who has the responsibility to address it (Ubuntu developers or whoever built the psycopg2 wheel), but I figured I may as well mention this anyway. It's great that everything was fine with nginx without any effort on my part; thanks! -- 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/1797386 Title: [SRU] OpenSSL 1.1.1 to 18.04 LTS Status in openssl package in Ubuntu: Confirmed Bug description: [Impact] * OpenSSL 1.1.1 is an LTS release upstream, which will continue to receive security support for much longer than 1.1.0 series will. * OpenSSL 1.1.1 comes with support for TLS v1.3 which is expected to be rapidly adopted due to increased set of supported hashes & algoes, as well as improved handshake [re-]negotiation. * OpenSSL 1.1.1 comes with improved hw-acceleration capabilities. * OpenSSL 1.1.1 is ABI/API compatible with 1.1.0, however some software is sensitive to the negotiation handshake and may either need patches/improvements or clamp-down to maximum v1.2. [Test Case] * Rebuild all reverse dependencies * Execute autopkg tests for all of them * Clamp down to TLS v1.2 software that does not support TLS v1.3 (e.g. mongodb) * Backport TLS v1.3 support patches, where applicable [Regression Potential] * Connectivity interop is the biggest issues which will be unavoidable with introducing TLS v1.3. However, tests on cosmic demonstrate that curl/nginx/google-chrome/mozilla-firefox connect and negotiate TLS v1.3 without issues. * Mitigation of discovered connectivity issues will be possible by clamping down to TLS v1.2 in either server-side or client-side software or by backporting relevant support fixes [Other Info] * Previous FFe for OpenSSL in 18.10 is at https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1793092 * TLS v1.3 support in NSS is expected to make it to 18.04 via security updates * TLS v1.3 support in GnuTLS is expected to be available in 19.04 * Test OpenSSL is being prepared in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3473 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1797386/+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 1806266] [NEW] package python3 3.6.5-3ubuntu1 failed to install/upgrade: new python3 package pre-removal script subprocess returned error exit status 139
Public bug reported: Just tried to run the updates the app updater recommended ProblemType: Package DistroRelease: Ubuntu 18.04 Package: python3 3.6.5-3ubuntu1 ProcVersionSignature: Ubuntu 4.15.0-29.31-generic 4.15.18 Uname: Linux 4.15.0-29-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.2 Architecture: amd64 Date: Sun Dec 2 12:06:44 2018 ErrorMessage: new python3 package pre-removal script subprocess returned error exit status 139 InstallationDate: Installed on 2018-11-24 (8 days ago) InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 (20180725) Python3Details: /usr/bin/python3.6, Python 3.6.7, python3-minimal, 3.6.7-1~18.04 PythonDetails: N/A RelatedPackageVersions: dpkg 1.19.0.5ubuntu2.1 apt 1.6.3 SourcePackage: python3-defaults Title: package python3 3.6.5-3ubuntu1 failed to install/upgrade: new python3 package pre-removal script subprocess returned error exit status 139 UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: python3-defaults (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-package bionic -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python3-defaults in Ubuntu. https://bugs.launchpad.net/bugs/1806266 Title: package python3 3.6.5-3ubuntu1 failed to install/upgrade: new python3 package pre-removal script subprocess returned error exit status 139 Status in python3-defaults package in Ubuntu: New Bug description: Just tried to run the updates the app updater recommended ProblemType: Package DistroRelease: Ubuntu 18.04 Package: python3 3.6.5-3ubuntu1 ProcVersionSignature: Ubuntu 4.15.0-29.31-generic 4.15.18 Uname: Linux 4.15.0-29-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.2 Architecture: amd64 Date: Sun Dec 2 12:06:44 2018 ErrorMessage: new python3 package pre-removal script subprocess returned error exit status 139 InstallationDate: Installed on 2018-11-24 (8 days ago) InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 (20180725) Python3Details: /usr/bin/python3.6, Python 3.6.7, python3-minimal, 3.6.7-1~18.04 PythonDetails: N/A RelatedPackageVersions: dpkg 1.19.0.5ubuntu2.1 apt 1.6.3 SourcePackage: python3-defaults Title: package python3 3.6.5-3ubuntu1 failed to install/upgrade: new python3 package pre-removal script subprocess returned error exit status 139 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python3-defaults/+bug/1806266/+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 1754693] Re: Xwayland crashed with SIGABRT in st_renderbuffer_delete() [often when running Skype or Slack snaps]
I recently switched back to Ubuntu, only to find that Slack in a snap is still crashing on Wayland! I previously reported what seems like a related bug on snapcraft-- here's the link to the related bug with logs and some details from experiences on Fedora28 and Arch. https://forum.snapcraft.io/t/slack-for-linux-crash-on-wayland/5909 Currently still experiencing the issue with Ubuntu 18.10: ``` $ snap info slack name: slack summary: Team communication for the 21st century. publisher: Slack✓ contact: https://get.slack.help/hc/en-us license: Proprietary description: | Caution: Slack for Linux is in beta. We’re still busy adding features and ironing out potential issues. Slack brings team communication and collaboration into one place so you can get more work done, whether you belong to a large enterprise or a small business. Check off your to-do list and move your projects forward by bringing the right people, conversations, tools, and information you need together. Slack is available on any device, so you can find and access your team and your work, whether you’re at your desk or on the go. Scientifically proven (or at least rumored) to make your working life simpler, more pleasant, and more productive. We hope you’ll give Slack a try. Stop by and learn more at: https://slack.com/ snap-id: JUJH91Ved74jd4ZgJCpzMBtYbPOzTlsD channels: stable: 3.3.3 (9) 148MB classic candidate: ↑ beta: ↑ edge: 3.3.1 (8) 148MB classic ``` ``` $ snap --version snap 2.35.5+18.10 snapd 2.35.5+18.10 series 16 ubuntu 18.10 kernel 4.18.0-10-generic ``` I'm happy to provide any testing or log resources-- let me know if there's anything I can help out with! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/1754693 Title: Xwayland crashed with SIGABRT in st_renderbuffer_delete() [often when running Skype or Slack snaps] Status in mesa package in Ubuntu: Confirmed Status in xorg-server package in Ubuntu: Confirmed Bug description: https://errors.ubuntu.com/problem/01a80d2110a46f6b6d857ce814079646e695f4ca --- Steps to reproduce: Install 'slack' snap: sudo snap install slack --classic Run slack: slack Instacrash. ProblemType: Crash DistroRelease: Ubuntu 18.04 Package: xwayland 2:1.19.6-1ubuntu2 ProcVersionSignature: Ubuntu 4.15.0-10.11-generic 4.15.3 Uname: Linux 4.15.0-10-generic x86_64 .tmp.unity_support_test.0: ApportVersion: 2.20.8-0ubuntu10 Architecture: amd64 CompizPlugins: [core,composite,opengl,decor,mousepoll,grid,vpswitch,compiztoolbox,imgpng,gnomecompat,regex,move,place,resize,snap,unitymtgrabhandles,wall,animation,session,expo,workarounds,fade,ezoom,scale,unityshell] CompositorRunning: None CurrentDesktop: GNOME Date: Fri Mar 9 10:31:06 2018 DistUpgraded: 2018-03-06 13:58:47,853 DEBUG Running PostInstallScript: './xorg_fix_proprietary.py' DistroCodename: bionic DistroVariant: ubuntu EcryptfsInUse: Yes ExecutablePath: /usr/bin/Xwayland ExtraDebuggingInterest: Yes, including running git bisection searches GraphicsCard: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller [8086:0412] (rev 06) (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller [1043:8534] MachineType: ASUS All Series ProcCmdline: /usr/bin/Xwayland :0 -rootless -terminate -accessx -core -listen 4 -listen 5 -displayfd 6 ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-10-generic root=UUID=cd444f9d-672e-4d7b-aea8-657fff0ea1f4 ro quiet splash crashkernel=384M-:128M crashkernel=384M-:128M crashkernel=384M-:128M nomdmonddf nomdmonisw crashkernel=384M-:128M nomdmonddf nomdmonisw crashkernel=384M-:128M nomdmonddf nomdmonisw crashkernel=384M-:128M nomdmonddf nomdmonisw crashkernel=384M-:128M nomdmonddf nomdmonisw crashkernel=384M-:128M nomdmonddf nomdmonisw crashkernel=384M-:128M nomdmonddf nomdmonisw crashkernel=384M-:128M crashkernel=384M-:128M crashkernel=384M-:128M crashkernel=384M-:128M crashkernel=384M-:128M crashkernel=384M-:128M crashkernel=384M-:128M crashkernel=384M-:128M crashkernel=384M-:128M crashkernel=384M-:128M crashkernel=384M-:128M crashkernel=384M-:128M crashkernel=384M-:128M crashkernel=384M-:128M vt.handoff=1 Signal: 6 SourcePackage: xorg-server StacktraceTop: ?? () from /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so ?? () from /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so ?? () from /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so ?? () from /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so ?? () from /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so Title: Xwayland crashed with SIGABRT UpgradeStatus: Upgraded to bionic on 2018-03-06 (2 days ago) UserGroups: adm admin audio cdrom chroot-admin dialout dip egbuild fax floppy fuse libvirt libvirtd lpadmin lxd plugdev
[Touch-packages] [Bug 1799265] Re: avahi-daemon high cpu, unusable networking
Ok, ignore previous post. My laptop was sitting unused and suddenly I hear the fans spin up (which they almost never do). Sure enough, the avahi-daemon was running up a full cpu core. I've attached the logs. Thanks for looking into it. ** Attachment added: "avahi.zip" https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/1799265/+attachment/5206777/+files/avahi.zip -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to avahi in Ubuntu. https://bugs.launchpad.net/bugs/1799265 Title: avahi-daemon high cpu, unusable networking Status in avahi package in Ubuntu: Incomplete Bug description: Currently running Kubuntu 18.10, Dell XPS 13 9350 Since updating from Kubuntu 18.04 to 18.10, the avahi-daemon has been consistently hampering network performance and using CPU for long periods of time. When booting machine from off state, avahi-daemon uses an entire CPU at max load for approx 10 minutes. During this time, internet connectivity via wifi is essentially unusable. The wifi connection is good, but it seems that http transactions are cutoff mid-way so no webpage is able to load. When waking from sleep, the avahi-daemon causes similar symptoms, but with less than 1 full cpu usage, and with somewhat less degraded network performance, but still quite unusable. I have never had issues with avahi prior to the 18.10 upgrade, so I am fairly confident the issue is rooted in that change. ProblemType: Bug DistroRelease: Ubuntu 18.10 Package: avahi-daemon 0.7-4ubuntu2 ProcVersionSignature: Ubuntu 4.18.0-10.11-generic 4.18.12 Uname: Linux 4.18.0-10-generic x86_64 ApportVersion: 2.20.10-0ubuntu13 Architecture: amd64 CurrentDesktop: KDE Date: Mon Oct 22 10:00:34 2018 InstallationDate: Installed on 2017-07-24 (455 days ago) InstallationMedia: Ubuntu 17.04 "Zesty Zapus" - Release amd64 (20170412) ProcEnviron: PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 LD_PRELOAD= SHELL=/bin/bash SourcePackage: avahi UpgradeStatus: Upgraded to cosmic on 2018-10-20 (2 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/1799265/+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 1799265] Re: avahi-daemon high cpu, unusable networking
Ok, ignore previous post. My laptop was sitting unused and suddenly I hear the fans spin up (which they almost never do). Sure enough, the avahi-daemon was running up a full cpu core. I've attached the logs. Thanks for looking into it. ** Attachment added: "avahi.zip" https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/1799265/+attachment/5206776/+files/avahi.zip -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to avahi in Ubuntu. https://bugs.launchpad.net/bugs/1799265 Title: avahi-daemon high cpu, unusable networking Status in avahi package in Ubuntu: Incomplete Bug description: Currently running Kubuntu 18.10, Dell XPS 13 9350 Since updating from Kubuntu 18.04 to 18.10, the avahi-daemon has been consistently hampering network performance and using CPU for long periods of time. When booting machine from off state, avahi-daemon uses an entire CPU at max load for approx 10 minutes. During this time, internet connectivity via wifi is essentially unusable. The wifi connection is good, but it seems that http transactions are cutoff mid-way so no webpage is able to load. When waking from sleep, the avahi-daemon causes similar symptoms, but with less than 1 full cpu usage, and with somewhat less degraded network performance, but still quite unusable. I have never had issues with avahi prior to the 18.10 upgrade, so I am fairly confident the issue is rooted in that change. ProblemType: Bug DistroRelease: Ubuntu 18.10 Package: avahi-daemon 0.7-4ubuntu2 ProcVersionSignature: Ubuntu 4.18.0-10.11-generic 4.18.12 Uname: Linux 4.18.0-10-generic x86_64 ApportVersion: 2.20.10-0ubuntu13 Architecture: amd64 CurrentDesktop: KDE Date: Mon Oct 22 10:00:34 2018 InstallationDate: Installed on 2017-07-24 (455 days ago) InstallationMedia: Ubuntu 17.04 "Zesty Zapus" - Release amd64 (20170412) ProcEnviron: PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 LD_PRELOAD= SHELL=/bin/bash SourcePackage: avahi UpgradeStatus: Upgraded to cosmic on 2018-10-20 (2 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/1799265/+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 1799265] Re: avahi-daemon high cpu, unusable networking
Ok, ignore previous post. My laptop was sitting unused and suddenly I hear the fans spin up (which they almost never do). Sure enough, the avahi-daemon was running up a full cpu core. I've attached the logs. Thanks for looking into it. ** Attachment added: "avahi.zip" https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/1799265/+attachment/5206775/+files/avahi.zip -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to avahi in Ubuntu. https://bugs.launchpad.net/bugs/1799265 Title: avahi-daemon high cpu, unusable networking Status in avahi package in Ubuntu: Incomplete Bug description: Currently running Kubuntu 18.10, Dell XPS 13 9350 Since updating from Kubuntu 18.04 to 18.10, the avahi-daemon has been consistently hampering network performance and using CPU for long periods of time. When booting machine from off state, avahi-daemon uses an entire CPU at max load for approx 10 minutes. During this time, internet connectivity via wifi is essentially unusable. The wifi connection is good, but it seems that http transactions are cutoff mid-way so no webpage is able to load. When waking from sleep, the avahi-daemon causes similar symptoms, but with less than 1 full cpu usage, and with somewhat less degraded network performance, but still quite unusable. I have never had issues with avahi prior to the 18.10 upgrade, so I am fairly confident the issue is rooted in that change. ProblemType: Bug DistroRelease: Ubuntu 18.10 Package: avahi-daemon 0.7-4ubuntu2 ProcVersionSignature: Ubuntu 4.18.0-10.11-generic 4.18.12 Uname: Linux 4.18.0-10-generic x86_64 ApportVersion: 2.20.10-0ubuntu13 Architecture: amd64 CurrentDesktop: KDE Date: Mon Oct 22 10:00:34 2018 InstallationDate: Installed on 2017-07-24 (455 days ago) InstallationMedia: Ubuntu 17.04 "Zesty Zapus" - Release amd64 (20170412) ProcEnviron: PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 LD_PRELOAD= SHELL=/bin/bash SourcePackage: avahi UpgradeStatus: Upgraded to cosmic on 2018-10-20 (2 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/1799265/+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 1799265] Re: avahi-daemon high cpu, unusable networking
Ok, the issue seems gone! I cannot recreate it, and I'm not sure why. First, thank you for the quick reply. When I first read your response, I ran the `echo "deb http://ddebs.ubuntu.com $(lsb_release -cs) main restricted universe multiverse" | sudo tee -a /etc/apt/sources.list.d/ddebs.list` command, and then realized the CPU wasn't being maximally taxed so I didn't continue and decided to try again later. I then ran the disable and stop commands to get rid of the issue temporarily. I later decided to try to recreate the issue, so I ran the corresponding enable and start commands, and the CPU didn't increase. I then restarted my system a couple times, but have yet to see the high CPU and bad networking issues. I can confirm that the avahi-daemon is indeed running. Running `ps aux | grep avahi` yields, avahi 915 0.0 0.0 18920 3868 ?Ss 23:46 0:00 avahi-daemon: running [tomboy.local] avahi 1035 0.0 0.0 18716 348 ?S23:46 0:00 avahi-daemon: chroot helper Since my initial post I have performed a couple normal package updates, so perhaps one of them solved the issue? The Kubuntu 18.10 I am on is a new release, so perhaps something was discovered and fixed. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to avahi in Ubuntu. https://bugs.launchpad.net/bugs/1799265 Title: avahi-daemon high cpu, unusable networking Status in avahi package in Ubuntu: Incomplete Bug description: Currently running Kubuntu 18.10, Dell XPS 13 9350 Since updating from Kubuntu 18.04 to 18.10, the avahi-daemon has been consistently hampering network performance and using CPU for long periods of time. When booting machine from off state, avahi-daemon uses an entire CPU at max load for approx 10 minutes. During this time, internet connectivity via wifi is essentially unusable. The wifi connection is good, but it seems that http transactions are cutoff mid-way so no webpage is able to load. When waking from sleep, the avahi-daemon causes similar symptoms, but with less than 1 full cpu usage, and with somewhat less degraded network performance, but still quite unusable. I have never had issues with avahi prior to the 18.10 upgrade, so I am fairly confident the issue is rooted in that change. ProblemType: Bug DistroRelease: Ubuntu 18.10 Package: avahi-daemon 0.7-4ubuntu2 ProcVersionSignature: Ubuntu 4.18.0-10.11-generic 4.18.12 Uname: Linux 4.18.0-10-generic x86_64 ApportVersion: 2.20.10-0ubuntu13 Architecture: amd64 CurrentDesktop: KDE Date: Mon Oct 22 10:00:34 2018 InstallationDate: Installed on 2017-07-24 (455 days ago) InstallationMedia: Ubuntu 17.04 "Zesty Zapus" - Release amd64 (20170412) ProcEnviron: PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 LD_PRELOAD= SHELL=/bin/bash SourcePackage: avahi UpgradeStatus: Upgraded to cosmic on 2018-10-20 (2 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/1799265/+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 1799858] [NEW] package linux-image-4.4.0-138-generic 4.4.0-138.164 failed to install/upgrade
Public bug reported: package linux-image-4.4.0-138-generic 4.4.0-138.164 failed to install/upgrade: run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 127 kernel installations halt while scanning mdadm arrays, eventually timing out and failing ProblemType: Package DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-138-generic 4.4.0-138.164 ProcVersionSignature: Ubuntu 4.4.0-137.163-generic 4.4.144 Uname: Linux 4.4.0-137-generic x86_64 NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia ApportVersion: 2.20.1-0ubuntu2.18 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC1: darknite 3697 F pulseaudio /dev/snd/controlC0: darknite 3697 F pulseaudio Date: Wed Oct 24 18:03:47 2018 ErrorMessage: run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 127 HibernationDevice: RESUME=UUID=93c26513-703e-41c7-b051-ce990cb1c75a InstallationDate: Installed on 2014-07-21 (1556 days ago) InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417) MachineType: To Be Filled By O.E.M. To Be Filled By O.E.M. ProcFB: 0 VESA VGA ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-137-generic root=UUID=58386e6d-2705-4538-831c-48934ded8dbb ro nomdmonddf nomdmonisw PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon. RelatedPackageVersions: grub-pc 2.02~beta2-36ubuntu3.18 RfKill: 0: phy0: Wireless LAN Soft blocked: no Hard blocked: no SourcePackage: initramfs-tools Title: package linux-image-4.4.0-138-generic 4.4.0-138.164 failed to install/upgrade: run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 127 UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 09/18/2014 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: P1.00 dmi.board.asset.tag: D050995F178D dmi.board.name: 980DE3/U3S3 R2.0 dmi.board.vendor: ASRock dmi.chassis.asset.tag: To Be Filled By O.E.M. dmi.chassis.type: 3 dmi.chassis.vendor: To Be Filled By O.E.M. dmi.chassis.version: To Be Filled By O.E.M. dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrP1.00:bd09/18/2014:svnToBeFilledByO.E.M.:pnToBeFilledByO.E.M.:pvrToBeFilledByO.E.M.:rvnASRock:rn980DE3/U3S3R2.0:rvr:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.: dmi.product.name: To Be Filled By O.E.M. dmi.product.version: To Be Filled By O.E.M. dmi.sys.vendor: To Be Filled By O.E.M. ** Affects: initramfs-tools (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-package xenial -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1799858 Title: package linux-image-4.4.0-138-generic 4.4.0-138.164 failed to install/upgrade Status in initramfs-tools package in Ubuntu: New Bug description: package linux-image-4.4.0-138-generic 4.4.0-138.164 failed to install/upgrade: run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 127 kernel installations halt while scanning mdadm arrays, eventually timing out and failing ProblemType: Package DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-138-generic 4.4.0-138.164 ProcVersionSignature: Ubuntu 4.4.0-137.163-generic 4.4.144 Uname: Linux 4.4.0-137-generic x86_64 NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia ApportVersion: 2.20.1-0ubuntu2.18 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC1: darknite 3697 F pulseaudio /dev/snd/controlC0: darknite 3697 F pulseaudio Date: Wed Oct 24 18:03:47 2018 ErrorMessage: run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 127 HibernationDevice: RESUME=UUID=93c26513-703e-41c7-b051-ce990cb1c75a InstallationDate: Installed on 2014-07-21 (1556 days ago) InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417) MachineType: To Be Filled By O.E.M. To Be Filled By O.E.M. ProcFB: 0 VESA VGA ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-137-generic root=UUID=58386e6d-2705-4538-831c-48934ded8dbb ro nomdmonddf nomdmonisw PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon. RelatedPackageVersions: grub-pc 2.02~beta2-36ubuntu3.18 RfKill: 0: phy0: Wireless LAN Soft blocked: no Hard blocked: no SourcePackage: initramfs-tools Title: package linux-image-4.4.0-138-generic 4.4.0-138.164 failed to install/upgrade: run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 127 UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 09/18/2014 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: P1.00 dmi.board.asset.tag: D050995F178D dmi.board.name: 980DE3/U3S3
[Touch-packages] [Bug 1799265] [NEW] avahi-daemon high cpu, unusable networking
Public bug reported: Currently running Kubuntu 18.10, Dell XPS 13 9350 Since updating from Kubuntu 18.04 to 18.10, the avahi-daemon has been consistently hampering network performance and using CPU for long periods of time. When booting machine from off state, avahi-daemon uses an entire CPU at max load for approx 10 minutes. During this time, internet connectivity via wifi is essentially unusable. The wifi connection is good, but it seems that http transactions are cutoff mid-way so no webpage is able to load. When waking from sleep, the avahi-daemon causes similar symptoms, but with less than 1 full cpu usage, and with somewhat less degraded network performance, but still quite unusable. I have never had issues with avahi prior to the 18.10 upgrade, so I am fairly confident the issue is rooted in that change. ProblemType: Bug DistroRelease: Ubuntu 18.10 Package: avahi-daemon 0.7-4ubuntu2 ProcVersionSignature: Ubuntu 4.18.0-10.11-generic 4.18.12 Uname: Linux 4.18.0-10-generic x86_64 ApportVersion: 2.20.10-0ubuntu13 Architecture: amd64 CurrentDesktop: KDE Date: Mon Oct 22 10:00:34 2018 InstallationDate: Installed on 2017-07-24 (455 days ago) InstallationMedia: Ubuntu 17.04 "Zesty Zapus" - Release amd64 (20170412) ProcEnviron: PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 LD_PRELOAD= SHELL=/bin/bash SourcePackage: avahi UpgradeStatus: Upgraded to cosmic on 2018-10-20 (2 days ago) ** Affects: avahi (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug cosmic -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to avahi in Ubuntu. https://bugs.launchpad.net/bugs/1799265 Title: avahi-daemon high cpu, unusable networking Status in avahi package in Ubuntu: New Bug description: Currently running Kubuntu 18.10, Dell XPS 13 9350 Since updating from Kubuntu 18.04 to 18.10, the avahi-daemon has been consistently hampering network performance and using CPU for long periods of time. When booting machine from off state, avahi-daemon uses an entire CPU at max load for approx 10 minutes. During this time, internet connectivity via wifi is essentially unusable. The wifi connection is good, but it seems that http transactions are cutoff mid-way so no webpage is able to load. When waking from sleep, the avahi-daemon causes similar symptoms, but with less than 1 full cpu usage, and with somewhat less degraded network performance, but still quite unusable. I have never had issues with avahi prior to the 18.10 upgrade, so I am fairly confident the issue is rooted in that change. ProblemType: Bug DistroRelease: Ubuntu 18.10 Package: avahi-daemon 0.7-4ubuntu2 ProcVersionSignature: Ubuntu 4.18.0-10.11-generic 4.18.12 Uname: Linux 4.18.0-10-generic x86_64 ApportVersion: 2.20.10-0ubuntu13 Architecture: amd64 CurrentDesktop: KDE Date: Mon Oct 22 10:00:34 2018 InstallationDate: Installed on 2017-07-24 (455 days ago) InstallationMedia: Ubuntu 17.04 "Zesty Zapus" - Release amd64 (20170412) ProcEnviron: PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 LD_PRELOAD= SHELL=/bin/bash SourcePackage: avahi UpgradeStatus: Upgraded to cosmic on 2018-10-20 (2 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/1799265/+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 884336]
I'm seeing a similar issue with a similar setup. I've got a media
center connected to a receiver via HDMI. Sometimes when I'm playing
audio and power-cycle devices in the chain (TV, receiver, etc), pulse
will stop playing audio. I don't get any errors or anything, and
issuing pulseaudio -k will bring it all back.
I tried commenting out the module-suspend-on-idle module. It seemed to
work at first, but I eventually got into a state where PA applications
complained about not being able to play back, and audio went silent.
I think this could be an ALSA issue, but it's quite difficult to debug.
Has anyone else come up with a solution to this problem?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to pulseaudio in Ubuntu.
https://bugs.launchpad.net/bugs/884336
Title:
[Oneiric] HDMI output does not work immediately
Status in PulseAudio:
Unknown
Status in pulseaudio package in Ubuntu:
Invalid
Bug description:
In Oneiric, the output of 5.1 sound (not AC3 passthrough, but multi-
channel PCM) via the HDMI connector of my onboard Intel graphics card
is finally working. This is really great!
For this to work, I have configured Pulseaudio to use the "Digital
Surround 5.1 (HDMI) Output". The HDMI output of my computer is
connected to a 5.1 receiver.
However, there is one nuisance: Whenever I start playing sound on the
computer (e.g., rhythmbox or VLC, both playing via PulseAudio), I hear
no sound. On my receiver I have to re-select the input source for the
computer, which seems to initiate a HDMI handshake (it lasts 3
seconds). Only after this I am able to hear sound.
If I press pause and continue in Rhythmbox, the sound continues fine.
If I stop and restart Rhythmbox, I have to do the above procedure
again. The same is true for VLC and probably for all other players.
While playing around, I have noticed that sound is also working after
killing pulseaudio while playing something in Rhythmbox. When the
connection to Pulseaudio is killed, Rhythmbox tries a fallback to
ALSA. As the Pulseaudio daemon was immediately restarted, this will
result in Rhythmbox being connected via the ALSA plugin (before the
connection was direct). It seems that Pulseaudio is doing the
necessary things here, because after this I do hear sound (as long as
Rhythmbox runs). However, this trick does not work for other players
like VLC which don't fall back to ALSA.
Note that while for me this is just a nuisance, it may be a real
blocker for other users. As long as you don't try to fiddle with the
receiver inputs while playing sound on the computer, you hear
absolutely nothing via HDMI. This includes the sounds from the speaker
test dialog of Pulseaudio. I guess a lot of users would give up and
think that HDMI output is broken in Ubuntu.
ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: pulseaudio 1:1.0-0ubuntu3
ProcVersionSignature: Ubuntu 3.0.0-12.20-generic 3.0.4
Uname: Linux 3.0.0-12-generic x86_64
AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.24.
ApportVersion: 1.23-0ubuntu3
Architecture: amd64
ArecordDevices:
List of CAPTURE Hardware Devices
card 0: PCH [HDA Intel PCH], device 0: ALC892 Analog [ALC892 Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
AudioDevicesInUse:
USERPID ACCESS COMMAND
/dev/snd/controlC0: philipp7706 F pulseaudio
Card0.Amixer.info:
Card hw:0 'PCH'/'HDA Intel PCH at 0xfe52 irq 50'
Mixer name : 'Intel CougarPoint HDMI'
Components : 'HDA:10ec0892,80862002,00100302
HDA:80862805,80862805,0010'
Controls : 31
Simple ctrls : 16
Date: Mon Oct 31 18:07:22 2011
InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Release amd64 (20110426)
ProcEnviron:
LANGUAGE=de:en
PATH=(custom, no user)
LANG=de_DE.UTF-8
LC_MESSAGES=de_DE.UTF-8
SHELL=/bin/bash
SourcePackage: pulseaudio
UpgradeStatus: Upgraded to oneiric on 2011-10-31 (0 days ago)
dmi.bios.date: 11/15/2010
dmi.bios.vendor: Intel Corp.
dmi.bios.version: BLH6710H.86A.0076.2010.1115.1959
dmi.board.asset.tag: To be filled by O.E.M.
dmi.board.name: DH67BL
dmi.board.vendor: Intel Corporation
dmi.board.version: AAG10189-205
dmi.chassis.type: 3
dmi.modalias:
dmi:bvnIntelCorp.:bvrBLH6710H.86A.0076.2010.1115.1959:bd11/15/2010:svn:pn:pvr:rvnIntelCorporation:rnDH67BL:rvrAAG10189-205:cvn:ct3:cvr:
To manage notifications about this bug go to:
https://bugs.launchpad.net/pulseaudio/+bug/884336/+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 1726856] Re: ufw does not start automatically at boot
I just tried: After=network.target After 5 reboot tests I got mixed results: The first two reboots failed to start networking at all and ufw reported its status as "inactive" immediately after boot. The next two reboots networking started successfully, and ufw reported as active. The final reboot, networking again did not start and ufw status was "inactive" -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1726856 Title: ufw does not start automatically at boot Status in ufw: Triaged Status in ufw package in Ubuntu: Triaged Status in ufw source package in Xenial: Triaged Status in ufw source package in Artful: Triaged Status in ufw source package in Bionic: Triaged Status in ufw source package in Cosmic: Triaged Bug description: Whenever I boot into 17.10 ufw is always inactive, even though /etc/ufw/ufw.conf has this: # Set to yes to start on boot. If setting this remotely, be sure to add a rule # to allow your remote connection before starting ufw. Eg: 'ufw allow 22/tcp' ENABLED=yes ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: ufw 0.35-5 ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4 Uname: Linux 4.13.0-16-generic x86_64 ApportVersion: 2.20.7-0ubuntu3 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Tue Oct 24 13:56:40 2017 InstallationDate: Installed on 2015-04-01 (936 days ago) InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 (20140722.2) PackageArchitecture: all SourcePackage: ufw UpgradeStatus: Upgraded to artful on 2017-10-24 (0 days ago) mtime.conffile..etc.default.ufw: 2015-06-17T22:01:02.089170 To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/1726856/+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 1726856] Re: ufw does not start automatically at boot
I just tried that: $ diff -u ufw.service.orig ufw.service --- ufw.service.orig2018-05-26 13:45:48.696356561 +0100 +++ ufw.service 2018-07-17 16:50:45.545596167 +0100 @@ -2,7 +2,8 @@ Description=Uncomplicated firewall Documentation=man:ufw(8) DefaultDependencies=no -Before=network.target +Before=network-pre.target +Wants=network-pre.target [Service] Type=oneshot But after a reboot, nothing changed: $ sudo ufw status Status: inactive -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1726856 Title: ufw does not start automatically at boot Status in ufw: Triaged Status in ufw package in Ubuntu: Triaged Status in ufw source package in Xenial: Triaged Status in ufw source package in Artful: Triaged Status in ufw source package in Bionic: Triaged Status in ufw source package in Cosmic: Triaged Bug description: Whenever I boot into 17.10 ufw is always inactive, even though /etc/ufw/ufw.conf has this: # Set to yes to start on boot. If setting this remotely, be sure to add a rule # to allow your remote connection before starting ufw. Eg: 'ufw allow 22/tcp' ENABLED=yes ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: ufw 0.35-5 ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4 Uname: Linux 4.13.0-16-generic x86_64 ApportVersion: 2.20.7-0ubuntu3 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Tue Oct 24 13:56:40 2017 InstallationDate: Installed on 2015-04-01 (936 days ago) InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 (20140722.2) PackageArchitecture: all SourcePackage: ufw UpgradeStatus: Upgraded to artful on 2017-10-24 (0 days ago) mtime.conffile..etc.default.ufw: 2015-06-17T22:01:02.089170 To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/1726856/+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 1780548] [NEW] SSH server won't start, exit code 255
Public bug reported: I keep trying to set up external SSH access using openssh server on my 18.04 system and it throws back this error sudo service ssh status ● ssh.service - OpenBSD Secure Shell server Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Sat 2018-07-07 09:33:19 CDT; 12min ago Process: 3243 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=255) Jul 07 09:33:19 warehouse systemd[1]: ssh.service: Service hold-off time over, scheduling restart. Jul 07 09:33:19 warehouse systemd[1]: ssh.service: Scheduled restart job, restart counter is at 5. Jul 07 09:33:19 warehouse systemd[1]: Stopped OpenBSD Secure Shell server. Jul 07 09:33:19 warehouse systemd[1]: ssh.service: Start request repeated too quickly. Jul 07 09:33:19 warehouse systemd[1]: ssh.service: Failed with result 'exit-code'. Jul 07 09:33:19 warehouse systemd[1]: Failed to start OpenBSD Secure Shell server. I was in the process of uninstalling the openssh-server and ssh packages and was prompted to start a bug report. If it's in error, just let me know. My ssh config file is all default except for passwordauthentication = yes. I've toggled that to default as well, and still get the same error. ProblemType: Package DistroRelease: Ubuntu 18.04 Package: openssh-server 1:7.6p1-4 ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18 Uname: Linux 4.15.0-23-generic x86_64 NonfreeKernelModules: kpatch_livepatch_Ubuntu_4_15_0_23_25_generic_40 ApportVersion: 2.20.9-0ubuntu7.2 AptOrdering: openssh-server:amd64: Install ssh:amd64: Install NULL: ConfigurePending Architecture: amd64 Date: Sat Jul 7 09:48:11 2018 ErrorMessage: installed openssh-server package post-installation script subprocess returned error exit status 1 InstallationDate: Installed on 2018-07-07 (0 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) Python3Details: /usr/bin/python3.6, Python 3.6.5, python3-minimal, 3.6.5-3 PythonDetails: N/A RelatedPackageVersions: dpkg 1.19.0.5ubuntu2 apt 1.6.2 SSHDConfig: Error: command ['/usr/sbin/sshd', '-T'] failed with exit code 255: /etc/ssh/sshd_config: line 1: Bad configuration option: \342\200\213\342\200\213 /etc/ssh/sshd_config: terminating, 1 bad configuration options SourcePackage: openssh Title: package openssh-server 1:7.6p1-4 failed to install/upgrade: installed openssh-server package post-installation script subprocess returned error exit status 1 UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: openssh (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-package bionic -- 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/1780548 Title: SSH server won't start, exit code 255 Status in openssh package in Ubuntu: New Bug description: I keep trying to set up external SSH access using openssh server on my 18.04 system and it throws back this error sudo service ssh status ● ssh.service - OpenBSD Secure Shell server Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Sat 2018-07-07 09:33:19 CDT; 12min ago Process: 3243 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=255) Jul 07 09:33:19 warehouse systemd[1]: ssh.service: Service hold-off time over, scheduling restart. Jul 07 09:33:19 warehouse systemd[1]: ssh.service: Scheduled restart job, restart counter is at 5. Jul 07 09:33:19 warehouse systemd[1]: Stopped OpenBSD Secure Shell server. Jul 07 09:33:19 warehouse systemd[1]: ssh.service: Start request repeated too quickly. Jul 07 09:33:19 warehouse systemd[1]: ssh.service: Failed with result 'exit-code'. Jul 07 09:33:19 warehouse systemd[1]: Failed to start OpenBSD Secure Shell server. I was in the process of uninstalling the openssh-server and ssh packages and was prompted to start a bug report. If it's in error, just let me know. My ssh config file is all default except for passwordauthentication = yes. I've toggled that to default as well, and still get the same error. ProblemType: Package DistroRelease: Ubuntu 18.04 Package: openssh-server 1:7.6p1-4 ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18 Uname: Linux 4.15.0-23-generic x86_64 NonfreeKernelModules: kpatch_livepatch_Ubuntu_4_15_0_23_25_generic_40 ApportVersion: 2.20.9-0ubuntu7.2 AptOrdering: openssh-server:amd64: Install ssh:amd64: Install NULL: ConfigurePending Architecture: amd64 Date: Sat Jul 7 09:48:11 2018 ErrorMessage: installed openssh-server package post-installation script subprocess returned error exit status 1 InstallationDate: Installed on 2018-07-07 (0 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) Python3Details:
[Touch-packages] [Bug 1726856] Re: ufw does not start automatically at boot
Unfortunately, after a few reboots using these settings it seems this is not the answer. While it does seem to work intermittently, it also sometimes fails. I've also had some issues with network not working at all. I'm not 100% sure that this change is the culprit - but for now I have reverted the change. It still seems to me likely that there is some issue with the systemd dependencies. With the previous settings ufw never seems to be active after boot. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1726856 Title: ufw does not start automatically at boot Status in ufw: Triaged Status in ufw package in Ubuntu: Triaged Status in ufw source package in Xenial: Triaged Status in ufw source package in Artful: Triaged Status in ufw source package in Bionic: Triaged Status in ufw source package in Cosmic: Triaged Bug description: Whenever I boot into 17.10 ufw is always inactive, even though /etc/ufw/ufw.conf has this: # Set to yes to start on boot. If setting this remotely, be sure to add a rule # to allow your remote connection before starting ufw. Eg: 'ufw allow 22/tcp' ENABLED=yes ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: ufw 0.35-5 ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4 Uname: Linux 4.13.0-16-generic x86_64 ApportVersion: 2.20.7-0ubuntu3 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Tue Oct 24 13:56:40 2017 InstallationDate: Installed on 2015-04-01 (936 days ago) InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 (20140722.2) PackageArchitecture: all SourcePackage: ufw UpgradeStatus: Upgraded to artful on 2017-10-24 (0 days ago) mtime.conffile..etc.default.ufw: 2015-06-17T22:01:02.089170 To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/1726856/+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 1726856] Re: ufw does not start automatically at boot
This issue still seems to be a problem in 18.04. If found a solution: https://askubuntu.com/questions/1040539/how-do-i-get-ufw-to-start-on-boot/1040584 I edited /lib/systemd/system/ufw.service as follows: $ diff -u ufw.service.orig ufw.service --- ufw.service.orig2018-05-26 13:45:48.696356561 +0100 +++ ufw.service 2018-05-26 14:17:22.030681670 +0100 @@ -2,7 +2,7 @@ Description=Uncomplicated firewall Documentation=man:ufw(8) DefaultDependencies=no -Before=network.target +After=network-pre.target [Service] Type=oneshot According to this page https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ the network-pre.target has this purpose: "It's primary purpose is for usage with firewall services that want to establish a firewall before any network interface is up" Making the above change solves the problem so that ufw does seem to start up after boot. Is it a bug that ufw.service is not setup this way to start with? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1726856 Title: ufw does not start automatically at boot Status in ufw package in Ubuntu: New Bug description: Whenever I boot into 17.10 ufw is always inactive, even though /etc/ufw/ufw.conf has this: # Set to yes to start on boot. If setting this remotely, be sure to add a rule # to allow your remote connection before starting ufw. Eg: 'ufw allow 22/tcp' ENABLED=yes ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: ufw 0.35-5 ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4 Uname: Linux 4.13.0-16-generic x86_64 ApportVersion: 2.20.7-0ubuntu3 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Tue Oct 24 13:56:40 2017 InstallationDate: Installed on 2015-04-01 (936 days ago) InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 (20140722.2) PackageArchitecture: all SourcePackage: ufw UpgradeStatus: Upgraded to artful on 2017-10-24 (0 days ago) mtime.conffile..etc.default.ufw: 2015-06-17T22:01:02.089170 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1726856/+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 1752705] Re: When run from systemd-nspawn, installation of mysql-server fails because postinst fails to shut down server
Thanks for pointing out the changes to server start/stop, Robie. Adding the `--as-pid2` parameter to `systemd-nspawn` allows it to work. ** Changed in: mysql-5.7 (Ubuntu) Status: New => Invalid ** Changed in: systemd (Ubuntu) Status: New => Invalid -- 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/1752705 Title: When run from systemd-nspawn, installation of mysql-server fails because postinst fails to shut down server Status in mysql-5.7 package in Ubuntu: Invalid Status in systemd package in Ubuntu: Invalid Bug description: Creating a fresh Bionic directory with `debootstrap` and then attempting to install `mysql-server` inside a `systemd-nspawn` container fails with the following message: Setting up mysql-server-5.7 (5.7.21-1ubuntu1) ... invoke-rc.d: could not determine current runlevel * Stopping MySQL database server mysqld [ OK ] update-alternatives: using /etc/mysql/mysql.cnf to provide /etc/mysql/my.cnf (my.cnf) in auto mode Renaming removed key_buffer and myisam-recover options (if present) Error: Unable to shut down server with process id 532 dpkg: error processing package mysql-server-5.7 (--configure): installed mysql-server-5.7 package post-installation script subprocess returned error exit status 1 Steps to reproduce: 1. debootstrap bionic testmysql 2. rm testmysql/etc/resolv.conf 2. systemd-nspawn -D testmyql --bind /etc/resolv.conf /bin/bash -c 'apt update && apt install mysql-server' To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mysql-5.7/+bug/1752705/+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 1752705] Re: When run from systemd-nspawn, installation of mysql-server fails because postinst fails to shut down server
It behaves differently (the installation succeeds) if you install mysql- server from a bash prompt inside the container. Running the installation as a parameter to `systemd-nspawn` will fail. I have tested this on a 16.04.3 system and an 18.04 system. I just noticed something especially weird: if I add `dpkg --configure -a` to the end of the `systemd-nspawn` command, then the `apt install` command will reliably finish. Prepare a base container to be used for the tests: 1. debootstrap bionic bionic 2. rm bionic/etc/resolv.conf This will always fail: sudo rm -rf testmysql && sudo cp -a bionic testmysql && sudo systemd-nspawn -D testmysql bash -c 'apt update && apt install mysql-server' This will always succeed: sudo rm -rf testmysql && sudo cp -a bionic testmysql && sudo systemd-nspawn -D testmysql bash -c 'apt update && apt install mysql-server; dpkg --configure -a' -- 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/1752705 Title: When run from systemd-nspawn, installation of mysql-server fails because postinst fails to shut down server Status in mysql-5.7 package in Ubuntu: New Status in systemd package in Ubuntu: New Bug description: Creating a fresh Bionic directory with `debootstrap` and then attempting to install `mysql-server` inside a `systemd-nspawn` container fails with the following message: Setting up mysql-server-5.7 (5.7.21-1ubuntu1) ... invoke-rc.d: could not determine current runlevel * Stopping MySQL database server mysqld [ OK ] update-alternatives: using /etc/mysql/mysql.cnf to provide /etc/mysql/my.cnf (my.cnf) in auto mode Renaming removed key_buffer and myisam-recover options (if present) Error: Unable to shut down server with process id 532 dpkg: error processing package mysql-server-5.7 (--configure): installed mysql-server-5.7 package post-installation script subprocess returned error exit status 1 Steps to reproduce: 1. debootstrap bionic testmysql 2. rm testmysql/etc/resolv.conf 2. systemd-nspawn -D testmyql --bind /etc/resolv.conf /bin/bash -c 'apt update && apt install mysql-server' To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mysql-5.7/+bug/1752705/+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 1752705] Re: When run from systemd-nspawn, installation of mysql-server fails because postinst fails to shut down server
It also succeeds if I replace `dpkg --configure -a` with `ls`: rm -rf testmysql && cp -a bionic testmysql && systemd-nspawn -D testmysql bash -c 'apt update && apt install mysql-server; ls' -- 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/1752705 Title: When run from systemd-nspawn, installation of mysql-server fails because postinst fails to shut down server Status in mysql-5.7 package in Ubuntu: New Status in systemd package in Ubuntu: New Bug description: Creating a fresh Bionic directory with `debootstrap` and then attempting to install `mysql-server` inside a `systemd-nspawn` container fails with the following message: Setting up mysql-server-5.7 (5.7.21-1ubuntu1) ... invoke-rc.d: could not determine current runlevel * Stopping MySQL database server mysqld [ OK ] update-alternatives: using /etc/mysql/mysql.cnf to provide /etc/mysql/my.cnf (my.cnf) in auto mode Renaming removed key_buffer and myisam-recover options (if present) Error: Unable to shut down server with process id 532 dpkg: error processing package mysql-server-5.7 (--configure): installed mysql-server-5.7 package post-installation script subprocess returned error exit status 1 Steps to reproduce: 1. debootstrap bionic testmysql 2. rm testmysql/etc/resolv.conf 2. systemd-nspawn -D testmyql --bind /etc/resolv.conf /bin/bash -c 'apt update && apt install mysql-server' To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mysql-5.7/+bug/1752705/+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 1743359] [NEW] 16.04 LTS fails to resize2fs mdadm ext4 raid5
Public bug reported: Adding a 4th 10TB disk to an existing 3 disk mdadm raid5 set. Left the stock resize2fs running for nearly 30 hours... 100% CPU no disk writing. Downloaded current e2fsprogs package 1.43.8.2, built and installed. This is working fine. Hope that helps someone, --Matt. ** Affects: e2fsprogs (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1743359 Title: 16.04 LTS fails to resize2fs mdadm ext4 raid5 Status in e2fsprogs package in Ubuntu: New Bug description: Adding a 4th 10TB disk to an existing 3 disk mdadm raid5 set. Left the stock resize2fs running for nearly 30 hours... 100% CPU no disk writing. Downloaded current e2fsprogs package 1.43.8.2, built and installed. This is working fine. Hope that helps someone, --Matt. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1743359/+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 1726856] Re: ufw does not start automatically at boot
Hi Seth, This is what I get: matt@matt-laptop:~$ sudo ufw status Status: inactive matt@matt-laptop:~$ journalctl -u ufw.service -- Logs begin at Tue 2017-10-24 22:48:54 BST, end at Wed 2017-10-25 00:03:54 BST. -- Oct 24 22:48:54 matt-laptop systemd[1]: Started Uncomplicated firewall. matt@matt-laptop:~$ systemctl status ufw ● ufw.service - Uncomplicated firewall Loaded: loaded (/lib/systemd/system/ufw.service; enabled; vendor preset: enabled) Active: active (exited) since Tue 2017-10-24 22:48:54 BST; 1h 15min ago Docs: man:ufw(8) Process: 443 ExecStart=/lib/ufw/ufw-init start quiet (code=exited, status=0/SUCCESS) Main PID: 443 (code=exited, status=0/SUCCESS) Tasks: 0 (limit: 4915) CGroup: /system.slice/ufw.service Oct 24 22:48:54 matt-laptop systemd[1]: Started Uncomplicated firewall. Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1726856 Title: ufw does not start automatically at boot Status in ufw package in Ubuntu: Incomplete Bug description: Whenever I boot into 17.10 ufw is always inactive, even though /etc/ufw/ufw.conf has this: # Set to yes to start on boot. If setting this remotely, be sure to add a rule # to allow your remote connection before starting ufw. Eg: 'ufw allow 22/tcp' ENABLED=yes ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: ufw 0.35-5 ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4 Uname: Linux 4.13.0-16-generic x86_64 ApportVersion: 2.20.7-0ubuntu3 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Tue Oct 24 13:56:40 2017 InstallationDate: Installed on 2015-04-01 (936 days ago) InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 (20140722.2) PackageArchitecture: all SourcePackage: ufw UpgradeStatus: Upgraded to artful on 2017-10-24 (0 days ago) mtime.conffile..etc.default.ufw: 2015-06-17T22:01:02.089170 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1726856/+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 1726856] [NEW] ufw does not start automatically at boot
Public bug reported: Whenever I boot into 17.10 ufw is always inactive, even though /etc/ufw/ufw.conf has this: # Set to yes to start on boot. If setting this remotely, be sure to add a rule # to allow your remote connection before starting ufw. Eg: 'ufw allow 22/tcp' ENABLED=yes ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: ufw 0.35-5 ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4 Uname: Linux 4.13.0-16-generic x86_64 ApportVersion: 2.20.7-0ubuntu3 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Tue Oct 24 13:56:40 2017 InstallationDate: Installed on 2015-04-01 (936 days ago) InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 (20140722.2) PackageArchitecture: all SourcePackage: ufw UpgradeStatus: Upgraded to artful on 2017-10-24 (0 days ago) mtime.conffile..etc.default.ufw: 2015-06-17T22:01:02.089170 ** Affects: ufw (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug artful wayland-session -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1726856 Title: ufw does not start automatically at boot Status in ufw package in Ubuntu: New Bug description: Whenever I boot into 17.10 ufw is always inactive, even though /etc/ufw/ufw.conf has this: # Set to yes to start on boot. If setting this remotely, be sure to add a rule # to allow your remote connection before starting ufw. Eg: 'ufw allow 22/tcp' ENABLED=yes ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: ufw 0.35-5 ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4 Uname: Linux 4.13.0-16-generic x86_64 ApportVersion: 2.20.7-0ubuntu3 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Tue Oct 24 13:56:40 2017 InstallationDate: Installed on 2015-04-01 (936 days ago) InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 (20140722.2) PackageArchitecture: all SourcePackage: ufw UpgradeStatus: Upgraded to artful on 2017-10-24 (0 days ago) mtime.conffile..etc.default.ufw: 2015-06-17T22:01:02.089170 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1726856/+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 1508146] Re: alt + left/right arrows switch between tty consoles, cannot disable
Just had this bug happen to me when installing my machine's first-ever Snappy package (keepassxc if it matters). Ubuntu Gnome 16.04. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lightdm in Ubuntu. https://bugs.launchpad.net/bugs/1508146 Title: alt + left/right arrows switch between tty consoles, cannot disable Status in gnome-shell package in Ubuntu: Confirmed Status in lightdm package in Ubuntu: Confirmed Bug description: I'm used to using alt+left/right arrow to navigate back and forward in web browsers and elsewhere (nautilus)... But on this fresh install of Ubuntu Gnome 15.10 beta, it seems to try and switch me between tty consoles (the ctrl+alt+f1 ones). But it's not listed as one of the shortcuts in the "keyboard" menu, so I don't know how to disable it... To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1508146/+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 1569925] Re: Shutdown hang on 16.04 with iscsi targets
Excellent, thank you for the details. -- 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/1569925 Title: Shutdown hang on 16.04 with iscsi targets Status in systemd package in Ubuntu: Confirmed Status in systemd source package in Xenial: In Progress Bug description: I have 4 servers running the latest 16.04 updates from the development branch (as of right now). Each server is connected to NetApp storage using iscsi software initiator. There are a total of 56 volumes spread across two NetApp arrays. Each volume has 4 paths available to it which are being managed by device mapper. While logged into the iscsi sessions all I have to do is reboot the server and I get a hang. I see a message that says: "Reached target Shutdown" followed by "systemd-shutdown[1]: Failed to finalize DM devices, ignoring" and then I see 8 lines that say: "connection1:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection2:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection3:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection4:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection5:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection6:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection7:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection8:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" NOTE: the actual values of the *'s differ for each line above. This seems like a bug somewhere but I am unaware of any additional logging that I could turn on to pinpoint the problem. Note I also have similar setups that are not doing iscsi and they don't have this problem. Here is a screenshot of what I see on the shell when I try to reboot: (https://launchpadlibrarian.net/291303059/Screenshot.jpg) This is being tracked in NetApp bug tracker CQ number 860251. If I log out of all iscsi sessions before rebooting then I do not experience the hang: iscsiadm -m node -U all We are wondering if this could be some kind of shutdown ordering problem. Like the network devices have already disappeared and then iscsi tries to perform some operation (hence the ping timeouts). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1569925/+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 1569925] Re: Shutdown hang on 16.04 with iscsi targets
As I said I don't have one up right now, but Comment 3 above has my interfaces for one of the recreates. Nothing bothered me in any way. I wanted to make sure that you knew that I wasn't one guy who was looking to fix his one system, that's all. You said "Usually those type of "partnership" product enablements/fixes"...what do you mean by that? Is there some avenue that I could be pursuing to get my bugs addressed sooner? -- 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/1569925 Title: Shutdown hang on 16.04 with iscsi targets Status in systemd package in Ubuntu: Confirmed Status in systemd source package in Xenial: In Progress Bug description: I have 4 servers running the latest 16.04 updates from the development branch (as of right now). Each server is connected to NetApp storage using iscsi software initiator. There are a total of 56 volumes spread across two NetApp arrays. Each volume has 4 paths available to it which are being managed by device mapper. While logged into the iscsi sessions all I have to do is reboot the server and I get a hang. I see a message that says: "Reached target Shutdown" followed by "systemd-shutdown[1]: Failed to finalize DM devices, ignoring" and then I see 8 lines that say: "connection1:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection2:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection3:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection4:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection5:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection6:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection7:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection8:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" NOTE: the actual values of the *'s differ for each line above. This seems like a bug somewhere but I am unaware of any additional logging that I could turn on to pinpoint the problem. Note I also have similar setups that are not doing iscsi and they don't have this problem. Here is a screenshot of what I see on the shell when I try to reboot: (https://launchpadlibrarian.net/291303059/Screenshot.jpg) This is being tracked in NetApp bug tracker CQ number 860251. If I log out of all iscsi sessions before rebooting then I do not experience the hang: iscsiadm -m node -U all We are wondering if this could be some kind of shutdown ordering problem. Like the network devices have already disappeared and then iscsi tries to perform some operation (hence the ping timeouts). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1569925/+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 1569925] Re: Shutdown hang on 16.04 with iscsi targets
Please let me explain who I am and what we do to possibly shed some light on this. I am an Interoperability engineer at NetApp. We test our storage products with many popular operating systems, adapters, protocols and switches, in varying combinations. We test software initiator iscsi continuously (on other distros) with exactly the same configuration as I have described above and have never seen this behavior. Indeed whatever the problem is seems fixed in Ubuntu upstream as I indicated above. This is also new behavior introduced between 14.04 and 16.04 because it did not occur in older versions. The purpose of me asking to get this issue resolved is not to fix MY system, it is to fix it for my customers' systems. We will not post support for Ubuntu 16.04 (iscsi) without resolving this issue so that we don't put our customers in the same position. With all that said, I do not currently have a configuration available or setup to reproduce this problem. If it is required, I can add it to the queue. When it is up and running, it reproduces every single time. Other folks on the thread may actually have it up and running right now and be able to test the immediate fail before I get to it. -- 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/1569925 Title: Shutdown hang on 16.04 with iscsi targets Status in systemd package in Ubuntu: Confirmed Status in systemd source package in Xenial: In Progress Bug description: I have 4 servers running the latest 16.04 updates from the development branch (as of right now). Each server is connected to NetApp storage using iscsi software initiator. There are a total of 56 volumes spread across two NetApp arrays. Each volume has 4 paths available to it which are being managed by device mapper. While logged into the iscsi sessions all I have to do is reboot the server and I get a hang. I see a message that says: "Reached target Shutdown" followed by "systemd-shutdown[1]: Failed to finalize DM devices, ignoring" and then I see 8 lines that say: "connection1:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection2:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection3:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection4:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection5:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection6:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection7:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection8:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" NOTE: the actual values of the *'s differ for each line above. This seems like a bug somewhere but I am unaware of any additional logging that I could turn on to pinpoint the problem. Note I also have similar setups that are not doing iscsi and they don't have this problem. Here is a screenshot of what I see on the shell when I try to reboot: (https://launchpadlibrarian.net/291303059/Screenshot.jpg) This is being tracked in NetApp bug tracker CQ number 860251. If I log out of all iscsi sessions before rebooting then I do not experience the hang: iscsiadm -m node -U all We are wondering if this could be some kind of shutdown ordering problem. Like the network devices have already disappeared and then iscsi tries to perform some operation (hence the ping timeouts). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1569925/+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 1569925] Re: Shutdown hang on 16.04 with iscsi targets
I have node.session.timeo.replacement_timeout = 20, which seems completely reasonable in my book. We have already established that this occurs without multipath even enabled, thus it is not a multipath settings problem. Also I have no containers. -- 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/1569925 Title: Shutdown hang on 16.04 with iscsi targets Status in systemd package in Ubuntu: Confirmed Status in systemd source package in Xenial: In Progress Bug description: I have 4 servers running the latest 16.04 updates from the development branch (as of right now). Each server is connected to NetApp storage using iscsi software initiator. There are a total of 56 volumes spread across two NetApp arrays. Each volume has 4 paths available to it which are being managed by device mapper. While logged into the iscsi sessions all I have to do is reboot the server and I get a hang. I see a message that says: "Reached target Shutdown" followed by "systemd-shutdown[1]: Failed to finalize DM devices, ignoring" and then I see 8 lines that say: "connection1:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection2:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection3:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection4:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection5:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection6:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection7:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection8:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" NOTE: the actual values of the *'s differ for each line above. This seems like a bug somewhere but I am unaware of any additional logging that I could turn on to pinpoint the problem. Note I also have similar setups that are not doing iscsi and they don't have this problem. Here is a screenshot of what I see on the shell when I try to reboot: (https://launchpadlibrarian.net/291303059/Screenshot.jpg) This is being tracked in NetApp bug tracker CQ number 860251. If I log out of all iscsi sessions before rebooting then I do not experience the hang: iscsiadm -m node -U all We are wondering if this could be some kind of shutdown ordering problem. Like the network devices have already disappeared and then iscsi tries to perform some operation (hence the ping timeouts). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1569925/+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 1664352] Re: dhclient-script doesn't use configured metric for rfc3442 classless routes
** Bug watch added: Debian Bug tracker #867625 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=867625 ** Also affects: isc-dhcp (Debian) via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=867625 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu. https://bugs.launchpad.net/bugs/1664352 Title: dhclient-script doesn't use configured metric for rfc3442 classless routes Status in isc-dhcp package in Ubuntu: Confirmed Status in isc-dhcp package in Debian: Unknown Bug description: lsb_release -rd Description: Ubuntu 16.04.2 LTS Release: 16.04 apt-cache policy isc-dhcp-client isc-dhcp-client: Installed: 4.3.3-5ubuntu12.6 Candidate: 4.3.3-5ubuntu12.6 Version table: *** 4.3.3-5ubuntu12.6 500 500 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages 100 /var/lib/dpkg/status 4.3.3-5ubuntu12 500 500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages If the metric option is set in interfaces(5), dhclient is executed with the variable IF_METRIC set to the configured administrative metric. The exit-hook rfc3442-classless-routes doesn't use the variable; thus, a multi-interface box will experience a race condition if multiple interfaces are supplied with one or more duplicate rfc3442 routes. The attached patch adds support for IF_METRIC handling. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1664352/+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 1615342] Re: variable of $new_rfc3442_classless_static_routes has spelling error in /sbin/dhclient-script
FYI this bug is fixed in newer versions, see: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748272 So perhaps this bug can be closed? --Matt ** Bug watch added: Debian Bug tracker #748272 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748272 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu. https://bugs.launchpad.net/bugs/1615342 Title: variable of $new_rfc3442_classless_static_routes has spelling error in /sbin/dhclient-script Status in isc-dhcp package in Ubuntu: New Bug description: version lastest ubuntu 14.04.5 isc-dhcp-client version 4.2.4-7ubuntu12 bug code location /sbin/dhclient-script line 275 and line 354 logic of ignore the router option defined in rfc3442 is not performing correctly > If the DHCP server returns both a Classless Static Routes option and > a Router option, the DHCP client MUST ignore the Router option. > > Similarly, if the DHCP server returns both a Classless Static Routes > option and a Static Routes option, the DHCP client MUST ignore the > Static Routes option. reason is spelling error of the variable "$new_rfc3442_classless_static_routes" error to "$new_rfc3442_classless_static_routers" . just correct the name to fix this bug. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1615342/+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 1664352] Re: dhclient-script doesn't use configured metric for rfc3442 classless routes
Is there something I can do to help make some progress fixing this bug? This issue is not applicable to the upstream software source however I did notice that it is relevant to Debian's isc-dhcp-client package which I believe is in a sense "upstream" for the Ubuntu package. In light of that should I pursue fixing the Debian package first? (https://wiki.ubuntu.com/Debian/Bugs) --Matt -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu. https://bugs.launchpad.net/bugs/1664352 Title: dhclient-script doesn't use configured metric for rfc3442 classless routes Status in isc-dhcp package in Ubuntu: Confirmed Bug description: lsb_release -rd Description: Ubuntu 16.04.2 LTS Release: 16.04 apt-cache policy isc-dhcp-client isc-dhcp-client: Installed: 4.3.3-5ubuntu12.6 Candidate: 4.3.3-5ubuntu12.6 Version table: *** 4.3.3-5ubuntu12.6 500 500 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages 100 /var/lib/dpkg/status 4.3.3-5ubuntu12 500 500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages If the metric option is set in interfaces(5), dhclient is executed with the variable IF_METRIC set to the configured administrative metric. The exit-hook rfc3442-classless-routes doesn't use the variable; thus, a multi-interface box will experience a race condition if multiple interfaces are supplied with one or more duplicate rfc3442 routes. The attached patch adds support for IF_METRIC handling. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1664352/+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 1702793] [NEW] Merge changes from upstream
Public bug reported: Changes to support day-of-week patching and logging to syslog were added to upstream (https://github.com/mvo5/unattended-upgrades) over a year ago. These changes are not present in the latest Xenial nor Trusty packages (0.90 and 0.82.1) - requesting that these changes be pulled from upstream. ** Affects: unattended-upgrades (Ubuntu) Importance: Undecided Status: New ** Description changed: Changes to support day-of-week patching and logging to syslog were added to upstream (https://github.com/mvo5/unattended-upgrades) over a year - ago. These changes are not present in the latest Xenial package (0.90) - - requesting that they be added. + ago. These changes are not present in the latest Xenial nor Trusty + packages (0.90 and 0.82.1) - requesting that these changes be merged + into both packages. ** Description changed: Changes to support day-of-week patching and logging to syslog were added to upstream (https://github.com/mvo5/unattended-upgrades) over a year ago. These changes are not present in the latest Xenial nor Trusty - packages (0.90 and 0.82.1) - requesting that these changes be merged - into both packages. + packages (0.90 and 0.82.1) - requesting that these changes be pulled + from upstream. -- 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/1702793 Title: Merge changes from upstream Status in unattended-upgrades package in Ubuntu: New Bug description: Changes to support day-of-week patching and logging to syslog were added to upstream (https://github.com/mvo5/unattended-upgrades) over a year ago. These changes are not present in the latest Xenial nor Trusty packages (0.90 and 0.82.1) - requesting that these changes be pulled from upstream. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1702793/+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 1569925] Re: Shutdown hang on 16.04 with iscsi targets
I can confirm that the daily 17.10 build does not exhibit the problem. Interestingly, the first time we tried we forgot to stop running IO to our iSCSI volumes and it _looked_ like we reproduced the problem, then the IOs timed out and our application stopped and we were able to complete the reboot. The next time we retried and correctly stopped our application before shutting down and had no issue. Whatever it is, is fixed in 17.10. -- 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/1569925 Title: Shutdown hang on 16.04 with iscsi targets Status in systemd package in Ubuntu: Confirmed Status in systemd source package in Xenial: Confirmed Bug description: I have 4 servers running the latest 16.04 updates from the development branch (as of right now). Each server is connected to NetApp storage using iscsi software initiator. There are a total of 56 volumes spread across two NetApp arrays. Each volume has 4 paths available to it which are being managed by device mapper. While logged into the iscsi sessions all I have to do is reboot the server and I get a hang. I see a message that says: "Reached target Shutdown" followed by "systemd-shutdown[1]: Failed to finalize DM devices, ignoring" and then I see 8 lines that say: "connection1:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection2:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection3:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection4:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection5:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection6:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection7:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection8:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" NOTE: the actual values of the *'s differ for each line above. This seems like a bug somewhere but I am unaware of any additional logging that I could turn on to pinpoint the problem. Note I also have similar setups that are not doing iscsi and they don't have this problem. Here is a screenshot of what I see on the shell when I try to reboot: (https://launchpadlibrarian.net/291303059/Screenshot.jpg) This is being tracked in NetApp bug tracker CQ number 860251. If I log out of all iscsi sessions before rebooting then I do not experience the hang: iscsiadm -m node -U all We are wondering if this could be some kind of shutdown ordering problem. Like the network devices have already disappeared and then iscsi tries to perform some operation (hence the ping timeouts). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1569925/+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 1569925] Re: Shutdown hang on 16.04 with iscsi targets
My test configuration has long since been re-tasked. I will eventually be able to come back and test as you ask, but it may take a few weeks. If anyone else on the bug has their systems up and available, please test and reply. -- 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/1569925 Title: Shutdown hang on 16.04 with iscsi targets Status in systemd package in Ubuntu: Confirmed Bug description: I have 4 servers running the latest 16.04 updates from the development branch (as of right now). Each server is connected to NetApp storage using iscsi software initiator. There are a total of 56 volumes spread across two NetApp arrays. Each volume has 4 paths available to it which are being managed by device mapper. While logged into the iscsi sessions all I have to do is reboot the server and I get a hang. I see a message that says: "Reached target Shutdown" followed by "systemd-shutdown[1]: Failed to finalize DM devices, ignoring" and then I see 8 lines that say: "connection1:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection2:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection3:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection4:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection5:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection6:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection7:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection8:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" NOTE: the actual values of the *'s differ for each line above. This seems like a bug somewhere but I am unaware of any additional logging that I could turn on to pinpoint the problem. Note I also have similar setups that are not doing iscsi and they don't have this problem. Here is a screenshot of what I see on the shell when I try to reboot: (https://launchpadlibrarian.net/291303059/Screenshot.jpg) This is being tracked in NetApp bug tracker CQ number 860251. If I log out of all iscsi sessions before rebooting then I do not experience the hang: iscsiadm -m node -U all We are wondering if this could be some kind of shutdown ordering problem. Like the network devices have already disappeared and then iscsi tries to perform some operation (hence the ping timeouts). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1569925/+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 385714] Re: GRUB2 Theme for Ubuntu
This bug is about using the GRUB2 gfxmenu theme api* to provide a fancy bitmap theme. GRUB being purple is just setting the background colour. *originally developed as this summer of code project: http://grub.gibibit.com/ Latest docs: https://www.gnu.org/software/grub/manual/grub.html#Theme- file-format -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-themes in Ubuntu. https://bugs.launchpad.net/bugs/385714 Title: GRUB2 Theme for Ubuntu Status in grub2 package in Ubuntu: Incomplete Status in ubuntu-themes package in Ubuntu: Incomplete Bug description: Binary package hint: grub2 The binary grub-pc installs /etc/grub.d/05_debian_theme which is where grub2 finds its theme. It looks for /usr/share/images/desktop-base/moreblue-orbit-grub.png to use as the theme background, which is part of desktop-base. Of course, we don't install that by default as it contains all the Debian theming. So grub shouldn't be looking for that theme, but we also need to provide a theme ourselves. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/385714/+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 1691491] [NEW] lookbehind broken
Public bug reported: Trying to troubleshoot unexpected behavior with haproxy, I discovered that lookbehind appears to be broken in version 1:8.31-2ubuntu2.3 of the libpcre3 package. I have an haproxy rule to rewrite URL paths that do not begin with "build" or "static": reqirep ^([^\ :]*)\ /(?!build|static).*\ (.*) \1\ /index.html\ \2 With the latest version of libpcre3 installed (1:8.31-2ubuntu2.3), this line matches all requests. If I downgrade to 1:8.31-2ubuntu2.2 and restart haproxy, the rule correctly matches only paths that do not start with "static" or "build". $ lsb_release -rd Description:Ubuntu 14.04.4 LTS Release:14.04 $ apt-cache policy libpcre3 libpcre3: Installed: 1:8.31-2ubuntu2.3 Candidate: 1:8.31-2ubuntu2.3 Version table: *** 1:8.31-2ubuntu2.3 0 500 http://us-east-1.ec2.archive.ubuntu.com/ubuntu/ trusty-updates/main amd64 Packages 100 /var/lib/dpkg/status 1:8.31-2ubuntu2.2 0 500 http://security.ubuntu.com/ubuntu/ trusty-security/main amd64 Packages 1:8.31-2ubuntu2 0 500 http://us-east-1.ec2.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages ** Affects: pcre3 (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pcre3 in Ubuntu. https://bugs.launchpad.net/bugs/1691491 Title: lookbehind broken Status in pcre3 package in Ubuntu: New Bug description: Trying to troubleshoot unexpected behavior with haproxy, I discovered that lookbehind appears to be broken in version 1:8.31-2ubuntu2.3 of the libpcre3 package. I have an haproxy rule to rewrite URL paths that do not begin with "build" or "static": reqirep ^([^\ :]*)\ /(?!build|static).*\ (.*) \1\ /index.html\ \2 With the latest version of libpcre3 installed (1:8.31-2ubuntu2.3), this line matches all requests. If I downgrade to 1:8.31-2ubuntu2.2 and restart haproxy, the rule correctly matches only paths that do not start with "static" or "build". $ lsb_release -rd Description: Ubuntu 14.04.4 LTS Release: 14.04 $ apt-cache policy libpcre3 libpcre3: Installed: 1:8.31-2ubuntu2.3 Candidate: 1:8.31-2ubuntu2.3 Version table: *** 1:8.31-2ubuntu2.3 0 500 http://us-east-1.ec2.archive.ubuntu.com/ubuntu/ trusty-updates/main amd64 Packages 100 /var/lib/dpkg/status 1:8.31-2ubuntu2.2 0 500 http://security.ubuntu.com/ubuntu/ trusty-security/main amd64 Packages 1:8.31-2ubuntu2 0 500 http://us-east-1.ec2.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pcre3/+bug/1691491/+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 1687019] Re: Cannot add a Google account using Online Accounts in Ubuntu Gnome
I am also have the issue of blank screen. I tried a fresh install of Fedora out of curiosity and worked perfect. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnome-online-accounts in Ubuntu. https://bugs.launchpad.net/bugs/1687019 Title: Cannot add a Google account using Online Accounts in Ubuntu Gnome Status in gnome-online-accounts package in Ubuntu: Confirmed Status in gnome-online-accounts package in Arch Linux: New Bug description: With Ubuntu Gnome 17.04 (brand new 64bit install on a Dell XPS13 laptop), I cannot add a Google account using Online-Accounts. If I choose to add a new Google account in Online Accounts, a window appears where I can enter my Google email. After entering my email and pressing the Next button, a window appears where I can enter my Google password. After entering the password and pressing the Next button, an empty window appears and nothing else happens. I expected this to show something useful, and actually add the Google account to my Gnome environment. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-online-accounts/+bug/1687019/+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 1664352] Re: dhclient-script doesn't use configured metric for rfc3442 classless routes
In my environment we have some dual-homed Ubuntu hosts that have one network interface with a WAN IP and one on a private network. For proper network connectivity we need to use the configurable metric value to prioritize the default route provided by the WAN connected interface over the default route (a NAT gateway) provided by the private network DHCP server. Unfortunately the current dhclient script ignores the configured metric when adding DHCP provided rfc3442 classless routes to the routing table. This patch from Tom fixes dhclient behavior for my use case. --Matt -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu. https://bugs.launchpad.net/bugs/1664352 Title: dhclient-script doesn't use configured metric for rfc3442 classless routes Status in isc-dhcp package in Ubuntu: Confirmed Bug description: lsb_release -rd Description: Ubuntu 16.04.2 LTS Release: 16.04 apt-cache policy isc-dhcp-client isc-dhcp-client: Installed: 4.3.3-5ubuntu12.6 Candidate: 4.3.3-5ubuntu12.6 Version table: *** 4.3.3-5ubuntu12.6 500 500 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages 100 /var/lib/dpkg/status 4.3.3-5ubuntu12 500 500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages If the metric option is set in interfaces(5), dhclient is executed with the variable IF_METRIC set to the configured administrative metric. The exit-hook rfc3442-classless-routes doesn't use the variable; thus, a multi-interface box will experience a race condition if multiple interfaces are supplied with one or more duplicate rfc3442 routes. The attached patch adds support for IF_METRIC handling. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1664352/+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 1636862] Re: Shutdown hangs with active iscsi sessions
Installed the most recent build of Zesty (zesty-server-amd64.iso 2017-02-22 06:54676M). I was able to: 1. Confirm the issue still exists. 2. Confirm that the issue is not caused by multipath (i.e. it still occurs during reboot when multipathing is disabled). -- 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/1636862 Title: Shutdown hangs with active iscsi sessions Status in systemd package in Ubuntu: Confirmed Bug description: This is a duplicate of the bug listed here: https://bugs.launchpad.net/bugs/1569925 for 16.04. That bug was automatically closed though the problem still persists. I am opening this bug for 16.10 in hopes that it will catch somebody's attention. I have 4 servers running the latest 16.10 updates. Each server is connected to NetApp storage using iscsi software initiator. There are a total of 56 volumes spread across two NetApp arrays. Each volume has 4 paths available to it which are being managed by device mapper. While logged into the iscsi sessions all I have to do is reboot the server and I get a hang. I see a message that says: "Reached target Shutdown" followed by "systemd-shutdown[1]: Failed to finalize DM devices, ignoring" and then I see 8 lines that say: "connection1:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection2:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection3:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection4:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection5:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection6:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection7:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection8:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" NOTE: the actual values of the *'s differ for each line above. Screenshot of the issue: https://www.dropbox.com/s/93mv7cj8asspcpa/ShutdownCapture.JPG?dl=0 ~# lsb_release -rd Description:Ubuntu 16.10 Release:16.10 ~# apt-cache policy open-iscsi open-iscsi: Installed: 2.0.873+git0.3b4b4500-14ubuntu8 Candidate: 2.0.873+git0.3b4b4500-14ubuntu8 Version table: *** 2.0.873+git0.3b4b4500-14ubuntu8 500 500 http://repomirror-ict.eng.netapp.com/ubuntu yakkety/main amd64 Packages 100 /var/lib/dpkg/status ~# cat /etc/network/interfaces # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). source /etc/network/interfaces.d/* # The loopback network interface auto lo iface lo inet loopback # The primary network interface auto eno1 iface eno1 inet dhcp # This is an autoconfigured IPv6 interface iface eno1 inet6 auto # This is an autoconfigured interface auto enp4s0 iface enp4s0 inet static address 192.12.21.2 netmask 255.255.255.0 mtu 9000 # This is an autoconfigured interface auto enp130s0f3 iface enp130s0f3 inet static address 192.12.22.2 netmask 255.255.255.0 mtu 9000 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1636862/+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 1569925] Re: Shutdown hang on 16.04 with iscsi targets
Didn't take as long as I thought. Installed the most recent build of Zesty (zesty-server-amd64.iso 2017-02-22 06:54676M). I was able to: 1. Confirm the issue still exists. 2. Confirm that the issue is not caused by multipath (i.e. it still occurs during reboot when multipathing is disabled). -- 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/1569925 Title: Shutdown hang on 16.04 with iscsi targets Status in systemd package in Ubuntu: Confirmed Bug description: I have 4 servers running the latest 16.04 updates from the development branch (as of right now). Each server is connected to NetApp storage using iscsi software initiator. There are a total of 56 volumes spread across two NetApp arrays. Each volume has 4 paths available to it which are being managed by device mapper. While logged into the iscsi sessions all I have to do is reboot the server and I get a hang. I see a message that says: "Reached target Shutdown" followed by "systemd-shutdown[1]: Failed to finalize DM devices, ignoring" and then I see 8 lines that say: "connection1:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection2:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection3:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection4:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection5:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection6:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection7:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection8:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" NOTE: the actual values of the *'s differ for each line above. This seems like a bug somewhere but I am unaware of any additional logging that I could turn on to pinpoint the problem. Note I also have similar setups that are not doing iscsi and they don't have this problem. Here is a screenshot of what I see on the shell when I try to reboot: (https://launchpadlibrarian.net/291303059/Screenshot.jpg) This is being tracked in NetApp bug tracker CQ number 860251. If I log out of all iscsi sessions before rebooting then I do not experience the hang: iscsiadm -m node -U all We are wondering if this could be some kind of shutdown ordering problem. Like the network devices have already disappeared and then iscsi tries to perform some operation (hence the ping timeouts). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1569925/+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 1569925] Re: Shutdown hang on 16.04 with iscsi targets
It is possible to test without multipath, this will take some time as I no longer have anything with 16.04 installed. For fun I may go ahead and try with 17.04 so we can figure out if it still exists then we'll kind of kill two birds with one stone. -- 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/1569925 Title: Shutdown hang on 16.04 with iscsi targets Status in systemd package in Ubuntu: Confirmed Bug description: I have 4 servers running the latest 16.04 updates from the development branch (as of right now). Each server is connected to NetApp storage using iscsi software initiator. There are a total of 56 volumes spread across two NetApp arrays. Each volume has 4 paths available to it which are being managed by device mapper. While logged into the iscsi sessions all I have to do is reboot the server and I get a hang. I see a message that says: "Reached target Shutdown" followed by "systemd-shutdown[1]: Failed to finalize DM devices, ignoring" and then I see 8 lines that say: "connection1:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection2:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection3:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection4:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection5:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection6:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection7:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection8:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" NOTE: the actual values of the *'s differ for each line above. This seems like a bug somewhere but I am unaware of any additional logging that I could turn on to pinpoint the problem. Note I also have similar setups that are not doing iscsi and they don't have this problem. Here is a screenshot of what I see on the shell when I try to reboot: (https://launchpadlibrarian.net/291303059/Screenshot.jpg) This is being tracked in NetApp bug tracker CQ number 860251. If I log out of all iscsi sessions before rebooting then I do not experience the hang: iscsiadm -m node -U all We are wondering if this could be some kind of shutdown ordering problem. Like the network devices have already disappeared and then iscsi tries to perform some operation (hence the ping timeouts). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1569925/+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 1569925] Re: Shutdown hang on 16.04 with iscsi targets
iSCSI disks are not the root/boot disks. Multipath IS in use. Hence the /dev/mapper at the beginning of the disk names. Yes I have tried 16.10, it is still present and I have another bug for that release. https://bugs.launchpad.net/bugs/1636862 -- 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/1569925 Title: Shutdown hang on 16.04 with iscsi targets Status in systemd package in Ubuntu: Confirmed Bug description: I have 4 servers running the latest 16.04 updates from the development branch (as of right now). Each server is connected to NetApp storage using iscsi software initiator. There are a total of 56 volumes spread across two NetApp arrays. Each volume has 4 paths available to it which are being managed by device mapper. While logged into the iscsi sessions all I have to do is reboot the server and I get a hang. I see a message that says: "Reached target Shutdown" followed by "systemd-shutdown[1]: Failed to finalize DM devices, ignoring" and then I see 8 lines that say: "connection1:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection2:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection3:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection4:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection5:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection6:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection7:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection8:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" NOTE: the actual values of the *'s differ for each line above. This seems like a bug somewhere but I am unaware of any additional logging that I could turn on to pinpoint the problem. Note I also have similar setups that are not doing iscsi and they don't have this problem. Here is a screenshot of what I see on the shell when I try to reboot: (https://launchpadlibrarian.net/291303059/Screenshot.jpg) This is being tracked in NetApp bug tracker CQ number 860251. If I log out of all iscsi sessions before rebooting then I do not experience the hang: iscsiadm -m node -U all We are wondering if this could be some kind of shutdown ordering problem. Like the network devices have already disappeared and then iscsi tries to perform some operation (hence the ping timeouts). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1569925/+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 1569925] Re: Shutdown hang on 16.04 with iscsi targets
Any idea on this one folks? -- 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/1569925 Title: Shutdown hang on 16.04 with iscsi targets Status in systemd package in Ubuntu: Confirmed Bug description: I have 4 servers running the latest 16.04 updates from the development branch (as of right now). Each server is connected to NetApp storage using iscsi software initiator. There are a total of 56 volumes spread across two NetApp arrays. Each volume has 4 paths available to it which are being managed by device mapper. While logged into the iscsi sessions all I have to do is reboot the server and I get a hang. I see a message that says: "Reached target Shutdown" followed by "systemd-shutdown[1]: Failed to finalize DM devices, ignoring" and then I see 8 lines that say: "connection1:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection2:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection3:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection4:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection5:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection6:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection7:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection8:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" NOTE: the actual values of the *'s differ for each line above. This seems like a bug somewhere but I am unaware of any additional logging that I could turn on to pinpoint the problem. Note I also have similar setups that are not doing iscsi and they don't have this problem. Here is a screenshot of what I see on the shell when I try to reboot: (https://launchpadlibrarian.net/291303059/Screenshot.jpg) This is being tracked in NetApp bug tracker CQ number 860251. If I log out of all iscsi sessions before rebooting then I do not experience the hang: iscsiadm -m node -U all We are wondering if this could be some kind of shutdown ordering problem. Like the network devices have already disappeared and then iscsi tries to perform some operation (hence the ping timeouts). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1569925/+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 1636862] Re: Shutdown hangs with active iscsi sessions
Any movement here? -- 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/1636862 Title: Shutdown hangs with active iscsi sessions Status in systemd package in Ubuntu: Confirmed Bug description: This is a duplicate of the bug listed here: https://bugs.launchpad.net/bugs/1569925 for 16.04. That bug was automatically closed though the problem still persists. I am opening this bug for 16.10 in hopes that it will catch somebody's attention. I have 4 servers running the latest 16.10 updates. Each server is connected to NetApp storage using iscsi software initiator. There are a total of 56 volumes spread across two NetApp arrays. Each volume has 4 paths available to it which are being managed by device mapper. While logged into the iscsi sessions all I have to do is reboot the server and I get a hang. I see a message that says: "Reached target Shutdown" followed by "systemd-shutdown[1]: Failed to finalize DM devices, ignoring" and then I see 8 lines that say: "connection1:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection2:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection3:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection4:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection5:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection6:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection7:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" "connection8:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4311815***, last ping 43118164**, now 4311817***" NOTE: the actual values of the *'s differ for each line above. Screenshot of the issue: https://www.dropbox.com/s/93mv7cj8asspcpa/ShutdownCapture.JPG?dl=0 ~# lsb_release -rd Description:Ubuntu 16.10 Release:16.10 ~# apt-cache policy open-iscsi open-iscsi: Installed: 2.0.873+git0.3b4b4500-14ubuntu8 Candidate: 2.0.873+git0.3b4b4500-14ubuntu8 Version table: *** 2.0.873+git0.3b4b4500-14ubuntu8 500 500 http://repomirror-ict.eng.netapp.com/ubuntu yakkety/main amd64 Packages 100 /var/lib/dpkg/status ~# cat /etc/network/interfaces # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). source /etc/network/interfaces.d/* # The loopback network interface auto lo iface lo inet loopback # The primary network interface auto eno1 iface eno1 inet dhcp # This is an autoconfigured IPv6 interface iface eno1 inet6 auto # This is an autoconfigured interface auto enp4s0 iface enp4s0 inet static address 192.12.21.2 netmask 255.255.255.0 mtu 9000 # This is an autoconfigured interface auto enp130s0f3 iface enp130s0f3 inet static address 192.12.22.2 netmask 255.255.255.0 mtu 9000 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1636862/+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 1253638] Re: dynamic linker does not use DT_RUNPATH for transitive dependencies
This bug (if it's a bug) also affects sys-libs/glibc-2.23-r3 on Gentoo. The Qt Blog has a post about this issue from 2011: http://blog.qt.io/blog/2011/10/28/rpath-and-runpath/ This may not be a bug: it is possible that DT_RUNPATH was never intended to be transitive. However, if this is so, then DT_RPATH should not have been deprecated, as DT_RUNPATH does not fully replicate its behavior (at a lower precedence than LD_LIBRARY_PATH). My use case: I have a cross-compiling toolchain setup to allow me to compile binaries for the Amazon Linux distribution, which has older everything than my host system. To test the compiled binaries on my host system, I set LD_RUN_PATH and -Wl,-dynamic-linker when linking so that the Amazon-versioned libraries are used instead of my host system's libraries. The particular problem I'm experiencing is that libstdc++.so.6 needs libm.so.6, but the latter is not loaded from the proper location when my binary uses DT_RUNPATH instead of DT_RPATH. Compare: * When I link my binary with -Wl,--enable-new-dtags (the default on Gentoo): $ ldd out/x86_64-amazon-linux-gnu/engine linux-vdso.so.1 (0x7ffeb6bdf000) libtcmalloc_minimal.so.4 => /usr/x86_64-amazon-linux-gnu/usr/lib64/libtcmalloc_minimal.so.4 (0x7f2592d85000) libstdc++.so.6 => /usr/lib/gcc/x86_64-amazon-linux-gnu/4.8.3/libstdc++.so.6 (0x7f2592a53000) libgcc_s.so.1 => /usr/lib/gcc/x86_64-amazon-linux-gnu/4.8.3/libgcc_s.so.1 (0x7f259283c000) libpthread.so.0 => /usr/x86_64-amazon-linux-gnu/lib64/libpthread.so.0 (0x7f259261f000) libc.so.6 => /usr/x86_64-amazon-linux-gnu/lib64/libc.so.6 (0x7f2592274000) libm.so.6 => /lib64/libm.so.6 (0x7f2591f76000) /usr/x86_64-amazon-linux-gnu/lib64/ld-linux-x86-64.so.2 (0x7f2592fcc000) Notice that libm.so.6 resolves to the system library in /lib64. * When I link my binary with -Wl,--disable-new-dtags: $ ldd out/x86_64-amazon-linux-gnu/engine linux-vdso.so.1 (0x7ffec67c2000) libtcmalloc_minimal.so.4 => /usr/x86_64-amazon-linux-gnu/usr/lib64/libtcmalloc_minimal.so.4 (0x7fb5208b) libstdc++.so.6 => /usr/lib/gcc/x86_64-amazon-linux-gnu/4.8.3/libstdc++.so.6 (0x7fb52057e000) libgcc_s.so.1 => /usr/lib/gcc/x86_64-amazon-linux-gnu/4.8.3/libgcc_s.so.1 (0x7fb520367000) libpthread.so.0 => /usr/x86_64-amazon-linux-gnu/lib64/libpthread.so.0 (0x7fb52014a000) libc.so.6 => /usr/x86_64-amazon-linux-gnu/lib64/libc.so.6 (0x7fb51fd9f000) libm.so.6 => /usr/x86_64-amazon-linux-gnu/lib64/libm.so.6 (0x7fb51faa1000) /usr/x86_64-amazon-linux-gnu/lib64/ld-linux-x86-64.so.2 (0x7fb520af7000) Notice that libm.so.6 resolves to the correct library. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to eglibc in Ubuntu. https://bugs.launchpad.net/bugs/1253638 Title: dynamic linker does not use DT_RUNPATH for transitive dependencies Status in eglibc package in Ubuntu: Confirmed Bug description: $ lsb_release -rd Description: Ubuntu 13.10 Release: 13.10 $ uname -a Linux mhassert 3.11.0-13-generic #20-Ubuntu SMP Wed Oct 23 07:38:26 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux $gcc -dumpversion 4.8 $ ld -v GNU ld (GNU Binutils for Ubuntu) 2.23.52.20130913 $ LC_ALL=C apt-cache policy libc-bin libc-bin: Installed: 2.17-93ubuntu4 * What you expected to happen Binaries with DT_RPATH or DT_RUNPATH behaving identical in the absence of LD_LIBRARY_PATH * What happened instead DT_RUNPATH not searched for transitive dependencies. When running a binary that depends on custom libraries which in turn depend on custom libraries, hard-coded search paths in DT_RUNPATH behave differently from those in DT_RPATH. Paths in DT_RPATH are being considered for everything that is dynamically loaded, even dependencies of dependencies. Paths in DT_RUNPATH seem being considered only for direct dependencies of the binary. Searching the web I think that the one and only difference between DT_RPATH and DT_RUNPATH should be that DT_RPATH is considered _before_ LD_LIBRARY_PATH and DT_RUNPATH _afterwards_. In the absence of LD_LIBRARY_PATH there should be no difference at all. I stumbled upon this problem when switching from "ld" to "gold" for the linker. The default for ld on Ubuntu 13.10 is "--disable-new- dtags" while the default for gold is "--enable-new-dtags". Therefore ld produces binaries with DT_RPATH and gold ones with DT_RUNPATH. In the attached minimal example - the binaries rpath and runpath both depend on libb but not directly on liba. - libb depends on liba. - liba and libb are linked without any hard-coded library paths. - rpath and runpath are linked with hard-coded library paths for both liba and libb - rpath is linked with --disable-new-dtags (producing DT_RPATH) -
[Touch-packages] [Bug 1587142] Re: Shutdown hangs in md kworker after "Reached target Shutdown."
I have a similar problem with a super micro X10DRH system board. If I have the intel sata controller set to ACHI and install a fresh instance of 16.04 the server works without issue. If I have the intel sata controller in RSTe RAID mode with a 2 drive RAID1 configuration the server will hang on reboot at the 'Reached target shutdown" message. Are there any logs that I can provide to assist in troubleshooting? Thanks, -Matt -- 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/1587142 Title: Shutdown hangs in md kworker after "Reached target Shutdown." Status in systemd package in Ubuntu: Confirmed Bug description: I'm booting a fully patched 16.04 from an Intel Rapid Storage Technology enterprise RAID1 volume (ThinkServer TS140 with two SATA ST1000NM0033-9ZM drives, ext4 root partition, no LVM, UEFI mode). If the RAID volume is recovering or resyncing for whatever reason, then `sudo systemctl reboot` and `sudo systemctl poweroff` work fine (I had to `sudo systemctl --now disable lvm2-lvmetad lvm2-lvmpolld lvm2-monitor` in order to consistently get that). However, once the recovery/resync is complete and clean, the reboot and poweroff commands above hang forever after "Reached target Shutdown.". Note that issuing `sudo swapoff -a` beforehand (suggested in the bug #1464917) does not help. [EDIT]Actually, the shutdown also hangs from time to time during a resync. But I've never seen it succeed once the resync is complete.[/EDIT] Then, if the server has been forcibly restarted with the power button, the Intel Matrix Storage Manager indicates a "Normal" status for the RAID1 volume, but Ubuntu then resyncs the volume anyway: [1.223649] md: bind [1.228426] md: bind [1.230030] md: bind [1.230738] md: bind [1.232985] usbcore: registered new interface driver usbhid [1.233494] usbhid: USB HID core driver [1.234022] md: raid1 personality registered for level 1 [1.234876] md/raid1:md126: not clean -- starting background reconstruction [1.234956] input: CHESEN USB Keyboard as /devices/pci:00/:00:14.0/usb3/3-10/3-10:1.0/0003:0A81:0101.0001/input/input5 [1.236273] md/raid1:md126: active with 2 out of 2 mirrors [1.236797] md126: detected capacity change from 0 to 1000202043392 [1.246271] md: md126 switched to read-write mode. [1.246834] md: resync of RAID array md126 [1.247325] md: minimum _guaranteed_ speed: 1000 KB/sec/disk. [1.247503] md126: p1 p2 p3 p4 [1.248269] md: using maximum available idle IO bandwidth (but not more than 20 KB/sec) for resync. [1.248774] md: using 128k window, over a total of 976759940k. Note that the pain of "resync upon every (re)boot" cannot even be a bit relieved thanks to bitmaps because mdadm does not support them for IMSM containers: $ sudo mdadm --grow --bitmap=internal /dev/md126 mdadm: Cannot add bitmaps to sub-arrays yet I also get this in syslog during boot when the individual drives are detected, but this seems to be harmless: May 30 17:26:07 wssrv1 systemd-udevd[608]: Process '/sbin/mdadm --incremental /dev/sdb --offroot' failed with exit code 1. May 30 17:26:07 wssrv1 systemd-udevd[608]: Process '/lib/udev/hdparm' failed with exit code 1. May 30 17:26:07 wssrv1 systemd-udevd[606]: Process '/sbin/mdadm --incremental /dev/sda --offroot' failed with exit code 1. May 30 17:26:07 wssrv1 systemd-udevd[606]: Process '/lib/udev/hdparm' failed with exit code 1. During a resync, `sudo sh -c 'echo idle > /sys/block/md126/md/sync_action'` actually stops it as expected, but it restarts immediately though nothing seems to have triggered it: May 30 18:17:02 wssrv1 kernel: [ 3106.826710] md: md126: resync interrupted. May 30 18:17:02 wssrv1 kernel: [ 3106.836320] md: checkpointing resync of md126. May 30 18:17:02 wssrv1 kernel: [ 3106.836623] md: resync of RAID array md126 May 30 18:17:02 wssrv1 kernel: [ 3106.836625] md: minimum _guaranteed_ speed: 1000 KB/sec/disk. May 30 18:17:02 wssrv1 kernel: [ 3106.836626] md: using maximum available idle IO bandwidth (but not more than 20 KB/sec) for resync. May 30 18:17:02 wssrv1 kernel: [ 3106.836627] md: using 128k window, over a total of 976759940k. May 30 18:17:02 wssrv1 kernel: [ 3106.836628] md: resuming resync of md126 from checkpoint. May 30 18:17:02 wssrv1 mdadm[982]: RebuildStarted event detected on md device /dev/md/Volume0 I attach screenshots of the hanging shutdown log after a `sudo sh -c 'echo 8 > /proc/sys/kernel/printk'`. The second screenshot shows that the kernel has deadlocked in md_write_start(). Note that `sudo systemctl start debug-shell` is unusable on this machine at this point because Ctrl+Alt+F9 brings tty9 without any keyboard. [ED
[Touch-packages] [Bug 1649729] Re: ntpd startup failures under xenial
Removing ntpdate should remove the if-up script, so I imagine that would "resolve" the bug by way of workaround. The hosts in question were upgraded from prior LTS, so they would have inherited ntpdate from there. I wasn't aware of the changes to sunset it in the current release. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ntp in Ubuntu. https://bugs.launchpad.net/bugs/1649729 Title: ntpd startup failures under xenial Status in ntp package in Ubuntu: Incomplete Bug description: I have a system running 16.04.1 with multiple interfaces configured via /etc/network/interfaces. Following a restart, ntpd will often be found not running, despite being installed and configured. syslog suggests ntpd is being repeatedly stopped and restarted within seconds. Dec 13 20:23:17 mail ntpd[4031]: ntpd 4.2.8p4@1.3265-o Wed Oct 5 12:34:45 UTC 2016 (1): Starting Dec 13 20:23:17 mail ntpd[4031]: ntpd 4.2.8p4@1.3265-o Wed Oct 5 12:34:45 UTC 2016 (1): Starting Dec 13 20:23:17 mail ntpd[4031]: Command line: /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 106:113 Dec 13 20:23:17 mail ntpd[4031]: Command line: /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 106:113 Dec 13 20:23:17 mail ntpd[4034]: proto: precision = 0.105 usec (-23) Dec 13 20:23:17 mail ntpd[4034]: unable to bind to wildcard address :: - another process may be running - EXITING Dec 13 20:23:17 mail ntpd[4034]: proto: precision = 0.105 usec (-23) Dec 13 20:23:17 mail ntpd[4034]: unable to bind to wildcard address :: - another process may be running - EXITING Dec 13 20:23:18 mail ntp[4119]: * Stopping NTP server ntpd Dec 13 20:23:18 mail ntp[4119]: * Stopping NTP server ntpd Dec 13 20:23:18 mail ntp[4183]: * Starting NTP server ntpd Dec 13 20:23:18 mail ntp[4183]: * Starting NTP server ntpd Dec 13 20:23:18 mail ntpd[4193]: ntpd 4.2.8p4@1.3265-o Wed Oct 5 12:34:45 UTC 2016 (1): Starting Dec 13 20:23:18 mail ntpd[4193]: ntpd 4.2.8p4@1.3265-o Wed Oct 5 12:34:45 UTC 2016 (1): Starting Dec 13 20:23:18 mail ntpd[4193]: Command line: /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 106:113 Dec 13 20:23:18 mail ntpd[4193]: Command line: /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 106:113 Dec 13 20:23:18 mail ntpd[4195]: proto: precision = 0.065 usec (-24) Dec 13 20:23:18 mail ntpd[4195]: proto: precision = 0.065 usec (-24) Dec 13 20:23:18 mail ntpd[4195]: unable to bind to wildcard address :: - another process may be running - EXITING Dec 13 20:23:18 mail ntpd[4195]: unable to bind to wildcard address :: - another process may be running - EXITING My current assumption is that this is the work of /etc/network/if- up.d/ntpdate being run on several interfaces nearly simultaneously. The rapid stop/start cycle of the daemon appears to trip up the port binding, and eventually cause ntpd to become unhappy and wind up stopped. Manually restarting ntpd (or even running /etc/network/if- up.d/ntpdate) outside of interface up/down time properly brings up ntpd. It doesn't appear to be a configuration issue as such. Further, running /etc/network/if-up.d/ntpdate from bash several times in rapid succession also produces the 'missing ntpd' behavior, outside of the context of any interface activity. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1649729/+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 1650707] [NEW] mplayer segfaults in ff_draw_horiz_band
Public bug reported: After the 6:9.20-0ubuntu0.14.04.1 security update, playing an XVID stream in an AVI container segfaults decoding video frames. Reverting to 6:9.11-2ubuntu2 works -- I can't find a .deb for the previous 9.18 release, but this system was playing videos without issue until recently. In GDB: [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". MPlayer 1.1-4.8 (C) 2000-2012 MPlayer Team mplayer: could not connect to socket mplayer: No such file or directory Failed to open LIRC support. You will not be able to use your remote control. libavformat version 54.20.4 (external) Mismatching header version 54.20.3 AVI file format detected. [aviheader] Video stream found, -vid 0 [aviheader] Audio stream found, -aid 1 VIDEO: [XVID] 624x352 12bpp 23.976 fps 989.1 kbps (120.7 kbyte/s) Clip info: Software: VirtualDubMod 1.5.10.2 (build 2540/release) Load subtitles in ./ Failed to open VDPAU backend libvdpau_i965.so: cannot open shared object file: No such file or directory [vdpau] Error when calling vdp_device_create_x11: 1 == Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family libavcodec version 54.35.1 (external) Mismatching header version 54.35.0 Unsupported AVPixelFormat 53 Selected video codec: [ffodivx] vfm: ffmpeg (FFmpeg MPEG-4) == == Requested audio codec family [mpg123] (afm=mpg123) not available. Enable it at compilation. Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders AUDIO: 48000 Hz, 2 ch, floatle, 134.6 kbit/4.38% (ratio: 16819->384000) Selected audio codec: [ffmp3float] afm: ffmpeg (FFmpeg MPEG layer-3 audio) == [New Thread 0x7fffe363c700 (LWP 20856)] AO: [pulse] 48000Hz 2ch floatle (4 bytes per sample) Starting playback... Movie-Aspect is 1.77:1 - prescaling to correct movie aspect. VO: [xv] 624x352 => 624x352 Planar YV12 Program received signal SIGSEGV, Segmentation fault. 0x0056edf7 in fast_memcpy () (gdb) bt #0 0x0056edf7 in fast_memcpy () #1 0x00498119 in ?? () #2 0x00571c7c in ?? () #3 0x73ca0a83 in ff_draw_horiz_band (avctx=0xbc68c0, dsp=dsp@entry=0xbc8428, cur=cur@entry=0xbc7e50, last=last@entry=0xbc70d0, y=0, h=, picture_structure=3, first_field=0, draw_edges=1, low_delay=0, v_edge_pos=352, h_edge_pos=624) at /build/libav-dVKvK5/libav-9.20/libavcodec/mpegvideo.c:2529 #4 0x73ca0d22 in ff_mpeg_draw_horiz_band (s=s@entry=0xbc6ce0, y=, h=h@entry=16) at /build/libav-dVKvK5/libav-9.20/libavcodec/mpegvideo.c:2537 #5 0x73b89f86 in decode_slice (s=s@entry=0xbc6ce0) at /build/libav-dVKvK5/libav-9.20/libavcodec/h263dec.c:259 #6 0x73b8ab78 in ff_h263_decode_frame (avctx=0xbc68c0, data=0xbc66e0, got_frame=0x7fffd024, avpkt=) at /build/libav-dVKvK5/libav-9.20/libavcodec/h263dec.c:651 #7 0x73d47433 in avcodec_decode_video2 (avctx=0xbc68c0, picture=0xbc66e0, got_picture_ptr=0x7fffd024, avpkt=0x7fffd030) at /build/libav-dVKvK5/libav-9.20/libavcodec/utils.c:1288 #8 0x00572342 in ?? () #9 0x004c35a1 in decode_video () #10 0x0043f4a4 in ?? () #11 0x004337d6 in main () ** Affects: libav (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libav in Ubuntu. https://bugs.launchpad.net/bugs/1650707 Title: mplayer segfaults in ff_draw_horiz_band Status in libav package in Ubuntu: New Bug description: After the 6:9.20-0ubuntu0.14.04.1 security update, playing an XVID stream in an AVI container segfaults decoding video frames. Reverting to 6:9.11-2ubuntu2 works -- I can't find a .deb for the previous 9.18 release, but this system was playing videos without issue until recently. In GDB: [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". MPlayer 1.1-4.8 (C) 2000-2012 MPlayer Team mplayer: could not connect to socket mplayer: No such file or directory Failed to open LIRC support. You will not be able to use your remote control. libavformat version 54.20.4 (external) Mismatching header version 54.20.3 AVI file format detected. [aviheader] Video stream found, -vid 0 [aviheader] Audio stream found, -aid 1 VIDEO: [XVID] 624x352 12bpp 23.976 fps 989.1 kbps (120.7 kbyte/s) Clip info: Software: VirtualDubMod 1.5.10.2 (build 2540/release) Load subtitles in ./ Failed to open VDPAU backend libvdpau_i965.so: cannot open shared object file: No such file or directory [vdpau] Error when calling vdp_device_create_x11: 1
