[Touch-packages] [Bug 2058976] Re: Configuration files for networkd are created when NetworkManager is the default renderer
To be clear, that carrier is set to "failed" when retriggering uevents
is not the main problem. The main problem is that after 5-10 minutes,
networkd silently takes control again of the ethernet interface. The
retriggering of uevents and the reaction on the networkd side is just an
indication that it still cares about the interface.
Maybe a better way to check if the issue is around without having to
wait for minutes would be to look at /run/systemd/netif/links/* and
check if the content still references the removed .network files.
--
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/2058976
Title:
Configuration files for networkd are created when NetworkManager is
the default renderer
Status in Netplan:
New
Status in systemd package in Ubuntu:
New
Bug description:
This is happening in a UC image created with a gadget that disables
console-conf:
$ ubuntu-image snap --snap=network-manager=22 --snap pc_22.snap
The snaps are:
$ snap list
Name Version RevTracking Publisher Notes
core22 202403211344 latest/edge canonical✓ base
network-manager 1.36.6-987622/stablecanonical✓ -
pc 22-0.3 x1 --
gadget
pc-kernel5.15.0-102.112.1+1 1731 22/beta canonical✓
kernel
snapd2.62+git2017.g1afc063e 21490 latest/edge canonical✓ snapd
On first boot, the content in /etc/netplan is:
ubuntu@ubuntu:~$ cat /etc/netplan/00-default-nm-renderer.yaml
network:
renderer: NetworkManager
ubuntu@ubuntu:~$ cat /etc/netplan/50-cloud-init.yaml
# This file is generated from information provided by the datasource. Changes
# to it will not persist across an instance reboot. To disable cloud-init's
# network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
ethernets:
ens3:
dhcp4: true
match:
macaddress: '52:54:00:12:34:56'
set-name: ens3
version: 2
But we have a configuration file for systemd-networkd that should not be
there:
ubuntu@ubuntu:~$ cat /run/systemd/network/10-netplan-ens3.link
[Match]
PermanentMACAddress=52:54:00:12:34:56
[Link]
Name=ens3
WakeOnLan=off
ubuntu@ubuntu:~$ networkctl
IDX LINK TYPE OPERATIONAL SETUP
1 lo loopback carrier unmanaged
2 ens3 etherroutableconfigured
While having to:
ubuntu@ubuntu:~$ sudo cat
/run/NetworkManager/system-connections/netplan-ens3.nmconnection
[connection]
id=netplan-ens3
type=ethernet
interface-name=ens3
[ethernet]
wake-on-lan=0
[ipv4]
method=auto
[ipv6]
method=ignore
ubuntu@ubuntu:~$ nmcli c
NAME UUID TYPE DEVICE
netplan-ens3 bec3d02a-c9e5-3283-92ab-ee43a4246c85 ethernet ens3
ubuntu@ubuntu:~$ nmcli d
DEVICE TYPE STATE CONNECTION
ens3ethernet connected netplan-ens3
lo loopback unmanaged --
To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/2058976/+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 2060676] Re: login: remove pam_lastlog.so from config
/etc/pam.d/login references the module: sessionoptional pam_lastlog.so -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to shadow in Ubuntu. https://bugs.launchpad.net/bugs/2060676 Title: login: remove pam_lastlog.so from config Status in shadow package in Ubuntu: New Status in shadow package in Debian: New Bug description: Imported from Debian bug http://bugs.debian.org/1068229: Package: libpam-modules Version: 1.5.3-6 Severity: normal I noticed the following line in my logs: login[2449]: PAM unable to dlopen(pam_lastlog.so): /usr/lib/security/pam_lastlog.so: cannot open shared object file: No such file or directory I looked in the deb files from snapshot.debian.org, and noticed the last version that had it was 1.5.2-9.1 - starting from 1.5.3-1 it disappeared. Maybe it's fallout from the time_t transition and you're already aware of it, in which case feel free to close. Thanks, -- M -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 6.7.9-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages libpam-modules depends on: ii debconf [debconf-2.0] 1.5.86 ii libaudit1 1:3.1.2-2.1 ii libc6 2.37-15.1 ii libcrypt1 1:4.4.36-4 ii libpam-modules-bin 1.5.3-6 ii libpam0g 1.5.3-6 ii libselinux13.5-2 ii libsystemd0255.4-1+b1 libpam-modules recommends no packages. libpam-modules suggests no packages. -- debconf information excluded To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/2060676/+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 2060676] [NEW] login: remove pam_lastlog.so from config
Public bug reported: Imported from Debian bug http://bugs.debian.org/1068229: Package: libpam-modules Version: 1.5.3-6 Severity: normal I noticed the following line in my logs: login[2449]: PAM unable to dlopen(pam_lastlog.so): /usr/lib/security/pam_lastlog.so: cannot open shared object file: No such file or directory I looked in the deb files from snapshot.debian.org, and noticed the last version that had it was 1.5.2-9.1 - starting from 1.5.3-1 it disappeared. Maybe it's fallout from the time_t transition and you're already aware of it, in which case feel free to close. Thanks, -- M -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 6.7.9-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages libpam-modules depends on: ii debconf [debconf-2.0] 1.5.86 ii libaudit1 1:3.1.2-2.1 ii libc6 2.37-15.1 ii libcrypt1 1:4.4.36-4 ii libpam-modules-bin 1.5.3-6 ii libpam0g 1.5.3-6 ii libselinux13.5-2 ii libsystemd0255.4-1+b1 libpam-modules recommends no packages. libpam-modules suggests no packages. -- debconf information excluded ** Affects: shadow (Ubuntu) Importance: Undecided Status: New ** Affects: shadow (Debian) Importance: Undecided Status: New ** Bug watch added: Debian Bug tracker #1068229 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068229 ** Changed in: shadow (Debian) Remote watch: None => Debian Bug tracker #1068229 ** Changed in: shadow (Ubuntu) Milestone: None => noble-updates -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to shadow in Ubuntu. https://bugs.launchpad.net/bugs/2060676 Title: login: remove pam_lastlog.so from config Status in shadow package in Ubuntu: New Status in shadow package in Debian: New Bug description: Imported from Debian bug http://bugs.debian.org/1068229: Package: libpam-modules Version: 1.5.3-6 Severity: normal I noticed the following line in my logs: login[2449]: PAM unable to dlopen(pam_lastlog.so): /usr/lib/security/pam_lastlog.so: cannot open shared object file: No such file or directory I looked in the deb files from snapshot.debian.org, and noticed the last version that had it was 1.5.2-9.1 - starting from 1.5.3-1 it disappeared. Maybe it's fallout from the time_t transition and you're already aware of it, in which case feel free to close. Thanks, -- M -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 6.7.9-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages libpam-modules depends on: ii debconf [debconf-2.0] 1.5.86 ii libaudit1 1:3.1.2-2.1 ii libc6 2.37-15.1 ii libcrypt1 1:4.4.36-4 ii libpam-modules-bin 1.5.3-6 ii libpam0g 1.5.3-6 ii libselinux13.5-2 ii libsystemd0255.4-1+b1 libpam-modules recommends no packages. libpam-modules suggests no packages. -- debconf information excluded To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/2060676/+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 2039411] Re: Addition of ppa repository failing intermittently
I am seeing this on focal, when running command:
$ add-apt-repository ppa:snappy-dev/image -y
on 20.04. 22.04 seems to be fine.
The errors I see are of the same two types as those in the bug
description:
<<
Cannot add PPA: 'ppa:~snappy-dev/ubuntu/image'.
The team named '~snappy-dev' has no PPA named 'ubuntu/image'
Please choose from the following available PPAs:
* '15.04': DEPRECATED - WILL REMOVE SOON (Tools for Snappy 15.04)
* 'beta': Snappy beta
* 'edge': Snappy Edge
* 'image': Packages used in constructing the Ubuntu Core component of Snappy
...
>>
or the backtrace:
<<
Traceback (most recent call last):
File "/usr/bin/add-apt-repository", line 137, in
shortcut = shortcut_handler(line)
File
"/usr/lib/python3/dist-packages/softwareproperties/SoftwareProperties.py", line
885, in shortcut_handler
ret = factory(shortcut)
File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 469, in
shortcut_handler
return PPAShortcutHandler(shortcut)
File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 426, in
__init__
info = get_ppa_info(self.shortcut)
File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 392, in
get_ppa_info
_get_suggested_ppa_message(user, ppa))
File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 349, in
_get_suggested_ppa_message
lp_user = get_info_from_lp(LAUNCHPAD_USER_API % user)
File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 104, in
get_info_from_lp
return get_info_from_https(lp_url, True)
File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 98, in
get_info_from_https
return json.loads(data)
File "/usr/lib/python3.8/json/__init__.py", line 357, in loads
return _default_decoder.decode(s)
File "/usr/lib/python3.8/json/decoder.py", line 337, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
File "/usr/lib/python3.8/json/decoder.py", line 355, in raw_decode
raise JSONDecodeError("Expecting value", s, err.value) from None
json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
>>
--
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/2039411
Title:
Addition of ppa repository failing intermittently
Status in software-properties package in Ubuntu:
Confirmed
Bug description:
I get following error intermittently when trying to add ppa repository:
$ sudo add-apt-repository ppa:~longsleep/ubuntu/golang-backports
Cannot add PPA: 'ppa:~longsleep/ubuntu/golang-backports'.
The user named '~longsleep' has no PPA named 'ubuntu/golang-backports'
Please choose from the following available PPAs:
* 'bcmwl': bcmwl
* 'couchdb': Apache CouchDB
* 'couchdb-precise-backport': Apache CouchDB with Erlang 18 for precise
* 'createrepo-backports': Createrepo Backports
* 'firehol-backports': Firehol Backports
* 'golang-backports': Golang Backports
* 'golang-backports-dev': Golang Backports Dev
* 'iridium-browser-dev': Iridium Browser Dev dependencies
* 'pixel-extras': Pixel extras
* 'python2.7-backports': Python 2.7 Backports
* 'python3-m2crypto-backports': Python 3 M2Crypto backports
* 'stuff': Stuff
* 'ubuntu-pine64-flavour-makers': Ubuntu Pine64 Makers PPA
After multiple attempts, it may succeed, but the same above command sometimes
may return following error as well (intermittently):
$ sudo add-apt-repository ppa:~longsleep/ubuntu/golang-backports
Traceback (most recent call last):
File "/usr/bin/add-apt-repository", line 137, in
shortcut = shortcut_handler(line)
File
"/usr/lib/python3/dist-packages/softwareproperties/SoftwareProperties.py", line
885, in shortcut_handler
ret = factory(shortcut)
File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 469,
in shortcut_handler
return PPAShortcutHandler(shortcut)
File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 426,
in __init__
info = get_ppa_info(self.shortcut)
File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 392,
in get_ppa_info
_get_suggested_ppa_message(user, ppa))
File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 349,
in _get_suggested_ppa_message
lp_user = get_info_from_lp(LAUNCHPAD_USER_API % user)
File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 104,
in get_info_from_lp
return get_info_from_https(lp_url, True)
File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 98,
in get_info_from_https
return json.loads(data)
File "/usr/lib/python3.8/json/__init__.py", line 357, in loads
return _default_decoder.decode(s)
File "/usr/lib/python3.8/json/decoder.py", line 337, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
File
[Touch-packages] [Bug 2025339] Re: FDE image fails to run e2fsck
Related debian bug: https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=1031622 ** Bug watch added: Debian Bug tracker #1031622 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031622 -- 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/2025339 Title: FDE image fails to run e2fsck Status in e2fsprogs package in Ubuntu: Confirmed Status in e2fsprogs source package in Jammy: Confirmed Bug description: After installation of the FDE image, the system fails to boot due to e2fsck failing with: Jun 21 12:48:19 ubuntu systemd-fsck[268]: /dev/vda2 has unsupported feature(s): FEATURE_C12 this means that Jammy fsck fails against mantic created ext4 which is not great Seems this is orphan_file feature / orphan_present Also need to check if grub2 supports this as it is RO_INCOMPAT feature. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/2025339/+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 2025339] Re: FDE image fails to run e2fsck
** Description changed: After installation of the FDE image, the system fails to boot due to e2fsck failing with: - Jun 21 12:48:19 ubuntu systemd-fsck[268]: /dev/vda2 has unsupported - feature(s): FEATURE_C12 + Jun 21 12:48:19 ubuntu systemd-fsck[268]: /dev/vda2 has unsupported feature(s): FEATURE_C12 + Jun 21 12:48:19 ubuntu systemd-fsck[268]: e2fsck: Get a newer version of e2fsck! + Jun 21 12:48:19 ubuntu systemd-fsck[268]: ubuntu-boot: ** WARNING: Filesystem still has errors ** + Jun 21 12:48:19 ubuntu systemd-fsck[265]: fsck failed with exit status 12. + Jun 21 12:48:19 ubuntu systemd-fsck[265]: Running request emergency.target/start/replace + Jun 21 12:48:19 ubuntu systemd[1]: systemd-fsck@dev-vda2.service: Main process exited, code=exited, status=1/FAILURE + Jun 21 12:48:19 ubuntu systemd[1]: systemd-fsck@dev-vda2.service: Failed with result 'exit-code'. + Jun 21 12:48:19 ubuntu systemd[1]: Failed to start File System Check on /dev/vda2. + Jun 21 12:48:19 ubuntu systemd[1]: Dependency failed for /run/mnt/ubuntu-boot. + Jun 21 12:48:19 ubuntu systemd[1]: run-mnt-ubuntu\x2dboot.mount: Job run-mnt-ubuntu\x -- 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/2025339 Title: FDE image fails to run e2fsck Status in e2fsprogs package in Ubuntu: New Status in e2fsprogs source package in Jammy: New Bug description: After installation of the FDE image, the system fails to boot due to e2fsck failing with: Jun 21 12:48:19 ubuntu systemd-fsck[268]: /dev/vda2 has unsupported feature(s): FEATURE_C12 this means that Jammy fsck fails against mantic created ext4 which is not great To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/2025339/+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 2015887] Re: VPN private key is visible
Please report this for the network-manager debian package, the snappy- hwe-snaps is only for the network-manager snap package. ** Also affects: network-manager (Ubuntu) Importance: Undecided Status: New ** Changed in: snappy-hwe-snaps Status: New => Invalid -- 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/2015887 Title: VPN private key is visible Status in snappy-hwe-snaps: Invalid Status in network-manager package in Ubuntu: New Bug description: When importing a configuration from .ovpn file, I select "Store the password only for this user" for Private key in Network Manager's GUI. It then works as expected, great job! What I did not expect though, is possibility of seeing the Private key at any time afterwards (actually, the same issue applies to Password in Wi-Fi Security settings). The problem is, that this key is confidential and may only be used by our sysadmin at work, and I'm not allowed to know it, but still, I need to be able to connect to remote desktop in his absence, so the key should be stored somewhere in an encrypted format. I'd appreciate an option, that allows to hide this key from end-user - a way to disable Show password check-boxes and buttons for Private key after VPN was added, otherwise I cannot use remote desktop feature on Ubuntu at my current work. Thank you! To manage notifications about this bug go to: https://bugs.launchpad.net/snappy-hwe-snaps/+bug/2015887/+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 2012902] [NEW] netplan plugin: generated NM config when using globbing will be used for only one connection
Public bug reported: There is a mismatch between what netplan expresses when using globbing in a netplan file and what NM understands when using a match setting. For instance: network: version: 2 ethernets: all-en: match: name: "en*" dhcp4: true Generates a NM connection in /run/NetworkManager/system-connections: ... [match] interface-name=en*; ... But an NM connection can only match one interface, so if two interfaces like ens2 and ens3 exist, only one of them will be configured, even though the netplan configuration is expected to be applied to both. Solving this might involve generating one NM connection in the netplan plugin per detected interface. ** Affects: network-manager (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/2012902 Title: netplan plugin: generated NM config when using globbing will be used for only one connection Status in network-manager package in Ubuntu: New Bug description: There is a mismatch between what netplan expresses when using globbing in a netplan file and what NM understands when using a match setting. For instance: network: version: 2 ethernets: all-en: match: name: "en*" dhcp4: true Generates a NM connection in /run/NetworkManager/system-connections: ... [match] interface-name=en*; ... But an NM connection can only match one interface, so if two interfaces like ens2 and ens3 exist, only one of them will be configured, even though the netplan configuration is expected to be applied to both. Solving this might involve generating one NM connection in the netplan plugin per detected interface. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/2012902/+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 1998207] Re: netplan network-manager plugin tries to save temporary connections
@slyon thanks, I have manually tested and seems to work. I've created https://github.com/snapcore/network-manager-snap/pull/15, let's see how tests go. -- 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/1998207 Title: netplan network-manager plugin tries to save temporary connections Status in netplan: Invalid Status in network-manager package in Ubuntu: Triaged Bug description: *** Note: This bug is mostly about comment #10, now *** When creating an OpenVPN connection, a temporal connection called tunN is created. For instance, after activating a connection called vpntest, I have: NAME UUID TYPE DEVICE vpntest 458856e6-8f0f-4dc6-82f2-dd72868252a0 vpn ens3 tun0 1eb1dbe8-5678-4818-9adf-fb2dc01ed132 tun tun0 tun0 is created/removed after activating/deactivating vpntest and should not really be saved, but I see netplan adding it in /etc/netplan. And while doing so the plugin also reports some errors (I see these when stopping the connection): Nov 28 16:16:57 ubuntu NetworkManager[11752]: [1669652217.2920] BUG: the profile cannot be stored in keyfile format without becoming unusable: cannot access file: No such file or directory Nov 28 16:16:57 ubuntu NetworkManager[11752]: ((src/libnm-core-impl/nm-connection.c:342)): assertion '' failed Nov 28 16:16:57 ubuntu NetworkManager[11752]: [1669652217.2920] keyfile: commit: failure to write 1eb1dbe8-5678-4818-9adf-fb2dc01ed132 ((null)) to "/run/NetworkManager/system-connections/tun0-1eb1dbe8-5678-4818-9adf-fb2dc01ed132.nmconnection": keyfile writer produces an invalid connection: cannot access file: No such file or directory To manage notifications about this bug go to: https://bugs.launchpad.net/netplan/+bug/1998207/+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 1998207] Re: netplan network-manager plugin tries to save temporary connections
To reproduce the problem, this should be enough: 1. Create a connection to an OpenVPN server 2. Start the connection. The OpenVPN plugin will create a tunnel interface. 3. "nmcli c" should show a tunX connection and the VPN connection. "nmcli d" should show tunX as a external connection. 4. Disconnect the VPN connection (nmcli c down ) 5. A file in /etc/netplan/ for the tunX which should not be there is created -- 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/1998207 Title: netplan network-manager plugin tries to save temporary connections Status in netplan: Triaged Status in network-manager package in Ubuntu: Confirmed Bug description: When creating an OpenVPN connection, a temporal connection called tunN is created. For instance, after activating a connection called vpntest, I have: NAME UUID TYPE DEVICE vpntest 458856e6-8f0f-4dc6-82f2-dd72868252a0 vpn ens3 tun0 1eb1dbe8-5678-4818-9adf-fb2dc01ed132 tun tun0 tun0 is created/removed after activating/deactivating vpntest and should not really be saved, but I see netplan adding it in /etc/netplan. And while doing so the plugin also reports some errors (I see these when stopping the connection): Nov 28 16:16:57 ubuntu NetworkManager[11752]: [1669652217.2920] BUG: the profile cannot be stored in keyfile format without becoming unusable: cannot access file: No such file or directory Nov 28 16:16:57 ubuntu NetworkManager[11752]: ((src/libnm-core-impl/nm-connection.c:342)): assertion '' failed Nov 28 16:16:57 ubuntu NetworkManager[11752]: [1669652217.2920] keyfile: commit: failure to write 1eb1dbe8-5678-4818-9adf-fb2dc01ed132 ((null)) to "/run/NetworkManager/system-connections/tun0-1eb1dbe8-5678-4818-9adf-fb2dc01ed132.nmconnection": keyfile writer produces an invalid connection: cannot access file: No such file or directory To manage notifications about this bug go to: https://bugs.launchpad.net/netplan/+bug/1998207/+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 1998207] Re: netplan network-manager plugin tries to save temporary connections
> So IIUC the connection works as expected, but only after reloading the connection profiles; it doesn't show up at the time it is expected, right? Hm, not sure if we mean the same. That two connections (tun2 and ) appear after connecting to the VPN is expected. NM recognizes tun2 as "external" as it is an auxiliary device/connection created by the OpenVPN plugin. The problem that is happening is that that connection is being stored in /etc/netplan/, which should not be the case. Note that tun0 and tun1 are slightly different as those are created by the OpenVPN server also running on the device. The netplan files for them are not written anymore after changing the patch. > Does running 'nmcli connection reload' after the connection profile for the VPN connection (tun2?) got written, make it show up in the NM daemon? No, that does not happen. But it happens if I reboot the system. I think that is because there is some file in /run that prevents this from happening if just reloading things. Before rebooting: $ sudo ls run/NetworkManager/system-connections/ -l total 20 lrwxrwxrwx 1 root root9 Jan 10 11:22 891164a5-1fed-42b8-8f6e-903db6396d5e.nmmeta -> /dev/null -rw--- 1 root root 403 Jan 10 11:24 netplan-NM-891164a5-1fed-42b8-8f6e-903db6396d5e.nmconnection -rw--- 1 root root 1248 Jan 10 11:24 netplan-NM-af486148-2495-48a9-9704-2a1230e97e32.nmconnection -rw--- 1 root root 131 Jan 10 11:24 netplan-ens3.nmconnection -rw--- 1 root root 336 Jan 10 09:37 tun0.nmconnection -rw--- 1 root root 336 Jan 10 09:37 tun1.nmconnection After rebooting: $ sudo ls run/NetworkManager/system-connections/ -l total 20 -rw--- 1 root root 403 Jan 10 11:28 netplan-NM-891164a5-1fed-42b8-8f6e-903db6396d5e.nmconnection -rw--- 1 root root 1248 Jan 10 11:28 netplan-NM-af486148-2495-48a9-9704-2a1230e97e32.nmconnection -rw--- 1 root root 131 Jan 10 11:28 netplan-ens3.nmconnection -rw--- 1 root root 336 Jan 10 11:28 tun0.nmconnection -rw--- 1 root root 336 Jan 10 11:28 tun1.nmconnection 891164a5 was tun2 and af486148 the VPN connection. -- 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/1998207 Title: netplan network-manager plugin tries to save temporary connections Status in netplan: Triaged Status in network-manager package in Ubuntu: Confirmed Bug description: When creating an OpenVPN connection, a temporal connection called tunN is created. For instance, after activating a connection called vpntest, I have: NAME UUID TYPE DEVICE vpntest 458856e6-8f0f-4dc6-82f2-dd72868252a0 vpn ens3 tun0 1eb1dbe8-5678-4818-9adf-fb2dc01ed132 tun tun0 tun0 is created/removed after activating/deactivating vpntest and should not really be saved, but I see netplan adding it in /etc/netplan. And while doing so the plugin also reports some errors (I see these when stopping the connection): Nov 28 16:16:57 ubuntu NetworkManager[11752]: [1669652217.2920] BUG: the profile cannot be stored in keyfile format without becoming unusable: cannot access file: No such file or directory Nov 28 16:16:57 ubuntu NetworkManager[11752]: ((src/libnm-core-impl/nm-connection.c:342)): assertion '' failed Nov 28 16:16:57 ubuntu NetworkManager[11752]: [1669652217.2920] keyfile: commit: failure to write 1eb1dbe8-5678-4818-9adf-fb2dc01ed132 ((null)) to "/run/NetworkManager/system-connections/tun0-1eb1dbe8-5678-4818-9adf-fb2dc01ed132.nmconnection": keyfile writer produces an invalid connection: cannot access file: No such file or directory To manage notifications about this bug go to: https://bugs.launchpad.net/netplan/+bug/1998207/+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 1998207] Re: netplan network-manager plugin tries to save temporary connections
Changing the check as suggested to:
if (!is_volatile && !is_nm_generated && !is_external) {
...
does help and netplan files for tun0 and tun1 are not written anymore.
But, when I create a VPN connection I still have problems.
$ network-manager.nmcli c import type openvpn file
$ network-manager.nmcli c up
$ network-manager.nmcli c
NAME UUID TYPE DEVICE
7b7fd99d-2651-4796-ba50-beda0890aab9 vpn ens3
tun0 1d7b454c-4897-4d3d-899a-619165a996bf tun tun0
tun1 f7b9ba1f-496b-4cca-ae79-31db28a64c29 tun tun1
tun2 46935370-3662-4aac-b563-877214b48cd8 tun tun2
netplan-ens3 bec3d02a-c9e5-3283-92ab-ee43a4246c85 ethernet ens3
$ sudo /snap/bin/network-manager.nmcli d
DEVICE TYPE STATE CONNECTION
tun0tun connected (externally) tun0
tun1tun connected (externally) tun1
tun2tun connected (externally) tun2
ens3ethernet connected netplan-ens3
lo loopback unmanaged --
$ network-manager.nmcli c down default
$ network-manager.nmcli c
NAME UUID TYPE DEVICE
netplan-ens3 bec3d02a-c9e5-3283-92ab-ee43a4246c85 ethernet ens3
tun0 8bc8d5b1-6000-4b78-9988-72d2d811bfb7 tun tun0
tun1 9d614be8-dac1-44ef-acfd-f9c60005b56f tun tun1
default 7b7fd99d-2651-4796-ba50-beda0890aab9 vpn --
$ ls /etc/netplan/
00-default-nm-renderer.yaml
50-cloud-init.yaml
90-NM-7b7fd99d-2651-4796-ba50-beda0890aab9.yaml
90-NM-46935370-3662-4aac-b563-877214b48cd8
Note that when you create an OpenVPN connection both a normal NM
connection and a new tunnel device (tun2) are created. NM creates a
external device for tun2. The interesting thing here is that the file
for tun2 is written after setting down the connection, and the NM daemon
actually forgets it (until you restart it and reads the netplan file).
Maybe this storing is in a different code path.
--
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/1998207
Title:
netplan network-manager plugin tries to save temporary connections
Status in netplan:
Triaged
Status in network-manager package in Ubuntu:
Confirmed
Bug description:
When creating an OpenVPN connection, a temporal connection called tunN
is created. For instance, after activating a connection called
vpntest, I have:
NAME UUID TYPE DEVICE
vpntest 458856e6-8f0f-4dc6-82f2-dd72868252a0 vpn ens3
tun0 1eb1dbe8-5678-4818-9adf-fb2dc01ed132 tun tun0
tun0 is created/removed after activating/deactivating vpntest and
should not really be saved, but I see netplan adding it in
/etc/netplan. And while doing so the plugin also reports some errors
(I see these when stopping the connection):
Nov 28 16:16:57 ubuntu NetworkManager[11752]: [1669652217.2920] BUG:
the profile cannot be stored in keyfile format without becoming unusable:
cannot access file: No such file or directory
Nov 28 16:16:57 ubuntu NetworkManager[11752]:
((src/libnm-core-impl/nm-connection.c:342)): assertion '' failed
Nov 28 16:16:57 ubuntu NetworkManager[11752]: [1669652217.2920]
keyfile: commit: failure to write 1eb1dbe8-5678-4818-9adf-fb2dc01ed132 ((null))
to
"/run/NetworkManager/system-connections/tun0-1eb1dbe8-5678-4818-9adf-fb2dc01ed132.nmconnection":
keyfile writer produces an invalid connection: cannot access file: No such
file or directory
To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/1998207/+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 1998207] Re: netplan network-manager plugin tries to save temporary connections
Unfortunately this is still happening with the patch from comment #3. In fact I do not even need to create a VPN connection for this. If I install easy-openvpn-server: $ snap install easy-openvpn-server it creates two tun devices (tun0 and tun1) that can be seen with "ip address" command. That makes NM create the corresponding devices and connections: /ssh:ubuntu@localhost#8022: $ /snap/bin/network-manager.nmcli c NAME UUID TYPE DEVICE netplan-ens3 bec3d02a-c9e5-3283-92ab-ee43a4246c85 ethernet ens3 tun0 edc2d2e1-b126-475d-8d5b-1a5b3bfd43d3 tun tun0 tun1 2945f4f4-2d44-4a61-83b4-cee73fd81129 tun tun1 /ssh:ubuntu@localhost#8022: $ /snap/bin/network-manager.nmcli d DEVICE TYPE STATE CONNECTION ens3ethernet connected netplan-ens3 tun0tun connected (externally) tun0 tun1tun connected (externally) tun1 lo loopback unmanaged but unfortunately these connections are still written as static connections in /etc/netplan/. And when I reboot, I see 4 of them: /ssh:ubuntu@localhost#8022: $ /snap/bin/network-manager.nmcli c NAME UUID TYPE DEVICE netplan-ens3 bec3d02a-c9e5-3283-92ab-ee43a4246c85 ethernet ens3 tun0 864e0de2-e5c6-4c9b-aa7f-20aef970067c tun tun0 tun1 ddfc7db2-2baa-488f-95da-c8e1e66e458b tun tun1 default be2bc22c-fc98-4b2b-9484-fd4d5c838d5f vpn -- tun0 3c1e12f9-1a08-4a6f-aef3-5ea22d9e9bb2 tun -- tun1 eb8ed73b-3312-401f-a4c4-c26aadb3a014 tun -- The files look like https://paste.ubuntu.com/p/KvTVXPwK75/ -- 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/1998207 Title: netplan network-manager plugin tries to save temporary connections Status in netplan: Triaged Status in network-manager package in Ubuntu: Fix Committed Bug description: When creating an OpenVPN connection, a temporal connection called tunN is created. For instance, after activating a connection called vpntest, I have: NAME UUID TYPE DEVICE vpntest 458856e6-8f0f-4dc6-82f2-dd72868252a0 vpn ens3 tun0 1eb1dbe8-5678-4818-9adf-fb2dc01ed132 tun tun0 tun0 is created/removed after activating/deactivating vpntest and should not really be saved, but I see netplan adding it in /etc/netplan. And while doing so the plugin also reports some errors (I see these when stopping the connection): Nov 28 16:16:57 ubuntu NetworkManager[11752]: [1669652217.2920] BUG: the profile cannot be stored in keyfile format without becoming unusable: cannot access file: No such file or directory Nov 28 16:16:57 ubuntu NetworkManager[11752]: ((src/libnm-core-impl/nm-connection.c:342)): assertion '' failed Nov 28 16:16:57 ubuntu NetworkManager[11752]: [1669652217.2920] keyfile: commit: failure to write 1eb1dbe8-5678-4818-9adf-fb2dc01ed132 ((null)) to "/run/NetworkManager/system-connections/tun0-1eb1dbe8-5678-4818-9adf-fb2dc01ed132.nmconnection": keyfile writer produces an invalid connection: cannot access file: No such file or directory To manage notifications about this bug go to: https://bugs.launchpad.net/netplan/+bug/1998207/+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 1965901] Re: SRU the new 1.18 serie to focal for hwe
It turns out that this actually regressed some qualcomm modems because modem-manager started to use some special netlink sockets that were not enabled in the 5.4 kernel. To have that we need (see LP: #1998194): CONFIG_QRTR=m CONFIG_QRTR_SMD=m CONFIG_QRTR_TUN=m CONFIG_QRTR_MHI=m in the 5.4 kernel. However, this might not be easy according to some discussion I had. Would it be possible to revisit this backport? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to modemmanager in Ubuntu. https://bugs.launchpad.net/bugs/1965901 Title: SRU the new 1.18 serie to focal for hwe Status in libmbim package in Ubuntu: Fix Released Status in libqmi package in Ubuntu: Fix Released Status in modemmanager package in Ubuntu: Fix Released Status in libmbim source package in Focal: Fix Released Status in libqmi source package in Focal: Fix Released Status in modemmanager source package in Focal: Fix Released Bug description: [Impact] We want to update to the newer serie for better hardware support (support for Quectel EM120R-GL and EM160R-GL) [Test Plan] * install modemmanager, libmbim, and libqmi from -proposed * reboot and try WWAN function to see if any regression there. * perform general dogfooding of its reverse dependencies (network- manager, gnome-control-center etc.) [Where problems could occur] The new version no longer automatically performs the FCC unlock procedure by default, see details on https://modemmanager.org/docs/modemmanager/fcc-unlock/ It means some modem will stop working out of the box. Users can manually install the unlock utility as described in the "FCC unlock procedures in ModemManager >= 1.18.4" section in the page above. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libmbim/+bug/1965901/+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 1998207] Re: netplan network-manager plugin tries to save temporary connections
Right, it is more about the plugin, was not fully sure where to put this, but now probably we can put under network-manager deb. -- 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/1998207 Title: netplan network-manager plugin tries to save temporary connections Status in netplan: Triaged Status in network-manager package in Ubuntu: New Bug description: When creating an OpenVPN connection, a temporal connection called tunN is created. For instance, after activating a connection called vpntest, I have: NAME UUID TYPE DEVICE vpntest 458856e6-8f0f-4dc6-82f2-dd72868252a0 vpn ens3 tun0 1eb1dbe8-5678-4818-9adf-fb2dc01ed132 tun tun0 tun0 is created/removed after activating/deactivating vpntest and should not really be saved, but I see netplan adding it in /etc/netplan. And while doing so the plugin also reports some errors (I see these when stopping the connection): Nov 28 16:16:57 ubuntu NetworkManager[11752]: [1669652217.2920] BUG: the profile cannot be stored in keyfile format without becoming unusable: cannot access file: No such file or directory Nov 28 16:16:57 ubuntu NetworkManager[11752]: ((src/libnm-core-impl/nm-connection.c:342)): assertion '' failed Nov 28 16:16:57 ubuntu NetworkManager[11752]: [1669652217.2920] keyfile: commit: failure to write 1eb1dbe8-5678-4818-9adf-fb2dc01ed132 ((null)) to "/run/NetworkManager/system-connections/tun0-1eb1dbe8-5678-4818-9adf-fb2dc01ed132.nmconnection": keyfile writer produces an invalid connection: cannot access file: No such file or directory To manage notifications about this bug go to: https://bugs.launchpad.net/netplan/+bug/1998207/+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 1982462] Re: Some modprobe loading services requested by the pstore service fail
I have tested core20 built using the proposed pocket and I can confirm that the issue does not appear (no failed services on start up). I have also tested the focal deb on classic and the modprobe services do not fail either: root@focal:~# apt policy systemd systemd: Installed: 245.4-4ubuntu3.18 Candidate: 245.4-4ubuntu3.18 Version table: *** 245.4-4ubuntu3.18 500 500 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 Packages 100 /var/lib/dpkg/status 245.4-4ubuntu3.17 500 500 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 245.4-4ubuntu3.15 500 500 http://security.ubuntu.com/ubuntu focal-security/main amd64 Packages 245.4-4ubuntu3 500 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages ** Tags removed: verification-needed-focal ** Tags added: verification-done-focal -- 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/1982462 Title: Some modprobe loading services requested by the pstore service fail Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Focal: Fix Committed Status in systemd source package in Jammy: Fix Committed Status in systemd source package in Kinetic: Fix Released Bug description: [Impact] It has been detected that some modprobe services fail on UC22 after the jammy upgrade 249.11-0ubuntu3.4: $ systemctl --system --no-ask-password --no-pager list-units --state=failed Failed units: UNIT LOAD ACTIVE SUBDESCRIPTION ● modprobe@chromeos_pstore.service loaded failed failed Load Kernel Module chromeos_pstore ● modprobe@efi_pstore.service loaded failed failed Load Kernel Module efi_pstore ● modprobe@mtdpstore.service loaded failed failed Load Kernel Module mtdpstore ● modprobe@pstore_blk.service loaded failed failed Load Kernel Module pstore_blk ● modprobe@pstore_zone.service loaded failed failed Load Kernel Module pstore_zone ● modprobe@ramoops.service loaded failed failed Load Kernel Module ramoops This happens because of some changes to systemd-pstore.service that now has: After=modprobe@efi_pstore.service modprobe@mtdpstore.service modprobe@chromeos_pstore.service modprobe@ramoops.service modprobe@pstore_zone.service modprobe@pstore_blk.service Wants=modprobe@efi_pstore.service modprobe@mtdpstore.service modprobe@chromeos_pstore.service modprobe@ramoops.service modprobe@pstore_zone.service modprobe@pstore_blk.service This causes too many tries of the modprobe services, that fail in the end with Jul 20 09:02:39 ubuntu systemd[1]: modprobe@chromeos_pstore.service: Start request repeated too quickly. Although we have seen this only on UC22, it potentially can affect classic systems as well, as systemd-pstore.service is re-tried there a few times too. See https://github.com/snapcore/core-base/issues/72 for more details. A fix for this is available upstream: https://github.com/systemd/systemd/commit/9625350e5381a68c1179ae4581e7586c206663e1 [Test Plan] Start the device and check that there is no modprobe-pstore related failed service. This is racy, so a few tries will be needed to make sure things are fine. [Where problems could occur] The modprobe services are usually dependencies from other services, so it should be fine if the retry behavior is controlled by those other services. Risk should be small. If something goes wrong we might see a lot of restarts for these services. [Other Info] Testing should happen on UC22 too. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1982462/+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 1982462] Re: Some modprobe loading services requested by the pstore service fail
I have tested core22 built using the proposed pocket and I can confirm that the issue is gone (no failed services on start up anymore). I have also tested the jammy deb on classic and the modprobe services do not fail either: root@jammy:~# apt policy systemd systemd: Installed: 249.11-0ubuntu3.5 Candidate: 249.11-0ubuntu3.5 Version table: *** 249.11-0ubuntu3.5 500 500 http://archive.ubuntu.com/ubuntu jammy-proposed/main amd64 Packages 100 /var/lib/dpkg/status 249.11-0ubuntu3.4 500 500 http://archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages 249.11-0ubuntu3 500 500 http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages ** Tags removed: verification-needed-focal verification-needed-jammy ** Tags added: verification-done-jammy ** Tags added: verification-needed-focal -- 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/1982462 Title: Some modprobe loading services requested by the pstore service fail Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Focal: Fix Committed Status in systemd source package in Jammy: Fix Committed Status in systemd source package in Kinetic: Fix Released Bug description: [Impact] It has been detected that some modprobe services fail on UC22 after the jammy upgrade 249.11-0ubuntu3.4: $ systemctl --system --no-ask-password --no-pager list-units --state=failed Failed units: UNIT LOAD ACTIVE SUBDESCRIPTION ● modprobe@chromeos_pstore.service loaded failed failed Load Kernel Module chromeos_pstore ● modprobe@efi_pstore.service loaded failed failed Load Kernel Module efi_pstore ● modprobe@mtdpstore.service loaded failed failed Load Kernel Module mtdpstore ● modprobe@pstore_blk.service loaded failed failed Load Kernel Module pstore_blk ● modprobe@pstore_zone.service loaded failed failed Load Kernel Module pstore_zone ● modprobe@ramoops.service loaded failed failed Load Kernel Module ramoops This happens because of some changes to systemd-pstore.service that now has: After=modprobe@efi_pstore.service modprobe@mtdpstore.service modprobe@chromeos_pstore.service modprobe@ramoops.service modprobe@pstore_zone.service modprobe@pstore_blk.service Wants=modprobe@efi_pstore.service modprobe@mtdpstore.service modprobe@chromeos_pstore.service modprobe@ramoops.service modprobe@pstore_zone.service modprobe@pstore_blk.service This causes too many tries of the modprobe services, that fail in the end with Jul 20 09:02:39 ubuntu systemd[1]: modprobe@chromeos_pstore.service: Start request repeated too quickly. Although we have seen this only on UC22, it potentially can affect classic systems as well, as systemd-pstore.service is re-tried there a few times too. See https://github.com/snapcore/core-base/issues/72 for more details. A fix for this is available upstream: https://github.com/systemd/systemd/commit/9625350e5381a68c1179ae4581e7586c206663e1 [Test Plan] Start the device and check that there is no modprobe-pstore related failed service. This is racy, so a few tries will be needed to make sure things are fine. [Where problems could occur] The modprobe services are usually dependencies from other services, so it should be fine if the retry behavior is controlled by those other services. Risk should be small. If something goes wrong we might see a lot of restarts for these services. [Other Info] Testing should happen on UC22 too. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1982462/+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 1982462] Re: Some modprobe loading services requested by the pstore service fail
I have tested a modified systemd-pstore.service in UC20 (focal based) adding: [Unit] After=modprobe@efi_pstore.service modprobe@mtdpstore.service modprobe@chromeos_pstore.service modprobe@ramoops.service modprobe@pstore_zone.service modprobe@pstore_blk.service Wants=modprobe@efi_pstore.service modprobe@mtdpstore.service modprobe@chromeos_pstore.service modprobe@ramoops.service modprobe@pstore_zone.service modprobe@pstore_blk.service As a result I get failures in the services trying to load modules for pstore, for instance: ubuntu@ubuntu:~$ sudo systemctl status modprobe@mtdpstore.service ● modprobe@mtdpstore.service - Load Kernel Module mtdpstore Loaded: loaded (/lib/systemd/system/modprobe@.service; static; vendor preset: enabled) Active: inactive (dead) since Thu 2022-08-04 15:59:31 UTC; 25s ago Docs: man:modprobe(8) Process: 400 ExecStart=/sbin/modprobe -abq mtdpstore (code=exited, status=1/FAILURE) Main PID: 400 (code=exited, status=1/FAILURE) Aug 04 15:59:31 ubuntu systemd[1]: modprobe@mtdpstore.service: Succeeded. Aug 04 15:59:31 ubuntu systemd[1]: Finished Load Kernel Module mtdpstore. Which is fine, but there is the potential of too many successive restart of these services, which would result in https://github.com/systemd/systemd/issues/23742. To prevent this, https://github.com/systemd/systemd/commit/9625350e5381a68c1179ae4581e7586c206663e1 should be included in the next systemd focal SRU. ** Bug watch added: github.com/systemd/systemd/issues #23742 https://github.com/systemd/systemd/issues/23742 -- 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/1982462 Title: Some modprobe loading services requested by the pstore service fail Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Focal: New Status in systemd source package in Jammy: Triaged Status in systemd source package in Kinetic: Fix Released Bug description: [Impact] It has been detected that some modprobe services fail on UC22 after the jammy upgrade 249.11-0ubuntu3.4: $ systemctl --system --no-ask-password --no-pager list-units --state=failed Failed units: UNIT LOAD ACTIVE SUBDESCRIPTION ● modprobe@chromeos_pstore.service loaded failed failed Load Kernel Module chromeos_pstore ● modprobe@efi_pstore.service loaded failed failed Load Kernel Module efi_pstore ● modprobe@mtdpstore.service loaded failed failed Load Kernel Module mtdpstore ● modprobe@pstore_blk.service loaded failed failed Load Kernel Module pstore_blk ● modprobe@pstore_zone.service loaded failed failed Load Kernel Module pstore_zone ● modprobe@ramoops.service loaded failed failed Load Kernel Module ramoops This happens because of some changes to systemd-pstore.service that now has: After=modprobe@efi_pstore.service modprobe@mtdpstore.service modprobe@chromeos_pstore.service modprobe@ramoops.service modprobe@pstore_zone.service modprobe@pstore_blk.service Wants=modprobe@efi_pstore.service modprobe@mtdpstore.service modprobe@chromeos_pstore.service modprobe@ramoops.service modprobe@pstore_zone.service modprobe@pstore_blk.service This causes too many tries of the modprobe services, that fail in the end with Jul 20 09:02:39 ubuntu systemd[1]: modprobe@chromeos_pstore.service: Start request repeated too quickly. Although we have seen this only on UC22, it potentially can affect classic systems as well, as systemd-pstore.service is re-tried there a few times too. See https://github.com/snapcore/core-base/issues/72 for more details. A fix for this is available upstream: https://github.com/systemd/systemd/commit/9625350e5381a68c1179ae4581e7586c206663e1 [Test Plan] Start the device and check that there is no modprobe-pstore related failed service. This is racy, so a few tries will be needed to make sure things are fine. [Where problems could occur] The modprobe services are usually dependencies from other services, so it should be fine if the retry behavior is controlled by those other services. Risk should be small. If something goes wrong we might see a lot of restarts for these services. [Other Info] Testing should happen on UC22 too. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1982462/+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 1982462] Re: Some modprobe loading services requested by the pstore service fail
** Bug watch added: github.com/snapcore/core-base/issues #72 https://github.com/snapcore/core-base/issues/72 -- 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/1982462 Title: Some modprobe loading services requested by the pstore service fail Status in systemd package in Ubuntu: In Progress Status in systemd source package in Jammy: Triaged Status in systemd source package in Kinetic: In Progress Bug description: [Impact] It has been detected that some modprobe services fail on UC22 after the jammy upgrade 249.11-0ubuntu3.4: $ systemctl --system --no-ask-password --no-pager list-units --state=failed Failed units: UNIT LOAD ACTIVE SUBDESCRIPTION ● modprobe@chromeos_pstore.service loaded failed failed Load Kernel Module chromeos_pstore ● modprobe@efi_pstore.service loaded failed failed Load Kernel Module efi_pstore ● modprobe@mtdpstore.service loaded failed failed Load Kernel Module mtdpstore ● modprobe@pstore_blk.service loaded failed failed Load Kernel Module pstore_blk ● modprobe@pstore_zone.service loaded failed failed Load Kernel Module pstore_zone ● modprobe@ramoops.service loaded failed failed Load Kernel Module ramoops This happens because of some changes to systemd-pstore.service that now has: After=modprobe@efi_pstore.service modprobe@mtdpstore.service modprobe@chromeos_pstore.service modprobe@ramoops.service modprobe@pstore_zone.service modprobe@pstore_blk.service Wants=modprobe@efi_pstore.service modprobe@mtdpstore.service modprobe@chromeos_pstore.service modprobe@ramoops.service modprobe@pstore_zone.service modprobe@pstore_blk.service This causes too many tries of the modprobe services, that fail in the end with Jul 20 09:02:39 ubuntu systemd[1]: modprobe@chromeos_pstore.service: Start request repeated too quickly. Although we have seen this only on UC22, it potentially can affect classic systems as well, as systemd-pstore.service is re-tried there a few times too. See https://github.com/snapcore/core-base/issues/72 for more details. A fix for this is available upstream: https://github.com/systemd/systemd/commit/9625350e5381a68c1179ae4581e7586c206663e1 [Test Plan] Start the device and check that there is no modprobe-pstore related failed service. This is racy, so a few tries will be needed to make sure things are fine. [Where problems could occur] The modprobe services are usually dependencies from other services, so it should be fine if the retry behavior is controlled by those other services. Risk should be small. If something goes wrong we might see a lot of restarts for these services. [Other Info] Testing should happen on UC22 too. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1982462/+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
Re: [Touch-packages] [Bug 1982462] Re: Some modprobe loading services requested by the pstore service fail
On Mon, Jul 25, 2022 at 4:00 PM Lukas Märdian <1982...@bugs.launchpad.net> wrote: > Alfonso, would this also affect Focal (Ubuntu Core 20), after this patch > is shipped to that series via SRU (as it happened on Jammy already)? > > https://git.launchpad.net/~ubuntu-core- > dev/ubuntu/+source/systemd/commit/?h=ubuntu- > focal=6e60756f2079d6408abdb967127a1d9b9a0eba8c > > Do we need to include this fix for Focal too, before uploading the next > Focal SRU? > Although the bug was reported for UC22, if the patch causing the problem is in focal I would say that yes, probably it would be needed to backport it there. > > -- > You received this bug notification because you are subscribed to the bug > report. > https://bugs.launchpad.net/bugs/1982462 > > Title: > Some modprobe loading services requested by the pstore service fail > > Status in systemd package in Ubuntu: > In Progress > Status in systemd source package in Jammy: > Triaged > Status in systemd source package in Kinetic: > In Progress > > Bug description: > [Impact] > > It has been detected that some modprobe services fail on UC22 after > the jammy upgrade 249.11-0ubuntu3.4: > > $ systemctl --system --no-ask-password --no-pager list-units > --state=failed > Failed units: > UNIT LOAD ACTIVE SUBDESCRIPTION > ● modprobe@chromeos_pstore.service loaded failed failed Load Kernel > Module chromeos_pstore > ● modprobe@efi_pstore.service loaded failed failed Load Kernel > Module efi_pstore > ● modprobe@mtdpstore.service loaded failed failed Load Kernel > Module mtdpstore > ● modprobe@pstore_blk.service loaded failed failed Load Kernel > Module pstore_blk > ● modprobe@pstore_zone.service loaded failed failed Load Kernel > Module pstore_zone > ● modprobe@ramoops.service loaded failed failed Load Kernel > Module ramoops > > This happens because of some changes to systemd-pstore.service that > now has: > > After=modprobe@efi_pstore.service modprobe@mtdpstore.service > modprobe@chromeos_pstore.service modprobe@ramoops.service > modprobe@pstore_zone.service modprobe@pstore_blk.service > Wants=modprobe@efi_pstore.service modprobe@mtdpstore.service > modprobe@chromeos_pstore.service modprobe@ramoops.service > modprobe@pstore_zone.service modprobe@pstore_blk.service > > This causes too many tries of the modprobe services, that fail in the > end with > > Jul 20 09:02:39 ubuntu systemd[1]: modprobe@chromeos_pstore.service: > Start request repeated too quickly. > > Although we have seen this only on UC22, it potentially can affect > classic systems as well, as systemd-pstore.service is re-tried there a > few times too. See https://github.com/snapcore/core-base/issues/72 for > more details. > > A fix for this is available upstream: > > https://github.com/systemd/systemd/commit/9625350e5381a68c1179ae4581e7586c206663e1 > > [Test Plan] > > Start the device and check that there is no modprobe-pstore related > failed service. This is racy, so a few tries will be needed to make > sure things are fine. > > [Where problems could occur] > > The modprobe services are usually dependencies from other services, so > it should be fine if the retry behavior is controlled by those other > services. Risk should be small. If something goes wrong we might see a > lot of restarts for these services. > > [Other Info] > > Testing should happen on UC22 too. > > To manage notifications about this bug go to: > > https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1982462/+subscriptions > > -- 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/1982462 Title: Some modprobe loading services requested by the pstore service fail Status in systemd package in Ubuntu: In Progress Status in systemd source package in Jammy: Triaged Status in systemd source package in Kinetic: In Progress Bug description: [Impact] It has been detected that some modprobe services fail on UC22 after the jammy upgrade 249.11-0ubuntu3.4: $ systemctl --system --no-ask-password --no-pager list-units --state=failed Failed units: UNIT LOAD ACTIVE SUBDESCRIPTION ● modprobe@chromeos_pstore.service loaded failed failed Load Kernel Module chromeos_pstore ● modprobe@efi_pstore.service loaded failed failed Load Kernel Module efi_pstore ● modprobe@mtdpstore.service loaded failed failed Load Kernel Module mtdpstore ● modprobe@pstore_blk.service loaded failed failed Load Kernel Module pstore_blk
[Touch-packages] [Bug 1982462] Re: Some modprobe loading services requested by the pstore service fail
** Tags added: rls-jj-incoming -- 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/1982462 Title: Some modprobe loading services requested by the pstore service fail Status in systemd package in Ubuntu: New Bug description: [Impact] It has been detected that some modprobe services fail on UC22 after the jammy upgrade 249.11-0ubuntu3.4: $ systemctl --system --no-ask-password --no-pager list-units --state=failed Failed units: UNIT LOAD ACTIVE SUBDESCRIPTION ● modprobe@chromeos_pstore.service loaded failed failed Load Kernel Module chromeos_pstore ● modprobe@efi_pstore.service loaded failed failed Load Kernel Module efi_pstore ● modprobe@mtdpstore.service loaded failed failed Load Kernel Module mtdpstore ● modprobe@pstore_blk.service loaded failed failed Load Kernel Module pstore_blk ● modprobe@pstore_zone.service loaded failed failed Load Kernel Module pstore_zone ● modprobe@ramoops.service loaded failed failed Load Kernel Module ramoops This happens because of some changes to systemd-pstore.service that now has: After=modprobe@efi_pstore.service modprobe@mtdpstore.service modprobe@chromeos_pstore.service modprobe@ramoops.service modprobe@pstore_zone.service modprobe@pstore_blk.service Wants=modprobe@efi_pstore.service modprobe@mtdpstore.service modprobe@chromeos_pstore.service modprobe@ramoops.service modprobe@pstore_zone.service modprobe@pstore_blk.service This causes too many tries of the modprobe services, that fail in the end with Jul 20 09:02:39 ubuntu systemd[1]: modprobe@chromeos_pstore.service: Start request repeated too quickly. Although we have seen this only on UC22, it potentially can affect classic systems as well, as systemd-pstore.service is re-tried there a few times too. See https://github.com/snapcore/core-base/issues/72 for more details. A fix for this is available upstream: https://github.com/systemd/systemd/commit/9625350e5381a68c1179ae4581e7586c206663e1 [Test Plan] Start the device and check that there is no modprobe-pstore related failed service. This is racy, so a few tries will be needed to make sure things are fine. [Where problems could occur] The modprobe services are usually dependencies from other services, so it should be fine if the retry behavior is controlled by those other services. Risk should be small. If something goes wrong we might see a lot of restarts for these services. [Other Info] Testing should happen on UC22 too. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1982462/+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 1982462] [NEW] Some modprobe loading services requested by the pstore service fail
Public bug reported: [Impact] It has been detected that some modprobe services fail on UC22 after the jammy upgrade 249.11-0ubuntu3.4: $ systemctl --system --no-ask-password --no-pager list-units --state=failed Failed units: UNIT LOAD ACTIVE SUBDESCRIPTION ● modprobe@chromeos_pstore.service loaded failed failed Load Kernel Module chromeos_pstore ● modprobe@efi_pstore.service loaded failed failed Load Kernel Module efi_pstore ● modprobe@mtdpstore.service loaded failed failed Load Kernel Module mtdpstore ● modprobe@pstore_blk.service loaded failed failed Load Kernel Module pstore_blk ● modprobe@pstore_zone.service loaded failed failed Load Kernel Module pstore_zone ● modprobe@ramoops.service loaded failed failed Load Kernel Module ramoops This happens because of some changes to systemd-pstore.service that now has: After=modprobe@efi_pstore.service modprobe@mtdpstore.service modprobe@chromeos_pstore.service modprobe@ramoops.service modprobe@pstore_zone.service modprobe@pstore_blk.service Wants=modprobe@efi_pstore.service modprobe@mtdpstore.service modprobe@chromeos_pstore.service modprobe@ramoops.service modprobe@pstore_zone.service modprobe@pstore_blk.service This causes too many tries of the modprobe services, that fail in the end with Jul 20 09:02:39 ubuntu systemd[1]: modprobe@chromeos_pstore.service: Start request repeated too quickly. Although we have seen this only on UC22, it potentially can affect classic systems as well, as systemd-pstore.service is re-tried there a few times too. See https://github.com/snapcore/core-base/issues/72 for more details. A fix for this is available upstream: https://github.com/systemd/systemd/commit/9625350e5381a68c1179ae4581e7586c206663e1 [Test Plan] Start the device and check that there is no modprobe-pstore related failed service. This is racy, so a few tries will be needed to make sure things are fine. [Where problems could occur] The modprobe services are usually dependencies from other services, so it should be fine if the retry behavior is controlled by those other services. Risk should be small. If something goes wrong we might see a lot of restarts for these services. [Other Info] Testing should happen on UC22 too. ** 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/1982462 Title: Some modprobe loading services requested by the pstore service fail Status in systemd package in Ubuntu: New Bug description: [Impact] It has been detected that some modprobe services fail on UC22 after the jammy upgrade 249.11-0ubuntu3.4: $ systemctl --system --no-ask-password --no-pager list-units --state=failed Failed units: UNIT LOAD ACTIVE SUBDESCRIPTION ● modprobe@chromeos_pstore.service loaded failed failed Load Kernel Module chromeos_pstore ● modprobe@efi_pstore.service loaded failed failed Load Kernel Module efi_pstore ● modprobe@mtdpstore.service loaded failed failed Load Kernel Module mtdpstore ● modprobe@pstore_blk.service loaded failed failed Load Kernel Module pstore_blk ● modprobe@pstore_zone.service loaded failed failed Load Kernel Module pstore_zone ● modprobe@ramoops.service loaded failed failed Load Kernel Module ramoops This happens because of some changes to systemd-pstore.service that now has: After=modprobe@efi_pstore.service modprobe@mtdpstore.service modprobe@chromeos_pstore.service modprobe@ramoops.service modprobe@pstore_zone.service modprobe@pstore_blk.service Wants=modprobe@efi_pstore.service modprobe@mtdpstore.service modprobe@chromeos_pstore.service modprobe@ramoops.service modprobe@pstore_zone.service modprobe@pstore_blk.service This causes too many tries of the modprobe services, that fail in the end with Jul 20 09:02:39 ubuntu systemd[1]: modprobe@chromeos_pstore.service: Start request repeated too quickly. Although we have seen this only on UC22, it potentially can affect classic systems as well, as systemd-pstore.service is re-tried there a few times too. See https://github.com/snapcore/core-base/issues/72 for more details. A fix for this is available upstream: https://github.com/systemd/systemd/commit/9625350e5381a68c1179ae4581e7586c206663e1 [Test Plan] Start the device and check that there is no modprobe-pstore related failed service. This is racy, so a few tries will be needed to make sure things are fine. [Where problems could occur] The modprobe services are usually dependencies from other services, so it should be fine if the retry behavior is controlled by those other services. Risk should be small. If something goes wrong we might see a lot of restarts for these services. [Other Info]
[Touch-packages] [Bug 1973835] Re: Ubuntu 22.04, Bluetooth issues
** Also affects: bluez (Ubuntu) Importance: Undecided Status: New ** No longer affects: snappy-hwe-snaps -- 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/1973835 Title: Ubuntu 22.04, Bluetooth issues Status in bluez package in Ubuntu: New Bug description: 0 I installed Ubuntu 22.04 and the Bluetooth was working fine. I turned off the bluetooth and could not turn it back on. I did some research and found some calls to turn it back on: sudo rfkill unblock all sudo hciconfig hci0 down sudo rmmod btusb sudo modprobe btusb sudo hciconfig hci0 up Now, I can turn it on and off as I please but It is now not connecting to any device. It would connect for a brief second and then disconnect. Can't find anything from research. Anyone can help with this ? Also, Whenever I boot up windows, the bluetooth works perfectly fine on windows. So it's not an hardware issue. I ran the command: bluetoothctl and the bluetooth is cycling through connecting to the device and disconnecting To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1973835/+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 1971430] [NEW] lz4 is not a dependency of initramfs-tools-core
Public bug reported: lz4 is not a dependency of initramfs-tools-core, although it uses lz4cat in the unmkinitramfs script. ** Affects: initramfs-tools (Ubuntu) Importance: Undecided Status: New -- 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/1971430 Title: lz4 is not a dependency of initramfs-tools-core Status in initramfs-tools package in Ubuntu: New Bug description: lz4 is not a dependency of initramfs-tools-core, although it uses lz4cat in the unmkinitramfs script. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1971430/+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 1958676] Re: error: too early for operation, device not yet seeded or device model not acknowledged Install failed
With systemd debug trace enabled. Look for Got message type=method_call sender=n/a destination=org.freedesktop.systemd1 path=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager member=RestartUnit cookie=22 reply_cookie=0 signature=ss error-name=n/a error-message=n/a ** Attachment added: "journal-debug.txt" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1958676/+attachment/5556977/+files/journal-debug.txt -- 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/1958676 Title: error: too early for operation, device not yet seeded or device model not acknowledged Install failed Status in launchpad-buildd: New Status in init-system-helpers package in Ubuntu: New Status in snapd package in Ubuntu: New Status in systemd package in Ubuntu: New Bug description: https://launchpad.net/~ubuntu-core-service/+snap/core22/+build/1650565 New deb-systemd-invoke added functionality for systemd v250 which ubuntu does not have yet. But it also appears to break postinst calls to deb-systemd-invoke, at least as seen during snap builds in lxd containers operated by launchpad-buildd. I wonder if there is a regression in new code, or new systemd, which may warrant a revert. To manage notifications about this bug go to: https://bugs.launchpad.net/launchpad-buildd/+bug/1958676/+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 1958676] Re: error: too early for operation, device not yet seeded or device model not acknowledged Install failed
Full journal attached ** Attachment added: "journal-fail.txt" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1958676/+attachment/5556929/+files/journal-fail.txt -- 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/1958676 Title: error: too early for operation, device not yet seeded or device model not acknowledged Install failed Status in launchpad-buildd: New Status in init-system-helpers package in Ubuntu: New Status in snapd package in Ubuntu: New Status in systemd package in Ubuntu: New Bug description: https://launchpad.net/~ubuntu-core-service/+snap/core22/+build/1650565 New deb-systemd-invoke added functionality for systemd v250 which ubuntu does not have yet. But it also appears to break postinst calls to deb-systemd-invoke, at least as seen during snap builds in lxd containers operated by launchpad-buildd. I wonder if there is a regression in new code, or new systemd, which may warrant a revert. To manage notifications about this bug go to: https://bugs.launchpad.net/launchpad-buildd/+bug/1958676/+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 1958676] Re: error: too early for operation, device not yet seeded or device model not acknowledged Install failed
This is what I see in a jammy lxd container: Jan 21 17:47:55 jammy systemd[1]: Starting Load AppArmor profiles managed internally by snapd... Jan 21 17:47:55 jammy systemd[1]: Condition check resulted in Auto import assertions from block devices being skipped. Jan 21 17:47:55 jammy systemd[1]: Condition check resulted in Automatically repair incorrect owner/permissions on core devices being skipped. Jan 21 17:47:55 jammy systemd[1]: Condition check resulted in Wait for the Ubuntu Core chooser trigger being skipped. Jan 21 17:47:55 jammy snapd-apparmor[1217]: /usr/lib/snapd/snapd-apparmor: 47: ns_stacked: not found Jan 21 17:47:55 jammy snapd-apparmor[1217]: /usr/lib/snapd/snapd-apparmor: 48: ns_name: not found Jan 21 17:47:55 jammy systemd[1]: Starting Socket activation for snappy daemon... Jan 21 17:47:55 jammy snapd-apparmor[1220]: find: ‘/var/lib/snapd/apparmor/profiles/’: No such file or directory Jan 21 17:47:55 jammy systemd[1]: Listening on Socket activation for snappy daemon. Jan 21 17:47:55 jammy systemd[1]: Starting Wait until snapd is fully seeded... Jan 21 17:47:55 jammy systemd[1]: Finished Load AppArmor profiles managed internally by snapd. Jan 21 17:47:55 jammy systemd[1]: Starting Snap Daemon... Jan 21 17:47:55 jammy systemd[1]: Condition check resulted in Timer to automatically fetch and run repair assertions being skipped. Jan 21 17:47:55 jammy systemd[1]: snapd.socket: Deactivated successfully. Jan 21 17:47:55 jammy systemd[1]: Closed Socket activation for snappy daemon. Jan 21 17:47:55 jammy systemd[1]: Stopping Socket activation for snappy daemon... Jan 21 17:47:55 jammy systemd[1]: snapd.socket: Socket service snapd.service already active, refusing. Jan 21 17:47:55 jammy systemd[1]: Failed to listen on Socket activation for snappy daemon. Jan 21 17:47:55 jammy systemd[1]: Dependency failed for Snap Daemon. Jan 21 17:47:55 jammy systemd[1]: snapd.service: Job snapd.service/start failed with result 'dependency'. Jan 21 17:47:55 jammy systemd[1]: snapd.service: Triggering OnFailure= dependencies. Jan 21 17:47:55 jammy systemd[1]: Dependency failed for Wait until snapd is fully seeded. Jan 21 17:47:55 jammy systemd[1]: snapd.seeded.service: Job snapd.seeded.service/start failed with result 'dependency'. Jan 21 17:47:55 jammy systemd[1]: Starting Failure handling of the snapd snap... -- 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/1958676 Title: error: too early for operation, device not yet seeded or device model not acknowledged Install failed Status in launchpad-buildd: New Status in init-system-helpers package in Ubuntu: New Status in snapd package in Ubuntu: New Status in systemd package in Ubuntu: New Bug description: https://launchpad.net/~ubuntu-core-service/+snap/core22/+build/1650565 New deb-systemd-invoke added functionality for systemd v250 which ubuntu does not have yet. But it also appears to break postinst calls to deb-systemd-invoke, at least as seen during snap builds in lxd containers operated by launchpad-buildd. I wonder if there is a regression in new code, or new systemd, which may warrant a revert. To manage notifications about this bug go to: https://bugs.launchpad.net/launchpad-buildd/+bug/1958676/+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 1948476] Re: [SRU] Allow target units to fail
This fixes https://github.com/snapcore/core-initrd/issues/33. Tested by building a core20 snap from focal proposed. Before: [6.611137] systemd[1]: systemd 245.4-4ubuntu3.13 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid) [6.628034] systemd[1]: Detected virtualization kvm. [6.629644] systemd[1]: Detected architecture x86-64. [6.706930] systemd[1]: Set hostname to . [7.212069] systemd[1]: emergency.target: Requested dependency OnFailure=reboot.target ignored (target units cannot fail). [7.499630] systemd[1]: Unnecessary job for /dev/vda4 was removed. With the change: [6.160462] systemd[1]: systemd 245.4-4ubuntu3.14 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid) [6.164774] systemd[1]: Detected virtualization kvm. [6.165851] systemd[1]: Detected architecture x86-64. [6.176059] systemd[1]: Set hostname to . [6.521391] systemd[1]: Unnecessary job for /dev/vda4 was removed. ** Bug watch added: github.com/snapcore/core-initrd/issues #33 https://github.com/snapcore/core-initrd/issues/33 ** Tags removed: verification-needed verification-needed-focal ** Tags added: verification-done verification-done-focal -- 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/1948476 Title: [SRU] Allow target units to fail Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Focal: Fix Committed Bug description: [Impact] A systemd regression in focal made it think that target units cannot fail, which produced warnings like: emergency.target: Requested dependency OnFailure=reboot.target ignored (target units cannot fail). So the OnFailure settings are ignored for targets (see https://github.com/snapcore/core-initrd/issues/33 for details). Upstream fixed the issue in v246: https://github.com/systemd/systemd/commit/94d1ddbd7cd15b1073757eb5ae0645c83f0b414c [Test Plan] Test on a UC system and check that the above warnings are not shown anymore. Check that when a target service type fails, the OnFailure setting is used and the mentioned service is run. [Where problems could occur] Issues might happen if some target has an OnFailure setting that was never run in the past because of this bug, and the behavior is not really right because it was never tested. However, OnFailure is not used that much on 20.04 in target services: /lib/systemd $ find . -name \*.target | xargs grep OnFailure /lib/systemd $ /etc/systemd $ find . -name \*.target | xargs grep OnFailure /etc/systemd $ I've seen it only in emergency.target for UC20. [Other Info] None To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1948476/+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 1948476] [NEW] [SRU] Allow target units to fail
Public bug reported: [Impact] A systemd regression in focal made it think that target units cannot fail, which produced warnings like: emergency.target: Requested dependency OnFailure=reboot.target ignored (target units cannot fail). So the OnFailure settings are ignored for targets (see https://github.com/snapcore/core-initrd/issues/33 for details). Upstream fixed the issue in v246: https://github.com/systemd/systemd/commit/94d1ddbd7cd15b1073757eb5ae0645c83f0b414c [Test Plan] Test on a UC system and check that the above warnings are not shown anymore. Check that when a target service type fails, the OnFailure setting is used and the mentioned service is run. [Where problems could occur] Issues might happen if some target has an OnFailure setting that was never run in the past because of this bug, and the behavior is not really right because it was never tested. However, OnFailure is not used that much on 20.04 in target services: /lib/systemd $ find . -name \*.target | xargs grep OnFailure /lib/systemd $ /etc/systemd $ find . -name \*.target | xargs grep OnFailure /etc/systemd $ I've seen it only in emergency.target for UC20. [Other Info] None ** Affects: systemd (Ubuntu) Importance: Undecided Status: New ** Attachment added: "target-units-can-fail.patch" https://bugs.launchpad.net/bugs/1948476/+attachment/5535284/+files/target-units-can-fail.patch -- 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/1948476 Title: [SRU] Allow target units to fail Status in systemd package in Ubuntu: New Bug description: [Impact] A systemd regression in focal made it think that target units cannot fail, which produced warnings like: emergency.target: Requested dependency OnFailure=reboot.target ignored (target units cannot fail). So the OnFailure settings are ignored for targets (see https://github.com/snapcore/core-initrd/issues/33 for details). Upstream fixed the issue in v246: https://github.com/systemd/systemd/commit/94d1ddbd7cd15b1073757eb5ae0645c83f0b414c [Test Plan] Test on a UC system and check that the above warnings are not shown anymore. Check that when a target service type fails, the OnFailure setting is used and the mentioned service is run. [Where problems could occur] Issues might happen if some target has an OnFailure setting that was never run in the past because of this bug, and the behavior is not really right because it was never tested. However, OnFailure is not used that much on 20.04 in target services: /lib/systemd $ find . -name \*.target | xargs grep OnFailure /lib/systemd $ /etc/systemd $ find . -name \*.target | xargs grep OnFailure /etc/systemd $ I've seen it only in emergency.target for UC20. [Other Info] None To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1948476/+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
Re: [Touch-packages] [Bug 1943984] Re: No archive files for static compilation are included in the -dev package
On Wed, Sep 29, 2021 at 1:35 PM Mattia Rizzolo <1943...@bugs.launchpad.net> wrote: > > As a member of the Debian LibreOffice Team, and also as an Ubuntu > Developer, I'm likewise not convinced that starting to build and ship > graphite2's static library is a really useful thing to do. > > I'm personally generically against static libraries, since I regularly see > grief caused by poor tracking of statically-builtand or embedded things. Well, I have seen grief caused by shared libraries pulling too many dependencies or by shared libraries updates that break applications even though in theory the ABI compatibility has been kept. Also, there is actually a trend towards static compilation (golang, rust), so I do not think I'm the only one seeing this. But that is not really relevant. There are valid uses of static libraries, and the developers should have the option to choose between shared and static. The patch does not prevent using shared libraries, it just gives more options to application developers. > > And I don't really buy the need to save space when talking about a 137328 > bytes shared lib (taken from the last build of graphite2 in Sid, that's the > size of the .so). > It feels like you are building some kind to system image that you'd then > flash into some embedded thingy. I don't think there is much value in > saving...what, a dozen kB perhaps? (I haven't tried building the .a, so > happy to get the number). If your system is so constrained in space you're > likely going to need some much more dedicated work to reduce the size of > all components anyway; similarly if you are after the (normally > uncountable) performance improvement of statically linked binaries. Nobody said this was about saving space. libgraphite was being pulled as many other dependencies and I wanted to have all statically compiled instead of some static, some dynamic. Said this, I agree in not carrying a delta between Debian and Ubuntu as this library does not pull additional dependencies and is small, so additional maintenance is not worth the effort. > > On Wed, 29 Sep 2021, 1:06 pm Sebastien Bacher, <1943...@bugs.launchpad.net> > wrote: > > > Debian wontfixed the change so it means we will need to carry a delta at > > the cost of increased workload from our team if we take the change. Not > > saying that we should be we need to weight the cost over time and the > > benefit > > > > -- > > You received this bug notification because you are subscribed to Ubuntu. > > https://bugs.launchpad.net/bugs/1943984 > > > > Title: > > No archive files for static compilation are included in the -dev > > package > > > > Status in graphite2 package in Ubuntu: > > New > > Status in graphite2 package in Debian: > > Won't Fix > > > > Bug description: > > There is no libgraphite2.a file, so it is not possible to compile > > statically against this library. See attached patch to solve this. > > > > To manage notifications about this bug go to: > > > > https://bugs.launchpad.net/ubuntu/+source/graphite2/+bug/1943984/+subscriptions > > > > > > > > -- > You received this bug notification because you are subscribed to the bug > report. > https://bugs.launchpad.net/bugs/1943984 > > Title: > No archive files for static compilation are included in the -dev > package > > Status in graphite2 package in Ubuntu: > New > Status in graphite2 package in Debian: > Won't Fix > > Bug description: > There is no libgraphite2.a file, so it is not possible to compile > statically against this library. See attached patch to solve this. > > To manage notifications about this bug go to: > https://bugs.launchpad.net/ubuntu/+source/graphite2/+bug/1943984/+subscriptions > -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to graphite2 in Ubuntu. https://bugs.launchpad.net/bugs/1943984 Title: No archive files for static compilation are included in the -dev package Status in graphite2 package in Ubuntu: New Status in graphite2 package in Debian: Won't Fix Bug description: There is no libgraphite2.a file, so it is not possible to compile statically against this library. See attached patch to solve this. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/graphite2/+bug/1943984/+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 1943984] Re: No archive files for static compilation are included in the -dev package
Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994757 ** Bug watch added: Debian Bug tracker #994757 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994757 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to graphite2 in Ubuntu. https://bugs.launchpad.net/bugs/1943984 Title: No archive files for static compilation are included in the -dev package Status in graphite2 package in Ubuntu: New Bug description: There is no libgraphite2.a file, so it is not possible to compile statically against this library. See attached patch to solve this. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/graphite2/+bug/1943984/+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 1943859] Re: The development package does not include static libraries
Debian bug report: https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=994752 ** Bug watch added: Debian Bug tracker #994752 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994752 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pango1.0 in Ubuntu. https://bugs.launchpad.net/bugs/1943859 Title: The development package does not include static libraries Status in pango1.0 package in Ubuntu: New Bug description: The development package for pango (libpango1.0-dev) does not include static libraries so it is not possible to link these libraries statically. See attached patch with the fix. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pango1.0/+bug/1943859/+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 1944107] [NEW] No archive files for static compilation are included in the -dev package
Public bug reported: There are no libdrm.a, libdrm_amdgpu.a, etc. files, so it is not possible to compile statically against this library. See attached debdiff to solve this. ** Affects: libdrm (Ubuntu) Importance: Undecided Status: New ** Attachment added: "debdiff.patch" https://bugs.launchpad.net/bugs/1944107/+attachment/5526398/+files/debdiff.patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libdrm in Ubuntu. https://bugs.launchpad.net/bugs/1944107 Title: No archive files for static compilation are included in the -dev package Status in libdrm package in Ubuntu: New Bug description: There are no libdrm.a, libdrm_amdgpu.a, etc. files, so it is not possible to compile statically against this library. See attached debdiff to solve this. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libdrm/+bug/1944107/+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 1943984] [NEW] No archive files for static compilation are included in the -dev package
Public bug reported: There is no libgraphite2.a file, so it is not possible to compile statically against this library. See attached patch to solve this. ** Affects: graphite2 (Ubuntu) Importance: Undecided Status: New ** Patch added: "debdiff.patch" https://bugs.launchpad.net/bugs/1943984/+attachment/5525961/+files/debdiff.patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to graphite2 in Ubuntu. https://bugs.launchpad.net/bugs/1943984 Title: No archive files for static compilation are included in the -dev package Status in graphite2 package in Ubuntu: New Bug description: There is no libgraphite2.a file, so it is not possible to compile statically against this library. See attached patch to solve this. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/graphite2/+bug/1943984/+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 1943859] [NEW] The development package does not include static libraries
Public bug reported: The development package for pango (libpango1.0-dev) does not include static libraries so it is not possible to link these libraries statically. See attached patch with the fix. ** Affects: pango1.0 (Ubuntu) Importance: Undecided Status: New ** Patch added: "debdiff.patch" https://bugs.launchpad.net/bugs/1943859/+attachment/5525735/+files/debdiff.patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pango1.0 in Ubuntu. https://bugs.launchpad.net/bugs/1943859 Title: The development package does not include static libraries Status in pango1.0 package in Ubuntu: New Bug description: The development package for pango (libpango1.0-dev) does not include static libraries so it is not possible to link these libraries statically. See attached patch with the fix. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pango1.0/+bug/1943859/+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 1914062] Re: NetworkManager-wait-online.service in 1.28.0-2ubuntu1 fails to start in LXC
Just FTR, note that the change in NM upstream was needed so the network- manager snap was able to correctly detect if udevd is running. We currently build the snap from the source package + some patches including this one. But, the long term target is to be able to create the snap by simply staging the network-manager debs. So, please keep this in mind and try to put back this change as soon as is feasible again, so we do not need to remove the change in the deb and then put it back in the snap. -- 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/1914062 Title: NetworkManager-wait-online.service in 1.28.0-2ubuntu1 fails to start in LXC Status in lxd package in Ubuntu: Won't Fix Status in network-manager package in Ubuntu: Invalid Status in systemd package in Ubuntu: Triaged Bug description: This regresses systemd's autopkgtest because it expects the system in the container to reach running state, but the system ends up in degraded state due to the service failing. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/amd64/s/systemd/20210112_185712_ff570@/log.gz ... == FAIL: test_no_failed (__main__.ServicesTest) No failed units -- Traceback (most recent call last): File "/tmp/autopkgtest.fFC3Lw/build.xLc/real-tree/debian/tests/boot-and-services", line 68, in test_no_failed self.assertEqual(failed, []) AssertionError: Lists differ: ['● NetworkManager-wait-online.service loa[42 chars]ine'] != [] First list contains 1 additional elements. First extra element 0: '● NetworkManager-wait-online.service loaded failed failed Network Manager Wait Online' + [] - ['● NetworkManager-wait-online.service loaded failed failed Network Manager ' - 'Wait Online'] -- Ran 23 tests in 4.435s ... Reproducible locally by installing n-m from -proposed, then restarting the system in the LXC container. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1914062/+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 1383858] Re: expr-simplify optimization slows click/snap policy compilation
This MR for apparmor_parser: https://gitlab.com/apparmor/apparmor/-/merge_requests/711 helps quite a bit with accelerating the expression optimization, and actually makes it worth enabling them back. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1383858 Title: expr-simplify optimization slows click/snap policy compilation Status in AppArmor: Triaged Status in apparmor package in Ubuntu: Fix Released Status in click-apparmor package in Ubuntu: Fix Released Status in apparmor package in Ubuntu RTM: Fix Released Status in click-apparmor package in Ubuntu RTM: Fix Released Bug description: AppArmor has several optimization options that can be used to help speed up policy compiles for certain types of policy. Currently, we are using expr tree simplification option by default, which has dramatic affects on policy compiles for the evince profile. However, with click profiles not using expr tree simplification (ie, adding the '-O no-expr-simplify' option) can improve click policy generation by 44% (375 vs 210 seconds). On Krillin, the difference is even more substantial: 636 vs 233 seconds (63%). Short term for rtm is to to use '-O no-expr-simplify' when compiling policy in /var/lib/apparmor/profiles but leave /etc/apparmor.d alone. We can do the same with click-apparmor. Note: the fix for bug #1385947 must be included with this fix. The long term fix is to adjust expr tree simplification to be more efficient (at least as fast as without) and drop the '-O no-expr- simplify' option. Justification: apparmor policy recompilation is not expected to happen as part of the normal user experience (see bug #1350598 for a lot of detail) and it is expected to only happen on upgrades from 14.10 to 15.04 or to fix very serious apparmor or apparmor policy bugs. None of these bugs are currently scheduled for OTA. However, *if* we ever need to fix one of these, policy will have to be recompiled. Choices: 1. do nothing for RTM since policy recompiles are expected to be rare, but do apply this change to 15.04. Policy is expected to be recompiled on upgrades to 15.04 and upgrades would use the new option 2. apply this change in OTA. This is problematic because this change alone will trigger a policy recompilation that would not otherwise be needed. Optionally, this change could accompany a severe bug fix Risk: The change consists of a small modification to the apparmor upstart job and a change to the arguments click-apparmor gives to apparmor_parser. The risk assessment is considered low because of the size of the change and the simple test case will immediately indicate if either were applied incorrectly. Test case: 1. run aa-status | wc -l and note the result 2. install the new apparmor and click-apparmor packages and verify there are no errors during installation 3. reboot 4. run aa-status | wc -l and compare to '1' 5. run 'sudo start apparmor' and make sure it finishes in a few seconds If they are the same, it indicates the upstart job is properly loading the profiles generated by click apparmor. While these changes may occur separately, landing them at the same time along with a regenerated custom tarball (for preinstalled policy) will reduce policy recompiles. To manage notifications about this bug go to: https://bugs.launchpad.net/apparmor/+bug/1383858/+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 1914062] Re: NetworkManager-wait-online.service in 1.28.0-2ubuntu1 fails to start in LXC
There is here a change in behavior in lxc/lxd. Running https://paste.ubuntu.com/p/vz7SXcX3K9/: On hirsute lxd container: root@hirsute:~# ./test access errno 13 path is read only: 0 root@hirsute:~# mount | grep 'sysfs on /sys ' sysfs on /sys type sysfs (rw,relatime) On focal lxd container: root@focal:~# ./test path is read only: 1 root@focal:~# mount | grep 'sysfs on /sys ' sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) sysfs on /sys type sysfs (ro,nosuid,nodev,noexec,relatime) (no idea why there are two mounts in focal) According to https://systemd.io/CONTAINER_INTERFACE/ , /sys should be mounted read-only? -- 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/1914062 Title: NetworkManager-wait-online.service in 1.28.0-2ubuntu1 fails to start in LXC Status in network-manager package in Ubuntu: Triaged Bug description: This regresses systemd's autopkgtest because it expects the system in the container to reach running state, but the system ends up in degraded state due to the service failing. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/amd64/s/systemd/20210112_185712_ff570@/log.gz ... == FAIL: test_no_failed (__main__.ServicesTest) No failed units -- Traceback (most recent call last): File "/tmp/autopkgtest.fFC3Lw/build.xLc/real-tree/debian/tests/boot-and-services", line 68, in test_no_failed self.assertEqual(failed, []) AssertionError: Lists differ: ['● NetworkManager-wait-online.service loa[42 chars]ine'] != [] First list contains 1 additional elements. First extra element 0: '● NetworkManager-wait-online.service loaded failed failed Network Manager Wait Online' + [] - ['● NetworkManager-wait-online.service loaded failed failed Network Manager ' - 'Wait Online'] -- Ran 23 tests in 4.435s ... Reproducible locally by installing n-m from -proposed, then restarting the system in the LXC container. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1914062/+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
Re: [Touch-packages] [Bug 1902652] Re: [arm64] [Libre Computer Board AML-S805X-AC] 3D rendering is very slow
This iso won't install. On Tue, Nov 3, 2020 at 8:35 PM Daniel van Vugt <1902...@bugs.launchpad.net> wrote: > Please run these commands: > > ls -l /dev/dri/* > dri.txt > glxinfo > glx.txt > > and attach the resulting text files here. > > ** Changed in: mesa (Ubuntu) >Status: New => Incomplete > > ** Changed in: xf86-video-armsoc (Ubuntu) >Status: New => Incomplete > > -- > You received this bug notification because you are subscribed to the bug > report. > https://bugs.launchpad.net/bugs/1902652 > > Title: > [arm64] [Libre Computer Board AML-S805X-AC] 3D rendering is very slow > > Status in mesa package in Ubuntu: > Incomplete > Status in xf86-video-armsoc package in Ubuntu: > Incomplete > > Bug description: > 3d rendering is very slow, also when surfing the internet, webpages > take a while to render. Internet access is not the problem. > > ProblemType: Bug > DistroRelease: Ubuntu 18.04 > Package: xorg 1:7.7+19ubuntu7.1 > Uname: Linux 4.19.64+ aarch64 > ApportVersion: 2.20.9-0ubuntu7.18 > Architecture: arm64 > 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: XFCE > Date: Tue Nov 3 05:42:00 2020 > DistUpgraded: Fresh install > DistroCodename: bionic > DistroVariant: ubuntu > ExtraDebuggingInterest: Yes, if not too technical > GraphicsCard: > > Lspci: > > ProcEnviron: >LANGUAGE=en >PATH=(custom, no user) >XDG_RUNTIME_DIR= >LANG=en_US.UTF-8 >SHELL=/bin/bash > ProcKernelCmdLine: BOOT_IMAGE=/@/boot/vmlinuz-4.19.64+ > root=UUID=ed29fecf-6335-4caf-989f-7400b169cb82 ro rootflags=subvol=@ > noquiet splash vt.handoff=1 > Renderer: Software > SourcePackage: xorg > Symptom: display > UpgradeStatus: No upgrade log present (probably fresh install) > XorgConf: >Section "Device" > Identifier "Allwinner sun4i DRM driver" > Driver "armsoc" > Option "DRI2" "true" >EndSection > version.compiz: compiz N/A > version.libdrm2: libdrm2 2.4.101-2~18.04.1 > version.libgl1-mesa-dri: libgl1-mesa-dri 20.0.8-0ubuntu1~18.04.1 > version.libgl1-mesa-glx: libgl1-mesa-glx 20.0.8-0ubuntu1~18.04.1 > version.xserver-xorg-core: xserver-xorg-core 2:1.19.6-1ubuntu4.7 > version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A > version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:18.0.1-1 > version.xserver-xorg-video-intel: xserver-xorg-video-intel N/A > version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.15-2 > > To manage notifications about this bug go to: > https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1902652/+subscriptions > -- 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/1902652 Title: [arm64] [Libre Computer Board AML-S805X-AC] 3D rendering is very slow Status in mesa package in Ubuntu: Incomplete Status in xf86-video-armsoc package in Ubuntu: Incomplete Bug description: 3d rendering is very slow, also when surfing the internet, webpages take a while to render. Internet access is not the problem. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: xorg 1:7.7+19ubuntu7.1 Uname: Linux 4.19.64+ aarch64 ApportVersion: 2.20.9-0ubuntu7.18 Architecture: arm64 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: XFCE Date: Tue Nov 3 05:42:00 2020 DistUpgraded: Fresh install DistroCodename: bionic DistroVariant: ubuntu ExtraDebuggingInterest: Yes, if not too technical GraphicsCard: Lspci: ProcEnviron: LANGUAGE=en PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/@/boot/vmlinuz-4.19.64+ root=UUID=ed29fecf-6335-4caf-989f-7400b169cb82 ro rootflags=subvol=@ noquiet splash vt.handoff=1 Renderer: Software SourcePackage: xorg Symptom: display UpgradeStatus: No upgrade log present (probably fresh install) XorgConf: Section "Device" Identifier "Allwinner sun4i DRM driver" Driver "armsoc" Option "DRI2" "true" EndSection version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.101-2~18.04.1 version.libgl1-mesa-dri: libgl1-mesa-dri 20.0.8-0ubuntu1~18.04.1 version.libgl1-mesa-glx: libgl1-mesa-glx 20.0.8-0ubuntu1~18.04.1 version.xserver-xorg-core: xserver-xorg-core 2:1.19.6-1ubuntu4.7 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:18.0.1-1 version.xserver-xorg-video-intel: xserver-xorg-video-intel N/A version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.15-2 To
Re: [Touch-packages] [Bug 1902652] Re: [arm64] [Libre Computer Board AML-S805X-AC] 3D rendering is very slow
there is no ubuntu 20 for my board. On Tue, Nov 3, 2020 at 12:25 AM Daniel van Vugt <1902...@bugs.launchpad.net> wrote: > ** Summary changed: > > - 3d rendering is very slow > + [arm64] [Libre Computer Board AML-S805X-AC] 3D rendering is very slow > > -- > You received this bug notification because you are subscribed to the bug > report. > https://bugs.launchpad.net/bugs/1902652 > > Title: > [arm64] [Libre Computer Board AML-S805X-AC] 3D rendering is very slow > > Status in xorg package in Ubuntu: > New > > Bug description: > 3d rendering is very slow, also when surfing the internet, webpages > take a while to render. Internet access is not the problem. > > ProblemType: Bug > DistroRelease: Ubuntu 18.04 > Package: xorg 1:7.7+19ubuntu7.1 > Uname: Linux 4.19.64+ aarch64 > ApportVersion: 2.20.9-0ubuntu7.18 > Architecture: arm64 > 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: XFCE > Date: Tue Nov 3 05:42:00 2020 > DistUpgraded: Fresh install > DistroCodename: bionic > DistroVariant: ubuntu > ExtraDebuggingInterest: Yes, if not too technical > GraphicsCard: > > Lspci: > > ProcEnviron: >LANGUAGE=en >PATH=(custom, no user) >XDG_RUNTIME_DIR= >LANG=en_US.UTF-8 >SHELL=/bin/bash > ProcKernelCmdLine: BOOT_IMAGE=/@/boot/vmlinuz-4.19.64+ > root=UUID=ed29fecf-6335-4caf-989f-7400b169cb82 ro rootflags=subvol=@ > noquiet splash vt.handoff=1 > Renderer: Software > SourcePackage: xorg > Symptom: display > UpgradeStatus: No upgrade log present (probably fresh install) > XorgConf: >Section "Device" > Identifier "Allwinner sun4i DRM driver" > Driver "armsoc" > Option "DRI2" "true" >EndSection > version.compiz: compiz N/A > version.libdrm2: libdrm2 2.4.101-2~18.04.1 > version.libgl1-mesa-dri: libgl1-mesa-dri 20.0.8-0ubuntu1~18.04.1 > version.libgl1-mesa-glx: libgl1-mesa-glx 20.0.8-0ubuntu1~18.04.1 > version.xserver-xorg-core: xserver-xorg-core 2:1.19.6-1ubuntu4.7 > version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A > version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:18.0.1-1 > version.xserver-xorg-video-intel: xserver-xorg-video-intel N/A > version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.15-2 > > To manage notifications about this bug go to: > https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1902652/+subscriptions > -- 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/1902652 Title: [arm64] [Libre Computer Board AML-S805X-AC] 3D rendering is very slow Status in mesa package in Ubuntu: New Status in xf86-video-armsoc package in Ubuntu: New Bug description: 3d rendering is very slow, also when surfing the internet, webpages take a while to render. Internet access is not the problem. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: xorg 1:7.7+19ubuntu7.1 Uname: Linux 4.19.64+ aarch64 ApportVersion: 2.20.9-0ubuntu7.18 Architecture: arm64 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: XFCE Date: Tue Nov 3 05:42:00 2020 DistUpgraded: Fresh install DistroCodename: bionic DistroVariant: ubuntu ExtraDebuggingInterest: Yes, if not too technical GraphicsCard: Lspci: ProcEnviron: LANGUAGE=en PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/@/boot/vmlinuz-4.19.64+ root=UUID=ed29fecf-6335-4caf-989f-7400b169cb82 ro rootflags=subvol=@ noquiet splash vt.handoff=1 Renderer: Software SourcePackage: xorg Symptom: display UpgradeStatus: No upgrade log present (probably fresh install) XorgConf: Section "Device" Identifier "Allwinner sun4i DRM driver" Driver "armsoc" Option "DRI2" "true" EndSection version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.101-2~18.04.1 version.libgl1-mesa-dri: libgl1-mesa-dri 20.0.8-0ubuntu1~18.04.1 version.libgl1-mesa-glx: libgl1-mesa-glx 20.0.8-0ubuntu1~18.04.1 version.xserver-xorg-core: xserver-xorg-core 2:1.19.6-1ubuntu4.7 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:18.0.1-1 version.xserver-xorg-video-intel: xserver-xorg-video-intel N/A version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.15-2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1902652/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net
[Touch-packages] [Bug 1902652] [NEW] 3d rendering is very slow
Public bug reported: 3d rendering is very slow, also when surfing the internet, webpages take a while to render. Internet access is not the problem. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: xorg 1:7.7+19ubuntu7.1 Uname: Linux 4.19.64+ aarch64 ApportVersion: 2.20.9-0ubuntu7.18 Architecture: arm64 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: XFCE Date: Tue Nov 3 05:42:00 2020 DistUpgraded: Fresh install DistroCodename: bionic DistroVariant: ubuntu ExtraDebuggingInterest: Yes, if not too technical GraphicsCard: Lspci: ProcEnviron: LANGUAGE=en PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/@/boot/vmlinuz-4.19.64+ root=UUID=ed29fecf-6335-4caf-989f-7400b169cb82 ro rootflags=subvol=@ noquiet splash vt.handoff=1 Renderer: Software SourcePackage: xorg Symptom: display UpgradeStatus: No upgrade log present (probably fresh install) XorgConf: Section "Device" Identifier "Allwinner sun4i DRM driver" Driver "armsoc" Option "DRI2" "true" EndSection version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.101-2~18.04.1 version.libgl1-mesa-dri: libgl1-mesa-dri 20.0.8-0ubuntu1~18.04.1 version.libgl1-mesa-glx: libgl1-mesa-glx 20.0.8-0ubuntu1~18.04.1 version.xserver-xorg-core: xserver-xorg-core 2:1.19.6-1ubuntu4.7 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:18.0.1-1 version.xserver-xorg-video-intel: xserver-xorg-video-intel N/A version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.15-2 ** Affects: xorg (Ubuntu) Importance: Undecided Status: New ** Tags: apport-bug arm64 bionic performance 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/1902652 Title: 3d rendering is very slow Status in xorg package in Ubuntu: New Bug description: 3d rendering is very slow, also when surfing the internet, webpages take a while to render. Internet access is not the problem. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: xorg 1:7.7+19ubuntu7.1 Uname: Linux 4.19.64+ aarch64 ApportVersion: 2.20.9-0ubuntu7.18 Architecture: arm64 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: XFCE Date: Tue Nov 3 05:42:00 2020 DistUpgraded: Fresh install DistroCodename: bionic DistroVariant: ubuntu ExtraDebuggingInterest: Yes, if not too technical GraphicsCard: Lspci: ProcEnviron: LANGUAGE=en PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/@/boot/vmlinuz-4.19.64+ root=UUID=ed29fecf-6335-4caf-989f-7400b169cb82 ro rootflags=subvol=@ noquiet splash vt.handoff=1 Renderer: Software SourcePackage: xorg Symptom: display UpgradeStatus: No upgrade log present (probably fresh install) XorgConf: Section "Device" Identifier "Allwinner sun4i DRM driver" Driver "armsoc" Option "DRI2" "true" EndSection version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.101-2~18.04.1 version.libgl1-mesa-dri: libgl1-mesa-dri 20.0.8-0ubuntu1~18.04.1 version.libgl1-mesa-glx: libgl1-mesa-glx 20.0.8-0ubuntu1~18.04.1 version.xserver-xorg-core: xserver-xorg-core 2:1.19.6-1ubuntu4.7 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:18.0.1-1 version.xserver-xorg-video-intel: xserver-xorg-video-intel N/A version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.15-2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1902652/+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 1880968] Re: fixrtc fails due to bad format of input to the date command
I have updated to focal-proposed and checked that now there is no date: invalid date ' Wed Apr 1 17:23:44 2020' output anymore in the console and that fixrtc finishes as expected. $ apt info initramfs-tools Package: initramfs-tools Version: 0.136ubuntu6.2 ... $ cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-5.4.0-1003-bluefield root=LABEL=writable ro console=ttyAMA0 earlycon=pl011,0x0100 fixrtc $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 20.04 LTS Release:20.04 Codename: focal $ uname -a Linux ubuntu 5.4.0-1003-bluefield #4-Ubuntu SMP PREEMPT Fri Jun 12 17:02:31 UTC 2020 aarch64 aarch64 aarch64 GNU/Linux ** Tags removed: verification-needed-focal ** Tags added: verification-done-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/1880968 Title: fixrtc fails due to bad format of input to the date command Status in initramfs-tools package in Ubuntu: Fix Released Status in initramfs-tools source package in Focal: Fix Committed Bug description: The fixrtc script is failing with message: date: invalid date ' Wed Apr 1 17:23:44 2020' when calling the date command. It looks like it does not like the leading spaces for the input date. The date is taken from 'dumpe2fs -h' ouptput, and some clean-up on it happens, but it looks like it is not enough for BusyBox' date command, at least for the version in focal. Backporting this to focal is needed. [Impact] The system date shown on first boot is incorrect, which can be problematic on first boot if at that point in time there is no network connection. If fixrtc works correctly at least we get the date of the last time the rootfs was mounted, which is modern enough to avoid problems with snap assertions validation, etc. [Test case] Boot an image with fixrtc in the kernel command line in a system with no network. snap seeding will fail without the patch. [Regression Potential] Quite small, as the fix is small and targeted. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1880968/+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 1881966] Re: Sporadic network disconnect and re-connect during wifi-scan after upgrading from Ubuntu 18.04 to 20.04
** Also affects: network-manager (Ubuntu) Importance: Undecided Status: New ** No longer affects: snappy-hwe-snaps -- 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/1881966 Title: Sporadic network disconnect and re-connect during wifi-scan after upgrading from Ubuntu 18.04 to 20.04 Status in network-manager package in Ubuntu: New Bug description: Hi, I am getting this highly recurrent problem in which the network inadvertently 'disconnects' for a minute or two and then automatically reconnects. It is so recurrent that it makes browsing and simple tasks almost impossible. My best guess is that this problem is a bug in the new NetworkManager, probably a blocking thread while network-manager performs a routine wifi-scan. I'm using the r88x2bu network driver from the rtl88x2bu-dkms package for WiFi. Here is some information about the network. $ nmcli c NAMEUUID TYPE DEVICE MIT SECURE 8b2ea417-ed65-4e36-a63e-a231344af87a wifi wlx74ee2af4348b virbr0 96dd3046-b80c-4995-8b83-289b0fc363d9 bridgevirbr0 MIT b2c5956d-b071-4d52-98c3-86852563d88e wifi -- Wired connection 1 bfacd008-8aae-3219-b84f-6d5dc9f0d9fa ethernet -- $ nmcli d DEVICE TYPE STATECONNECTION wlx74ee2af4348b wifi connectedMIT SECURE virbr0 bridgeconnectedvirbr0 enp3s0 ethernet unavailable -- lo loopback unmanaged-- virbr0-nic tun unmanaged-- I have attached the system logs, which have the NetworkManager and wpa_supplicant logging level set to DEBUG. I am happy to provide any information necessary to resolve this issue. Thanks To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1881966/+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 1880968] Re: fixrtc fails due to bad format of input to the date command
** Description changed: The fixrtc script is failing with message: date: invalid date ' Wed Apr 1 17:23:44 2020' when calling the date command. It looks like it does not like the leading spaces for the input date. The date is taken from 'dumpe2fs -h' ouptput, and some clean-up on it happens, but it looks like it is not enough for BusyBox' date command, at least for the version in focal. + + [Impact] + + The system date shown on first boot is incorrect, which can be + problematic on first boot if at that point in time there is no network + connection. If fixrtc works correctly at least we get the date of the + last time the rootfs was mounted, which is modern enough to avoid + problems with snap assertions validation, etc. + + [Test case] + + Boot an image with fixrtc in the kernel command line in a system with no + network. snap seeding will fail without the patch. + + [Regression Potential] + + Quite small, as the fix is small and targeted. ** Description changed: The fixrtc script is failing with message: date: invalid date ' Wed Apr 1 17:23:44 2020' when calling the date command. It looks like it does not like the leading spaces for the input date. The date is taken from 'dumpe2fs -h' ouptput, and some clean-up on it happens, but it looks like it is not enough for BusyBox' date command, at least for the version in focal. + + Backporting this to focal is needed. [Impact] The system date shown on first boot is incorrect, which can be problematic on first boot if at that point in time there is no network connection. If fixrtc works correctly at least we get the date of the last time the rootfs was mounted, which is modern enough to avoid problems with snap assertions validation, etc. [Test case] Boot an image with fixrtc in the kernel command line in a system with no network. snap seeding will fail without the patch. [Regression Potential] Quite small, as the fix is small and targeted. -- 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/1880968 Title: fixrtc fails due to bad format of input to the date command Status in initramfs-tools package in Ubuntu: New Bug description: The fixrtc script is failing with message: date: invalid date ' Wed Apr 1 17:23:44 2020' when calling the date command. It looks like it does not like the leading spaces for the input date. The date is taken from 'dumpe2fs -h' ouptput, and some clean-up on it happens, but it looks like it is not enough for BusyBox' date command, at least for the version in focal. Backporting this to focal is needed. [Impact] The system date shown on first boot is incorrect, which can be problematic on first boot if at that point in time there is no network connection. If fixrtc works correctly at least we get the date of the last time the rootfs was mounted, which is modern enough to avoid problems with snap assertions validation, etc. [Test case] Boot an image with fixrtc in the kernel command line in a system with no network. snap seeding will fail without the patch. [Regression Potential] Quite small, as the fix is small and targeted. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1880968/+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 1880968] Re: fixrtc fails due to bad format of input to the date command
See attached debdiff for the fix ** Patch added: "initramfs-tools_debdiff.patch" https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1880968/+attachment/5377425/+files/initramfs-tools_debdiff.patch -- 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/1880968 Title: fixrtc fails due to bad format of input to the date command Status in initramfs-tools package in Ubuntu: New Bug description: The fixrtc script is failing with message: date: invalid date ' Wed Apr 1 17:23:44 2020' when calling the date command. It looks like it does not like the leading spaces for the input date. The date is taken from 'dumpe2fs -h' ouptput, and some clean-up on it happens, but it looks like it is not enough for BusyBox' date command, at least for the version in focal. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1880968/+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 1880968] [NEW] fixrtc fails due to bad format of input to the date command
Public bug reported: The fixrtc script is failing with message: date: invalid date ' Wed Apr 1 17:23:44 2020' when calling the date command. It looks like it does not like the leading spaces for the input date. The date is taken from 'dumpe2fs -h' ouptput, and some clean-up on it happens, but it looks like it is not enough for BusyBox' date command, at least for the version in focal. ** Affects: initramfs-tools (Ubuntu) Importance: Undecided Status: New -- 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/1880968 Title: fixrtc fails due to bad format of input to the date command Status in initramfs-tools package in Ubuntu: New Bug description: The fixrtc script is failing with message: date: invalid date ' Wed Apr 1 17:23:44 2020' when calling the date command. It looks like it does not like the leading spaces for the input date. The date is taken from 'dumpe2fs -h' ouptput, and some clean-up on it happens, but it looks like it is not enough for BusyBox' date command, at least for the version in focal. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1880968/+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 1781597] Re: [SRU] WoWLAN settings are not supported
It looks like the VPN related SRU that was previous to this one was reverted. Could we land this into bionic? -- 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/1781597 Title: [SRU] WoWLAN settings are not supported Status in network-manager package in Ubuntu: Fix Released Status in network-manager source package in Bionic: Triaged Status in network-manager source package in Cosmic: Fix Released Bug description: [Impact] WoWLAN lets us wake up the system by sending wake packets over the wifi connection. This is something requested by some OEM projects, for bionic server images. NM 1.12 supports configuring this feature, so this can be achieved by backporting that support to 1.10 (bionic version). These are the MPs for cosmic and bionic: https://code.launchpad.net/~alfonsosanchezbeato/network-manager/+git/network-manager/+merge/349468 https://code.launchpad.net/~alfonsosanchezbeato/network-manager/+git/network-manager/+merge/349465 [Test Case] First, the wifi card must support WoWLAN. This can be checked by running $ iw phy and searching for "WoWLAN support:" in the output. If it is supported, with the patch applied a connection configured with wowlan can be created with: $ sudo nmcli d wifi connect password $ sudo nmcli c modify 802-11-wireless.wake-on-wlan 8 $ sudo nmcli c down $ sudo nmcli c up We can check with 'iw' that WoWLAN is active for the connection: $ iw phy phy0 wowlan show WoWLAN is enabled: * wake up on magic packet In this case we have configured the connection to wake up the system when a 'magic' packet is received. We can then suspend the system with $ sudo systemctl suspend And we should be able to wake the system from another device with the command $ sudo etherwake -i [Regression Potential] Although the patch is not especially small, it is a backport of changes that have been merged upstream, with very little modifications to make it compile in 1.10. It is also a rather isolated feature that should not conflict with existing ones. The feature will be activated only if configured from the command line, so the risk of regressions should be small. Note also that the patch will be removed as soon as Ubuntu moves to NM 1.12. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1781597/+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 1825194] Re: [SRU] resolvconf is racy, which leads to broken resolv.conf in parallel calls
I have tested on xenial, the problem is solved with the change. ubuntu@xenial:~$ apt policy resolvconf resolvconf: Installed: 1.78ubuntu7 Candidate: 1.78ubuntu7 Version table: *** 1.78ubuntu7 500 500 http://archive.ubuntu.com/ubuntu xenial-proposed/main amd64 Packages 100 /var/lib/dpkg/status 1.78ubuntu6 500 500 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages 1.78ubuntu2 500 500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages ubuntu@xenial:~$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 16.04.6 LTS Release:16.04 ** Tags removed: verification-needed-xenial ** Tags added: verification-done-xenial -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1825194 Title: [SRU] resolvconf is racy, which leads to broken resolv.conf in parallel calls Status in resolvconf package in Ubuntu: Fix Released Status in resolvconf source package in Xenial: Fix Committed Bug description: [Impact] The bug can lead to non-working DNS. This is a critical bug that needs to be fixed in the stable release. The patch fixes the bug by using a file lock via the flock command. [Test case] This script should eventually stop with the current version, thing that should not happen after applying the patch: while true; do printf "\n" | sudo resolvconf -a NetworkManager printf "nameserver 8.8.8.8\n" | sudo resolvconf -a networkd wait printf "nameserver 8.8.8.8\n" | sudo resolvconf -a NetworkManager & printf "\n" | sudo resolvconf -a networkd wait ping -c 1 www.google.com || break done [Regression Potential] The patch is small and what it does is straightforward. It has also been thoroughly tested. However, the effect if something is wrong would be not being able to resolve DNS names, which is disastrous, so it needs to be very well tested for the SRU. [Other Info] It has been found that simultaneous calls to resolvconf can lead to inconsistent content in resolv.conf. For instance, no nameservers while NetworkManager has one in its record (see LP: #1824395): $ cat /run/resolvconf/resolv.conf # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN $ cat /run/resolvconf/interface/NetworkManager nameserver 192.168.1.6 nameserver 192.168.1.2 This can happen easily when calling "netplan apply", which can re- start both networkd and NM. resolvconf is called at that point by the "systemd-networkd-resolvconf-update.service" service, and also directly by NetworkManager, which leads to the situation described above. This is not surprising as there is nothing preventing different instances of resolvconf to access the same files. This sort of situation can be reproduced by running in a loop commands like: $ printf "\n" | sudo resolvconf -a NetworkManager & printf "\n" | sudo resolvconf -a networkd $ printf "nameserver 80.58.61.250\n" | sudo resolvconf -a NetworkManager & printf "\n" | sudo resolvconf -a networkd Eventually, this leads to a resolv.conf that is not consistent with the last run command. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1825194/+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 1825194] Re: [SRU] resolvconf is racy, which leads to broken resolv.conf in parallel calls
Thanks Robie, good catch. Please find attached the new patch for xenial: I have moved a bit below the call to flock to ensure the dir was created - the lines now out of the lock do not change any files so that should not be a problem. ** Patch added: "xenial-debdiff.patch" https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1825194/+attachment/5261798/+files/xenial-debdiff.patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1825194 Title: [SRU] resolvconf is racy, which leads to broken resolv.conf in parallel calls Status in resolvconf package in Ubuntu: Fix Released Status in resolvconf source package in Xenial: In Progress Bug description: [Impact] The bug can lead to non-working DNS. This is a critical bug that needs to be fixed in the stable release. The patch fixes the bug by using a file lock via the flock command. [Test case] This script should eventually stop with the current version, thing that should not happen after applying the patch: while true; do printf "\n" | sudo resolvconf -a NetworkManager printf "nameserver 8.8.8.8\n" | sudo resolvconf -a networkd wait printf "nameserver 8.8.8.8\n" | sudo resolvconf -a NetworkManager & printf "\n" | sudo resolvconf -a networkd wait ping -c 1 www.google.com || break done [Regression Potential] The patch is small and what it does is straightforward. It has also been thoroughly tested. However, the effect if something is wrong would be not being able to resolve DNS names, which is disastrous, so it needs to be very well tested for the SRU. [Other Info] It has been found that simultaneous calls to resolvconf can lead to inconsistent content in resolv.conf. For instance, no nameservers while NetworkManager has one in its record (see LP: #1824395): $ cat /run/resolvconf/resolv.conf # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN $ cat /run/resolvconf/interface/NetworkManager nameserver 192.168.1.6 nameserver 192.168.1.2 This can happen easily when calling "netplan apply", which can re- start both networkd and NM. resolvconf is called at that point by the "systemd-networkd-resolvconf-update.service" service, and also directly by NetworkManager, which leads to the situation described above. This is not surprising as there is nothing preventing different instances of resolvconf to access the same files. This sort of situation can be reproduced by running in a loop commands like: $ printf "\n" | sudo resolvconf -a NetworkManager & printf "\n" | sudo resolvconf -a networkd $ printf "nameserver 80.58.61.250\n" | sudo resolvconf -a NetworkManager & printf "\n" | sudo resolvconf -a networkd Eventually, this leads to a resolv.conf that is not consistent with the last run command. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1825194/+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 1825194] Re: resolvconf is racy, which leads to broken resolv.conf in parallel calls
Patch for xenial. ** Description changed: + [Impact] + + The bug can lead to non-working DNS. This is a critical bug that needs + to be fixed in the stable release. + + The patch fixes the bug by using a file lock via the flock command. + + [Test case] + + This script should eventually stop with the current version, thing that + should not happen after applying the patch: + + while true; do + printf "\n" | sudo resolvconf -a NetworkManager + printf "nameserver 8.8.8.8\n" | sudo resolvconf -a networkd + wait + printf "nameserver 8.8.8.8\n" | + sudo resolvconf -a NetworkManager & + printf "\n" | sudo resolvconf -a networkd + wait + ping -c 1 www.google.com || break + done + + [Regression Potential] + + The patch is small and what it does is straightforward. It has also been + thoroughly tested. However, the effect if something is wrong would be + not being able to resolve DNS names, which is disastrous, so it needs to + be very well tested for the SRU. + + [Other Info] + It has been found that simultaneous calls to resolvconf can lead to inconsistent content in resolv.conf. For instance, no nameservers while NetworkManager has one in its record (see LP: #1824395): $ cat /run/resolvconf/resolv.conf # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN $ cat /run/resolvconf/interface/NetworkManager nameserver 192.168.1.6 nameserver 192.168.1.2 This can happen easily when calling "netplan apply", which can re-start both networkd and NM. resolvconf is called at that point by the "systemd-networkd-resolvconf-update.service" service, and also directly by NetworkManager, which leads to the situation described above. This is not surprising as there is nothing preventing different instances of resolvconf to access the same files. This sort of situation can be reproduced by running in a loop commands like: $ printf "\n" | sudo resolvconf -a NetworkManager & printf "\n" | sudo resolvconf -a networkd $ printf "nameserver 80.58.61.250\n" | sudo resolvconf -a NetworkManager & printf "\n" | sudo resolvconf -a networkd Eventually, this leads to a resolv.conf that is not consistent with the last run command. ** Patch added: "xenial-debdiff.patch" https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1825194/+attachment/5257832/+files/xenial-debdiff.patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1825194 Title: [SRU] resolvconf is racy, which leads to broken resolv.conf in parallel calls Status in resolvconf package in Ubuntu: Fix Released Status in resolvconf source package in Xenial: New Bug description: [Impact] The bug can lead to non-working DNS. This is a critical bug that needs to be fixed in the stable release. The patch fixes the bug by using a file lock via the flock command. [Test case] This script should eventually stop with the current version, thing that should not happen after applying the patch: while true; do printf "\n" | sudo resolvconf -a NetworkManager printf "nameserver 8.8.8.8\n" | sudo resolvconf -a networkd wait printf "nameserver 8.8.8.8\n" | sudo resolvconf -a NetworkManager & printf "\n" | sudo resolvconf -a networkd wait ping -c 1 www.google.com || break done [Regression Potential] The patch is small and what it does is straightforward. It has also been thoroughly tested. However, the effect if something is wrong would be not being able to resolve DNS names, which is disastrous, so it needs to be very well tested for the SRU. [Other Info] It has been found that simultaneous calls to resolvconf can lead to inconsistent content in resolv.conf. For instance, no nameservers while NetworkManager has one in its record (see LP: #1824395): $ cat /run/resolvconf/resolv.conf # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN $ cat /run/resolvconf/interface/NetworkManager nameserver 192.168.1.6 nameserver 192.168.1.2 This can happen easily when calling "netplan apply", which can re- start both networkd and NM. resolvconf is called at that point by the "systemd-networkd-resolvconf-update.service" service, and also directly by NetworkManager, which leads to the situation described above. This is not surprising as there is nothing preventing different instances of resolvconf to access the same files. This sort of situation can be reproduced by running in a loop commands like: $ printf "\n" | sudo resolvconf -a NetworkManager & printf "\n" | sudo resolvconf -a networkd $ printf "nameserver 80.58.61.250\n" | sudo resolvconf -a NetworkManager &
[Touch-packages] [Bug 1825194] Re: resolvconf is racy, which leads to broken resolv.conf in parallel calls
@vorlon, @tsimonq2, patch for xenial attached, and description changed for SRU. Sponsors teamm re-subscribed. ** Summary changed: - resolvconf is racy, which leads to broken resolv.conf in parallel calls + [SRU] resolvconf is racy, which leads to broken resolv.conf in parallel calls -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1825194 Title: [SRU] resolvconf is racy, which leads to broken resolv.conf in parallel calls Status in resolvconf package in Ubuntu: Fix Released Status in resolvconf source package in Xenial: New Bug description: [Impact] The bug can lead to non-working DNS. This is a critical bug that needs to be fixed in the stable release. The patch fixes the bug by using a file lock via the flock command. [Test case] This script should eventually stop with the current version, thing that should not happen after applying the patch: while true; do printf "\n" | sudo resolvconf -a NetworkManager printf "nameserver 8.8.8.8\n" | sudo resolvconf -a networkd wait printf "nameserver 8.8.8.8\n" | sudo resolvconf -a NetworkManager & printf "\n" | sudo resolvconf -a networkd wait ping -c 1 www.google.com || break done [Regression Potential] The patch is small and what it does is straightforward. It has also been thoroughly tested. However, the effect if something is wrong would be not being able to resolve DNS names, which is disastrous, so it needs to be very well tested for the SRU. [Other Info] It has been found that simultaneous calls to resolvconf can lead to inconsistent content in resolv.conf. For instance, no nameservers while NetworkManager has one in its record (see LP: #1824395): $ cat /run/resolvconf/resolv.conf # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN $ cat /run/resolvconf/interface/NetworkManager nameserver 192.168.1.6 nameserver 192.168.1.2 This can happen easily when calling "netplan apply", which can re- start both networkd and NM. resolvconf is called at that point by the "systemd-networkd-resolvconf-update.service" service, and also directly by NetworkManager, which leads to the situation described above. This is not surprising as there is nothing preventing different instances of resolvconf to access the same files. This sort of situation can be reproduced by running in a loop commands like: $ printf "\n" | sudo resolvconf -a NetworkManager & printf "\n" | sudo resolvconf -a networkd $ printf "nameserver 80.58.61.250\n" | sudo resolvconf -a NetworkManager & printf "\n" | sudo resolvconf -a networkd Eventually, this leads to a resolv.conf that is not consistent with the last run command. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1825194/+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 1781597] Re: [SRU] WoWLAN settings are not supported
I would very much like the SRU to happen. -- 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/1781597 Title: [SRU] WoWLAN settings are not supported Status in network-manager package in Ubuntu: Fix Released Status in network-manager source package in Bionic: Triaged Status in network-manager source package in Cosmic: Fix Released Bug description: [Impact] WoWLAN lets us wake up the system by sending wake packets over the wifi connection. This is something requested by some OEM projects, for bionic server images. NM 1.12 supports configuring this feature, so this can be achieved by backporting that support to 1.10 (bionic version). These are the MPs for cosmic and bionic: https://code.launchpad.net/~alfonsosanchezbeato/network-manager/+git/network-manager/+merge/349468 https://code.launchpad.net/~alfonsosanchezbeato/network-manager/+git/network-manager/+merge/349465 [Test Case] First, the wifi card must support WoWLAN. This can be checked by running $ iw phy and searching for "WoWLAN support:" in the output. If it is supported, with the patch applied a connection configured with wowlan can be created with: $ sudo nmcli d wifi connect password $ sudo nmcli c modify 802-11-wireless.wake-on-wlan 8 $ sudo nmcli c down $ sudo nmcli c up We can check with 'iw' that WoWLAN is active for the connection: $ iw phy phy0 wowlan show WoWLAN is enabled: * wake up on magic packet In this case we have configured the connection to wake up the system when a 'magic' packet is received. We can then suspend the system with $ sudo systemctl suspend And we should be able to wake the system from another device with the command $ sudo etherwake -i [Regression Potential] Although the patch is not especially small, it is a backport of changes that have been merged upstream, with very little modifications to make it compile in 1.10. It is also a rather isolated feature that should not conflict with existing ones. The feature will be activated only if configured from the command line, so the risk of regressions should be small. Note also that the patch will be removed as soon as Ubuntu moves to NM 1.12. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1781597/+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 1825194] Re: resolvconf is racy, which leads to broken resolv.conf in parallel calls
** Patch added: "debdiff.patch" https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1825194/+attachment/5256569/+files/debdiff.patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1825194 Title: resolvconf is racy, which leads to broken resolv.conf in parallel calls Status in resolvconf package in Ubuntu: New Bug description: It has been found that simultaneous calls to resolvconf can lead to inconsistent content in resolv.conf. For instance, no nameservers while NetworkManager has one in its record (see LP: #1824395): $ cat /run/resolvconf/resolv.conf # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN $ cat /run/resolvconf/interface/NetworkManager nameserver 192.168.1.6 nameserver 192.168.1.2 This can happen easily when calling "netplan apply", which can re- start both networkd and NM. resolvconf is called at that point by the "systemd-networkd-resolvconf-update.service" service, and also directly by NetworkManager, which leads to the situation described above. This is not surprising as there is nothing preventing different instances of resolvconf to access the same files. This sort of situation can be reproduced by running in a loop commands like: $ printf "\n" | sudo resolvconf -a NetworkManager & printf "\n" | sudo resolvconf -a networkd $ printf "nameserver 80.58.61.250\n" | sudo resolvconf -a NetworkManager & printf "\n" | sudo resolvconf -a networkd Eventually, this leads to a resolv.conf that is not consistent with the last run command. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1825194/+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 1825194] [NEW] resolvconf is racy, which leads to broken resolv.conf in parallel calls
Public bug reported: It has been found that simultaneous calls to resolvconf can lead to inconsistent content in resolv.conf. For instance, no nameservers while NetworkManager has one in its record (see LP: #1824395): $ cat /run/resolvconf/resolv.conf # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN $ cat /run/resolvconf/interface/NetworkManager nameserver 192.168.1.6 nameserver 192.168.1.2 This can happen easily when calling "netplan apply", which can re-start both networkd and NM. resolvconf is called at that point by the "systemd-networkd-resolvconf-update.service" service, and also directly by NetworkManager, which leads to the situation described above. This is not surprising as there is nothing preventing different instances of resolvconf to access the same files. This sort of situation can be reproduced by running in a loop commands like: $ printf "\n" | sudo resolvconf -a NetworkManager & printf "\n" | sudo resolvconf -a networkd $ printf "nameserver 80.58.61.250\n" | sudo resolvconf -a NetworkManager & printf "\n" | sudo resolvconf -a networkd Eventually, this leads to a resolv.conf that is not consistent with the last run command. ** Affects: resolvconf (Ubuntu) Importance: Undecided Status: New ** Description changed: It has been found that simultaneous calls to resolvconf can lead to inconsistent content in resolv.conf. For instance, no nameservers while NetworkManager has one in its record (see LP: #1824395): $ cat /run/resolvconf/resolv.conf # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN $ cat /run/resolvconf/interface/NetworkManager nameserver 192.168.1.6 nameserver 192.168.1.2 - This can happen easily when calling "netplan generate", which can re- - start both networkd and NM. resolvconf is called at that point by the + This can happen easily when calling "netplan apply", which can re-start + both networkd and NM. resolvconf is called at that point by the "systemd-networkd-resolvconf-update.service" service, and also directly by NetworkManager, which leads to the situation described above. This is not surprising as there is nothing preventing different instances of resolvconf to access the same files. This sort of situation can be reproduced by running in a loop commands like: $ printf "\n" | sudo resolvconf -a NetworkManager & printf "\n" | sudo resolvconf -a networkd $ printf "nameserver 80.58.61.250\n" | sudo resolvconf -a NetworkManager & printf "\n" | sudo resolvconf -a networkd Eventually, this leads to a resolv.conf that is not consistent with the last run command. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1825194 Title: resolvconf is racy, which leads to broken resolv.conf in parallel calls Status in resolvconf package in Ubuntu: New Bug description: It has been found that simultaneous calls to resolvconf can lead to inconsistent content in resolv.conf. For instance, no nameservers while NetworkManager has one in its record (see LP: #1824395): $ cat /run/resolvconf/resolv.conf # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN $ cat /run/resolvconf/interface/NetworkManager nameserver 192.168.1.6 nameserver 192.168.1.2 This can happen easily when calling "netplan apply", which can re- start both networkd and NM. resolvconf is called at that point by the "systemd-networkd-resolvconf-update.service" service, and also directly by NetworkManager, which leads to the situation described above. This is not surprising as there is nothing preventing different instances of resolvconf to access the same files. This sort of situation can be reproduced by running in a loop commands like: $ printf "\n" | sudo resolvconf -a NetworkManager & printf "\n" | sudo resolvconf -a networkd $ printf "nameserver 80.58.61.250\n" | sudo resolvconf -a NetworkManager & printf "\n" | sudo resolvconf -a networkd Eventually, this leads to a resolv.conf that is not consistent with the last run command. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1825194/+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 1812507] Re: Typo in description of snap
Changed now, thanks! ** Changed in: network-manager (Ubuntu) Status: New => Fix Released ** Changed in: network-manager (Ubuntu) Assignee: (unassigned) => Alfonso Sanchez-Beato (alfonsosanchezbeato) -- 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/1812507 Title: Typo in description of snap Status in network-manager package in Ubuntu: Fix Released Bug description: https://snapcraft.io/network-manager lists the description for NetworkManager as “Network management based on NeworkManager” (sic). NeworkManager should be NetworkManager. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1812507/+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 1781597] Re: [SRU] WoWLAN settings are not supported
@sil2100, where can I take a look at those? -- 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/1781597 Title: [SRU] WoWLAN settings are not supported Status in network-manager package in Ubuntu: Fix Released Status in network-manager source package in Bionic: Triaged Status in network-manager source package in Cosmic: Fix Committed Bug description: [Impact] WoWLAN lets us wake up the system by sending wake packets over the wifi connection. This is something requested by some OEM projects, for bionic server images. NM 1.12 supports configuring this feature, so this can be achieved by backporting that support to 1.10 (bionic version). These are the MPs for cosmic and bionic: https://code.launchpad.net/~alfonsosanchezbeato/network-manager/+git/network-manager/+merge/349468 https://code.launchpad.net/~alfonsosanchezbeato/network-manager/+git/network-manager/+merge/349465 [Test Case] First, the wifi card must support WoWLAN. This can be checked by running $ iw phy and searching for "WoWLAN support:" in the output. If it is supported, with the patch applied a connection configured with wowlan can be created with: $ sudo nmcli d wifi connect password $ sudo nmcli c modify 802-11-wireless.wake-on-wlan 8 $ sudo nmcli c down $ sudo nmcli c up We can check with 'iw' that WoWLAN is active for the connection: $ iw phy phy0 wowlan show WoWLAN is enabled: * wake up on magic packet In this case we have configured the connection to wake up the system when a 'magic' packet is received. We can then suspend the system with $ sudo systemctl suspend And we should be able to wake the system from another device with the command $ sudo etherwake -i [Regression Potential] Although the patch is not especially small, it is a backport of changes that have been merged upstream, with very little modifications to make it compile in 1.10. It is also a rather isolated feature that should not conflict with existing ones. The feature will be activated only if configured from the command line, so the risk of regressions should be small. Note also that the patch will be removed as soon as Ubuntu moves to NM 1.12. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1781597/+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 1781597] Re: [SRU] WoWLAN settings are not supported
Verified on cosmic, using network-manager 1.12.4-1ubuntu1.2: $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 18.10 Release:18.10 Codename: cosmic $ apt policy network-manager network-manager: Installed: 1.12.4-1ubuntu1.2 Candidate: 1.12.4-1ubuntu1.2 Version table: *** 1.12.4-1ubuntu1.2 500 500 http://es.archive.ubuntu.com/ubuntu cosmic-proposed/main amd64 Packages 100 /var/lib/dpkg/status 1.12.4-1ubuntu1.1 500 500 http://es.archive.ubuntu.com/ubuntu cosmic-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu cosmic-security/main amd64 Packages 1.12.4-1ubuntu1 500 500 http://es.archive.ubuntu.com/ubuntu cosmic/main amd64 Packages ** Tags removed: verification-needed-cosmic ** Tags added: verification-done-cosmic -- 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/1781597 Title: [SRU] WoWLAN settings are not supported Status in network-manager package in Ubuntu: Fix Released Status in network-manager source package in Bionic: Triaged Status in network-manager source package in Cosmic: Fix Committed Bug description: [Impact] WoWLAN lets us wake up the system by sending wake packets over the wifi connection. This is something requested by some OEM projects, for bionic server images. NM 1.12 supports configuring this feature, so this can be achieved by backporting that support to 1.10 (bionic version). These are the MPs for cosmic and bionic: https://code.launchpad.net/~alfonsosanchezbeato/network-manager/+git/network-manager/+merge/349468 https://code.launchpad.net/~alfonsosanchezbeato/network-manager/+git/network-manager/+merge/349465 [Test Case] First, the wifi card must support WoWLAN. This can be checked by running $ iw phy and searching for "WoWLAN support:" in the output. If it is supported, with the patch applied a connection configured with wowlan can be created with: $ sudo nmcli d wifi connect password $ sudo nmcli c modify 802-11-wireless.wake-on-wlan 8 $ sudo nmcli c down $ sudo nmcli c up We can check with 'iw' that WoWLAN is active for the connection: $ iw phy phy0 wowlan show WoWLAN is enabled: * wake up on magic packet In this case we have configured the connection to wake up the system when a 'magic' packet is received. We can then suspend the system with $ sudo systemctl suspend And we should be able to wake the system from another device with the command $ sudo etherwake -i [Regression Potential] Although the patch is not especially small, it is a backport of changes that have been merged upstream, with very little modifications to make it compile in 1.10. It is also a rather isolated feature that should not conflict with existing ones. The feature will be activated only if configured from the command line, so the risk of regressions should be small. Note also that the patch will be removed as soon as Ubuntu moves to NM 1.12. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1781597/+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 1645232] Re: e2fsprogs - could not preserve ACL permissions : The getxattr() returns with (EINVAL)
@tytso awesome, thanks for pointing out. -- 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/1645232 Title: e2fsprogs - could not preserve ACL permissions : The getxattr() returns with (EINVAL) Status in e2fsprogs package in Ubuntu: Fix Released Bug description: The original installed e2fsprogs did not support mke2fs -d /directory " option . So , git cloned from e2fsprogs packages from repository and installed it and followed below steps to reproduce this : 1. set the ACL rules as below to one of the binary : $ setfacl -m u:vipatil:r-- rootfs/usr/bin/helloworld $ getfacl rootfs/usr/bin/helloworld # file: rootfs/usr/bin/helloworld # owner: shkumar # group: hardev user::rwx user:vipatil:r-- group::--- mask::r-- other::--- 2. $ dd if=/dev/zero of=test.ext4 bs=1M count=60 3. $ mke2fs -t ext4 test.ext4 -d rootfs/ mke2fs 1.43.3 (04-Sep-2016) Discarding device blocks: done Creating filesystem with 61440 1k blocks and 15360 inodes Filesystem UUID: 495713b3-5f1f-427a-8359-a736dfb2ece9 Superblock backups stored on blocks: 8193, 24577, 40961, 57345 Allocating group tables: done Writing inode tables: done Creating journal (4096 blocks): done Copying files into the device: done Writing superblocks and filesystem accounting information: done 4. sudo mount -o loop,acl,user_xattr,rw,sync test.ext4 mountpoint 5.@/mountpoint$ getfacl usr/bin/helloworld getfacl: usr/bin/helloworld: Invalid argument To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1645232/+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 1645232] Re: e2fsprogs - could not preserve ACL permissions : The getxattr() returns with (EINVAL)
I am getting this in bionic, with e2fsprogs 1.44.1-1. In fact, I have tried with e2fsprogs upstream and happens as well. I have simply followed the instructions in the bug description to reproduce. So, somewhat, although part of the patch was included upstream, it did not fix completely the issue. -- 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/1645232 Title: e2fsprogs - could not preserve ACL permissions : The getxattr() returns with (EINVAL) Status in e2fsprogs package in Ubuntu: Fix Released Bug description: The original installed e2fsprogs did not support mke2fs -d /directory " option . So , git cloned from e2fsprogs packages from repository and installed it and followed below steps to reproduce this : 1. set the ACL rules as below to one of the binary : $ setfacl -m u:vipatil:r-- rootfs/usr/bin/helloworld $ getfacl rootfs/usr/bin/helloworld # file: rootfs/usr/bin/helloworld # owner: shkumar # group: hardev user::rwx user:vipatil:r-- group::--- mask::r-- other::--- 2. $ dd if=/dev/zero of=test.ext4 bs=1M count=60 3. $ mke2fs -t ext4 test.ext4 -d rootfs/ mke2fs 1.43.3 (04-Sep-2016) Discarding device blocks: done Creating filesystem with 61440 1k blocks and 15360 inodes Filesystem UUID: 495713b3-5f1f-427a-8359-a736dfb2ece9 Superblock backups stored on blocks: 8193, 24577, 40961, 57345 Allocating group tables: done Writing inode tables: done Creating journal (4096 blocks): done Copying files into the device: done Writing superblocks and filesystem accounting information: done 4. sudo mount -o loop,acl,user_xattr,rw,sync test.ext4 mountpoint 5.@/mountpoint$ getfacl usr/bin/helloworld getfacl: usr/bin/helloworld: Invalid argument To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1645232/+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 1780606] Re: NetworkManager not able to manage WWAN devices in 18.04 server
** Merge proposal unlinked: https://code.launchpad.net/~awe/network-manager/+git/ubuntu/+merge/352119 -- 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/1780606 Title: NetworkManager not able to manage WWAN devices in 18.04 server Status in network-manager package in Ubuntu: Triaged Bug description: Installed a 18.04 server image, and installed NetworkManager. NetworkManager comes with a "/usr/lib/NetworkManager/conf.d/10 -globally-managed-devices.conf" file where it speciefies that all devices are by default unmanaged except for types "wifi" and "wwan". Now, the problem is that the filter should apply to "gsm" or "cdma" types, not "wwan". E.g.: [keyfile] unmanaged-devices=*,except:type:wifi,except:type:gsm,except:type:cdma Before the change: $ nmcli d DEVICETYPE STATE CONNECTION wlan0 wifi connected Bumbu eth0 ethernet unmanaged -- cdc-wdm0 gsm unmanaged -- loloopback unmanaged -- After the change: $ nmcli d DEVICETYPE STATE CONNECTION wlan0 wifi connected Bumbu cdc-wdm0 gsm connected cell eth0 ethernet unmanaged -- loloopback unmanaged -- To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1780606/+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 1692494] Re: klibc does not support reboot arguments
The patch has been included in Debian klibc package 2.0.4-12: http://metadata.ftp- master.debian.org/changelogs/main/k/klibc/klibc_2.0.4-12_changelog -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to klibc in Ubuntu. https://bugs.launchpad.net/bugs/1692494 Title: klibc does not support reboot arguments Status in klibc package in Ubuntu: New Status in klibc source package in Xenial: New Status in klibc package in Debian: Confirmed Bug description: ... so we cannot do things like "reboot recovery" in devices that follow the Android partitions conventions. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1692494/+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 1781597] Re: [SRU] WoWLAN settings are not supported
** Summary changed: - WoWLAN settings are not supported + [SRU] WoWLAN settings are not supported -- 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/1781597 Title: [SRU] WoWLAN settings are not supported Status in network-manager package in Ubuntu: New Bug description: [Impact] WoWLAN lets us wake up the system by sending wake packages over the wifi connection. This is something requested by some OEM projects, for bionic server images. NM 1.12 supports configuring this feature, so this can be achieved by backporting that support to 1.10 (bionic version). These are the MPs for cosmic and bionic: https://code.launchpad.net/~alfonsosanchezbeato/network-manager/+git/network-manager/+merge/349468 https://code.launchpad.net/~alfonsosanchezbeato/network-manager/+git/network-manager/+merge/349465 [Test Case] First, the wifi card must support WoWLAN. This can be checked by running $ iw phy and searching for "WoWLAN support:" in the output. If it is supported, with the patch applied a connection configured with wowlan can be created with: $ sudo nmcli d wifi connect password $ sudo nmcli c modify 802-11-wireless.wake-on-wlan 8 $ sudo nmcli c down $ sudo nmcli c up We can check with 'iw' that WoWLAN is active for the connection: $ iw phy phy0 wowlan show WoWLAN is enabled: * wake up on magic packet In this case we have configured the connection to wake up the system when a 'magic' packet is received. We can then suspend the system with $ sudo systemctl suspend And we should be able to wake the system from another device with the command $ sudo etherwake -i [Regression Potential] Although the patch is not especially small, it is a backport of changes that have been merged upstream, with very little modifications to make it compile in 1.10. It is also a rather isolated feature that should not conflict with existing ones. The feature will be activated only if configured from the command line, so the risk of regressions should be small. Note also that the patch will be removed as soon as Ubuntu moves to NM 1.12. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1781597/+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 1781597] [NEW] WoWLAN settings are not supported
Public bug reported: [Impact] WoWLAN lets us wake up the system by sending wake packages over the wifi connection. This is something requested by some OEM projects, for bionic server images. NM 1.12 supports configuring this feature, so this can be achieved by backporting that support to 1.10 (bionic version). These are the MPs for cosmic and bionic: https://code.launchpad.net/~alfonsosanchezbeato/network-manager/+git/network-manager/+merge/349468 https://code.launchpad.net/~alfonsosanchezbeato/network-manager/+git/network-manager/+merge/349465 [Test Case] First, the wifi card must support WoWLAN. This can be checked by running $ iw phy and searching for "WoWLAN support:" in the output. If it is supported, with the patch applied a connection configured with wowlan can be created with: $ sudo nmcli d wifi connect password $ sudo nmcli c modify 802-11-wireless.wake-on-wlan 8 $ sudo nmcli c down $ sudo nmcli c up We can check with 'iw' that WoWLAN is active for the connection: $ iw phy phy0 wowlan show WoWLAN is enabled: * wake up on magic packet In this case we have configured the connection to wake up the system when a 'magic' packet is received. We can then suspend the system with $ sudo systemctl suspend And we should be able to wake the system from another device with the command $ sudo etherwake -i [Regression Potential] Although the patch is not especially small, it is a backport of changes that have been merged upstream, with very little modifications to make it compile in 1.10. It is also a rather isolated feature that should not conflict with existing ones. The feature will be activated only if configured from the command line, so the risk of regressions should be small. Note also that the patch will be removed as soon as Ubuntu moves to NM 1.12. ** Affects: network-manager (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1781597 Title: WoWLAN settings are not supported Status in network-manager package in Ubuntu: New Bug description: [Impact] WoWLAN lets us wake up the system by sending wake packages over the wifi connection. This is something requested by some OEM projects, for bionic server images. NM 1.12 supports configuring this feature, so this can be achieved by backporting that support to 1.10 (bionic version). These are the MPs for cosmic and bionic: https://code.launchpad.net/~alfonsosanchezbeato/network-manager/+git/network-manager/+merge/349468 https://code.launchpad.net/~alfonsosanchezbeato/network-manager/+git/network-manager/+merge/349465 [Test Case] First, the wifi card must support WoWLAN. This can be checked by running $ iw phy and searching for "WoWLAN support:" in the output. If it is supported, with the patch applied a connection configured with wowlan can be created with: $ sudo nmcli d wifi connect password $ sudo nmcli c modify 802-11-wireless.wake-on-wlan 8 $ sudo nmcli c down $ sudo nmcli c up We can check with 'iw' that WoWLAN is active for the connection: $ iw phy phy0 wowlan show WoWLAN is enabled: * wake up on magic packet In this case we have configured the connection to wake up the system when a 'magic' packet is received. We can then suspend the system with $ sudo systemctl suspend And we should be able to wake the system from another device with the command $ sudo etherwake -i [Regression Potential] Although the patch is not especially small, it is a backport of changes that have been merged upstream, with very little modifications to make it compile in 1.10. It is also a rather isolated feature that should not conflict with existing ones. The feature will be activated only if configured from the command line, so the risk of regressions should be small. Note also that the patch will be removed as soon as Ubuntu moves to NM 1.12. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1781597/+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 1779708] [NEW] My screen got deconfigurtated
Public bug reported: WHen I get into google or some other programs, my screen fails, and don't work any longer. It became a screen like that of the Tv shows when there is not signal, and it just doesn't respond any more. I can't do anything, and I must restart the PC, the screen doesn't allow me to do any other operation. I previously have the 16.04 LTS ubuntu with unity and conpiz, and I tried to actualize it to 18.04 LTS version, the bug began. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: xorg 1:7.7+19ubuntu7 ProcVersionSignature: Ubuntu 4.15.0-24.26-generic 4.15.18 Uname: Linux 4.15.0-24-generic x86_64 .tmp.unity_support_test.0: ApportVersion: 2.20.9-0ubuntu7.2 Architecture: amd64 CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins' CompositorRunning: None Date: Mon Jul 2 10:07:31 2018 DistUpgraded: Fresh install DistroCodename: bionic DistroVariant: ubuntu GraphicsCard: NVIDIA Corporation C61 [GeForce 7025 / nForce 630a] [10de:03d6] (rev a2) (prog-if 00 [VGA controller]) Subsystem: Gigabyte Technology Co., Ltd C61 [GeForce 7025 / nForce 630a] [1458:d000] InstallationDate: Installed on 2015-04-16 (1172 days ago) InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417) MachineType: Gigabyte Technology Co., Ltd. M68MT-S2 ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-24-generic root=UUID=78b08060-d316-4ee6-92e7-4f94861741cd ro quiet splash vt.handoff=1 SourcePackage: xorg UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 11/15/2010 dmi.bios.vendor: Award Software International, Inc. dmi.bios.version: F1 dmi.board.name: M68MT-S2 dmi.board.vendor: Gigabyte Technology Co., Ltd. dmi.board.version: x.x dmi.chassis.type: 3 dmi.chassis.vendor: Gigabyte Technology Co., Ltd. dmi.modalias: dmi:bvnAwardSoftwareInternational,Inc.:bvrF1:bd11/15/2010:svnGigabyteTechnologyCo.,Ltd.:pnM68MT-S2:pvr:rvnGigabyteTechnologyCo.,Ltd.:rnM68MT-S2:rvrx.x:cvnGigabyteTechnologyCo.,Ltd.:ct3:cvr: dmi.product.name: M68MT-S2 dmi.sys.vendor: Gigabyte Technology Co., Ltd. version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.92+git20180609.c1f2d9b9-0ubuntu0ricotz~18.04.1 version.libgl1-mesa-dri: libgl1-mesa-dri 18.0.0~rc5-1ubuntu1 version.libgl1-mesa-glx: libgl1-mesa-glx 18.0.0~rc5-1ubuntu1 version.xserver-xorg-core: xserver-xorg-core 2:1.19.6-1ubuntu4 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.10.5-1ubuntu1 version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:18.0.1-1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20171229-1 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.15-2 xserver.bootTime: Mon Jul 2 09:02:38 2018 xserver.configfile: default xserver.devices: inputPower Button KEYBOARD, id 6 inputPower Button KEYBOARD, id 7 inputAT Translated Set 2 keyboard KEYBOARD, id 8 inputImPS/2 Generic Wheel Mouse MOUSE, id 9 xserver.errors: xserver.logfile: /var/log/Xorg.0.log xserver.version: 2:1.19.6-1ubuntu4 xserver.video_driver: nouveau ** Affects: xorg (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug bionic third-party-packages 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/1779708 Title: My screen got deconfigurtated Status in xorg package in Ubuntu: New Bug description: WHen I get into google or some other programs, my screen fails, and don't work any longer. It became a screen like that of the Tv shows when there is not signal, and it just doesn't respond any more. I can't do anything, and I must restart the PC, the screen doesn't allow me to do any other operation. I previously have the 16.04 LTS ubuntu with unity and conpiz, and I tried to actualize it to 18.04 LTS version, the bug began. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: xorg 1:7.7+19ubuntu7 ProcVersionSignature: Ubuntu 4.15.0-24.26-generic 4.15.18 Uname: Linux 4.15.0-24-generic x86_64 .tmp.unity_support_test.0: ApportVersion: 2.20.9-0ubuntu7.2 Architecture: amd64 CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins' CompositorRunning: None Date: Mon Jul 2 10:07:31 2018 DistUpgraded: Fresh install DistroCodename: bionic DistroVariant: ubuntu GraphicsCard: NVIDIA Corporation C61 [GeForce 7025 / nForce 630a] [10de:03d6] (rev a2) (prog-if 00 [VGA controller]) Subsystem: Gigabyte Technology Co., Ltd C61 [GeForce 7025 / nForce 630a] [1458:d000] InstallationDate: Installed on 2015-04-16 (1172 days ago) InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417) MachineType: Gigabyte Technology Co., Ltd. M68MT-S2 ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-24-generic root=UUID=78b08060-d316-4ee6-92e7-4f94861741cd ro quiet splash
[Touch-packages] [Bug 1725190] Re: Please update modemmanager in xenial to the 1.6 series
** Tags removed: verification-needed-xenial ** Tags added: verification-done-xenial -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to modemmanager in Ubuntu. https://bugs.launchpad.net/bugs/1725190 Title: Please update modemmanager in xenial to the 1.6 series Status in OEM Priority Project: Confirmed Status in libmbim package in Ubuntu: Fix Released Status in libqmi package in Ubuntu: Fix Released Status in modemmanager package in Ubuntu: Fix Released Status in libmbim source package in Xenial: Fix Committed Status in libqmi source package in Xenial: Fix Committed Status in modemmanager source package in Xenial: Fix Committed Bug description: [Impact] * the new modemmanager packages bring in DW5816 supporting. * These modemmanager packages is needed to support new devices. [Test Case] * install modemmanager and it's dependencies from -proposed libmbim-glib4:amd64 1.14.0-1ubuntu0.16.04.1 libmbim-proxy 1.14.0-1ubuntu0.16.04.1 libmm-glib0:amd64 1.6.4-1ubuntu0.16.04.1 libqmi-glib5:amd64 1.16.2-1ubuntu0.16.04.1 libqmi-proxy 1.16.2-1ubuntu0.16.04.1 modemmanager 1.6.4-1ubuntu0.16.04.1 * reboot and try WWAN function to see if any regression there. * perform general dogfooding of its reverse dependencies (network-manager, gnome-control-center etc.) [Regression Potential] * The package comes from Zesty and should not have regression there. * Every new upstream release can potentially break existing dependencies if any of the required features have been changed/removed, so besides regular testing a general dogfooding session with the new modemmanager is advised. [Original Description] We would like to upgrade xenial to 1.6 series so it supports the same modems as the modem-manager snap, specifically some new Sierra modems (HL8548 and others from HL series, popular in IoT devices). These are the packages that would need to be updated: libmbim: 1.12.2-2ubuntu1 in xenial, 1.14.0 in snap libqmi: 1.12.6-1 in xenial, 1.16.2 in snap modemmanager: 1.4.12-1ubuntu1 in xenial, 1.6.2 in snap This is also related to bug #1693756 which includes a subset of patches of what would be updated. To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1725190/+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 1725190] Re: Please update modemmanager in xenial to the 1.6 series
I have tried the packages in xenial-proposed for two modems: Sierra HL8548 ZTE MF626 I was able to connect and everything seemed to be working as expected. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to modemmanager in Ubuntu. https://bugs.launchpad.net/bugs/1725190 Title: Please update modemmanager in xenial to the 1.6 series Status in OEM Priority Project: Confirmed Status in libmbim package in Ubuntu: Fix Released Status in libqmi package in Ubuntu: Fix Released Status in modemmanager package in Ubuntu: Fix Released Status in libmbim source package in Xenial: Fix Committed Status in libqmi source package in Xenial: Fix Committed Status in modemmanager source package in Xenial: Fix Committed Bug description: [Impact] * the new modemmanager packages bring in DW5816 supporting. * These modemmanager packages is needed to support new devices. [Test Case] * install modemmanager and it's dependencies from -proposed libmbim-glib4:amd64 1.14.0-1ubuntu0.16.04.1 libmbim-proxy 1.14.0-1ubuntu0.16.04.1 libmm-glib0:amd64 1.6.4-1ubuntu0.16.04.1 libqmi-glib5:amd64 1.16.2-1ubuntu0.16.04.1 libqmi-proxy 1.16.2-1ubuntu0.16.04.1 modemmanager 1.6.4-1ubuntu0.16.04.1 * reboot and try WWAN function to see if any regression there. * perform general dogfooding of its reverse dependencies (network-manager, gnome-control-center etc.) [Regression Potential] * The package comes from Zesty and should not have regression there. * Every new upstream release can potentially break existing dependencies if any of the required features have been changed/removed, so besides regular testing a general dogfooding session with the new modemmanager is advised. [Original Description] We would like to upgrade xenial to 1.6 series so it supports the same modems as the modem-manager snap, specifically some new Sierra modems (HL8548 and others from HL series, popular in IoT devices). These are the packages that would need to be updated: libmbim: 1.12.2-2ubuntu1 in xenial, 1.14.0 in snap libqmi: 1.12.6-1 in xenial, 1.16.2 in snap modemmanager: 1.4.12-1ubuntu1 in xenial, 1.6.2 in snap This is also related to bug #1693756 which includes a subset of patches of what would be updated. To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1725190/+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 1735134] Re: ModemManager uses a wrong plugin for Dell DW5818/5819
** Description changed: - Since linux-4.4.0-98, the kernel additionally load gcserial driver for + [Impact] + + * Dell Wireless DW5818/5819 modems showed an incorrect signal strength + and were using a ttyUSB* port for data connections instead of the MBIM + device (which provides better performance). + + Since linux-4.4.0-98, the kernel additionally loads gcserial driver for Dell Wireless DW5818/5819. The reason behind it is to support firmware - switching and upgrading. However, the change makes ModemManager to use - Gobi plugin for this two modules. With Gobi plugin, the modules could + switching and upgrading. However, the change makes ModemManager use Gobi + plugin for this two modules. With Gobi plugin, the modules could establish data links, but it failed to retrieve the signal state. And it caused the mmcli and nm-applet giving wrong signal strength. The modules support the MBIM protocol, so ModemManager should use Dell plugin for these two modules. I have worked out a patch to forbid these two modules in Gobi plugin, and it does work well. + + [Test Case] + + Current MM: + * Create connection with + $ nmcli c add type gsm ifname ttyUSB2 con-name gsmconn apn + * Without the patched package, mmcli shows, with an active connection (see comment #2): + primary port: 'ttyUSB2' + signal quality: '0' (recent) + + Patched MM: + * Create connection with + $ nmcli c add type gsm ifname cdc-wdm0 con-name gsmconn apn + * With the patched package, mmcli shows, with an active connection (see comment #7): + primary port: 'cdc-wdm0' + signal quality: '38' (cached) + + [Regression Potential] + + The patch simply adds the Sierra modems VID/PIDs to the list of + forbidden ids in the Gobi plugin, so the possibility of a regression is + very small: only products with said VID/PID will be affected. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to modemmanager in Ubuntu. https://bugs.launchpad.net/bugs/1735134 Title: ModemManager uses a wrong plugin for Dell DW5818/5819 Status in modemmanager package in Ubuntu: New Bug description: [Impact] * Dell Wireless DW5818/5819 modems showed an incorrect signal strength and were using a ttyUSB* port for data connections instead of the MBIM device (which provides better performance). Since linux-4.4.0-98, the kernel additionally loads gcserial driver for Dell Wireless DW5818/5819. The reason behind it is to support firmware switching and upgrading. However, the change makes ModemManager use Gobi plugin for this two modules. With Gobi plugin, the modules could establish data links, but it failed to retrieve the signal state. And it caused the mmcli and nm-applet giving wrong signal strength. The modules support the MBIM protocol, so ModemManager should use Dell plugin for these two modules. I have worked out a patch to forbid these two modules in Gobi plugin, and it does work well. [Test Case] Current MM: * Create connection with $ nmcli c add type gsm ifname ttyUSB2 con-name gsmconn apn * Without the patched package, mmcli shows, with an active connection (see comment #2): primary port: 'ttyUSB2' signal quality: '0' (recent) Patched MM: * Create connection with $ nmcli c add type gsm ifname cdc-wdm0 con-name gsmconn apn * With the patched package, mmcli shows, with an active connection (see comment #7): primary port: 'cdc-wdm0' signal quality: '38' (cached) [Regression Potential] The patch simply adds the Sierra modems VID/PIDs to the list of forbidden ids in the Gobi plugin, so the possibility of a regression is very small: only products with said VID/PID will be affected. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/1735134/+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 1725190] Re: Please update modemmanager in xenial to the 1.6 series
@Lukasz please go for sponsoring the zesty->xenial backport, that is enough to get support for the original modem OEM enablement needed. The work in the patches needs some time, so better do this for the moment. Thanks! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to modemmanager in Ubuntu. https://bugs.launchpad.net/bugs/1725190 Title: Please update modemmanager in xenial to the 1.6 series Status in OEM Priority Project: Confirmed Status in modemmanager package in Ubuntu: In Progress Bug description: We would like to upgrade xenial to 1.6 series so it supports the same modems as the modem-manager snap, specifically some new Sierra modems (HL8548 and others from HL series, popular in IoT devices). These are the packages that would need to be updated: libmbim: 1.12.2-2ubuntu1 in xenial, 1.14.0 in snap libqmi: 1.12.6-1 in xenial, 1.16.2 in snap modemmanager: 1.4.12-1ubuntu1 in xenial, 1.6.2 in snap This is also related to bug #1693756 which includes a subset of patches of what would be updated. To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1725190/+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 1725190] Re: Please update modemmanager in xenial to the 1.6 series
@Lukasz those are patches for Dell modems (plano project, unbuntu core). It makes sense to upstream some of them in fact, and that is something I can try. But, it would still make sense to backport the zesty packages to xenial, as that has the support needed for DW5816e (lp #1693756). If you prefer, we can go that way and leave out the patches for the moment until I get a response for MM upstream. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to modemmanager in Ubuntu. https://bugs.launchpad.net/bugs/1725190 Title: Please update modemmanager in xenial to the 1.6 series Status in OEM Priority Project: Confirmed Status in modemmanager package in Ubuntu: In Progress Bug description: We would like to upgrade xenial to 1.6 series so it supports the same modems as the modem-manager snap, specifically some new Sierra modems (HL8548 and others from HL series, popular in IoT devices). These are the packages that would need to be updated: libmbim: 1.12.2-2ubuntu1 in xenial, 1.14.0 in snap libqmi: 1.12.6-1 in xenial, 1.16.2 in snap modemmanager: 1.4.12-1ubuntu1 in xenial, 1.6.2 in snap This is also related to bug #1693756 which includes a subset of patches of what would be updated. To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1725190/+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 1725190] Re: Please update modemmanager in xenial to the 1.6 series
@Lukasz, I uploaded the backported packages (zesty->xenial) + patches from the snap in: https://launchpad.net/~alfonsosanchezbeato/+archive/ubuntu/modem- manager-backport -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to modemmanager in Ubuntu. https://bugs.launchpad.net/bugs/1725190 Title: Please update modemmanager in xenial to the 1.6 series Status in OEM Priority Project: Confirmed Status in modemmanager package in Ubuntu: In Progress Bug description: We would like to upgrade xenial to 1.6 series so it supports the same modems as the modem-manager snap, specifically some new Sierra modems (HL8548 and others from HL series, popular in IoT devices). These are the packages that would need to be updated: libmbim: 1.12.2-2ubuntu1 in xenial, 1.14.0 in snap libqmi: 1.12.6-1 in xenial, 1.16.2 in snap modemmanager: 1.4.12-1ubuntu1 in xenial, 1.6.2 in snap This is also related to bug #1693756 which includes a subset of patches of what would be updated. To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1725190/+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 1725190] Re: Please update modemmanager in xenial to the 1.6 series
@Lukasz yes, I think that using the version in zesty is perfectly feasible, I can prepare the packages for that. About using the backports pocket, I will let YC or Alex comment on that. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to modemmanager in Ubuntu. https://bugs.launchpad.net/bugs/1725190 Title: Please update modemmanager in xenial to the 1.6 series Status in OEM Priority Project: Confirmed Status in modemmanager package in Ubuntu: In Progress Bug description: We would like to upgrade xenial to 1.6 series so it supports the same modems as the modem-manager snap, specifically some new Sierra modems (HL8548 and others from HL series, popular in IoT devices). These are the packages that would need to be updated: libmbim: 1.12.2-2ubuntu1 in xenial, 1.14.0 in snap libqmi: 1.12.6-1 in xenial, 1.16.2 in snap modemmanager: 1.4.12-1ubuntu1 in xenial, 1.6.2 in snap This is also related to bug #1693756 which includes a subset of patches of what would be updated. To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1725190/+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 1725190] Re: Please update modemmanager in xenial to the 1.6 series
Packages uploaded to https://launchpad.net/~snappy-hwe- team/+archive/ubuntu/stacks-overlay and built for xenial. The versions are the same as for artful, plus additional patches for Dell modems in the modem-manager source package. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to modemmanager in Ubuntu. https://bugs.launchpad.net/bugs/1725190 Title: Please update modemmanager in xenial to the 1.6 series Status in OEM Priority Project: New Status in modemmanager package in Ubuntu: New Bug description: We would like to upgrade xenial to 1.6 series so it supports the same modems as the modem-manager snap, specifically some new Sierra modems (HL8548 and others from HL series, popular in IoT devices). These are the packages that would need to be updated: libmbim: 1.12.2-2ubuntu1 in xenial, 1.14.0 in snap libqmi: 1.12.6-1 in xenial, 1.16.2 in snap modemmanager: 1.4.12-1ubuntu1 in xenial, 1.6.2 in snap This is also related to bug #1693756 which includes a subset of patches of what would be updated. To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1725190/+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 1725190] Re: Please update modemmanager in xenial to the 1.6 series
** Description changed: We would like to upgrade xenial to 1.6 series so it supports the same - modems as the modem-manager snap, specifically some new Sierra modems. - These are the packages that would need to be updated: + modems as the modem-manager snap, specifically some new Sierra modems + (HL8548 and others from HL series, popular in IoT devices). These are + the packages that would need to be updated: libmbim: 1.12.2-2ubuntu1 in xenial, 1.14.0 in snap libqmi: 1.12.6-1 in xenial, 1.16.2 in snap modemmanager: 1.4.12-1ubuntu1 in xenial, 1.6.2 in snap This is also related to bug #1693756 which includes a subset of patches of what would be updated. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to modemmanager in Ubuntu. https://bugs.launchpad.net/bugs/1725190 Title: Please update modemmanager in xenial to the 1.6 series Status in OEM Priority Project: New Status in modemmanager package in Ubuntu: New Bug description: We would like to upgrade xenial to 1.6 series so it supports the same modems as the modem-manager snap, specifically some new Sierra modems (HL8548 and others from HL series, popular in IoT devices). These are the packages that would need to be updated: libmbim: 1.12.2-2ubuntu1 in xenial, 1.14.0 in snap libqmi: 1.12.6-1 in xenial, 1.16.2 in snap modemmanager: 1.4.12-1ubuntu1 in xenial, 1.6.2 in snap This is also related to bug #1693756 which includes a subset of patches of what would be updated. To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1725190/+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 1693756] Re: [Xenial][ DW5816e] to support qmi over mbim which needed for FCC authentication.
After chatting with sil2100, he said that potentially we could backport artful 1.6.8 modemmanager to xenial, which would be great. I have created bug #1725190 to track that and start in a clean state from there. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to modemmanager in Ubuntu. https://bugs.launchpad.net/bugs/1693756 Title: [Xenial][ DW5816e] to support qmi over mbim which needed for FCC authentication. Status in ModemManager: New Status in OEM Priority Project: Triaged Status in OEM Priority Project xenial series: New Status in modemmanager package in Ubuntu: Confirmed Bug description: # issue: * wwan card DW5816e[413c:81cc] couldn't be recognized by modemmanager 1.4.12-1ubuntu1 on xenial. - but works well on on Yakkety. # investgation: * in failed case, mmcli -L shows nothing on Xenial with DW5816. Then tried install followed packages from Yakkety ppa on Xenial and wwan card works on 1st boot but failed after 2nd boot sometimes. - libmbim-glib4_1.14.0-1_amd64.deb - libmbim-glib-dev_1.14.0-1_amd64.deb - libmbim-proxy_1.14.0-1_amd64.deb - libmbim-utils_1.14.0-1_amd64.deb - libqmi-glib5_1.16.0-1_amd64.deb - libqmi-proxy_1.16.0-1_amd64.deb * different from ModemManager --debug - In passed case, it received message from /dev/cdc-wdm1 after send "Read max control message size from descriptors file: 4096" , but not happens to failed case. So, it prints "[mm-port-probe.c:261] mm_port_probe_set_result_qcdm(): (tty/ttyS4) port is not QCDM-capable" in failed case. - passed case: http://paste.ubuntu.com/24664908/ - failed case: http://paste.ubuntu.com/24664910/ # Plan: * let the newer version packages could also works well on Xenial. * find out needed patches on newer version packages. * packport needed patches to older version packages on Xenial. # environment information: * modinfo cdc_mbim for original kernel module: http://paste.ubuntu.com/24662359/ - the code /driver/net/usb/cdc_mbim.c is the same between xenial kernel 4.4.0 and yakkety kernel 4.8.0. * uname -r: 4.4.0-73-generic * lsusb -v: http://paste.ubuntu.com/24662332/ FCC authentication reference: * http://lists.infradead.org/pipermail/lede-dev/2016-August/002332.html * https://lists.freedesktop.org/archives/libmbim-devel/2016-April/thread.html#704 To manage notifications about this bug go to: https://bugs.launchpad.net/modemmanager/+bug/1693756/+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 1725190] [NEW] Please update modemmanager in xenial to the 1.6 series
Public bug reported: We would like to upgrade xenial to 1.6 series so it supports the same modems as the modem-manager snap, specifically some new Sierra modems. These are the packages that would need to be updated: libmbim: 1.12.2-2ubuntu1 in xenial, 1.14.0 in snap libqmi: 1.12.6-1 in xenial, 1.16.2 in snap modemmanager: 1.4.12-1ubuntu1 in xenial, 1.6.2 in snap This is also related to bug #1693756 which includes a subset of patches of what would be updated. ** Affects: modemmanager (Ubuntu) Importance: Undecided Status: New ** Description changed: We would like to upgrade xenial to 1.6 series so it supports the same modems as the modem-manager snap, specifically some new Sierra modems. These are the packages that would need to be updated: - xenialin snap - libmbim 1.12.2-2ubuntu1 1.14.0 - libqmi 1.12.6-1 1.16.2 - modemmanager 1.4.12-1ubuntu1 1.6.2 + libmbim: 1.12.2-2ubuntu1 in xenial, 1.14.0 in snap + libqmi: 1.12.6-1 in xenial, 1.16.2 in snap + modemmanager: 1.4.12-1ubuntu1 in xenial, 1.6.2 in snap This is also related to bug #1693756 which includes a subset of patches of what would be updated. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to modemmanager in Ubuntu. https://bugs.launchpad.net/bugs/1725190 Title: Please update modemmanager in xenial to the 1.6 series Status in modemmanager package in Ubuntu: New Bug description: We would like to upgrade xenial to 1.6 series so it supports the same modems as the modem-manager snap, specifically some new Sierra modems. These are the packages that would need to be updated: libmbim: 1.12.2-2ubuntu1 in xenial, 1.14.0 in snap libqmi: 1.12.6-1 in xenial, 1.16.2 in snap modemmanager: 1.4.12-1ubuntu1 in xenial, 1.6.2 in snap This is also related to bug #1693756 which includes a subset of patches of what would be updated. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/1725190/+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 1692494] Re: klibc does not support reboot arguments
It looks like both upstream and debian are not being responsive, looks like klibc has no maintainer in neither of those. Should we add this patch to the Ubuntu package? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to klibc in Ubuntu. https://bugs.launchpad.net/bugs/1692494 Title: klibc does not support reboot arguments Status in klibc package in Ubuntu: New Status in klibc package in Debian: New Bug description: ... so we cannot do things like "reboot recovery" in devices that follow the Android partitions conventions. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1692494/+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 1696981] Re: fixrtc is ineffective when there is no battery for the RTC
*** This bug is a duplicate of bug 1623125 *** https://bugs.launchpad.net/bugs/1623125 @smb, actually, there is no create time field in the fs header, see http://paste.ubuntu.com/25478756/ (this comes from a file with the mount time already corrected). This is a partition created with android tools, as the ones from mkfs.ext4 do not work for this device (for unknown reasons). I understand this is sort of a special case though. -- 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/1696981 Title: fixrtc is ineffective when there is no battery for the RTC Status in initramfs-tools package in Ubuntu: Incomplete Bug description: When there is no battery for the RTC, fixrtc is not able to find a good enough date. To fix the clock, this script is using the last time the root filesystem was mounted, but as that is done before there is any network, and as after a reboot/poweroff the RTC time is always reset (because time is not kept due to lack of battery), the mount time will never be good. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1696981/+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 1696981] Re: fixrtc is ineffective when there is no battery for the RTC
@smb the concrete problem this was solving was happening with an armhf device running Ubuntu Core. UC assertions were not validated and a system user could not be created if there was no network (no date update). Not sure if this was breaking the system even if later you connected the device. -- 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/1696981 Title: fixrtc is ineffective when there is no battery for the RTC Status in initramfs-tools package in Ubuntu: Incomplete Bug description: When there is no battery for the RTC, fixrtc is not able to find a good enough date. To fix the clock, this script is using the last time the root filesystem was mounted, but as that is done before there is any network, and as after a reboot/poweroff the RTC time is always reset (because time is not kept due to lack of battery), the mount time will never be good. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1696981/+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 1696981] Re: fixrtc is ineffective when there is no battery for the RTC
@smb what I have seen is that devices lacking RTC battery tend to never had a good date in the "last mount day" date of the root filesystem, as when root is mounted the date is always near the epoch. The patch can correct this, otherwise we would be getting the date systemd was built. Of course this is not terribly accurate, but solves issues with certificates/assertions that were deemed as not yet valid on first boot if there was no network. -- 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/1696981 Title: fixrtc is ineffective when there is no battery for the RTC Status in initramfs-tools package in Ubuntu: Incomplete Bug description: When there is no battery for the RTC, fixrtc is not able to find a good enough date. To fix the clock, this script is using the last time the root filesystem was mounted, but as that is done before there is any network, and as after a reboot/poweroff the RTC time is always reset (because time is not kept due to lack of battery), the mount time will never be good. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1696981/+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 1698671] [NEW] package initramfs-tools 0.103ubuntu4.7 failed to install/upgrade: el subproceso instalado el script post-installation devolvió el código de salida de error 1
Public bug reported: it got stuck in login page, only reinstalling drivers helped, but my screen looks too different. ProblemType: Package DistroRelease: Ubuntu 14.04 Package: initramfs-tools 0.103ubuntu4.7 ProcVersionSignature: Ubuntu 4.2.0-27.32~14.04.1-lowlatency 4.2.8-ckt1 Uname: Linux 4.2.0-27-lowlatency x86_64 ApportVersion: 2.14.1-0ubuntu3.24 Architecture: amd64 Date: Sun Jun 18 11:23:05 2017 DuplicateSignature: package:initramfs-tools:0.103ubuntu4.7:el subproceso instalado el script post-installation devolvió el código de salida de error 1 ErrorMessage: el subproceso instalado el script post-installation devolvió el código de salida de error 1 InstallationDate: Installed on 2017-03-24 (85 days ago) InstallationMedia: Ubuntu-Studio 14.04.4 LTS "Trusty Tahr" - Release amd64 (20160217.1) PackageArchitecture: all RelatedPackageVersions: dpkg 1.17.5ubuntu5.7 apt 1.0.1ubuntu2.17 SourcePackage: initramfs-tools Title: package initramfs-tools 0.103ubuntu4.7 failed to install/upgrade: el subproceso instalado el script post-installation devolvió el código de salida de error 1 UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: initramfs-tools (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-package trusty -- 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/1698671 Title: package initramfs-tools 0.103ubuntu4.7 failed to install/upgrade: el subproceso instalado el script post-installation devolvió el código de salida de error 1 Status in initramfs-tools package in Ubuntu: New Bug description: it got stuck in login page, only reinstalling drivers helped, but my screen looks too different. ProblemType: Package DistroRelease: Ubuntu 14.04 Package: initramfs-tools 0.103ubuntu4.7 ProcVersionSignature: Ubuntu 4.2.0-27.32~14.04.1-lowlatency 4.2.8-ckt1 Uname: Linux 4.2.0-27-lowlatency x86_64 ApportVersion: 2.14.1-0ubuntu3.24 Architecture: amd64 Date: Sun Jun 18 11:23:05 2017 DuplicateSignature: package:initramfs-tools:0.103ubuntu4.7:el subproceso instalado el script post-installation devolvió el código de salida de error 1 ErrorMessage: el subproceso instalado el script post-installation devolvió el código de salida de error 1 InstallationDate: Installed on 2017-03-24 (85 days ago) InstallationMedia: Ubuntu-Studio 14.04.4 LTS "Trusty Tahr" - Release amd64 (20160217.1) PackageArchitecture: all RelatedPackageVersions: dpkg 1.17.5ubuntu5.7 apt 1.0.1ubuntu2.17 SourcePackage: initramfs-tools Title: package initramfs-tools 0.103ubuntu4.7 failed to install/upgrade: el subproceso instalado el script post-installation devolvió el código de salida de error 1 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1698671/+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 1696981] Re: fixrtc is ineffective when there is no battery for the RTC
New patch version, which includes now a patch from ogra (LP: #1623125) ** Patch added: "fixrtc-changes.patch" https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1696981/+attachment/4893078/+files/fixrtc-changes.patch -- 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/1696981 Title: fixrtc is ineffective when there is no battery for the RTC Status in initramfs-tools package in Ubuntu: New Bug description: When there is no battery for the RTC, fixrtc is not able to find a good enough date. To fix the clock, this script is using the last time the root filesystem was mounted, but as that is done before there is any network, and as after a reboot/poweroff the RTC time is always reset (because time is not kept due to lack of battery), the mount time will never be good. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1696981/+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 1696981] Re: fixrtc is ineffective when there is no battery for the RTC
This is the output of dumpe2fs: http://paste.ubuntu.com/24815516/ -- 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/1696981 Title: fixrtc is ineffective when there is no battery for the RTC Status in initramfs-tools package in Ubuntu: New Bug description: When there is no battery for the RTC, fixrtc is not able to find a good enough date. To fix the clock, this script is using the last time the root filesystem was mounted, but as that is done before there is any network, and as after a reboot/poweroff the RTC time is always reset (because time is not kept due to lack of battery), the mount time will never be good. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1696981/+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 1696981] Re: fixrtc is ineffective when there is no battery for the RTC
This debdiff adds a fixrtc-mount that helps with this issue by looking at dates from files, once root has been mounted. ** Patch added: "add-fixrtc-mount.patch" https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1696981/+attachment/4893067/+files/add-fixrtc-mount.patch -- 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/1696981 Title: fixrtc is ineffective when there is no battery for the RTC Status in initramfs-tools package in Ubuntu: New Bug description: When there is no battery for the RTC, fixrtc is not able to find a good enough date. To fix the clock, this script is using the last time the root filesystem was mounted, but as that is done before there is any network, and as after a reboot/poweroff the RTC time is always reset (because time is not kept due to lack of battery), the mount time will never be good. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1696981/+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 1696981] [NEW] fixrtc is ineffective when there is no battery for the RTC
Public bug reported: When there is no battery for the RTC, fixrtc is not able to find a good enough date. To fix the clock, this script is using the last time the root filesystem was mounted, but as that is done before there is any network, and as after a reboot/poweroff the RTC time is always reset (because time is not kept due to lack of battery), the mount time will never be good. ** Affects: initramfs-tools (Ubuntu) Importance: Undecided Status: New -- 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/1696981 Title: fixrtc is ineffective when there is no battery for the RTC Status in initramfs-tools package in Ubuntu: New Bug description: When there is no battery for the RTC, fixrtc is not able to find a good enough date. To fix the clock, this script is using the last time the root filesystem was mounted, but as that is done before there is any network, and as after a reboot/poweroff the RTC time is always reset (because time is not kept due to lack of battery), the mount time will never be good. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1696981/+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 1696126] Re: package apport 2.20.1-0ubuntu2.6 failed to install/upgrade: El paquete está en un estado grave de inconsistencia - debe reinstalarlo antes de intentar su configurac
I'm beeing asked to re-install apport 2.20.1-0ubuntu2. How do I do that? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apport in Ubuntu. https://bugs.launchpad.net/bugs/1696126 Title: package apport 2.20.1-0ubuntu2.6 failed to install/upgrade: El paquete está en un estado grave de inconsistencia - debe reinstalarlo antes de intentar su configuración. Status in apport package in Ubuntu: New Bug description: none ProblemType: Package DistroRelease: Ubuntu 16.04 Package: apport 2.20.1-0ubuntu2.6 ProcVersionSignature: Ubuntu 4.4.0-78.99-generic 4.4.62 Uname: Linux 4.4.0-78-generic x86_64 ApportLog: ApportVersion: 2.20.1-0ubuntu2.6 AptOrdering: libtasn1-6: Install apport: Configure libtasn1-6: Configure NULL: ConfigurePending Architecture: amd64 Date: Tue Jun 6 12:49:47 2017 ErrorMessage: El paquete está en un estado grave de inconsistencia - debe reinstalarlo antes de intentar su configuración. InstallationDate: Installed on 2016-12-16 (172 days ago) InstallationMedia: Ubuntu 16.04.1 LTS "Xenial Xerus" - Release amd64 (20160719) PackageArchitecture: all RelatedPackageVersions: dpkg 1.18.4ubuntu1.2 apt 1.2.20 SourcePackage: apport Title: package apport 2.20.1-0ubuntu2.6 failed to install/upgrade: El paquete está en un estado grave de inconsistencia - debe reinstalarlo antes de intentar su configuración. UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1696126/+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 1696126] [NEW] package apport 2.20.1-0ubuntu2.6 failed to install/upgrade: El paquete está en un estado grave de inconsistencia - debe reinstalarlo antes de intentar su configur
Public bug reported: none ProblemType: Package DistroRelease: Ubuntu 16.04 Package: apport 2.20.1-0ubuntu2.6 ProcVersionSignature: Ubuntu 4.4.0-78.99-generic 4.4.62 Uname: Linux 4.4.0-78-generic x86_64 ApportLog: ApportVersion: 2.20.1-0ubuntu2.6 AptOrdering: libtasn1-6: Install apport: Configure libtasn1-6: Configure NULL: ConfigurePending Architecture: amd64 Date: Tue Jun 6 12:49:47 2017 ErrorMessage: El paquete está en un estado grave de inconsistencia - debe reinstalarlo antes de intentar su configuración. InstallationDate: Installed on 2016-12-16 (172 days ago) InstallationMedia: Ubuntu 16.04.1 LTS "Xenial Xerus" - Release amd64 (20160719) PackageArchitecture: all RelatedPackageVersions: dpkg 1.18.4ubuntu1.2 apt 1.2.20 SourcePackage: apport Title: package apport 2.20.1-0ubuntu2.6 failed to install/upgrade: El paquete está en un estado grave de inconsistencia - debe reinstalarlo antes de intentar su configuración. UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: apport (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 apport in Ubuntu. https://bugs.launchpad.net/bugs/1696126 Title: package apport 2.20.1-0ubuntu2.6 failed to install/upgrade: El paquete está en un estado grave de inconsistencia - debe reinstalarlo antes de intentar su configuración. Status in apport package in Ubuntu: New Bug description: none ProblemType: Package DistroRelease: Ubuntu 16.04 Package: apport 2.20.1-0ubuntu2.6 ProcVersionSignature: Ubuntu 4.4.0-78.99-generic 4.4.62 Uname: Linux 4.4.0-78-generic x86_64 ApportLog: ApportVersion: 2.20.1-0ubuntu2.6 AptOrdering: libtasn1-6: Install apport: Configure libtasn1-6: Configure NULL: ConfigurePending Architecture: amd64 Date: Tue Jun 6 12:49:47 2017 ErrorMessage: El paquete está en un estado grave de inconsistencia - debe reinstalarlo antes de intentar su configuración. InstallationDate: Installed on 2016-12-16 (172 days ago) InstallationMedia: Ubuntu 16.04.1 LTS "Xenial Xerus" - Release amd64 (20160719) PackageArchitecture: all RelatedPackageVersions: dpkg 1.18.4ubuntu1.2 apt 1.2.20 SourcePackage: apport Title: package apport 2.20.1-0ubuntu2.6 failed to install/upgrade: El paquete está en un estado grave de inconsistencia - debe reinstalarlo antes de intentar su configuración. UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1696126/+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 1692494] Re: klibc does not support reboot arguments
Reported to debian: https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=863761 ** Bug watch added: Debian Bug tracker #863761 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863761 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to klibc in Ubuntu. https://bugs.launchpad.net/bugs/1692494 Title: klibc does not support reboot arguments Status in klibc package in Ubuntu: New Bug description: ... so we cannot do things like "reboot recovery" in devices that follow the Android partitions conventions. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1692494/+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 1692494] Re: klibc does not support reboot arguments
Add a slightly modified version of the patch. ** Patch added: "add-reboot-argument-support.patch" https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1692494/+attachment/4883202/+files/add-reboot-argument-support.patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to klibc in Ubuntu. https://bugs.launchpad.net/bugs/1692494 Title: klibc does not support reboot arguments Status in klibc package in Ubuntu: New Bug description: ... so we cannot do things like "reboot recovery" in devices that follow the Android partitions conventions. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1692494/+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 1692494] [NEW] klibc does not support reboot arguments
Public bug reported: ... so we cannot do things like "reboot recovery" in devices that follow the Android partitions conventions. ** Affects: klibc (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to klibc in Ubuntu. https://bugs.launchpad.net/bugs/1692494 Title: klibc does not support reboot arguments Status in klibc package in Ubuntu: New Bug description: ... so we cannot do things like "reboot recovery" in devices that follow the Android partitions conventions. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1692494/+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 1692494] Re: klibc does not support reboot arguments
** Patch added: "add-reboot-argument-support.patch" https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1692494/+attachment/4881283/+files/add-reboot-argument-support.patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to klibc in Ubuntu. https://bugs.launchpad.net/bugs/1692494 Title: klibc does not support reboot arguments Status in klibc package in Ubuntu: New Bug description: ... so we cannot do things like "reboot recovery" in devices that follow the Android partitions conventions. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1692494/+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 788167] Re: CUPS cannot print to Kerberos-authenticated SMB print queue
Fix released in Debian? Reading the bug report (https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=711341) they just closed it with a wontfix. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/788167 Title: CUPS cannot print to Kerberos-authenticated SMB print queue Status in cups package in Ubuntu: Confirmed Status in Debian: Fix Released Bug description: Binary package hint: cups That was investigated on maverick (cups 1.4.4) and natty (cups 1.4.6). CUPS in Ubuntu cannot authenticate using Kerberos to an SMB print queue, such as one in an Active Directory. This is because the smb backend is being invoked as user lp, and this user cannot access the Kerberos credential cache of the user who submitted the job. When trying to print, the job is held for authentication, and a dialog prompting for username/password is being shown. On Windows (and possibly other OS), the user would not be prompted if he has a ticket in the Kerberos realm (ie, "logged on to the domain") he is trying to print to. The CUPS smb backend on Ubuntu is the smbspool binary provided by Samba. When run as a user, it will pick the Kerberos credential cache by itself and authenticate seamlessly. Otherwise, it will read the KRB5CCNAME environment variable and try to use that when possible. There is two possible solutions to that: - Invoke the smb backend as root and pass it the KRB5CCNAME environment variable pointing to the user's Kerberos credential cache. CUPS execute the backend as user lp if it is world-executable, which is currently the case on Ubuntu. User lp do not have the permission to read the user's credential cache, hence why the smb backend would need to be executed as root (by removing the world-executable bit). Also, CUPS does not currently set KRB5CCNAME before invoking the smb backend (see http://www.cups.org/str.php?L3847). - Execute smbspool as the user submitting the job. I presume we would have the same problem with other backend that would do Kerberos authentication, although I do not know of a specific one. I have only tested and investigated with the smb backend. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/788167/+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 1639776] Re: dnsmasq fails to send queries out after suspend disconnects the interface
I have tested the package in yakkety and fixed the issue for me too. In
my case it appeared when switching wifi connection between two APs which
shared the DHCP server.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1639776
Title:
dnsmasq fails to send queries out after suspend disconnects the
interface
Status in dnsmasq package in Ubuntu:
Fix Released
Status in dnsmasq source package in Xenial:
Fix Committed
Status in dnsmasq source package in Yakkety:
Fix Committed
Status in dnsmasq package in Debian:
Fix Released
Bug description:
[Impact]
* suspend/resume (which involves disconnection of network devices)
leads to dnsmasq failures.
[Test Case]
* suspend/resume on 16.04 or 16.10 when using dnsmasq, and see
failures upon resume.
[Regression Potential]
* The fix was NMU'd in Debian in the version immediately after
16.10's. I believe the regression potential is very low as this is a
clear bug-fix from upstream.
---
Failure is caused by ENODEV return for all dns queries like:
sendto(11, "\232\325\1\0\0\1\0\0\0\0\0\0\4mail\6google\3com\0\0\1\0"..., 33,
0, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr("62.241.198.245")}, 16) = -1 ENODEV (No such device)
Problem is reported and fixed:
https://bugzilla.redhat.com/show_bug.cgi?id=1367772
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=2675f2061525bc954be14988d64384b74aa7bf8b
I didn't yet test if applying that patch to ubuntu package works. I
will try the patch in a few hours.
ProblemType: Bug
DistroRelease: Ubuntu 16.10
Package: dnsmasq-base 2.76-4
ProcVersionSignature: Ubuntu 4.8.0-26.28-generic 4.8.0
Uname: Linux 4.8.0-26-generic x86_64
ApportVersion: 2.20.3-0ubuntu8
Architecture: amd64
CurrentDesktop: GNOME
Date: Mon Nov 7 14:11:51 2016
InstallationDate: Installed on 2037-12-25 (-7718 days ago)
InstallationMedia: Lubuntu 16.04 LTS "Xenial Xerus" - Release amd64
(20160420.1)
SourcePackage: dnsmasq
UpgradeStatus: Upgraded to yakkety on 2016-10-21 (16 days ago)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1639776/+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 1664994] Re: Black screen when trying to log in into unity8 session
** Attachment added: "unity-system-compositor.log" https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1664994/+attachment/4819575/+files/unity-system-compositor.log -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unity8 in Ubuntu. https://bugs.launchpad.net/bugs/1664994 Title: Black screen when trying to log in into unity8 session Status in unity8 package in Ubuntu: New Bug description: When I log in into unity8 I get a black screen. This is happening on xenial+overlay, using the unity8 snap. It seems to have started to happen after doing a dist-upgrade which installed packages from the overlay (15 Feb). Installed snaps: $ snap list NameVersion Rev Developer Notes address-book-app0.2+17.04.20161219-0ubuntu1 21canonical devmode camera-app 3.0.0+17.04.20170106-0ubuntu1 11canonical devmode core16.04.1 1079 canonical - gallery-app 0.0.67+17.04.20161213-0ubuntu1 13canonical devmode inkscape0.92.0 1880 inkscape - mediaplayer-app 0.20.5+17.04.20161201-0ubuntu1 x1 devmode ubuntu-app-platform 1 37canonical devmode ubuntu-calculator-app 2.3.1 26ubuntucoredev devmode ubuntu-calendar-app 0.1.1 22canonical devmode ubuntu-clock-app3.8.480 29ubuntucoredev devmode ubuntu-filemanager-app 0.4 10canonical devmode ubuntu-terminal-app 0.1142canonical devmode unity8-session 16.04 439 canonical devmode webbrowser-app 20170119~staging10canonical devmode See also attached unity-system-compositor.log and ~/user/.xsession- errors To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1664994/+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 1664994] [NEW] Black screen when trying to log in into unity8 session
Public bug reported: When I log in into unity8 I get a black screen. This is happening on xenial+overlay, using the unity8 snap. It seems to have started to happen after doing a dist-upgrade which installed packages from the overlay (15 Feb). Installed snaps: $ snap list NameVersion Rev Developer Notes address-book-app0.2+17.04.20161219-0ubuntu1 21canonical devmode camera-app 3.0.0+17.04.20170106-0ubuntu1 11canonical devmode core16.04.1 1079 canonical - gallery-app 0.0.67+17.04.20161213-0ubuntu1 13canonical devmode inkscape0.92.0 1880 inkscape - mediaplayer-app 0.20.5+17.04.20161201-0ubuntu1 x1 devmode ubuntu-app-platform 1 37canonical devmode ubuntu-calculator-app 2.3.1 26ubuntucoredev devmode ubuntu-calendar-app 0.1.1 22canonical devmode ubuntu-clock-app3.8.480 29ubuntucoredev devmode ubuntu-filemanager-app 0.4 10canonical devmode ubuntu-terminal-app 0.1142canonical devmode unity8-session 16.04 439 canonical devmode webbrowser-app 20170119~staging10canonical devmode See also attached unity-system-compositor.log and ~/user/.xsession- errors ** Affects: unity8 (Ubuntu) Importance: Undecided Status: New ** Attachment added: "xsession-errors" https://bugs.launchpad.net/bugs/1664994/+attachment/4819574/+files/xsession-errors -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unity8 in Ubuntu. https://bugs.launchpad.net/bugs/1664994 Title: Black screen when trying to log in into unity8 session Status in unity8 package in Ubuntu: New Bug description: When I log in into unity8 I get a black screen. This is happening on xenial+overlay, using the unity8 snap. It seems to have started to happen after doing a dist-upgrade which installed packages from the overlay (15 Feb). Installed snaps: $ snap list NameVersion Rev Developer Notes address-book-app0.2+17.04.20161219-0ubuntu1 21canonical devmode camera-app 3.0.0+17.04.20170106-0ubuntu1 11canonical devmode core16.04.1 1079 canonical - gallery-app 0.0.67+17.04.20161213-0ubuntu1 13canonical devmode inkscape0.92.0 1880 inkscape - mediaplayer-app 0.20.5+17.04.20161201-0ubuntu1 x1 devmode ubuntu-app-platform 1 37canonical devmode ubuntu-calculator-app 2.3.1 26ubuntucoredev devmode ubuntu-calendar-app 0.1.1 22canonical devmode ubuntu-clock-app3.8.480 29ubuntucoredev devmode ubuntu-filemanager-app 0.4 10canonical devmode ubuntu-terminal-app 0.1142canonical devmode unity8-session 16.04 439 canonical devmode webbrowser-app 20170119~staging10canonical devmode See also attached unity-system-compositor.log and ~/user/.xsession- errors To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1664994/+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 1577641] Re: Unity8 creates a blank black window for windowless apps
This is an issue for me too. The use case is media-hub on desktop. We render into a framebuffer object and pass the textures to other process (mediaplayer-app usually) that renders them in a window. We obviously do not want a window shown by media-hub-server, but we need to connect to mir to access the GPU and render into the fbo. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unity8 in Ubuntu. https://bugs.launchpad.net/bugs/1577641 Title: Unity8 creates a blank black window for windowless apps Status in Canonical System Image: New Status in Mir: Invalid Status in unity8 package in Ubuntu: Confirmed Bug description: Unity8 creates a blank black window for windowless apps. Windowless apps are closer thank you think: Xmir -rootless is one such example while no X apps have started yet. To manage notifications about this bug go to: https://bugs.launchpad.net/canonical-devices-system-image/+bug/1577641/+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 1653373] Re: [gst-hybris] Support COLOR_QCOM_FormatYVU420SemiPlanar32mMultiView color format.
PR proposed with the patch: https://code.launchpad.net/~alfonsosanchezbeato/ubuntu/+source/gst- plugins-bad1.0/+git/gst-plugins-bad1.0/+merge/314513 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gst-plugins-bad1.0 in Ubuntu. https://bugs.launchpad.net/bugs/1653373 Title: [gst-hybris] Support COLOR_QCOM_FormatYVU420SemiPlanar32mMultiView color format. Status in gst-plugins-bad1.0 package in Ubuntu: New Bug description: From gstamc-constants.h: /* NV12 but with stride and plane heights aligned to 32, Stores two images, * one after the other in top-bottom layout */ COLOR_QCOM_FormatYVU420SemiPlanar32mMultiView = 0x7fa30c05, Support is added by adding android-gst color format mapping, using the same code as COLOR_QCOM_FormatYUV420SemiPlanar to handle software conversion (as in gstamc.c) and adding special handling for multi-view nature of the format (as in gstamcvideodec.c). Adding support for this format fixes video playback on Fairphone 2. gst-plugins-bad1.0 version 1.8.2-1ubuntu0.1~overlay1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gst-plugins-bad1.0/+bug/1653373/+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 1630399] Re: [Phone] Please enable opus audio codec support in qtmultimedia
@d.filoni, you can find gstreamer0.10 and qtmultimedia packages in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2147 Please give the silo a try and let us know if things work as expected. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to qtmultimedia-opensource- src in Ubuntu. https://bugs.launchpad.net/bugs/1630399 Title: [Phone] Please enable opus audio codec support in qtmultimedia Status in Canonical System Image: In Progress Status in gst-plugins-bad0.10 package in Ubuntu: In Progress Status in qtmultimedia-opensource-src package in Ubuntu: In Progress Bug description: Hi, as described in QTBUG-50567 [1], qtmultimedia doesn't support opus audio codec so for example we cannot record Telegram voice messages ( bug #1460464 and bug #1375179 ). I patched qtmultimedia adding the support for audio/x-opus codec through opusdec encoder in qtmultimedia, then I found qtmultimedia 5.4.1 (shipped with Ubuntu Phone vivid) is built against gstreamer0.10 and, as gstreamer0.10-plugins-bad packages is not installed by default, opusdec encoder is not available. I'm working on this bug, I created it to track the progress, in order to add opus support I have to: 1 - create a new gstreamer0.10-opus package containing only the opusdec plugin: I don't know whether I have to create a new source package containing opusdec sources or only a new .deb package (generated from gst-plugins-bad0.10 sources). I'm working on the latter as gst-plugins-bad0.10 package requires work in any ways. 2 - properly patch qtmultimedia source, I'm attaching a working-but-needs-cleanup patch. I think some opus declarations in the attached patch can be avoided, but I haven't had time to work on it so I'm attaching the patch I tested (requires gstreamer0.10-plugins-bad). I don't know if qtmultimedia xenial/yakkety versions requires the patch too, I haven't checked them yet. [1] https://bugreports.qt.io/browse/QTBUG-50567 To manage notifications about this bug go to: https://bugs.launchpad.net/canonical-devices-system-image/+bug/1630399/+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 1630399] Re: [Phone] Please enable opus audio codec support in qtmultimedia
@d.filoni oh, I see, there is some glue code missing in qtmultimedia in all versions. That needs landing in xenial too indeed :) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to qtmultimedia-opensource- src in Ubuntu. https://bugs.launchpad.net/bugs/1630399 Title: [Phone] Please enable opus audio codec support in qtmultimedia Status in Canonical System Image: In Progress Status in gst-plugins-bad0.10 package in Ubuntu: In Progress Status in qtmultimedia-opensource-src package in Ubuntu: In Progress Bug description: Hi, as described in QTBUG-50567 [1], qtmultimedia doesn't support opus audio codec so for example we cannot record Telegram voice messages ( bug #1460464 and bug #1375179 ). I patched qtmultimedia adding the support for audio/x-opus codec through opusdec encoder in qtmultimedia, then I found qtmultimedia 5.4.1 (shipped with Ubuntu Phone vivid) is built against gstreamer0.10 and, as gstreamer0.10-plugins-bad packages is not installed by default, opusdec encoder is not available. I'm working on this bug, I created it to track the progress, in order to add opus support I have to: 1 - create a new gstreamer0.10-opus package containing only the opusdec plugin: I don't know whether I have to create a new source package containing opusdec sources or only a new .deb package (generated from gst-plugins-bad0.10 sources). I'm working on the latter as gst-plugins-bad0.10 package requires work in any ways. 2 - properly patch qtmultimedia source, I'm attaching a working-but-needs-cleanup patch. I think some opus declarations in the attached patch can be avoided, but I haven't had time to work on it so I'm attaching the patch I tested (requires gstreamer0.10-plugins-bad). I don't know if qtmultimedia xenial/yakkety versions requires the patch too, I haven't checked them yet. [1] https://bugreports.qt.io/browse/QTBUG-50567 To manage notifications about this bug go to: https://bugs.launchpad.net/canonical-devices-system-image/+bug/1630399/+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 1630399] Re: [Phone] Please enable opus audio codec support in qtmultimedia
Another note: playing opus works just fine because the code path in that case goes through qtmultimedia -> qtubuntu-media -> media-hub -> gstreamer 1.0. So the missing thing is opus encoding in vivid for qtmultimedia/gstreamer 0.10, and that is what Devid's patches fix. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to qtmultimedia-opensource- src in Ubuntu. https://bugs.launchpad.net/bugs/1630399 Title: [Phone] Please enable opus audio codec support in qtmultimedia Status in Canonical System Image: In Progress Status in gst-plugins-bad0.10 package in Ubuntu: In Progress Status in qtmultimedia-opensource-src package in Ubuntu: In Progress Bug description: Hi, as described in QTBUG-50567 [1], qtmultimedia doesn't support opus audio codec so for example we cannot record Telegram voice messages ( bug #1460464 and bug #1375179 ). I patched qtmultimedia adding the support for audio/x-opus codec through opusdec encoder in qtmultimedia, then I found qtmultimedia 5.4.1 (shipped with Ubuntu Phone vivid) is built against gstreamer0.10 and, as gstreamer0.10-plugins-bad packages is not installed by default, opusdec encoder is not available. I'm working on this bug, I created it to track the progress, in order to add opus support I have to: 1 - create a new gstreamer0.10-opus package containing only the opusdec plugin: I don't know whether I have to create a new source package containing opusdec sources or only a new .deb package (generated from gst-plugins-bad0.10 sources). I'm working on the latter as gst-plugins-bad0.10 package requires work in any ways. 2 - properly patch qtmultimedia source, I'm attaching a working-but-needs-cleanup patch. I think some opus declarations in the attached patch can be avoided, but I haven't had time to work on it so I'm attaching the patch I tested (requires gstreamer0.10-plugins-bad). I don't know if qtmultimedia xenial/yakkety versions requires the patch too, I haven't checked them yet. [1] https://bugreports.qt.io/browse/QTBUG-50567 To manage notifications about this bug go to: https://bugs.launchpad.net/canonical-devices-system-image/+bug/1630399/+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 1630399] Re: [Phone] Please enable opus audio codec support in qtmultimedia
@timo-jyrinki regarding whether this is fixed in xenial or newer: 1. xenial uses qtmultimedia 5.5.1, which depends on gstreamer1.0 2. gstreamer1.0 moved the opus[dec|enc] codecs to plugins-base in version 1.8, which is included by default in phone images So yes, this should be solved in xenial and newer. Note also that this issue is happening because qtmultimedia 5.4.1 uses old gstreamer 0.10. In fact you can already use opus in OTA13 by using directly gstreamer1.0 instead of via Qt. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to qtmultimedia-opensource- src in Ubuntu. https://bugs.launchpad.net/bugs/1630399 Title: [Phone] Please enable opus audio codec support in qtmultimedia Status in Canonical System Image: In Progress Status in gst-plugins-bad0.10 package in Ubuntu: In Progress Status in qtmultimedia-opensource-src package in Ubuntu: In Progress Bug description: Hi, as described in QTBUG-50567 [1], qtmultimedia doesn't support opus audio codec so for example we cannot record Telegram voice messages ( bug #1460464 and bug #1375179 ). I patched qtmultimedia adding the support for audio/x-opus codec through opusdec encoder in qtmultimedia, then I found qtmultimedia 5.4.1 (shipped with Ubuntu Phone vivid) is built against gstreamer0.10 and, as gstreamer0.10-plugins-bad packages is not installed by default, opusdec encoder is not available. I'm working on this bug, I created it to track the progress, in order to add opus support I have to: 1 - create a new gstreamer0.10-opus package containing only the opusdec plugin: I don't know whether I have to create a new source package containing opusdec sources or only a new .deb package (generated from gst-plugins-bad0.10 sources). I'm working on the latter as gst-plugins-bad0.10 package requires work in any ways. 2 - properly patch qtmultimedia source, I'm attaching a working-but-needs-cleanup patch. I think some opus declarations in the attached patch can be avoided, but I haven't had time to work on it so I'm attaching the patch I tested (requires gstreamer0.10-plugins-bad). I don't know if qtmultimedia xenial/yakkety versions requires the patch too, I haven't checked them yet. [1] https://bugreports.qt.io/browse/QTBUG-50567 To manage notifications about this bug go to: https://bugs.launchpad.net/canonical-devices-system-image/+bug/1630399/+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
