[Touch-packages] [Bug 1965535] Re: Stop recommending snap
+1 For the record, Snap being forced upon users for critical packages is the primary reason why I recently dropped Ubuntu and stopped recommending the distro to others, after using it for over 15 years. Container-based packaging has its place. Snap has some interesting features compared to FlatPak and AppImage. However, none of them are suitable replacements for deb & apt, and this is really driven home when they're used for core packages like the web browser. Snap in particular has multiple fundamental design and implementation problems that make it intolerable. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-meta in Ubuntu. https://bugs.launchpad.net/bugs/1965535 Title: Stop recommending snap Status in ubuntu-meta package in Ubuntu: Opinion Bug description: Currently, ubuntu recommends installing snap by default, and some apps are slowly transitioning from DEB-based installation to Snap-based installation. APT is great, and facilitates having a clean, maintainable system. The snap project is not very well designed or engineered (just changing the location of where snap data is located is taking the project more than 5 years because it was hardcoded: https://bugs.launchpad.net/snapd/+bug/1575053). Snaps are large and VERY slow. The design of snap, as well as the way that decisions are made, are very questionable, and are receiving increasing amounts of criticism. I'd like to request that Ubuntu stops recommending snap, stops transitioning towards snaps, and we come back to defaulting to DEB/APT-based installation for all apps. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1965535/+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 1547589] Re: rtkit-daemon flooding syslog
** Bug watch added: github.com/heftig/rtkit/issues #22 https://github.com/heftig/rtkit/issues/22 ** Also affects: rtkit via https://github.com/heftig/rtkit/issues/22 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rtkit in Ubuntu. https://bugs.launchpad.net/bugs/1547589 Title: rtkit-daemon flooding syslog Status in Rtkit: Unknown Status in rtkit package in Ubuntu: Confirmed Status in rtkit package in Debian: Confirmed Bug description: rtkit is flooding syslog with the following: Feb 19 11:42:07 galactica rtkit-daemon[20798]: Supervising 0 threads of 0 processes of 1 users. Feb 19 11:42:07 galactica rtkit-daemon[20798]: Warning: Reached burst limit for user '1000', denying request. Feb 19 11:42:07 galactica rtkit-daemon[20798]: Supervising 0 threads of 0 processes of 1 users. Feb 19 11:42:07 galactica rtkit-daemon[20798]: Warning: Reached burst limit for user '1000', denying request. Feb 19 11:42:07 galactica rtkit-daemon[20798]: Supervising 0 threads of 0 processes of 1 users. Feb 19 11:42:07 galactica rtkit-daemon[20798]: Warning: Reached burst limit for user '1000', denying request. Feb 19 11:42:07 galactica rtkit-daemon[20798]: Supervising 0 threads of 0 processes of 1 users. Feb 19 11:42:07 galactica rtkit-daemon[20798]: Warning: Reached burst limit for user '1000', denying request. Feb 19 11:42:07 galactica rtkit-daemon[20798]: Supervising 0 threads of 0 processes of 1 users. Feb 19 11:42:07 galactica rtkit-daemon[20798]: Warning: Reached burst limit for user '1000', denying request. Feb 19 11:42:07 galactica rtkit-daemon[20798]: Supervising 0 threads of 0 processes of 1 users. Feb 19 11:42:07 galactica rtkit-daemon[20798]: Warning: Reached burst limit for user '1000', denying request. Feb 19 11:42:07 galactica rtkit-daemon[20798]: Supervising 0 threads of 0 processes of 1 users. Feb 19 11:42:07 galactica rtkit-daemon[20798]: Warning: Reached burst limit for user '1000', denying request. Feb 19 11:42:07 galactica rtkit-daemon[20798]: Supervising 0 threads of 0 processes of 1 users. Feb 19 11:42:07 galactica rtkit-daemon[20798]: Warning: Reached burst limit for user '1000', denying request. This may be related to but #1547585 ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: rtkit 0.11-4 ProcVersionSignature: Ubuntu 4.4.0-6.21-generic 4.4.1 Uname: Linux 4.4.0-6-generic x86_64 ApportVersion: 2.20-0ubuntu3 Architecture: amd64 CurrentDesktop: Unity Date: Fri Feb 19 11:42:58 2016 InstallationDate: Installed on 2016-02-11 (7 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Alpha amd64 (20160210) SourcePackage: rtkit UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/rtkit/+bug/1547589/+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 1718658] Re: ecryptfs-mount-private fails to initialize ecryptfs keys
I hate to say this, folks, but ecryptfs looks like a dead end for us. It's no longer supported by Ubuntu (the package has been moved to the Universe repo). Also, the problem at hand is caused by systemd, which is run by a man famous for releasing poorly-vetted, system-breaking software, and then refusing to fix the damage he causes. For a year or so, I maintained a systemd patch to work around this bug. (It is posted above, but no longer applies to current systemd code.) There was a time when it looked like the problem was finally fixed upstream, but then it just broke again. Anyone who (like me) has been using ecryptfs to encrypt a private directory and unlock it only when needed, might consider switching to gocryptfs. From a user's point of view, it works similarly to ecryptfs. There's also a handy GUI called SiriKali that works with it. https://nuetzlich.net/gocryptfs/ https://mhogomchungu.github.io/sirikali/ Good luck. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1718658 Title: ecryptfs-mount-private fails to initialize ecryptfs keys Status in ecryptfs-utils package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: ecryptfs-mount-private fails to mount the ecryptfs after the 1st reboot after creating the ecryptfs by ecryptfs-setup-private. After the unsucessful attempt dmesg contains: [ 1265.695388] Could not find key with description: [] [ 1265.695393] process_request_key_err: No key [ 1265.695394] Could not find valid key in user session keyring for sig specified in mount option: [] [ 1265.695395] One or more global auth toks could not properly register; rc = [-2] [ 1265.695396] Error parsing options; rc = [-2] Note: The correct key ID has been replaced in the "". I also accidentally found an workaround - just running ecrytpfs- manager and then the ecryptfs-mount-private (it does not ask for password for the second time and mounts the ecryptfs correctly): host:~$ ecryptfs-manager eCryptfs key management menu --- 1. Add passphrase key to keyring 2. Add public key to keyring 3. Generate new public/private keypair 4. Exit Make selection: 4 host:~$ ls Private/ Access-Your-Private-Data.desktop README.txt host:~$ ecryptfs-mount-private host:~$ ls Private/ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1718658/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1877219] Re: dozens of empty grilo-plugin-cache folders polluting /tmp
** Bug watch added: gitlab.gnome.org/GNOME/grilo-plugins/-/issues #70 https://gitlab.gnome.org/GNOME/grilo-plugins/-/issues/70 ** Also affects: grilo-plugins via https://gitlab.gnome.org/GNOME/grilo-plugins/-/issues/70 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to grilo-plugins in Ubuntu. https://bugs.launchpad.net/bugs/1877219 Title: dozens of empty grilo-plugin-cache folders polluting /tmp Status in Grilo Plugins: Unknown Status in grilo-plugins package in Ubuntu: New Bug description: My /tmp folder has dozens of empty folders with names like grilo- plugin-cache-ABCDEF. I don't know anything about grilo-plugins, but surely they can do their job without leaving endless garbage directories behind when they're done? $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 19.10 Release: 19.10 Codename: eoan $ dpkg-query --show grilo-plugins-0.3-base grilo-plugins-0.3-base:amd64 0.3.9-1ubuntu1 To manage notifications about this bug go to: https://bugs.launchpad.net/grilo-plugins/+bug/1877219/+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 1877219] [NEW] dozens of empty grilo-plugin-cache folders polluting /tmp
Public bug reported: My /tmp folder has dozens of empty folders with names like grilo-plugin- cache-ABCDEF. I don't know anything about grilo-plugins, but surely they can do their job without leaving endless garbage directories behind when they're done? $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 19.10 Release:19.10 Codename: eoan $ dpkg-query --show grilo-plugins-0.3-base grilo-plugins-0.3-base:amd640.3.9-1ubuntu1 ** Affects: grilo-plugins (Ubuntu) Importance: Undecided Status: New ** Description changed: My /tmp folder has dozens of empty folders with names like grilo-plugin- cache-ABCDEF. I don't know anything about grilo-plugins, but surely they can do their job without leaving endless garbage directories behind when they're done? + + $ lsb_release -a + No LSB modules are available. + Distributor ID: Ubuntu + Description: Ubuntu 19.10 + Release: 19.10 + Codename: eoan + + $ dpkg-query --show grilo-plugins-0.3-base + grilo-plugins-0.3-base:amd64 0.3.9-1ubuntu1 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to grilo-plugins in Ubuntu. https://bugs.launchpad.net/bugs/1877219 Title: dozens of empty grilo-plugin-cache folders polluting /tmp Status in grilo-plugins package in Ubuntu: New Bug description: My /tmp folder has dozens of empty folders with names like grilo- plugin-cache-ABCDEF. I don't know anything about grilo-plugins, but surely they can do their job without leaving endless garbage directories behind when they're done? $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 19.10 Release: 19.10 Codename: eoan $ dpkg-query --show grilo-plugins-0.3-base grilo-plugins-0.3-base:amd64 0.3.9-1ubuntu1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grilo-plugins/+bug/1877219/+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 1866124] Re: ps -eo lxc no longer shows a task's lxc container
The top command's LXC column (not shown by default, but can be enabled through the 'f' menu) also shows a - for all processes, including those that belong to containers. My containers are unprivileged, in case that matters. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1866124 Title: ps -eo lxc no longer shows a task's lxc container Status in lxc package in Ubuntu: New Status in procps package in Ubuntu: New Bug description: When I use the ps command's "lxc" format specifier, for example: ps -eo pid,lxc,command The second output column is supposed to show "the name of the lxc container within which a task is running. If a process is not running inside a container, a dash ('-') will be shown." [1] This worked fine until I upgraded from ubuntu 19.04 to 19.10, which brought me from lxc 3.03 to 3.04. Now, that column always contains a dash instead of the container name, even for processes that are running inside a container. The "lxc" format specifier seems to be broken now. [1] https://manpages.ubuntu.com/manpages/eoan/man1/ps.1.html#standard%20format%20specifiers To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1866124/+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 1866124] [NEW] ps -eo lxc no longer shows a task's lxc container
Public bug reported: When I use the ps command's "lxc" format specifier, for example: ps -eo pid,lxc,command The second output column is supposed to show "the name of the lxc container within which a task is running. If a process is not running inside a container, a dash ('-') will be shown." [1] This worked fine until I upgraded from ubuntu 19.04 to 19.10, which brought me from lxc 3.03 to 3.04. Now, that column always contains a dash instead of the container name, even for processes that are running inside a container. The "lxc" format specifier seems to be broken now. [1] https://manpages.ubuntu.com/manpages/eoan/man1/ps.1.html#standard%20format%20specifiers ** Affects: lxc (Ubuntu) Importance: Undecided Status: New ** Affects: procps (Ubuntu) Importance: Undecided Status: New ** Also affects: lxc (Ubuntu) Importance: Undecided Status: New ** Description changed: When I use the ps command's "lxc" format specifier, for example: ps -eo pid,lxc,command The second output column is supposed to show "the name of the lxc container within which a task is running. If a process is not running inside a container, a dash ('-') will be shown." [1] - This worked fine until I upgraded from ubuntu 19.04 to 19.10. Now, that - column always contains a dash instead of the container name, even for - processes that are running inside a container. The "lxc" format - specifier seems to be broken now. + This worked fine until I upgraded from ubuntu 19.04 to 19.10, which + brought me from lxc 3.03 to 3.04. Now, that column always contains a + dash instead of the container name, even for processes that are running + inside a container. The "lxc" format specifier seems to be broken now. - - [1] https://manpages.ubuntu.com/manpages/eoan/man1/ps.1.html#standard%20format%20specifiers + [1] + https://manpages.ubuntu.com/manpages/eoan/man1/ps.1.html#standard%20format%20specifiers -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to procps in Ubuntu. https://bugs.launchpad.net/bugs/1866124 Title: ps -eo lxc no longer shows a task's lxc container Status in lxc package in Ubuntu: New Status in procps package in Ubuntu: New Bug description: When I use the ps command's "lxc" format specifier, for example: ps -eo pid,lxc,command The second output column is supposed to show "the name of the lxc container within which a task is running. If a process is not running inside a container, a dash ('-') will be shown." [1] This worked fine until I upgraded from ubuntu 19.04 to 19.10, which brought me from lxc 3.03 to 3.04. Now, that column always contains a dash instead of the container name, even for processes that are running inside a container. The "lxc" format specifier seems to be broken now. [1] https://manpages.ubuntu.com/manpages/eoan/man1/ps.1.html#standard%20format%20specifiers To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1866124/+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 1843490] [NEW] lxc.cgroup.devices.allow prevents unprivileged container from starting
Public bug reported: Adding lxc.cgroup.devices.allow directives to an unprivileged container config prevent the container from starting. These lxc-start errors look relevant: lxc-start testbox 20190910192712.171 WARN cgfsng - cgroups/cgfsng.c:get_hierarchy:204 - There is no useable devices controller lxc-start testbox 20190910192712.171 ERRORcgfsng - cgroups/cgfsng.c:cg_legacy_set_data:2191 - Failed to setup limits for the "devices" controller. The controller seems to be unused by "cgfsng" cgroup driver or not enabled on the cgroup hierarchy lxc-start testbox 20190910192712.171 WARN cgfsng - cgroups/cgfsng.c:__cg_legacy_setup_limits:2228 - Failed to set "devices.allow" to "c 10:57 rwm" It seems to me that I used lxc.cgroup.devices.allow directives without trouble a few years ago. I wonder which system upgrades broke it. To reproduce: (Note: subuid, subgid, and lxc-usernet are already configured for this user.) $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 19.04 Release:19.04 Codename: disco $ dpkg-query --show libpam-cgfs lxc1 libpam-cgfs 3.0.3-0ubuntu1 lxc13.0.3-0ubuntu1 $ lxc-create -t download -n testbox -- -d ubuntu -r bionic -a amd64 The cached copy has expired, re-downloading... Setting up the GPG keyring Downloading the image index Downloading the rootfs Downloading the metadata The image cache is now ready Unpacking the rootfs --- You just created an Ubuntu bionic amd64 (20190910_07:42) container. To enable SSH, run: apt install openssh-server No default root or user password are set by LXC. $ echo "lxc.cgroup.devices.allow = c 10:57 rwm" >> lxc/testbox/config $ lxc-start -n testbox -o debug.out -l trace lxc-start: testbox: lxccontainer.c: wait_on_daemonized_start: 842 Received container state "ABORTING" instead of "RUNNING" lxc-start: testbox: tools/lxc_start.c: main: 330 The container failed to start lxc-start: testbox: tools/lxc_start.c: main: 333 To get more details, run the container in foreground mode lxc-start: testbox: tools/lxc_start.c: main: 336 Additional information can be obtained by setting the --logfile and --logpriority options $ cat debug.out lxc-start testbox 20190910192712.380 INFO confile - confile.c:set_config_idmaps:1555 - Read uid map: type u nsid 0 hostid 10 range 65536 lxc-start testbox 20190910192712.380 INFO confile - confile.c:set_config_idmaps:1555 - Read uid map: type g nsid 0 hostid 10 range 65536 lxc-start testbox 20190910192712.382 TRACEcommands - commands.c:lxc_cmd:300 - Connection refused - Command "get_init_pid" failed to connect command socket lxc-start testbox 20190910192712.383 TRACEcommands - commands.c:lxc_cmd:300 - Connection refused - Command "get_state" failed to connect command socket lxc-start testbox 20190910192712.383 TRACEstart - start.c:lxc_init_handler:748 - Created anonymous pair {4,5} of unix sockets lxc-start testbox 20190910192712.383 TRACEcommands - commands.c:lxc_cmd_init:1248 - Creating abstract unix socket "/home/ubuntu/lxc/testbox/command" lxc-start testbox 20190910192712.383 TRACEstart - start.c:lxc_init_handler:760 - Unix domain socket 6 for command server is ready lxc-start testbox 20190910192712.388 INFO lxccontainer - lxccontainer.c:do_lxcapi_start:961 - Set process title to [lxc monitor] /home/ubuntu/lxc testbox lxc-start testbox 20190910192712.392 TRACEstart - start.c:lxc_start:2052 - Doing lxc_start lxc-start testbox 20190910192712.393 INFO lsm - lsm/lsm.c:lsm_init:50 - LSM security driver AppArmor lxc-start testbox 20190910192712.393 TRACEstart - start.c:lxc_init:777 - Initialized LSM lxc-start testbox 20190910192712.395 TRACEseccomp - seccomp.c:get_new_ctx:458 - Added arch 2 to main seccomp context lxc-start testbox 20190910192712.395 TRACEseccomp - seccomp.c:get_new_ctx:466 - Removed native arch from main seccomp context lxc-start testbox 20190910192712.395 TRACEseccomp - seccomp.c:get_new_ctx:458 - Added arch 3 to main seccomp context lxc-start testbox 20190910192712.395 TRACEseccomp - seccomp.c:get_new_ctx:466 - Removed native arch from main seccomp context lxc-start testbox 20190910192712.395 TRACEseccomp - seccomp.c:get_new_ctx:471 - Arch 4 already present in main seccomp context lxc-start testbox 20190910192712.395 INFO seccomp - seccomp.c:parse_config_v2:759 - Processing "reject_force_umount # comment this to allow umount -f; not recommended" lxc-start testbox 20190910192712.395 INFO seccomp - seccomp.c:do_resolve_add_rule:505 - Set seccomp rule to reject force umounts lxc-start testbox 20190910192712.395 INFO seccomp - seccomp.c:parse_config_v2:937 - Added native rule for arch 0 for reject_force_umount action 0(kill) lxc-start testbox 20190910192712.396 INFO seccomp - seccomp.c:do_resolve_add_rule:505 - Set seccomp rule to reject force umounts lxc-start testbox 20190910192712.396 INFO seccomp - sec
[Touch-packages] [Bug 1718658] Re: ecryptfs-mount-private fails to initialize ecryptfs keys
The systemd patch I posted earlier no longer works in disco, and the workarounds posted here only partially fix the problem and only for a subset of use cases. Looks like we're back to needing a proper fix. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1718658 Title: ecryptfs-mount-private fails to initialize ecryptfs keys Status in ecryptfs-utils package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: ecryptfs-mount-private fails to mount the ecryptfs after the 1st reboot after creating the ecryptfs by ecryptfs-setup-private. After the unsucessful attempt dmesg contains: [ 1265.695388] Could not find key with description: [] [ 1265.695393] process_request_key_err: No key [ 1265.695394] Could not find valid key in user session keyring for sig specified in mount option: [] [ 1265.695395] One or more global auth toks could not properly register; rc = [-2] [ 1265.695396] Error parsing options; rc = [-2] Note: The correct key ID has been replaced in the "". I also accidentally found an workaround - just running ecrytpfs- manager and then the ecryptfs-mount-private (it does not ask for password for the second time and mounts the ecryptfs correctly): host:~$ ecryptfs-manager eCryptfs key management menu --- 1. Add passphrase key to keyring 2. Add public key to keyring 3. Generate new public/private keypair 4. Exit Make selection: 4 host:~$ ls Private/ Access-Your-Private-Data.desktop README.txt host:~$ ecryptfs-mount-private host:~$ ls Private/ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1718658/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1718658] Re: ecryptfs-mount-private fails to initialize ecryptfs keys
Still broken in disco. ** Tags added: disco -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1718658 Title: ecryptfs-mount-private fails to initialize ecryptfs keys Status in ecryptfs-utils package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: ecryptfs-mount-private fails to mount the ecryptfs after the 1st reboot after creating the ecryptfs by ecryptfs-setup-private. After the unsucessful attempt dmesg contains: [ 1265.695388] Could not find key with description: [] [ 1265.695393] process_request_key_err: No key [ 1265.695394] Could not find valid key in user session keyring for sig specified in mount option: [] [ 1265.695395] One or more global auth toks could not properly register; rc = [-2] [ 1265.695396] Error parsing options; rc = [-2] Note: The correct key ID has been replaced in the "". I also accidentally found an workaround - just running ecrytpfs- manager and then the ecryptfs-mount-private (it does not ask for password for the second time and mounts the ecryptfs correctly): host:~$ ecryptfs-manager eCryptfs key management menu --- 1. Add passphrase key to keyring 2. Add public key to keyring 3. Generate new public/private keypair 4. Exit Make selection: 4 host:~$ ls Private/ Access-Your-Private-Data.desktop README.txt host:~$ ecryptfs-mount-private host:~$ ls Private/ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1718658/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1718658] Re: ecryptfs-mount-private fails to initialize ecryptfs keys
A systemd build with my patch applied is available here: https://launchpad.net/~foresto/+archive/ubuntu/ubuntutweaks/ -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1718658 Title: ecryptfs-mount-private fails to initialize ecryptfs keys Status in ecryptfs-utils package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: ecryptfs-mount-private fails to mount the ecryptfs after the 1st reboot after creating the ecryptfs by ecryptfs-setup-private. After the unsucessful attempt dmesg contains: [ 1265.695388] Could not find key with description: [] [ 1265.695393] process_request_key_err: No key [ 1265.695394] Could not find valid key in user session keyring for sig specified in mount option: [] [ 1265.695395] One or more global auth toks could not properly register; rc = [-2] [ 1265.695396] Error parsing options; rc = [-2] Note: The correct key ID has been replaced in the "". I also accidentally found an workaround - just running ecrytpfs- manager and then the ecryptfs-mount-private (it does not ask for password for the second time and mounts the ecryptfs correctly): host:~$ ecryptfs-manager eCryptfs key management menu --- 1. Add passphrase key to keyring 2. Add public key to keyring 3. Generate new public/private keypair 4. Exit Make selection: 4 host:~$ ls Private/ Access-Your-Private-Data.desktop README.txt host:~$ ecryptfs-mount-private host:~$ ls Private/ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1718658/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1718658] Re: ecryptfs-mount-private fails to initialize ecryptfs keys
The ecryptfs-manager workaround helps the mount to succeed, but (at least in my case) the system refuses to unmount it afterward. This is a problem for those of us who open our ecryptfs volumes only for as long as they're needed. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1718658 Title: ecryptfs-mount-private fails to initialize ecryptfs keys Status in ecryptfs-utils package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: ecryptfs-mount-private fails to mount the ecryptfs after the 1st reboot after creating the ecryptfs by ecryptfs-setup-private. After the unsucessful attempt dmesg contains: [ 1265.695388] Could not find key with description: [] [ 1265.695393] process_request_key_err: No key [ 1265.695394] Could not find valid key in user session keyring for sig specified in mount option: [] [ 1265.695395] One or more global auth toks could not properly register; rc = [-2] [ 1265.695396] Error parsing options; rc = [-2] Note: The correct key ID has been replaced in the "". I also accidentally found an workaround - just running ecrytpfs- manager and then the ecryptfs-mount-private (it does not ask for password for the second time and mounts the ecryptfs correctly): host:~$ ecryptfs-manager eCryptfs key management menu --- 1. Add passphrase key to keyring 2. Add public key to keyring 3. Generate new public/private keypair 4. Exit Make selection: 4 host:~$ ls Private/ Access-Your-Private-Data.desktop README.txt host:~$ ecryptfs-mount-private host:~$ ls Private/ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1718658/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1718658] Re: ecryptfs-mount-private fails to initialize ecryptfs keys
This is a systemd bug, created by this commit: https://github.com/systemd/systemd/commit/74dd6b5 It looks like poettering has attempted to address it in more recent versions of systemd (though that doesn't help us in ubuntu 17.10): https://github.com/systemd/systemd/pull/6832 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1718658 Title: ecryptfs-mount-private fails to initialize ecryptfs keys Status in ecryptfs-utils package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: ecryptfs-mount-private fails to mount the ecryptfs after the 1st reboot after creating the ecryptfs by ecryptfs-setup-private. After the unsucessful attempt dmesg contains: [ 1265.695388] Could not find key with description: [] [ 1265.695393] process_request_key_err: No key [ 1265.695394] Could not find valid key in user session keyring for sig specified in mount option: [] [ 1265.695395] One or more global auth toks could not properly register; rc = [-2] [ 1265.695396] Error parsing options; rc = [-2] Note: The correct key ID has been replaced in the "". I also accidentally found an workaround - just running ecrytpfs- manager and then the ecryptfs-mount-private (it does not ask for password for the second time and mounts the ecryptfs correctly): host:~$ ecryptfs-manager eCryptfs key management menu --- 1. Add passphrase key to keyring 2. Add public key to keyring 3. Generate new public/private keypair 4. Exit Make selection: 4 host:~$ ls Private/ Access-Your-Private-Data.desktop README.txt host:~$ ecryptfs-mount-private host:~$ ls Private/ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1718658/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1718658] Re: ecryptfs-mount-private fails to initialize ecryptfs keys
Here's a simple patch to disable the broken systemd feature, and restore ecryptfs functionality. ** Patch added: "disable_system_service_session_keyrings.patch" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1718658/+attachment/5038578/+files/disable_system_service_session_keyrings.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/1718658 Title: ecryptfs-mount-private fails to initialize ecryptfs keys Status in ecryptfs-utils package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: ecryptfs-mount-private fails to mount the ecryptfs after the 1st reboot after creating the ecryptfs by ecryptfs-setup-private. After the unsucessful attempt dmesg contains: [ 1265.695388] Could not find key with description: [] [ 1265.695393] process_request_key_err: No key [ 1265.695394] Could not find valid key in user session keyring for sig specified in mount option: [] [ 1265.695395] One or more global auth toks could not properly register; rc = [-2] [ 1265.695396] Error parsing options; rc = [-2] Note: The correct key ID has been replaced in the "". I also accidentally found an workaround - just running ecrytpfs- manager and then the ecryptfs-mount-private (it does not ask for password for the second time and mounts the ecryptfs correctly): host:~$ ecryptfs-manager eCryptfs key management menu --- 1. Add passphrase key to keyring 2. Add public key to keyring 3. Generate new public/private keypair 4. Exit Make selection: 4 host:~$ ls Private/ Access-Your-Private-Data.desktop README.txt host:~$ ecryptfs-mount-private host:~$ ls Private/ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1718658/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1726873] Re: mount.ecryptfs_private can't mount in 17.10
*** This bug is a duplicate of bug 1718658 *** https://bugs.launchpad.net/bugs/1718658 ** Also affects: systemd (Ubuntu) Importance: Undecided Status: New ** This bug has been marked a duplicate of bug 1718658 ecryptfs-mount-private fails to initialize ecryptfs keys -- 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/1726873 Title: mount.ecryptfs_private can't mount in 17.10 Status in ecryptfs-utils package in Ubuntu: Confirmed Status in systemd package in Ubuntu: New Bug description: Hi, I am using several ecryptfs mounts with ecryptfs-add-passphrase and mount.ecryptfs_private, configured in ~/.ecryptfs/xxx.conf and ~/.ecryptfs/xxx.sig, which was working well for years up to 17.04. With 17.10 I can't mount these file systems anymore. ecryptfs-add-passphrase says Inserted auth tok with sig [] into the user session keyring with the correct sig (!). Trying to mount with mount.ecryptfs_private then says mount: No such file or directory although all directories present and correct. the Kernel then says (dmesg): [10149.247972] Could not find key with description: [...] [10149.247994] process_request_key_err: No key [10149.248000] Could not find valid key in user session keyring for sig specified in mount option: [...] [10149.248012] One or more global auth toks could not properly register; rc = [-2] [10149.248019] Error parsing options; rc = [-2] with exactly the same sig! So although ecryptfs-add-passphrase claimed to have added the key to the keyring, the kernel complains that it could not find such a key. ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: ecryptfs-utils 111-0ubuntu5 ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4 Uname: Linux 4.13.0-16-generic x86_64 NonfreeKernelModules: zfs zunicode zavl zcommon znvpair ApportVersion: 2.20.7-0ubuntu3 Architecture: amd64 CurrentDesktop: LXDE Date: Tue Oct 24 15:31:45 2017 InstallationDate: Installed on 2017-10-24 (0 days ago) InstallationMedia: Lubuntu 17.10 "Artful Aardvark" - Release amd64 (20171017.1) SourcePackage: ecryptfs-utils UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1726873/+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 1718658] Re: ecryptfs-mount-private fails to initialize ecryptfs keys
** Also 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/1718658 Title: ecryptfs-mount-private fails to initialize ecryptfs keys Status in ecryptfs-utils package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: ecryptfs-mount-private fails to mount the ecryptfs after the 1st reboot after creating the ecryptfs by ecryptfs-setup-private. After the unsucessful attempt dmesg contains: [ 1265.695388] Could not find key with description: [] [ 1265.695393] process_request_key_err: No key [ 1265.695394] Could not find valid key in user session keyring for sig specified in mount option: [] [ 1265.695395] One or more global auth toks could not properly register; rc = [-2] [ 1265.695396] Error parsing options; rc = [-2] Note: The correct key ID has been replaced in the "". I also accidentally found an workaround - just running ecrytpfs- manager and then the ecryptfs-mount-private (it does not ask for password for the second time and mounts the ecryptfs correctly): host:~$ ecryptfs-manager eCryptfs key management menu --- 1. Add passphrase key to keyring 2. Add public key to keyring 3. Generate new public/private keypair 4. Exit Make selection: 4 host:~$ ls Private/ Access-Your-Private-Data.desktop README.txt host:~$ ecryptfs-mount-private host:~$ ls Private/ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1718658/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1699660] Re: systemd-resolve breaks resolution of local network hostnames
No, that won't help either. You don't seem to understand: Adding a domain search list will not help because the local machines do not have domains. They only have names, like "host1" or "beetle", even on the network's DNS servers. Since systemd's resolver refuses to consult the name servers for names like these, it completely breaks name resolution on networks like this. -- 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/1699660 Title: systemd-resolve breaks resolution of local network hostnames Status in systemd package in Ubuntu: New Bug description: After upgrading to Ubuntu 17.04 (zesty), resolution of my local network's host names is completely broken. Apparently the upgrade replaced my existing resolver with systemd-resolve, which deliberately refuses to pass "single-label" domain names to my domain name server. That is the server where all my network's host names are kept, so I can no longer resolve any of them. Apparently, this is yet another example of Poettering's upstream decisions causing denial of service to people who have been saddled with his malware. https://github.com/systemd/systemd/issues/2514#issuecomment-179203186 Would someone sensible please put a stop to this forced breakage during upgrade, and advise on how to fix it now that the damage has been done? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1699660/+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 1699660] Re: systemd-resolve breaks resolution of local network hostnames
According to the systemd documentation, UseDomains only affects systems that get their network setup from DHCP, which is not the case at my site. Furthermore, it is documented as a way to add a DNS search domain, which would not help resolve hosts that have no domains. So far, the only way I have found to fix the breakage is to manually disable systemd-resolve and configure a resolver that actually works properly. -- 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/1699660 Title: systemd-resolve breaks resolution of local network hostnames Status in systemd package in Ubuntu: New Bug description: After upgrading to Ubuntu 17.04 (zesty), resolution of my local network's host names is completely broken. Apparently the upgrade replaced my existing resolver with systemd-resolve, which deliberately refuses to pass "single-label" domain names to my domain name server. That is the server where all my network's host names are kept, so I can no longer resolve any of them. Apparently, this is yet another example of Poettering's upstream decisions causing denial of service to people who have been saddled with his malware. https://github.com/systemd/systemd/issues/2514#issuecomment-179203186 Would someone sensible please put a stop to this forced breakage during upgrade, and advise on how to fix it now that the damage has been done? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1699660/+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 1699660] [NEW] systemd-resolve breaks resolution of local network hostnames
Public bug reported: After upgrading to Ubuntu 17.04 (zesty), resolution of my local network's host names is completely broken. Apparently the upgrade replaced my existing resolver with systemd-resolve, which deliberately refuses to pass "single-label" domain names to my domain name server. That is the server where all my network's host names are kept, so I can no longer resolve any of them. Apparently, this is yet another example of Poettering's upstream decisions causing denial of service to people who have been saddled with his malware. https://github.com/systemd/systemd/issues/2514#issuecomment-179203186 Would someone sensible please put a stop to this forced breakage during upgrade, and advise on how to fix it now that the damage has been done? ** 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/1699660 Title: systemd-resolve breaks resolution of local network hostnames Status in systemd package in Ubuntu: New Bug description: After upgrading to Ubuntu 17.04 (zesty), resolution of my local network's host names is completely broken. Apparently the upgrade replaced my existing resolver with systemd-resolve, which deliberately refuses to pass "single-label" domain names to my domain name server. That is the server where all my network's host names are kept, so I can no longer resolve any of them. Apparently, this is yet another example of Poettering's upstream decisions causing denial of service to people who have been saddled with his malware. https://github.com/systemd/systemd/issues/2514#issuecomment-179203186 Would someone sensible please put a stop to this forced breakage during upgrade, and advise on how to fix it now that the damage has been done? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1699660/+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 1528173] Re: org.freedesktop.DBus.Properties.GetAll fails always for fi.w1.wpa_supplicant1.Interface interface
I'm actually a bit confused -- the bug status is "fix released" but it is not at all clear to me in what Ubuntu release this fix has been applied. Can someone clarify this for me? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to wpa in Ubuntu. https://bugs.launchpad.net/bugs/1528173 Title: org.freedesktop.DBus.Properties.GetAll fails always for fi.w1.wpa_supplicant1.Interface interface Status in wpa package in Ubuntu: Fix Released Bug description: With our package for wpa-supplicant a call $ sudo gdbus call -y -d fi.w1.wpa_supplicant1 -o /fi/w1/wpa_supplicant1/Interfaces/1 -m org.freedesktop.DBus.Properties.GetAll 'fi.w1.wpa_supplicant1.Interface' fails always with Error: GDBus.Error:org.freedesktop.DBus.Error.InvalidArgs: No readable properties in this interface The reason for this is that the internal properties getter routine will never return any result when one internal getter fails. The responsible property here is the "Stations" one which was added by a patch in Ubuntu and is not available upstream. Take a look at https://bazaar.launchpad.net/~ubuntu- branches/ubuntu/wily/wpa/wily/view/head:/debian/patches/dbus- available-sta.patch The getter method wpas_dbus_getter_stas expects the ap_iface element to be see which isn't always the case and if that isn't true it will return false and causes the whole Properties.GetAll call to fail. The expected result is that the getter just returns an empty list if it can't determine the actual value. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1528173/+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 1528173] Re: org.freedesktop.DBus.Properties.GetAll fails always for fi.w1.wpa_supplicant1.Interface interface
This bug completely breaks WiFi support on my system using ConnMan. Took a bit to hunt down and I also wrote my own patch before finding this bug report. Can we please get this fix pushed out? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to wpa in Ubuntu. https://bugs.launchpad.net/bugs/1528173 Title: org.freedesktop.DBus.Properties.GetAll fails always for fi.w1.wpa_supplicant1.Interface interface Status in wpa package in Ubuntu: Fix Released Bug description: With our package for wpa-supplicant a call $ sudo gdbus call -y -d fi.w1.wpa_supplicant1 -o /fi/w1/wpa_supplicant1/Interfaces/1 -m org.freedesktop.DBus.Properties.GetAll 'fi.w1.wpa_supplicant1.Interface' fails always with Error: GDBus.Error:org.freedesktop.DBus.Error.InvalidArgs: No readable properties in this interface The reason for this is that the internal properties getter routine will never return any result when one internal getter fails. The responsible property here is the "Stations" one which was added by a patch in Ubuntu and is not available upstream. Take a look at https://bazaar.launchpad.net/~ubuntu- branches/ubuntu/wily/wpa/wily/view/head:/debian/patches/dbus- available-sta.patch The getter method wpas_dbus_getter_stas expects the ap_iface element to be see which isn't always the case and if that isn't true it will return false and causes the whole Properties.GetAll call to fail. The expected result is that the getter just returns an empty list if it can't determine the actual value. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1528173/+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 1642767] Re: starting any container with umask 007 breaks lxc-stop and prevents host system shutdown
Problem still exists in Ubuntu 16.10. ** Summary changed: - starting any container with umask 007 breaks lxc-stop and prevents host system shutdown + starting any container with umask 007 breaks host system shutdown. lxc-stop just hangs. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1642767 Title: starting any container with umask 007 breaks host system shutdown. lxc-stop just hangs. Status in lxc package in Ubuntu: New Bug description: If I have umask 007 (or any other value that masks the world-execute bit) when I run lxc-start for the first time after logging in, my host system enters a state with the following problems: * lxc-stop hangs forever instead of stopping any container, even one that wasn't started with umask 007. * lxc-stop --kill --nolock hangs in the same way. * Attempts to reboot or shut down the host system fail, requiring a hard reset to recover. When lxc-stop hangs, messages like these appear in syslog every couple of minutes: Nov 17 01:22:11 hostbox kernel: [ 3360.091624] INFO: task systemd:12179 blocked for more than 120 seconds. Nov 17 01:22:11 hostbox kernel: [ 3360.091629] Tainted: P OE 4.4.0-47-generic #68-Ubuntu Nov 17 01:22:11 hostbox kernel: [ 3360.091631] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Nov 17 01:22:11 hostbox kernel: [ 3360.091633] systemd D 8800c6febb58 0 12179 12168 0x0104 Nov 17 01:22:11 hostbox kernel: [ 3360.091638] 8800c6febb58 8800d318d280 88040c649b80 8800d318d280 Nov 17 01:22:11 hostbox kernel: [ 3360.091641] 8800c6fec000 8800345bc088 8800345bc070 Nov 17 01:22:11 hostbox kernel: [ 3360.091644] fffe0001 8800c6febb70 81830f15 8800d318d280 Nov 17 01:22:11 hostbox kernel: [ 3360.091647] Call Trace: Nov 17 01:22:11 hostbox kernel: [ 3360.091653] [] schedule+0x35/0x80 Nov 17 01:22:11 hostbox kernel: [ 3360.091657] [] rwsem_down_write_failed+0x202/0x350 Nov 17 01:22:11 hostbox kernel: [ 3360.091662] [] ? kernfs_sop_show_options+0x40/0x40 Nov 17 01:22:11 hostbox kernel: [ 3360.091666] [] call_rwsem_down_write_failed+0x13/0x20 Nov 17 01:22:11 hostbox kernel: [ 3360.091669] [] ? down_write+0x2d/0x40 Nov 17 01:22:11 hostbox kernel: [ 3360.091672] [] grab_super+0x30/0xa0 Nov 17 01:22:11 hostbox kernel: [ 3360.091674] [] sget_userns+0x152/0x450 Nov 17 01:22:11 hostbox kernel: [ 3360.091677] [] ? kernfs_sop_show_path+0x50/0x50 Nov 17 01:22:11 hostbox kernel: [ 3360.091680] [] kernfs_mount_ns+0x7e/0x230 Nov 17 01:22:11 hostbox kernel: [ 3360.091685] [] cgroup_mount+0x2eb/0x7f0 Nov 17 01:22:11 hostbox kernel: [ 3360.091687] [] mount_fs+0x38/0x160 Nov 17 01:22:11 hostbox kernel: [ 3360.091691] [] vfs_kern_mount+0x67/0x110 Nov 17 01:22:11 hostbox kernel: [ 3360.091694] [] do_mount+0x269/0xde0 Nov 17 01:22:11 hostbox kernel: [ 3360.091698] [] SyS_mount+0x9f/0x100 Nov 17 01:22:11 hostbox kernel: [ 3360.091701] [] entry_SYSCALL_64_fastpath+0x16/0x71 When system shutdown hangs, similar messages appear on the console every couple of minutes. I can reproduce this at will with a freshly-installed and fully- updated host OS in VirtualBox, and with either an old-ish container or a new one. I'm running lxc 2.0.5-0ubuntu1~ubuntu16.04.2 on xubuntu 16.04.1 LTS amd64. My containers are all unprivileged. My umask at container creation time does not seem to matter. As far as I have seen, my umask only matters the first time I start a container in my login session. I can work around the bug by manually setting my umask to something more permissive before I start my first container of the day, and then setting it back again, but that's rather a hassle. (Even worse, it's very easy to forget this workaround and be left with containers that can't be stopped and a host system that won't shut down cleanly.) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1642767/+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 1642767] Re: starting any container with umask 007 breaks lxc-stop and prevents host system shutdown
I reproduced it with the latest mainline kernel as well: Linux xenialbox 4.9.0-040900rc6-generic #201611201731 SMP Sun Nov 20 22:33:21 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux Here's the slightly different syslog output: Nov 22 14:36:55 xenialbox kernel: [ 484.506570] INFO: task systemd:3086 blocked for more than 120 seconds. Nov 22 14:36:55 xenialbox kernel: [ 484.506578] Not tainted 4.9.0-040900rc6-generic #201611201731 Nov 22 14:36:55 xenialbox kernel: [ 484.506579] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Nov 22 14:36:55 xenialbox kernel: [ 484.506582] systemd D0 3086 3076 0x0104 Nov 22 14:36:55 xenialbox kernel: [ 484.506589] 8eaa1810bc00 8eaa58f4d800 8eaa57f59d00 8eaa5fc19340 Nov 22 14:36:55 xenialbox kernel: [ 484.506593] 8eaa54bec880 9bab80f17b78 8bc87183 8c244480 Nov 22 14:36:55 xenialbox kernel: [ 484.506596] 00ff8eaa57f59d00 8eaa5fc19340 8eaa57f59d00 Nov 22 14:36:55 xenialbox kernel: [ 484.506600] Call Trace: Nov 22 14:36:55 xenialbox kernel: [ 484.506622] [] ? __schedule+0x233/0x6e0 Nov 22 14:36:55 xenialbox kernel: [ 484.506626] [] schedule+0x36/0x80 Nov 22 14:36:55 xenialbox kernel: [ 484.506629] [] rwsem_down_write_failed+0x20a/0x380 Nov 22 14:36:55 xenialbox kernel: [ 484.506634] [] ? kvm_sched_clock_read+0x1e/0x30 Nov 22 14:36:55 xenialbox kernel: [ 484.506643] [] ? kernfs_sop_show_options+0x40/0x40 Nov 22 14:36:55 xenialbox kernel: [ 484.506651] [] call_rwsem_down_write_failed+0x17/0x30 Nov 22 14:36:55 xenialbox kernel: [ 484.506655] [] down_write+0x2d/0x40 Nov 22 14:36:55 xenialbox kernel: [ 484.506658] [] grab_super+0x30/0xa0 Nov 22 14:36:55 xenialbox kernel: [ 484.506661] [] sget_userns+0x18f/0x4d0 Nov 22 14:36:55 xenialbox kernel: [ 484.506663] [] ? kernfs_sop_show_path+0x50/0x50 Nov 22 14:36:55 xenialbox kernel: [ 484.50] [] kernfs_mount_ns+0x7e/0x230 Nov 22 14:36:55 xenialbox kernel: [ 484.506674] [] cgroup_mount+0x328/0x840 Nov 22 14:36:55 xenialbox kernel: [ 484.506679] [] ? alloc_pages_current+0x95/0x140 Nov 22 14:36:55 xenialbox kernel: [ 484.506682] [] mount_fs+0x38/0x150 Nov 22 14:36:55 xenialbox kernel: [ 484.506686] [] vfs_kern_mount+0x67/0x110 Nov 22 14:36:55 xenialbox kernel: [ 484.506688] [] do_mount+0x1e1/0xcb0 Nov 22 14:36:55 xenialbox kernel: [ 484.506691] [] ? __check_object_size+0xff/0x1d6 Nov 22 14:36:55 xenialbox kernel: [ 484.506695] [] ? kmem_cache_alloc_trace+0xd7/0x190 Nov 22 14:36:55 xenialbox kernel: [ 484.506697] [] SyS_mount+0x83/0xd0 Nov 22 14:36:55 xenialbox kernel: [ 484.506700] [] do_syscall_64+0x5b/0xc0 Nov 22 14:36:55 xenialbox kernel: [ 484.506702] [] entry_SYSCALL64_slow_path+0x25/0x25 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1642767 Title: starting any container with umask 007 breaks lxc-stop and prevents host system shutdown Status in lxc package in Ubuntu: New Bug description: If I have umask 007 (or any other value that masks the world-execute bit) when I run lxc-start for the first time after logging in, my host system enters a state with the following problems: * lxc-stop hangs forever instead of stopping any container, even one that wasn't started with umask 007. * lxc-stop --kill --nolock hangs in the same way. * Attempts to reboot or shut down the host system fail, requiring a hard reset to recover. When lxc-stop hangs, messages like these appear in syslog every couple of minutes: Nov 17 01:22:11 hostbox kernel: [ 3360.091624] INFO: task systemd:12179 blocked for more than 120 seconds. Nov 17 01:22:11 hostbox kernel: [ 3360.091629] Tainted: P OE 4.4.0-47-generic #68-Ubuntu Nov 17 01:22:11 hostbox kernel: [ 3360.091631] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Nov 17 01:22:11 hostbox kernel: [ 3360.091633] systemd D 8800c6febb58 0 12179 12168 0x0104 Nov 17 01:22:11 hostbox kernel: [ 3360.091638] 8800c6febb58 8800d318d280 88040c649b80 8800d318d280 Nov 17 01:22:11 hostbox kernel: [ 3360.091641] 8800c6fec000 8800345bc088 8800345bc070 Nov 17 01:22:11 hostbox kernel: [ 3360.091644] fffe0001 8800c6febb70 81830f15 8800d318d280 Nov 17 01:22:11 hostbox kernel: [ 3360.091647] Call Trace: Nov 17 01:22:11 hostbox kernel: [ 3360.091653] [] schedule+0x35/0x80 Nov 17 01:22:11 hostbox kernel: [ 3360.091657] [] rwsem_down_write_failed+0x202/0x350 Nov 17 01:22:11 hostbox kernel: [ 3360.091662] [] ? kernfs_sop_show_options+0x40/0x40 Nov 17 01:22:11 hostbox kernel: [ 3360.091666] [] call_rwsem_down_write_failed+0x13/0x20 Nov 17 01:22:11 hostbox kernel: [ 3360.091669] [] ? down_write+0x2d/0x40 Nov 17 01:22:11 hostbox
[Touch-packages] [Bug 1642767] Re: starting any container with umask 007 breaks lxc-stop and prevents host system shutdown
Linux xenialbox 4.4.0-47-generic #68-Ubuntu SMP Wed Oct 26 19:39:52 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1642767 Title: starting any container with umask 007 breaks lxc-stop and prevents host system shutdown Status in lxc package in Ubuntu: New Bug description: If I have umask 007 (or any other value that masks the world-execute bit) when I run lxc-start for the first time after logging in, my host system enters a state with the following problems: * lxc-stop hangs forever instead of stopping any container, even one that wasn't started with umask 007. * lxc-stop --kill --nolock hangs in the same way. * Attempts to reboot or shut down the host system fail, requiring a hard reset to recover. When lxc-stop hangs, messages like these appear in syslog every couple of minutes: Nov 17 01:22:11 hostbox kernel: [ 3360.091624] INFO: task systemd:12179 blocked for more than 120 seconds. Nov 17 01:22:11 hostbox kernel: [ 3360.091629] Tainted: P OE 4.4.0-47-generic #68-Ubuntu Nov 17 01:22:11 hostbox kernel: [ 3360.091631] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Nov 17 01:22:11 hostbox kernel: [ 3360.091633] systemd D 8800c6febb58 0 12179 12168 0x0104 Nov 17 01:22:11 hostbox kernel: [ 3360.091638] 8800c6febb58 8800d318d280 88040c649b80 8800d318d280 Nov 17 01:22:11 hostbox kernel: [ 3360.091641] 8800c6fec000 8800345bc088 8800345bc070 Nov 17 01:22:11 hostbox kernel: [ 3360.091644] fffe0001 8800c6febb70 81830f15 8800d318d280 Nov 17 01:22:11 hostbox kernel: [ 3360.091647] Call Trace: Nov 17 01:22:11 hostbox kernel: [ 3360.091653] [] schedule+0x35/0x80 Nov 17 01:22:11 hostbox kernel: [ 3360.091657] [] rwsem_down_write_failed+0x202/0x350 Nov 17 01:22:11 hostbox kernel: [ 3360.091662] [] ? kernfs_sop_show_options+0x40/0x40 Nov 17 01:22:11 hostbox kernel: [ 3360.091666] [] call_rwsem_down_write_failed+0x13/0x20 Nov 17 01:22:11 hostbox kernel: [ 3360.091669] [] ? down_write+0x2d/0x40 Nov 17 01:22:11 hostbox kernel: [ 3360.091672] [] grab_super+0x30/0xa0 Nov 17 01:22:11 hostbox kernel: [ 3360.091674] [] sget_userns+0x152/0x450 Nov 17 01:22:11 hostbox kernel: [ 3360.091677] [] ? kernfs_sop_show_path+0x50/0x50 Nov 17 01:22:11 hostbox kernel: [ 3360.091680] [] kernfs_mount_ns+0x7e/0x230 Nov 17 01:22:11 hostbox kernel: [ 3360.091685] [] cgroup_mount+0x2eb/0x7f0 Nov 17 01:22:11 hostbox kernel: [ 3360.091687] [] mount_fs+0x38/0x160 Nov 17 01:22:11 hostbox kernel: [ 3360.091691] [] vfs_kern_mount+0x67/0x110 Nov 17 01:22:11 hostbox kernel: [ 3360.091694] [] do_mount+0x269/0xde0 Nov 17 01:22:11 hostbox kernel: [ 3360.091698] [] SyS_mount+0x9f/0x100 Nov 17 01:22:11 hostbox kernel: [ 3360.091701] [] entry_SYSCALL_64_fastpath+0x16/0x71 When system shutdown hangs, similar messages appear on the console every couple of minutes. I can reproduce this at will with a freshly-installed and fully- updated host OS in VirtualBox, and with either an old-ish container or a new one. I'm running lxc 2.0.5-0ubuntu1~ubuntu16.04.2 on xubuntu 16.04.1 LTS amd64. My containers are all unprivileged. My umask at container creation time does not seem to matter. As far as I have seen, my umask only matters the first time I start a container in my login session. I can work around the bug by manually setting my umask to something more permissive before I start my first container of the day, and then setting it back again, but that's rather a hassle. (Even worse, it's very easy to forget this workaround and be left with containers that can't be stopped and a host system that won't shut down cleanly.) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1642767/+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 1642767] Re: starting any container with umask 007 breaks lxc-stop and prevents host system shutdown
** Description changed: - If I run lxc-start with umask 007 (or any other value that masks the - world-execute bit), my host system enters a state with the following - problems: + If I have umask 007 (or any other value that masks the world-execute + bit) when I run lxc-start for the first time after logging in, my host + system enters a state with the following problems: * lxc-stop hangs forever instead of stopping any container, even one that wasn't started with umask 007. * lxc-stop --kill --nolock hangs in the same way. - * Attempts to reboot or shut down my host system fail, requiring a hard reset to recover. + * Attempts to reboot or shut down the host system fail, requiring a hard reset to recover. When lxc-stop hangs, messages like these appear in syslog every couple of minutes: Nov 17 01:22:11 hostbox kernel: [ 3360.091624] INFO: task systemd:12179 blocked for more than 120 seconds. Nov 17 01:22:11 hostbox kernel: [ 3360.091629] Tainted: P OE 4.4.0-47-generic #68-Ubuntu Nov 17 01:22:11 hostbox kernel: [ 3360.091631] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Nov 17 01:22:11 hostbox kernel: [ 3360.091633] systemd D 8800c6febb58 0 12179 12168 0x0104 Nov 17 01:22:11 hostbox kernel: [ 3360.091638] 8800c6febb58 8800d318d280 88040c649b80 8800d318d280 Nov 17 01:22:11 hostbox kernel: [ 3360.091641] 8800c6fec000 8800345bc088 8800345bc070 Nov 17 01:22:11 hostbox kernel: [ 3360.091644] fffe0001 8800c6febb70 81830f15 8800d318d280 Nov 17 01:22:11 hostbox kernel: [ 3360.091647] Call Trace: Nov 17 01:22:11 hostbox kernel: [ 3360.091653] [] schedule+0x35/0x80 Nov 17 01:22:11 hostbox kernel: [ 3360.091657] [] rwsem_down_write_failed+0x202/0x350 Nov 17 01:22:11 hostbox kernel: [ 3360.091662] [] ? kernfs_sop_show_options+0x40/0x40 Nov 17 01:22:11 hostbox kernel: [ 3360.091666] [] call_rwsem_down_write_failed+0x13/0x20 Nov 17 01:22:11 hostbox kernel: [ 3360.091669] [] ? down_write+0x2d/0x40 Nov 17 01:22:11 hostbox kernel: [ 3360.091672] [] grab_super+0x30/0xa0 Nov 17 01:22:11 hostbox kernel: [ 3360.091674] [] sget_userns+0x152/0x450 Nov 17 01:22:11 hostbox kernel: [ 3360.091677] [] ? kernfs_sop_show_path+0x50/0x50 Nov 17 01:22:11 hostbox kernel: [ 3360.091680] [] kernfs_mount_ns+0x7e/0x230 Nov 17 01:22:11 hostbox kernel: [ 3360.091685] [] cgroup_mount+0x2eb/0x7f0 Nov 17 01:22:11 hostbox kernel: [ 3360.091687] [] mount_fs+0x38/0x160 Nov 17 01:22:11 hostbox kernel: [ 3360.091691] [] vfs_kern_mount+0x67/0x110 Nov 17 01:22:11 hostbox kernel: [ 3360.091694] [] do_mount+0x269/0xde0 Nov 17 01:22:11 hostbox kernel: [ 3360.091698] [] SyS_mount+0x9f/0x100 Nov 17 01:22:11 hostbox kernel: [ 3360.091701] [] entry_SYSCALL_64_fastpath+0x16/0x71 When system shutdown hangs, similar messages appear on the console every couple of minutes. I can reproduce this at will with a freshly-installed and fully-updated host OS in VirtualBox, and with either an old-ish container or a new one. I'm running lxc 2.0.5-0ubuntu1~ubuntu16.04.2 on xubuntu 16.04.1 LTS amd64. My containers are all unprivileged. My umask at container creation time does not seem to matter. As far as I have seen, my umask only matters the first time I start a container in my login session. I can work around the bug by manually setting my umask to something more permissive before I start my first container of the day, and then setting it back again, but that's rather a hassle. (Even worse, it's very easy to forget this workaround and be left with containers that can't be stopped and a host system that won't shut down cleanly.) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1642767 Title: starting any container with umask 007 breaks lxc-stop and prevents host system shutdown Status in lxc package in Ubuntu: New Bug description: If I have umask 007 (or any other value that masks the world-execute bit) when I run lxc-start for the first time after logging in, my host system enters a state with the following problems: * lxc-stop hangs forever instead of stopping any container, even one that wasn't started with umask 007. * lxc-stop --kill --nolock hangs in the same way. * Attempts to reboot or shut down the host system fail, requiring a hard reset to recover. When lxc-stop hangs, messages like these appear in syslog every couple of minutes: Nov 17 01:22:11 hostbox kernel: [ 3360.091624] INFO: task systemd:12179 blocked for more than 120 seconds. Nov 17 01:22:11 hostbox kernel: [ 3360.091629] Tainted: P OE 4.4.0-47-generic #68-Ubuntu Nov 17 01:22:11 hostbox kernel: [ 3360.091631] "echo 0 > /proc/sys/kernel/hung_task
[Touch-packages] [Bug 1642767] Re: starting any container with umask 007 breaks lxc-stop and prevents host system shutdown
** Description changed: If I run lxc-start with umask 007 (or any other value that masks the world-execute bit), my host system enters a state with the following problems: * lxc-stop hangs forever instead of stopping any container, even one that wasn't started with umask 007. * lxc-stop --kill --nolock hangs in the same way. * Attempts to reboot or shut down my host system fail, requiring a hard reset to recover. When lxc-stop hangs, messages like these appear in syslog every couple of minutes: Nov 17 01:22:11 hostbox kernel: [ 3360.091624] INFO: task systemd:12179 blocked for more than 120 seconds. Nov 17 01:22:11 hostbox kernel: [ 3360.091629] Tainted: P OE 4.4.0-47-generic #68-Ubuntu Nov 17 01:22:11 hostbox kernel: [ 3360.091631] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Nov 17 01:22:11 hostbox kernel: [ 3360.091633] systemd D 8800c6febb58 0 12179 12168 0x0104 Nov 17 01:22:11 hostbox kernel: [ 3360.091638] 8800c6febb58 8800d318d280 88040c649b80 8800d318d280 Nov 17 01:22:11 hostbox kernel: [ 3360.091641] 8800c6fec000 8800345bc088 8800345bc070 Nov 17 01:22:11 hostbox kernel: [ 3360.091644] fffe0001 8800c6febb70 81830f15 8800d318d280 Nov 17 01:22:11 hostbox kernel: [ 3360.091647] Call Trace: Nov 17 01:22:11 hostbox kernel: [ 3360.091653] [] schedule+0x35/0x80 Nov 17 01:22:11 hostbox kernel: [ 3360.091657] [] rwsem_down_write_failed+0x202/0x350 Nov 17 01:22:11 hostbox kernel: [ 3360.091662] [] ? kernfs_sop_show_options+0x40/0x40 Nov 17 01:22:11 hostbox kernel: [ 3360.091666] [] call_rwsem_down_write_failed+0x13/0x20 Nov 17 01:22:11 hostbox kernel: [ 3360.091669] [] ? down_write+0x2d/0x40 Nov 17 01:22:11 hostbox kernel: [ 3360.091672] [] grab_super+0x30/0xa0 Nov 17 01:22:11 hostbox kernel: [ 3360.091674] [] sget_userns+0x152/0x450 Nov 17 01:22:11 hostbox kernel: [ 3360.091677] [] ? kernfs_sop_show_path+0x50/0x50 Nov 17 01:22:11 hostbox kernel: [ 3360.091680] [] kernfs_mount_ns+0x7e/0x230 Nov 17 01:22:11 hostbox kernel: [ 3360.091685] [] cgroup_mount+0x2eb/0x7f0 Nov 17 01:22:11 hostbox kernel: [ 3360.091687] [] mount_fs+0x38/0x160 Nov 17 01:22:11 hostbox kernel: [ 3360.091691] [] vfs_kern_mount+0x67/0x110 Nov 17 01:22:11 hostbox kernel: [ 3360.091694] [] do_mount+0x269/0xde0 Nov 17 01:22:11 hostbox kernel: [ 3360.091698] [] SyS_mount+0x9f/0x100 Nov 17 01:22:11 hostbox kernel: [ 3360.091701] [] entry_SYSCALL_64_fastpath+0x16/0x71 When system shutdown hangs, similar messages appear on the console every couple of minutes. + I can reproduce this at will with a freshly-installed and fully-updated + host OS in VirtualBox, and with either an old-ish container or a new + one. + I'm running lxc 2.0.5-0ubuntu1~ubuntu16.04.2 on xubuntu 16.04.1 LTS amd64. My containers are all unprivileged. - - I can reproduce this at will with a freshly installed host OS in - VirtualBox, and with either an old-ish container or a new one. My umask at container creation time does not seem to matter. As far as I have seen, my umask only matters the first time I start a container in my login session. I can work around the bug by manually setting my umask to something more permissive before I start my first container of the day, and then setting it back again, but that's rather a hassle. (Even worse, it's very easy to forget this workaround and be left with containers that can't be stopped and a host system that won't shut down cleanly.) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1642767 Title: starting any container with umask 007 breaks lxc-stop and prevents host system shutdown Status in lxc package in Ubuntu: New Bug description: If I have umask 007 (or any other value that masks the world-execute bit) when I run lxc-start for the first time after logging in, my host system enters a state with the following problems: * lxc-stop hangs forever instead of stopping any container, even one that wasn't started with umask 007. * lxc-stop --kill --nolock hangs in the same way. * Attempts to reboot or shut down the host system fail, requiring a hard reset to recover. When lxc-stop hangs, messages like these appear in syslog every couple of minutes: Nov 17 01:22:11 hostbox kernel: [ 3360.091624] INFO: task systemd:12179 blocked for more than 120 seconds. Nov 17 01:22:11 hostbox kernel: [ 3360.091629] Tainted: P OE 4.4.0-47-generic #68-Ubuntu Nov 17 01:22:11 hostbox kernel: [ 3360.091631] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Nov 17 01:22:11 hostbox kernel: [ 3360.091633] systemd D 8800c6febb58 0 12179 12168 0x0104 N
[Touch-packages] [Bug 1642767] Re: starting any container with umask 007 breaks lxc-stop and prevents host system shutdown
** Description changed: If I run lxc-start with umask 007 (or any other value that masks the world-execute bit), my host system enters a state with the following problems: * lxc-stop hangs forever instead of stopping any container, even one that wasn't started with umask 007. * lxc-stop --kill --nolock hangs in the same way. * Attempts to reboot or shut down my host system fail, requiring a hard reset to recover. When lxc-stop hangs, messages like these appear in syslog every couple of minutes: Nov 17 01:22:11 hostbox kernel: [ 3360.091624] INFO: task systemd:12179 blocked for more than 120 seconds. Nov 17 01:22:11 hostbox kernel: [ 3360.091629] Tainted: P OE 4.4.0-47-generic #68-Ubuntu Nov 17 01:22:11 hostbox kernel: [ 3360.091631] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Nov 17 01:22:11 hostbox kernel: [ 3360.091633] systemd D 8800c6febb58 0 12179 12168 0x0104 Nov 17 01:22:11 hostbox kernel: [ 3360.091638] 8800c6febb58 8800d318d280 88040c649b80 8800d318d280 Nov 17 01:22:11 hostbox kernel: [ 3360.091641] 8800c6fec000 8800345bc088 8800345bc070 Nov 17 01:22:11 hostbox kernel: [ 3360.091644] fffe0001 8800c6febb70 81830f15 8800d318d280 Nov 17 01:22:11 hostbox kernel: [ 3360.091647] Call Trace: Nov 17 01:22:11 hostbox kernel: [ 3360.091653] [] schedule+0x35/0x80 Nov 17 01:22:11 hostbox kernel: [ 3360.091657] [] rwsem_down_write_failed+0x202/0x350 Nov 17 01:22:11 hostbox kernel: [ 3360.091662] [] ? kernfs_sop_show_options+0x40/0x40 Nov 17 01:22:11 hostbox kernel: [ 3360.091666] [] call_rwsem_down_write_failed+0x13/0x20 Nov 17 01:22:11 hostbox kernel: [ 3360.091669] [] ? down_write+0x2d/0x40 Nov 17 01:22:11 hostbox kernel: [ 3360.091672] [] grab_super+0x30/0xa0 Nov 17 01:22:11 hostbox kernel: [ 3360.091674] [] sget_userns+0x152/0x450 Nov 17 01:22:11 hostbox kernel: [ 3360.091677] [] ? kernfs_sop_show_path+0x50/0x50 Nov 17 01:22:11 hostbox kernel: [ 3360.091680] [] kernfs_mount_ns+0x7e/0x230 Nov 17 01:22:11 hostbox kernel: [ 3360.091685] [] cgroup_mount+0x2eb/0x7f0 Nov 17 01:22:11 hostbox kernel: [ 3360.091687] [] mount_fs+0x38/0x160 Nov 17 01:22:11 hostbox kernel: [ 3360.091691] [] vfs_kern_mount+0x67/0x110 Nov 17 01:22:11 hostbox kernel: [ 3360.091694] [] do_mount+0x269/0xde0 Nov 17 01:22:11 hostbox kernel: [ 3360.091698] [] SyS_mount+0x9f/0x100 Nov 17 01:22:11 hostbox kernel: [ 3360.091701] [] entry_SYSCALL_64_fastpath+0x16/0x71 When system shutdown hangs, similar messages appear on the console every couple of minutes. I'm running lxc 2.0.5-0ubuntu1~ubuntu16.04.2 on xubuntu 16.04.1 LTS amd64. My containers are all unprivileged. - I can reproduce this at will with either an old-ish container or a fresh - new one. + I can reproduce this at will with a freshly installed host OS in + VirtualBox, and with either an old-ish container or a new one. My umask at container creation time does not seem to matter. As far as I have seen, my umask only matters the first time I start a container in my login session. I can work around the bug by manually setting my umask to something more permissive before I start my first container of the day, and then setting it back again, but that's rather a hassle. (Even worse, it's very easy to forget this workaround and be left with containers that can't be stopped and a host system that won't shut down cleanly.) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1642767 Title: starting any container with umask 007 breaks lxc-stop and prevents host system shutdown Status in lxc package in Ubuntu: New Bug description: If I run lxc-start with umask 007 (or any other value that masks the world-execute bit), my host system enters a state with the following problems: * lxc-stop hangs forever instead of stopping any container, even one that wasn't started with umask 007. * lxc-stop --kill --nolock hangs in the same way. * Attempts to reboot or shut down my host system fail, requiring a hard reset to recover. When lxc-stop hangs, messages like these appear in syslog every couple of minutes: Nov 17 01:22:11 hostbox kernel: [ 3360.091624] INFO: task systemd:12179 blocked for more than 120 seconds. Nov 17 01:22:11 hostbox kernel: [ 3360.091629] Tainted: P OE 4.4.0-47-generic #68-Ubuntu Nov 17 01:22:11 hostbox kernel: [ 3360.091631] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Nov 17 01:22:11 hostbox kernel: [ 3360.091633] systemd D 8800c6febb58 0 12179 12168 0x0104 Nov 17 01:22:11 hostbox kernel: [ 3360.091638] 8800c6febb58 8800d318d280 88040c649b80 8800d318d2
[Touch-packages] [Bug 1642767] Re: starting any container with umask 007 breaks lxc-stop and prevents host system shutdown
Possibly related: when the problem is triggered, I notice that my guest instances start with no /etc/resolv.conf and no inet address. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1642767 Title: starting any container with umask 007 breaks lxc-stop and prevents host system shutdown Status in lxc package in Ubuntu: New Bug description: If I run lxc-start with umask 007 (or any other value that masks the world-execute bit), my host system enters a state with the following problems: * lxc-stop hangs forever instead of stopping any container, even one that wasn't started with umask 007. * lxc-stop --kill --nolock hangs in the same way. * Attempts to reboot or shut down my host system fail, requiring a hard reset to recover. When lxc-stop hangs, messages like these appear in syslog every couple of minutes: Nov 17 01:22:11 hostbox kernel: [ 3360.091624] INFO: task systemd:12179 blocked for more than 120 seconds. Nov 17 01:22:11 hostbox kernel: [ 3360.091629] Tainted: P OE 4.4.0-47-generic #68-Ubuntu Nov 17 01:22:11 hostbox kernel: [ 3360.091631] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Nov 17 01:22:11 hostbox kernel: [ 3360.091633] systemd D 8800c6febb58 0 12179 12168 0x0104 Nov 17 01:22:11 hostbox kernel: [ 3360.091638] 8800c6febb58 8800d318d280 88040c649b80 8800d318d280 Nov 17 01:22:11 hostbox kernel: [ 3360.091641] 8800c6fec000 8800345bc088 8800345bc070 Nov 17 01:22:11 hostbox kernel: [ 3360.091644] fffe0001 8800c6febb70 81830f15 8800d318d280 Nov 17 01:22:11 hostbox kernel: [ 3360.091647] Call Trace: Nov 17 01:22:11 hostbox kernel: [ 3360.091653] [] schedule+0x35/0x80 Nov 17 01:22:11 hostbox kernel: [ 3360.091657] [] rwsem_down_write_failed+0x202/0x350 Nov 17 01:22:11 hostbox kernel: [ 3360.091662] [] ? kernfs_sop_show_options+0x40/0x40 Nov 17 01:22:11 hostbox kernel: [ 3360.091666] [] call_rwsem_down_write_failed+0x13/0x20 Nov 17 01:22:11 hostbox kernel: [ 3360.091669] [] ? down_write+0x2d/0x40 Nov 17 01:22:11 hostbox kernel: [ 3360.091672] [] grab_super+0x30/0xa0 Nov 17 01:22:11 hostbox kernel: [ 3360.091674] [] sget_userns+0x152/0x450 Nov 17 01:22:11 hostbox kernel: [ 3360.091677] [] ? kernfs_sop_show_path+0x50/0x50 Nov 17 01:22:11 hostbox kernel: [ 3360.091680] [] kernfs_mount_ns+0x7e/0x230 Nov 17 01:22:11 hostbox kernel: [ 3360.091685] [] cgroup_mount+0x2eb/0x7f0 Nov 17 01:22:11 hostbox kernel: [ 3360.091687] [] mount_fs+0x38/0x160 Nov 17 01:22:11 hostbox kernel: [ 3360.091691] [] vfs_kern_mount+0x67/0x110 Nov 17 01:22:11 hostbox kernel: [ 3360.091694] [] do_mount+0x269/0xde0 Nov 17 01:22:11 hostbox kernel: [ 3360.091698] [] SyS_mount+0x9f/0x100 Nov 17 01:22:11 hostbox kernel: [ 3360.091701] [] entry_SYSCALL_64_fastpath+0x16/0x71 When system shutdown hangs, similar messages appear on the console every couple of minutes. I'm running lxc 2.0.5-0ubuntu1~ubuntu16.04.2 on xubuntu 16.04.1 LTS amd64. My containers are all unprivileged. I can reproduce this at will with either an old-ish container or a fresh new one. My umask at container creation time does not seem to matter. As far as I have seen, my umask only matters the first time I start a container in my login session. I can work around the bug by manually setting my umask to something more permissive before I start my first container of the day, and then setting it back again, but that's rather a hassle. (Even worse, it's very easy to forget this workaround and be left with containers that can't be stopped and a host system that won't shut down cleanly.) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1642767/+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 1642767] [NEW] starting any container with umask 007 breaks lxc-stop and prevents host system shutdown
Public bug reported: If I run lxc-start with umask 007 (or any other value that masks the world-execute bit), my host system enters a state with the following problems: * lxc-stop hangs forever instead of stopping any container, even one that wasn't started with umask 007. * lxc-stop --kill --nolock hangs in the same way. * Attempts to reboot or shut down my host system fail, requiring a hard reset to recover. When lxc-stop hangs, messages like these appear in syslog every couple of minutes: Nov 17 01:22:11 hostbox kernel: [ 3360.091624] INFO: task systemd:12179 blocked for more than 120 seconds. Nov 17 01:22:11 hostbox kernel: [ 3360.091629] Tainted: P OE 4.4.0-47-generic #68-Ubuntu Nov 17 01:22:11 hostbox kernel: [ 3360.091631] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Nov 17 01:22:11 hostbox kernel: [ 3360.091633] systemd D 8800c6febb58 0 12179 12168 0x0104 Nov 17 01:22:11 hostbox kernel: [ 3360.091638] 8800c6febb58 8800d318d280 88040c649b80 8800d318d280 Nov 17 01:22:11 hostbox kernel: [ 3360.091641] 8800c6fec000 8800345bc088 8800345bc070 Nov 17 01:22:11 hostbox kernel: [ 3360.091644] fffe0001 8800c6febb70 81830f15 8800d318d280 Nov 17 01:22:11 hostbox kernel: [ 3360.091647] Call Trace: Nov 17 01:22:11 hostbox kernel: [ 3360.091653] [] schedule+0x35/0x80 Nov 17 01:22:11 hostbox kernel: [ 3360.091657] [] rwsem_down_write_failed+0x202/0x350 Nov 17 01:22:11 hostbox kernel: [ 3360.091662] [] ? kernfs_sop_show_options+0x40/0x40 Nov 17 01:22:11 hostbox kernel: [ 3360.091666] [] call_rwsem_down_write_failed+0x13/0x20 Nov 17 01:22:11 hostbox kernel: [ 3360.091669] [] ? down_write+0x2d/0x40 Nov 17 01:22:11 hostbox kernel: [ 3360.091672] [] grab_super+0x30/0xa0 Nov 17 01:22:11 hostbox kernel: [ 3360.091674] [] sget_userns+0x152/0x450 Nov 17 01:22:11 hostbox kernel: [ 3360.091677] [] ? kernfs_sop_show_path+0x50/0x50 Nov 17 01:22:11 hostbox kernel: [ 3360.091680] [] kernfs_mount_ns+0x7e/0x230 Nov 17 01:22:11 hostbox kernel: [ 3360.091685] [] cgroup_mount+0x2eb/0x7f0 Nov 17 01:22:11 hostbox kernel: [ 3360.091687] [] mount_fs+0x38/0x160 Nov 17 01:22:11 hostbox kernel: [ 3360.091691] [] vfs_kern_mount+0x67/0x110 Nov 17 01:22:11 hostbox kernel: [ 3360.091694] [] do_mount+0x269/0xde0 Nov 17 01:22:11 hostbox kernel: [ 3360.091698] [] SyS_mount+0x9f/0x100 Nov 17 01:22:11 hostbox kernel: [ 3360.091701] [] entry_SYSCALL_64_fastpath+0x16/0x71 When system shutdown hangs, similar messages appear on the console every couple of minutes. I'm running lxc 2.0.5-0ubuntu1~ubuntu16.04.2 on xubuntu 16.04.1 LTS amd64. My containers are all unprivileged. I can reproduce this at will with either an old-ish container or a fresh new one. My umask at container creation time does not seem to matter. As far as I have seen, my umask only matters the first time I start a container in my login session. I can work around the bug by manually setting my umask to something more permissive before I start my first container of the day, and then setting it back again, but that's rather a hassle. (Even worse, it's very easy to forget this workaround and be left with containers that can't be stopped and a host system that won't shut down cleanly.) ** Affects: lxc (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1642767 Title: starting any container with umask 007 breaks lxc-stop and prevents host system shutdown Status in lxc package in Ubuntu: New Bug description: If I run lxc-start with umask 007 (or any other value that masks the world-execute bit), my host system enters a state with the following problems: * lxc-stop hangs forever instead of stopping any container, even one that wasn't started with umask 007. * lxc-stop --kill --nolock hangs in the same way. * Attempts to reboot or shut down my host system fail, requiring a hard reset to recover. When lxc-stop hangs, messages like these appear in syslog every couple of minutes: Nov 17 01:22:11 hostbox kernel: [ 3360.091624] INFO: task systemd:12179 blocked for more than 120 seconds. Nov 17 01:22:11 hostbox kernel: [ 3360.091629] Tainted: P OE 4.4.0-47-generic #68-Ubuntu Nov 17 01:22:11 hostbox kernel: [ 3360.091631] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Nov 17 01:22:11 hostbox kernel: [ 3360.091633] systemd D 8800c6febb58 0 12179 12168 0x0104 Nov 17 01:22:11 hostbox kernel: [ 3360.091638] 8800c6febb58 8800d318d280 88040c649b80 8800d318d280 Nov 17 01:22:11 hostbox kernel: [ 3360.091641] 8800c6fec000 8800345bc088 8800345bc070 Nov 17 01:22:11 hostbox kernel: [ 3360.091644]
[Touch-packages] [Bug 1576454] [NEW] Superfluous Xsession.d script: 60x11-common_localhost
Public bug reported: Both of these scripts do the same thing, and both are installed by x11-common: /etc/X11/Xsession.d/35x11-common_xhost-local /etc/X11/Xsession.d/60x11-common_localhost 35x11-common_xhost-local is present in debian, while 60x11-common_localhost is not. I suspect the latter should be removed. ** Affects: xorg (Ubuntu) Importance: Undecided Status: New ** Summary changed: - Duplicate Xsession.d script: 60x11-common_localhost + Superfluous Xsession.d script: 60x11-common_localhost -- 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/1576454 Title: Superfluous Xsession.d script: 60x11-common_localhost Status in xorg package in Ubuntu: New Bug description: Both of these scripts do the same thing, and both are installed by x11-common: /etc/X11/Xsession.d/35x11-common_xhost-local /etc/X11/Xsession.d/60x11-common_localhost 35x11-common_xhost-local is present in debian, while 60x11-common_localhost is not. I suspect the latter should be removed. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1576454/+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 1321418] Re: fsck.ext4 fails to fix multiply-claimed blocks: can't find dup_blk
Chris, I have no way to test this, because I no longer have a filesystem with multiply-claimed blocks. -- 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/1321418 Title: fsck.ext4 fails to fix multiply-claimed blocks: can't find dup_blk Status in e2fsprogs package in Ubuntu: Invalid Status in e2fsprogs source package in Precise: Fix Committed Status in e2fsprogs source package in Trusty: Fix Committed Bug description: [SRU justification] [Impact] The last few times my root ext4 filesystem had its regularly-scheduled boot-time check, errors were reported. The first time it happened, I simply told the system to fix the errors, but since they kept coming up again, I decided to look more closely. I booted from a live USB drive, assembled my raid partitions, and ran fsck.ext4 manually. Without any options, fsck.ext4 simply reported that the filesystem was clean, and exited. Things got more interesting when I ran with -f. It reported several multiply-claimed blocks, and when I told fsck to go ahead and clone them, it failed with an internal error. Repeated runs of fsck revealed that the filesystem was still not fixed, and repeated attempts to fix the problem also failed, reporting that multiply- claimed blocks already reassigned or cloned. I was lucky in that the files in question were unimportant, so deleting one of them and running fsck again seems to have fixed my problem this time. However, fsck's internal error and failure to fix the problem in the first place is worrisome. [Test Case] Here's the full output: $ sudo fsck.ext4 -f /dev/md/1 e2fsck 1.42.8 (20-Jun-2013) Pass 1: Checking inodes, blocks, and sizes Running additional passes to resolve blocks claimed by more than one inode... Pass 1B: Rescanning for multiply-claimed blocks Multiply-claimed block(s) in inode 27528089: 73467268 9287 9288 9289 9290 9291 9292 9293 Multiply-claimed block(s) in inode 27528105: 73467268 9287 9288 9289 9290 9291 9292 9293 Pass 1C: Scanning directories for inodes with multiply-claimed blocks Pass 1D: Reconciling multiply-claimed blocks (There are 2 inodes containing multiply-claimed blocks.) File /home/user/dir/subdir/05.09.2013_13.15.48.300.jpg (inode #27528089, mod time Mon Jan 13 02:50:08 2014) has 7 multiply-claimed block(s), shared with 1 file(s): /home/user/.thumbnails/normal/51048a1138d61df87bf3fdc7deed50e3.png/WebpageIcons.db (inode #27528105, mod time Mon Jan 13 02:50:08 2014) Clone multiply-claimed blocks? yes clone_file_block: internal error: can't find dup_blk for 73467268 clone_file_block: internal error: can't find dup_blk for 73467268 File /home/user/.thumbnails/normal/51048a1138d61df87bf3fdc7deed50e3.png/WebpageIcons.db (inode #27528105, mod time Mon Jan 13 02:50:08 2014) has 7 multiply-claimed block(s), shared with 1 file(s): /home/user/dir/subdir/05.09.2013_13.15.48.300.jpg (inode #27528089, mod time Mon Jan 13 02:50:08 2014) Multiply-claimed blocks already reassigned or cloned. Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information root: * FILE SYSTEM WAS MODIFIED * root: 1038356/30285824 files (0.3% non-contiguous), 106319516/121119454 blocks [Regression Potential] [Other Info] backported from upstream https://kernel.googlesource.com/pub/scm/fs/ext2/e2fsprogs/+/9a1d614df217c02ea6b2cb0072fccfe706aea111 https://kernel.googlesource.com/pub/scm/fs/ext2/e2fsprogs/+/84397754250d13e8596dd68c157c4c9863800079%5E%21/#F0 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1321418/+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 772709] Re: Network Manager Icon Is not changin when VPN is connected (nm-device-wired-secure icon is missing)
Also, this is a security problem. It robs the user of the ability to easily see that the VPN is (still) connected. If the VPN goes down, and the user doesn't happen to see the momentary pop-up message (or if that message has been accidentally or deliberately suppressed), the user will think his communications are encrypted when they are actually exposed. It can easily be exploited: 1. Distract the user or wait until he looks away from his screen. 2. Interfere with the internet connection for a few seconds, causing the user's VPN to fail. 3. Capture the user's packets. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnome-icon-theme in Ubuntu. https://bugs.launchpad.net/bugs/772709 Title: Network Manager Icon Is not changin when VPN is connected (nm-device- wired-secure icon is missing) Status in GNOME Icon Theme: New Status in tango-icon-theme: Confirmed Status in elementary-icon-theme package in Ubuntu: Confirmed Status in gnome-icon-theme package in Ubuntu: Confirmed Status in lubuntu-artwork package in Ubuntu: Fix Released Status in network-manager-applet package in Ubuntu: Confirmed Status in tango-icon-theme package in Ubuntu: Confirmed Bug description: Binary package hint: gnome-icon-theme Ater upgrading to 11.04 in gnome icon the (humanity and unity themes works fine) is see bad icons when connecting VPN and VPN is connected. Connected VPN icon is the same as original Network Manager. And connectin icon doen't show the Network manager icon only the flashing yellow lock (that must be over network manger icon) ProblemType: Bug DistroRelease: Ubuntu 11.04 Package: gnome-icon-theme 2.31.0-0ubuntu2 ProcVersionSignature: Ubuntu 2.6.38-8.42-generic 2.6.38.2 Uname: Linux 2.6.38-8-generic i686 NonfreeKernelModules: nvidia Architecture: i386 Date: Fri Apr 29 01:05:10 2011 InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release i386 (20091028.5) PackageArchitecture: all ProcEnviron: LANGUAGE=en_US:en LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: gnome-icon-theme UpgradeStatus: Upgraded to natty on 2011-04-28 (0 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-icon-theme/+bug/772709/+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 772709] Re: Network Manager Icon Is not changin when VPN is connected (nm-device-wired-secure icon is missing)
I also created an upstream bug report against the Tango icon theme, mainly to get more eyes on the problem. Honestly, though, I don't expect every icon theme developer will want to to modify their software in order to compensate for something that was broken by an Ubuntu-specific patch. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnome-icon-theme in Ubuntu. https://bugs.launchpad.net/bugs/772709 Title: Network Manager Icon Is not changin when VPN is connected (nm-device- wired-secure icon is missing) Status in GNOME Icon Theme: New Status in tango-icon-theme: Confirmed Status in elementary-icon-theme package in Ubuntu: Confirmed Status in gnome-icon-theme package in Ubuntu: Confirmed Status in lubuntu-artwork package in Ubuntu: Fix Released Status in network-manager-applet package in Ubuntu: Confirmed Status in tango-icon-theme package in Ubuntu: Confirmed Bug description: Binary package hint: gnome-icon-theme Ater upgrading to 11.04 in gnome icon the (humanity and unity themes works fine) is see bad icons when connecting VPN and VPN is connected. Connected VPN icon is the same as original Network Manager. And connectin icon doen't show the Network manager icon only the flashing yellow lock (that must be over network manger icon) ProblemType: Bug DistroRelease: Ubuntu 11.04 Package: gnome-icon-theme 2.31.0-0ubuntu2 ProcVersionSignature: Ubuntu 2.6.38-8.42-generic 2.6.38.2 Uname: Linux 2.6.38-8-generic i686 NonfreeKernelModules: nvidia Architecture: i386 Date: Fri Apr 29 01:05:10 2011 InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release i386 (20091028.5) PackageArchitecture: all ProcEnviron: LANGUAGE=en_US:en LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: gnome-icon-theme UpgradeStatus: Upgraded to natty on 2011-04-28 (0 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-icon-theme/+bug/772709/+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 772709] Re: Network Manager Icon Is not changin when VPN is connected (nm-device-wired-secure icon is missing)
Removing nm-applet-use-indicator.patch (and refreshing the patches that depend on it) fixes this in Xubuntu. In other words, that patch causes the regression. I'm removing the invalid status on network-manager-applet (Ubuntu), in hopes of getting someone to reevaluate this. If Ubuntu maintainers are going to patch in special functionality just for Unity, how about doing it without breaking things? (This is not the first time a patch intended to make a package use Unity's Application Indicators has broken the package for Xubuntu and other desktops. I really wish the people responsible would be more careful.) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnome-icon-theme in Ubuntu. https://bugs.launchpad.net/bugs/772709 Title: Network Manager Icon Is not changin when VPN is connected (nm-device- wired-secure icon is missing) Status in GNOME Icon Theme: New Status in tango-icon-theme: Confirmed Status in elementary-icon-theme package in Ubuntu: Confirmed Status in gnome-icon-theme package in Ubuntu: Confirmed Status in lubuntu-artwork package in Ubuntu: Fix Released Status in network-manager-applet package in Ubuntu: Confirmed Status in tango-icon-theme package in Ubuntu: Confirmed Bug description: Binary package hint: gnome-icon-theme Ater upgrading to 11.04 in gnome icon the (humanity and unity themes works fine) is see bad icons when connecting VPN and VPN is connected. Connected VPN icon is the same as original Network Manager. And connectin icon doen't show the Network manager icon only the flashing yellow lock (that must be over network manger icon) ProblemType: Bug DistroRelease: Ubuntu 11.04 Package: gnome-icon-theme 2.31.0-0ubuntu2 ProcVersionSignature: Ubuntu 2.6.38-8.42-generic 2.6.38.2 Uname: Linux 2.6.38-8-generic i686 NonfreeKernelModules: nvidia Architecture: i386 Date: Fri Apr 29 01:05:10 2011 InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release i386 (20091028.5) PackageArchitecture: all ProcEnviron: LANGUAGE=en_US:en LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: gnome-icon-theme UpgradeStatus: Upgraded to natty on 2011-04-28 (0 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-icon-theme/+bug/772709/+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 772709] Re: Network Manager Icon Is not changin when VPN is connected (nm-device-wired-secure icon is missing)
** Changed in: network-manager-applet (Ubuntu) Status: Invalid => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnome-icon-theme in Ubuntu. https://bugs.launchpad.net/bugs/772709 Title: Network Manager Icon Is not changin when VPN is connected (nm-device- wired-secure icon is missing) Status in GNOME Icon Theme: New Status in tango-icon-theme: Confirmed Status in elementary-icon-theme package in Ubuntu: Confirmed Status in gnome-icon-theme package in Ubuntu: Confirmed Status in lubuntu-artwork package in Ubuntu: Fix Released Status in network-manager-applet package in Ubuntu: Confirmed Status in tango-icon-theme package in Ubuntu: Confirmed Bug description: Binary package hint: gnome-icon-theme Ater upgrading to 11.04 in gnome icon the (humanity and unity themes works fine) is see bad icons when connecting VPN and VPN is connected. Connected VPN icon is the same as original Network Manager. And connectin icon doen't show the Network manager icon only the flashing yellow lock (that must be over network manger icon) ProblemType: Bug DistroRelease: Ubuntu 11.04 Package: gnome-icon-theme 2.31.0-0ubuntu2 ProcVersionSignature: Ubuntu 2.6.38-8.42-generic 2.6.38.2 Uname: Linux 2.6.38-8-generic i686 NonfreeKernelModules: nvidia Architecture: i386 Date: Fri Apr 29 01:05:10 2011 InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release i386 (20091028.5) PackageArchitecture: all ProcEnviron: LANGUAGE=en_US:en LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: gnome-icon-theme UpgradeStatus: Upgraded to natty on 2011-04-28 (0 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-icon-theme/+bug/772709/+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 772709] Re: Network Manager Icon Is not changin when VPN is connected (nm-device-wired-secure icon is missing)
** Bug watch added: freedesktop.org Bugzilla #91887 https://bugs.freedesktop.org/show_bug.cgi?id=91887 ** Also affects: tango-icon-theme via https://bugs.freedesktop.org/show_bug.cgi?id=91887 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnome-icon-theme in Ubuntu. https://bugs.launchpad.net/bugs/772709 Title: Network Manager Icon Is not changin when VPN is connected (nm-device- wired-secure icon is missing) Status in GNOME Icon Theme: New Status in tango-icon-theme: Unknown Status in elementary-icon-theme package in Ubuntu: Confirmed Status in gnome-icon-theme package in Ubuntu: Confirmed Status in lubuntu-artwork package in Ubuntu: Fix Released Status in network-manager-applet package in Ubuntu: Invalid Status in tango-icon-theme package in Ubuntu: Confirmed Bug description: Binary package hint: gnome-icon-theme Ater upgrading to 11.04 in gnome icon the (humanity and unity themes works fine) is see bad icons when connecting VPN and VPN is connected. Connected VPN icon is the same as original Network Manager. And connectin icon doen't show the Network manager icon only the flashing yellow lock (that must be over network manger icon) ProblemType: Bug DistroRelease: Ubuntu 11.04 Package: gnome-icon-theme 2.31.0-0ubuntu2 ProcVersionSignature: Ubuntu 2.6.38-8.42-generic 2.6.38.2 Uname: Linux 2.6.38-8-generic i686 NonfreeKernelModules: nvidia Architecture: i386 Date: Fri Apr 29 01:05:10 2011 InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release i386 (20091028.5) PackageArchitecture: all ProcEnviron: LANGUAGE=en_US:en LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: gnome-icon-theme UpgradeStatus: Upgraded to natty on 2011-04-28 (0 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-icon-theme/+bug/772709/+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 1466587] [NEW] PackageKit doesn't respect phased updates
Public bug reported: PackageKit-based tools, such as pkcon and pk-update-icon, do not respect Ubuntu phased updates. As far as I can tell, they do not provide a way to access or react to the Phased-Update-Percentage field in an apt package index at all. The result is that utilities based on PackageKit disagree with Ubuntu's native tools about what packages are ready for update. ** Affects: packagekit (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to packagekit in Ubuntu. https://bugs.launchpad.net/bugs/1466587 Title: PackageKit doesn't respect phased updates Status in packagekit package in Ubuntu: New Bug description: PackageKit-based tools, such as pkcon and pk-update-icon, do not respect Ubuntu phased updates. As far as I can tell, they do not provide a way to access or react to the Phased-Update-Percentage field in an apt package index at all. The result is that utilities based on PackageKit disagree with Ubuntu's native tools about what packages are ready for update. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/packagekit/+bug/1466587/+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 1389954] Re: Make .lxc domain name resolution easier to discover and enable
Here's a first attempt: https://github.com/lxc/lxc-pkg-ubuntu/pull/2 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1389954 Title: Make .lxc domain name resolution easier to discover and enable Status in lxc package in Ubuntu: Confirmed Bug description: The lxc package on ubuntu does almost nothing to help a user enable DNS resolution for containers via dnsmaq, let alone discover that it is possible. How about enabling it by default? I think all it would take is adding server=/lxc/10.0.3.1 to a file in /etc/NetworkManager/dnsmasq.d/ and uncommenting LXC_DOMAIN="lxc" in /etc/default/lxc-net. Even if there's a good reason not to enable this by default, shouldn't it at least be clearly documented someplace obvious instead of buried in a system config file with a misleading comment that mentions the wrong dnsmasq file to edit? (The one currently mentioned by /etc/default/lxc-net does nothing on ubuntu desktop systems, because ubuntu's NetworkManager starts dnsmasq with a special config directory.) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1389954/+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 1389954] Re: Make .lxc domain name resolution easier to discover and enable
Okay, I've written up a short README.Debian describing the necessary changes to /etc/default/lxc-net and the dnsmasq config file. I don't remember what steps are necessary to make the domain names accessible, though, and I'd like to include those steps in the readme. Do I have to restart the lxc-net service? (And is that service called the same thing regardless of whether sysv init, upstart, or systemd is in use?) Do I have to restart NetworkManager? Do I have to restart any already-running containers? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1389954 Title: Make .lxc domain name resolution easier to discover and enable Status in lxc package in Ubuntu: Confirmed Bug description: The lxc package on ubuntu does almost nothing to help a user enable DNS resolution for containers via dnsmaq, let alone discover that it is possible. How about enabling it by default? I think all it would take is adding server=/lxc/10.0.3.1 to a file in /etc/NetworkManager/dnsmasq.d/ and uncommenting LXC_DOMAIN="lxc" in /etc/default/lxc-net. Even if there's a good reason not to enable this by default, shouldn't it at least be clearly documented someplace obvious instead of buried in a system config file with a misleading comment that mentions the wrong dnsmasq file to edit? (The one currently mentioned by /etc/default/lxc-net does nothing on ubuntu desktop systems, because ubuntu's NetworkManager starts dnsmasq with a special config directory.) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1389954/+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 1389954] Re: Make .lxc domain name resolution easier to discover and enable
Which branch? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1389954 Title: Make .lxc domain name resolution easier to discover and enable Status in lxc package in Ubuntu: Confirmed Bug description: The lxc package on ubuntu does almost nothing to help a user enable DNS resolution for containers via dnsmaq, let alone discover that it is possible. How about enabling it by default? I think all it would take is adding server=/lxc/10.0.3.1 to a file in /etc/NetworkManager/dnsmasq.d/ and uncommenting LXC_DOMAIN="lxc" in /etc/default/lxc-net. Even if there's a good reason not to enable this by default, shouldn't it at least be clearly documented someplace obvious instead of buried in a system config file with a misleading comment that mentions the wrong dnsmasq file to edit? (The one currently mentioned by /etc/default/lxc-net does nothing on ubuntu desktop systems, because ubuntu's NetworkManager starts dnsmasq with a special config directory.) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1389954/+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 1347859] Re: Introduction of Predictable Network Interface Names (aka biosdevname) breaks working systems
On Mon, 13 Apr 2015 13:32:15 -, Robie Basak wrote: >A release >upgrade should not cause biosdevname to get installed. So can you (or >someone) please confirm that this is definitely the behaviour in some >case, It has now been most of a year since I filed the bug report, so as you might imagine, I no longer remember the details of the upgrade that prompted it. Here's what I know: On the system in question, eth0 disappeared and was replaced by pp. The main.log files under /var/log/dist-upgrade include lsb-release: quantal, raring, and saucy. The currently-installed release is trusty. This implies that the steps to reproduce include one or more of those distribution upgrades. I guess precise must have been the first-installed release. Although I don't know when biosdevname was first installed, it is listed in the Upgrade: log entries of all the /var/log/dist-upgrade//main.log files, including one from a year before my bug report. I suppose that means biosdevname was likely installed by some earlier release, rather than being newly installed during the problematic dist-upgrade. The motherboard's chipset is an Intel Z77 Express. The ethernet device uses a Realtek RTL8111/8168/8411 series chip. The r8169 kernel driver is currently in use. >and if so provide steps to reproduce so that we can understand the >mechanism involved here that is making this happen? Sorry, but I already spent too much time on this issue when it bit me in the first place. Reproducing it to determine step-by-step instructions would require taking the computer out of service, saving all of its data and state, taking it through several install and upgrade cycles, and then restoring everything. That is far more disruption and time than I can spare. >Second, you say that some distributions require both systemd and >biosdevname interface renaming to be disabled. My understanding is that >on Ubuntu with systemd (so Vivid only), we do not rename interfaces via >systemd by default - this must be done explicitly. Can we assume for the >rest of the discussion that this is true, or otherwise can you provide >steps to reproduce that demonstrate that it is not (again, another bug >might be a good idea to avoid cluttering this one)? That's quite possible. It has been most of a year since I wrote that text, but I probably meant to include non-ubuntu distros when I wrote "some distributions". -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-meta in Ubuntu. https://bugs.launchpad.net/bugs/1347859 Title: Introduction of Predictable Network Interface Names (aka biosdevname) breaks working systems Status in biosdevname package in Ubuntu: Opinion Status in ubuntu-meta package in Ubuntu: New Status in udev package in Ubuntu: Opinion Bug description: Relatively recent linux distribution upgrades have been causing computers' ethernet devices to be unexpectedly renamed. While I understand that consistent device naming solves problems on some systems (mostly multi-NIC servers and a few specialty embedded devices), unilaterally forcing these changes on everyone is causing a lot of frustration. Here are some of the problems I've encountered: Interface names that were easily recognized as abbreviations for their device type have been replaced by cryptic names that have no obvious meaning whatsoever. It's easy to guess that eth0 is short for ethernet #0. What the heck is p4p1 supposed to mean? How is a human supposed to guess that the first p stands for "PCI slot", that the second p stands for "port number", and that the whole mysterious string represents an ethernet interface? This new naming convention is inferior to the old one in at least one significant respect: it makes things more difficult to understand. One of the more useful examples of consistency that unix-like systems have enjoyed for decades has been thrown out: the extremely well-known ethernet device names. This creates yet another hurtle for users and admins when switching between different operating systems or trying to apply general-purpose unix knowledge. A lot of documentation has been broken. I have no idea how many manuals, forum posts, bug reports, printed instructions, email messages, personal notes, books, and other forms of documentation in the world refer to a unix ethernet device as eth0, but I'll bet the number is huge. All that valuable guidance has just been rendered misleading or even useless to anyone who doesn't keep up with the latest distribution-specific device naming experiments; in other words: the people who need it most. Well-established workflows have been broken. The change trips up users and admins who have for years been getting tasks done quickly with commands that they could recall and execute without a second thought. They are suddenly finding that their workflows no longer work. This interr
[Touch-packages] [Bug 1440440] Re: gstreamer 0.10 apps prematurely stop parsing some flac files
I discovered the problem with Exaile, Totem, and Sound Converter. I verified it and narrowed it down with gst-launch. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gst-plugins-good0.10 in Ubuntu. https://bugs.launchpad.net/bugs/1440440 Title: gstreamer 0.10 apps prematurely stop parsing some flac files Status in gst-plugins-good0.10 package in Ubuntu: Confirmed Bug description: Gstreamer 0.10 stops processing certain flac files before their end is reached. When it happens, no error condition is reported. It fails silently, as if the file was truncated. This affects all applications that use gstreamer0.10-plugins-good, including clementine, exaile, soundconverter, and many others. Upstream git branch 0.10 has had patches since 2012 that seem to fix the problem, but they have not yet made it into an official 0.10.x release. The relevant changesets are: 5881603 flacparse: avoid indefinite extended search for frame end if possible 440d703 flacparse: perform additional frame crc check if applicable 32cddf6 flacparse: avoid some more frame misparsing by additional header sanity check The fixes are present in gstreamer 1.0, but applications that still depend on 0.10 (either directly or through python-gst) remain broken. This seems like a good reason to apply the fixes to 0.10. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gst-plugins-good0.10/+bug/1440440/+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 1440440] Re: gstreamer 0.10 apps prematurely stop parsing some flac files
All I have is a couple of files that trigger the bug. Unfortunately, I don't have the rights to post them publicly, and I haven't found a way to extract a useful segment from them without remuxing (and hiding the problem). -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gst-plugins-good0.10 in Ubuntu. https://bugs.launchpad.net/bugs/1440440 Title: gstreamer 0.10 apps prematurely stop parsing some flac files Status in gst-plugins-good0.10 package in Ubuntu: Confirmed Bug description: Gstreamer 0.10 stops processing certain flac files before their end is reached. When it happens, no error condition is reported. It fails silently, as if the file was truncated. This affects all applications that use gstreamer0.10-plugins-good, including clementine, exaile, soundconverter, and many others. Upstream git branch 0.10 has had patches since 2012 that seem to fix the problem, but they have not yet made it into an official 0.10.x release. The relevant changesets are: 5881603 flacparse: avoid indefinite extended search for frame end if possible 440d703 flacparse: perform additional frame crc check if applicable 32cddf6 flacparse: avoid some more frame misparsing by additional header sanity check The fixes are present in gstreamer 1.0, but applications that still depend on 0.10 (either directly or through python-gst) remain broken. This seems like a good reason to apply the fixes to 0.10. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gst-plugins-good0.10/+bug/1440440/+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 1440440] Re: gstreamer 0.10 apps prematurely stop parsing some flac files
I have attached 3 upstream patches to fix the premature eos on some flac files: 0010-flacparse-avoid-indefinite-search-for-frame-end.patch 0011-flacparse-additional-frame-crc-check.patch 0012-flacparse-additional-header-sanity-check.patch These are suitable for adding to the debian/patches directory (and series file) of gst-plugins-good0.10-0.10.31. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gst-plugins-good0.10 in Ubuntu. https://bugs.launchpad.net/bugs/1440440 Title: gstreamer 0.10 apps prematurely stop parsing some flac files Status in gst-plugins-good0.10 package in Ubuntu: New Bug description: Gstreamer 0.10 stops processing certain flac files before their end is reached. When it happens, no error condition is reported. It fails silently, as if the file was truncated. This affects all applications that use gstreamer0.10-plugins-good, including clementine, exaile, soundconverter, and many others. Upstream git branch 0.10 has had patches since 2012 that seem to fix the problem, but they have not yet made it into an official 0.10.x release. The relevant changesets are: 5881603 flacparse: avoid indefinite extended search for frame end if possible 440d703 flacparse: perform additional frame crc check if applicable 32cddf6 flacparse: avoid some more frame misparsing by additional header sanity check The fixes are present in gstreamer 1.0, but applications that still depend on 0.10 (either directly or through python-gst) remain broken. This seems like a good reason to apply the fixes to 0.10. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gst-plugins-good0.10/+bug/1440440/+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 1440440] Re: gstreamer 0.10 apps prematurely stop parsing some flac files
** Patch added: "0012-flacparse-additional-header-sanity-check.patch" https://bugs.launchpad.net/ubuntu/+source/gst-plugins-good0.10/+bug/1440440/+attachment/4366260/+files/0012-flacparse-additional-header-sanity-check.patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gst-plugins-good0.10 in Ubuntu. https://bugs.launchpad.net/bugs/1440440 Title: gstreamer 0.10 apps prematurely stop parsing some flac files Status in gst-plugins-good0.10 package in Ubuntu: New Bug description: Gstreamer 0.10 stops processing certain flac files before their end is reached. When it happens, no error condition is reported. It fails silently, as if the file was truncated. This affects all applications that use gstreamer0.10-plugins-good, including clementine, exaile, soundconverter, and many others. Upstream git branch 0.10 has had patches since 2012 that seem to fix the problem, but they have not yet made it into an official 0.10.x release. The relevant changesets are: 5881603 flacparse: avoid indefinite extended search for frame end if possible 440d703 flacparse: perform additional frame crc check if applicable 32cddf6 flacparse: avoid some more frame misparsing by additional header sanity check The fixes are present in gstreamer 1.0, but applications that still depend on 0.10 (either directly or through python-gst) remain broken. This seems like a good reason to apply the fixes to 0.10. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gst-plugins-good0.10/+bug/1440440/+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 1440440] Re: gstreamer 0.10 apps prematurely stop parsing some flac files
** Patch added: "0011-flacparse-additional-frame-crc-check.patch" https://bugs.launchpad.net/ubuntu/+source/gst-plugins-good0.10/+bug/1440440/+attachment/4366259/+files/0011-flacparse-additional-frame-crc-check.patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gst-plugins-good0.10 in Ubuntu. https://bugs.launchpad.net/bugs/1440440 Title: gstreamer 0.10 apps prematurely stop parsing some flac files Status in gst-plugins-good0.10 package in Ubuntu: New Bug description: Gstreamer 0.10 stops processing certain flac files before their end is reached. When it happens, no error condition is reported. It fails silently, as if the file was truncated. This affects all applications that use gstreamer0.10-plugins-good, including clementine, exaile, soundconverter, and many others. Upstream git branch 0.10 has had patches since 2012 that seem to fix the problem, but they have not yet made it into an official 0.10.x release. The relevant changesets are: 5881603 flacparse: avoid indefinite extended search for frame end if possible 440d703 flacparse: perform additional frame crc check if applicable 32cddf6 flacparse: avoid some more frame misparsing by additional header sanity check The fixes are present in gstreamer 1.0, but applications that still depend on 0.10 (either directly or through python-gst) remain broken. This seems like a good reason to apply the fixes to 0.10. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gst-plugins-good0.10/+bug/1440440/+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 1440440] Re: gstreamer 0.10 apps prematurely stop parsing some flac files
** Patch added: "0010-flacparse-avoid-indefinite-search-for-frame-end.patch" https://bugs.launchpad.net/ubuntu/+source/gst-plugins-good0.10/+bug/1440440/+attachment/4366258/+files/0010-flacparse-avoid-indefinite-search-for-frame-end.patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gst-plugins-good0.10 in Ubuntu. https://bugs.launchpad.net/bugs/1440440 Title: gstreamer 0.10 apps prematurely stop parsing some flac files Status in gst-plugins-good0.10 package in Ubuntu: New Bug description: Gstreamer 0.10 stops processing certain flac files before their end is reached. When it happens, no error condition is reported. It fails silently, as if the file was truncated. This affects all applications that use gstreamer0.10-plugins-good, including clementine, exaile, soundconverter, and many others. Upstream git branch 0.10 has had patches since 2012 that seem to fix the problem, but they have not yet made it into an official 0.10.x release. The relevant changesets are: 5881603 flacparse: avoid indefinite extended search for frame end if possible 440d703 flacparse: perform additional frame crc check if applicable 32cddf6 flacparse: avoid some more frame misparsing by additional header sanity check The fixes are present in gstreamer 1.0, but applications that still depend on 0.10 (either directly or through python-gst) remain broken. This seems like a good reason to apply the fixes to 0.10. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gst-plugins-good0.10/+bug/1440440/+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 1440440] [NEW] gstreamer 0.10 apps prematurely stop parsing some flac files
Public bug reported: Gstreamer 0.10 stops processing certain flac files before their end is reached. When it happens, no error condition is reported. It fails silently, as if the file was truncated. This affects all applications that use gstreamer0.10-plugins-good, including clementine, exaile, soundconverter, and many others. Upstream git branch 0.10 has had patches since 2012 that seem to fix the problem, but they have not yet made it into an official 0.10.x release. The relevant changesets are: 5881603 flacparse: avoid indefinite extended search for frame end if possible 440d703 flacparse: perform additional frame crc check if applicable 32cddf6 flacparse: avoid some more frame misparsing by additional header sanity check The fixes are present in gstreamer 1.0, but applications that still depend on 0.10 (either directly or through python-gst) remain broken. This seems like a good reason to apply the fixes to 0.10. ** Affects: gst-plugins-good0.10 (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gst-plugins-good0.10 in Ubuntu. https://bugs.launchpad.net/bugs/1440440 Title: gstreamer 0.10 apps prematurely stop parsing some flac files Status in gst-plugins-good0.10 package in Ubuntu: New Bug description: Gstreamer 0.10 stops processing certain flac files before their end is reached. When it happens, no error condition is reported. It fails silently, as if the file was truncated. This affects all applications that use gstreamer0.10-plugins-good, including clementine, exaile, soundconverter, and many others. Upstream git branch 0.10 has had patches since 2012 that seem to fix the problem, but they have not yet made it into an official 0.10.x release. The relevant changesets are: 5881603 flacparse: avoid indefinite extended search for frame end if possible 440d703 flacparse: perform additional frame crc check if applicable 32cddf6 flacparse: avoid some more frame misparsing by additional header sanity check The fixes are present in gstreamer 1.0, but applications that still depend on 0.10 (either directly or through python-gst) remain broken. This seems like a good reason to apply the fixes to 0.10. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gst-plugins-good0.10/+bug/1440440/+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 1389954] Re: Make .lxc domain name resolution easier to discover and enable
Sure. Is this the right place? https://github.com/lxc/lxc-pkg-ubuntu -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1389954 Title: Make .lxc domain name resolution easier to discover and enable Status in lxc package in Ubuntu: Confirmed Bug description: The lxc package on ubuntu does almost nothing to help a user enable DNS resolution for containers via dnsmaq, let alone discover that it is possible. How about enabling it by default? I think all it would take is adding server=/lxc/10.0.3.1 to a file in /etc/NetworkManager/dnsmasq.d/ and uncommenting LXC_DOMAIN="lxc" in /etc/default/lxc-net. Even if there's a good reason not to enable this by default, shouldn't it at least be clearly documented someplace obvious instead of buried in a system config file with a misleading comment that mentions the wrong dnsmasq file to edit? (The one currently mentioned by /etc/default/lxc-net does nothing on ubuntu desktop systems, because ubuntu's NetworkManager starts dnsmasq with a special config directory.) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1389954/+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 1390792] Re: Synaptic Other Software tab jumps/scrolls to top when a repository check box is clicked
** Also affects: software-properties (Ubuntu) Importance: Undecided Status: New -- 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/1390792 Title: Synaptic Other Software tab jumps/scrolls to top when a repository check box is clicked Status in software-properties package in Ubuntu: New Status in synaptic package in Ubuntu: New Bug description: In Synaptic's Software & Updates window, clicking the check box for a repository in the Other Software tab causes the list of repositories to jump to the top of the list. The scroll position of the list is instantly lost, disorienting the user, and hiding the fact that the click did anything, until the user scrolls back down to find the item that was clicked. This is only noticeable when there are enough repositories in the list to require scrolling. Finding the clicked repository again is especially difficult when all of them look nearly identical, as is the case when they're all PPAs with no comment string. (Every item in the list is just a long URL that looks very similar to the others.) It's even worse when there are both package and source URLs for each repo. This is especially problematic when updating the repo URLs after a distribution upgrade, because it's a very repetitive task, and the scroll window jumps and loses its place every single time. Ubuntu 14.04.1 LTS synaptic 0.81.1ubuntu1 amd64 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1390792/+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 1389954] Re: Make .lxc domain name resolution easier to discover and enable
Thanks for taking an interest in the issue. Since I filed this specifically against lxc in Ubuntu, wouldn't it make sense to start by documenting the necessary config changes (including NetworkManager's dnsmasq config, since it is part of Ubuntu by default) in /usr/share/doc/lxc/README? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1389954 Title: Make .lxc domain name resolution easier to discover and enable Status in lxc package in Ubuntu: Confirmed Bug description: The lxc package on ubuntu does almost nothing to help a user enable DNS resolution for containers via dnsmaq, let alone discover that it is possible. How about enabling it by default? I think all it would take is adding server=/lxc/10.0.3.1 to a file in /etc/NetworkManager/dnsmasq.d/ and uncommenting LXC_DOMAIN="lxc" in /etc/default/lxc-net. Even if there's a good reason not to enable this by default, shouldn't it at least be clearly documented someplace obvious instead of buried in a system config file with a misleading comment that mentions the wrong dnsmasq file to edit? (The one currently mentioned by /etc/default/lxc-net does nothing on ubuntu desktop systems, because ubuntu's NetworkManager starts dnsmasq with a special config directory.) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1389954/+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 1389954] [NEW] Make .lxc domain name resolution easier to discover and enable
Public bug reported: The lxc package on ubuntu does almost nothing to help a user enable DNS resolution for containers via dnsmaq, let alone discover that it is possible. How about enabling it by default? I think all it would take is adding server=/lxc/10.0.3.1 to a file in /etc/NetworkManager/dnsmasq.d/ and uncommenting LXC_DOMAIN="lxc" in /etc/default/lxc-net. Even if there's a good reason not to enable this by default, shouldn't it at least be clearly documented someplace obvious instead of buried in a system config file with a misleading comment that mentions the wrong dnsmasq file to edit? (The one currently mentioned by /etc/default/lxc- net does nothing on ubuntu desktop systems, because ubuntu's NetworkManager starts dnsmasq with a special config directory.) ** Affects: lxc (Ubuntu) Importance: Undecided Status: New ** Description changed: The lxc package on ubuntu does almost nothing to help a user enable DNS resolution for containers via dnsmaq, let alone discover that it is possible. How about enabling it by default? I think all it would take is adding server=/lxc/10.0.3.1 to a file in /etc/NetworkManager/dnsmasq.d/ and uncommenting LXC_DOMAIN="lxc" in /etc/default/lxc-net. Even if there's a good reason not to enable this by default, shouldn't it at least be clearly documented someplace obvious instead of buried in a system config file with a misleading comment that mentions the wrong - dnsconf file to edit? (The dnsconf file path currently mentioned in + dnsmasq file to edit? (The dnsconf file path currently mentioned in /etc/default/lxc-net does nothing on ubuntu desktop systems, because NetworkManager starts dnsconf with a special config directory.) ** Description changed: The lxc package on ubuntu does almost nothing to help a user enable DNS resolution for containers via dnsmaq, let alone discover that it is possible. How about enabling it by default? I think all it would take is adding server=/lxc/10.0.3.1 to a file in /etc/NetworkManager/dnsmasq.d/ and uncommenting LXC_DOMAIN="lxc" in /etc/default/lxc-net. Even if there's a good reason not to enable this by default, shouldn't it at least be clearly documented someplace obvious instead of buried in a system config file with a misleading comment that mentions the wrong - dnsmasq file to edit? (The dnsconf file path currently mentioned in - /etc/default/lxc-net does nothing on ubuntu desktop systems, because - NetworkManager starts dnsconf with a special config directory.) + dnsmasq file to edit? (The one currently mentioned by /etc/default/lxc- + net does nothing on ubuntu desktop systems, because ubuntu's + NetworkManager starts dnsmasq with a special config directory.) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1389954 Title: Make .lxc domain name resolution easier to discover and enable Status in “lxc” package in Ubuntu: New Bug description: The lxc package on ubuntu does almost nothing to help a user enable DNS resolution for containers via dnsmaq, let alone discover that it is possible. How about enabling it by default? I think all it would take is adding server=/lxc/10.0.3.1 to a file in /etc/NetworkManager/dnsmasq.d/ and uncommenting LXC_DOMAIN="lxc" in /etc/default/lxc-net. Even if there's a good reason not to enable this by default, shouldn't it at least be clearly documented someplace obvious instead of buried in a system config file with a misleading comment that mentions the wrong dnsmasq file to edit? (The one currently mentioned by /etc/default/lxc-net does nothing on ubuntu desktop systems, because ubuntu's NetworkManager starts dnsmasq with a special config directory.) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1389954/+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 1389864] Re: /etc/dnsmasq.d-available/lxc has no effect on a NetworkManager system
** Description changed: The lxc package installs dnsmasq configuration as /etc/dnsmasq.d-available/lxc, and a symlink to it is created at /etc/dnsmasq.d/lxc, but neither has any effect on the main dnsmasq instance on systems running NetworkManager, because NetworkManager starts a dnsmasq instance that looks in /etc/NetworkManager/dnsmasq.d instead. - This makes directing .lxc domain name lookups to the right place seem to - fail, which is how I noticed it. I imagine it also leads to other + This means that when someone adds server=/lxc/10.0.3.1 to lxc's dnsmasq + config file, it doesn't work. I imagine it also leads to other configurations not working as expected. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1389864 Title: /etc/dnsmasq.d-available/lxc has no effect on a NetworkManager system Status in “lxc” package in Ubuntu: New Bug description: The lxc package installs dnsmasq configuration as /etc/dnsmasq.d-available/lxc, and a symlink to it is created at /etc/dnsmasq.d/lxc, but neither has any effect on the main dnsmasq instance on systems running NetworkManager, because NetworkManager starts a dnsmasq instance that looks in /etc/NetworkManager/dnsmasq.d instead. This means that when someone adds server=/lxc/10.0.3.1 to lxc's dnsmasq config file, it doesn't work. I imagine it also leads to other configurations not working as expected. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1389864/+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 1389864] [NEW] /etc/dnsmasq.d-available/lxc has no effect on a NetworkManager system
Public bug reported: The lxc package installs dnsmasq configuration as /etc/dnsmasq.d-available/lxc, and a symlink to it is created at /etc/dnsmasq.d/lxc, but neither has any effect on the main dnsmasq instance on systems running NetworkManager, because NetworkManager starts a dnsmasq instance that looks in /etc/NetworkManager/dnsmasq.d instead. This makes directing .lxc domain name lookups to the right place seem to fail, which is how I noticed it. I imagine it also leads to other configurations not working as expected. ** Affects: lxc (Ubuntu) Importance: Undecided Status: New ** Description changed: The lxc package installs dnsmasq configuration as /etc/dnsmasq.d-available/lxc, and a symlink to it is created at - /etc/dnsmasq.d/lxc, but neither has any effect on systems running - NetworkManager, because NetworkManager starts a dnsmasq instance that - looks in /etc/NetworkManager/dnsmasq.d instead. + /etc/dnsmasq.d/lxc, but neither has any effect on the main dnsmasq + instance on systems running NetworkManager, because NetworkManager + starts a dnsmasq instance that looks in /etc/NetworkManager/dnsmasq.d + instead. This makes directing .lxc domain name lookups to the right place seem to - fail, and probably leads to other thinks not seeming to work as - expected. + fail, which is how I noticed it. I imagine it also leads to other + configurations not working as expected. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1389864 Title: /etc/dnsmasq.d-available/lxc has no effect on a NetworkManager system Status in “lxc” package in Ubuntu: New Bug description: The lxc package installs dnsmasq configuration as /etc/dnsmasq.d-available/lxc, and a symlink to it is created at /etc/dnsmasq.d/lxc, but neither has any effect on the main dnsmasq instance on systems running NetworkManager, because NetworkManager starts a dnsmasq instance that looks in /etc/NetworkManager/dnsmasq.d instead. This makes directing .lxc domain name lookups to the right place seem to fail, which is how I noticed it. I imagine it also leads to other configurations not working as expected. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1389864/+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 1286836] Re: package libpostproc52 6:0.8.10-0ubuntu0.13.10.1 failed to install/upgrade: libpostproc52:amd64 6:0.git20120821-4 (Multi-Arch: no) is not co-installable with libpostp
For the record: This happened to me during a distribution upgrade from 13.10 (saucy) to 14.04 (trusty). When it happened, the release upgrade tool interrupted itself with a dialog box containing this alarming and not very helpful message: Could not install the upgrades The upgrade has aborted. Your system could be in an unusable state. A recovery will run now (dpkg --configure -a). This dialog box was modal, preventing me from scrolling or copying the text in the Terminal widget to see what really happened. The text visible in the Terminal widget did not show up in any of the /var/log /dist-upgrade/* logs, but it was clearly a python exception and stack trace. Upon closing the dialog box, the upgrade continued, contrary to what the alarming message stated. (I guess the message was referring to one particular package, not the overall release upgrade, but most end users wouldn't know that, and even if they did the message didn't state which package.) As the upgrade continued, I was unable to copy & paste the stack trace before it was pushed out of the Terminal widget's rather short scroll buffer. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libav in Ubuntu. https://bugs.launchpad.net/bugs/1286836 Title: package libpostproc52 6:0.8.10-0ubuntu0.13.10.1 failed to install/upgrade: libpostproc52:amd64 6:0.git20120821-4 (Multi-Arch: no) is not co-installable with libpostproc52 which has multiple installed instances Status in “libav” package in Ubuntu: Confirmed Status in “libpostproc” package in Ubuntu: Confirmed Bug description: - ProblemType: Package DistroRelease: Ubuntu 14.04 Package: libpostproc52 6:0.8.10-0ubuntu0.13.10.1 ProcVersionSignature: Ubuntu 3.13.0-14.34-generic 3.13.5 Uname: Linux 3.13.0-14-generic x86_64 ApportVersion: 2.13.2-0ubuntu5 Architecture: amd64 Date: Mon Mar 3 00:57:47 2014 Dependencies: gcc-4.9-base 4.9-20140222-0ubuntu1 libavutil51 6:0.8.10-0ubuntu0.13.10.1 [origin: unknown] libc6 2.19-0ubuntu2 libgcc1 1:4.9-20140222-0ubuntu1 multiarch-support 2.19-0ubuntu2 ErrorMessage: libpostproc52:amd64 6:0.git20120821-4 (Multi-Arch: no) is not co-installable with libpostproc52 which has multiple installed instances InstallationDate: Installed on 2013-12-12 (79 days ago) InstallationMedia: Ubuntu 13.10 "Saucy Salamander" - Release amd64 (20131016.1) SourcePackage: libav Title: package libpostproc52 6:0.8.10-0ubuntu0.13.10.1 failed to install/upgrade: libpostproc52:amd64 6:0.git20120821-4 (Multi-Arch: no) is not co-installable with libpostproc52 which has multiple installed instances UpgradeStatus: Upgraded to trusty on 2014-03-02 (0 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libav/+bug/1286836/+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 1247719] Re: crackling, popping, clicking in playback to audigy2 surround51 device
** Tags added: regression-release saucy ** Tags added: trusty -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to alsa-driver in Ubuntu. https://bugs.launchpad.net/bugs/1247719 Title: crackling, popping, clicking in playback to audigy2 surround51 device Status in “alsa-driver” package in Ubuntu: New Bug description: After upgrading from Xubuntu 13.04 to 13.10, I hear lots of popping (aka crackle, click noises) during playback to my Audigy2 surround51 device. This was never a problem before the upgrade. The noises do not show up if I use the card's default, front, or rear devices instead, but those leave me without surround sound, so they're no good for movie playback. The same problem shows up on the surround40 device. I haven't tried the other surround* devices. I can reproduce problem in Totem or gst-launch playbin with an .asoundrc containing this: pcm.!default { type plug slave.pcm "surround51" } I can reproduce problem in Exaile with the custom sink pipeline set to "alsasink device=surround51" and no .asoundrc. I'm running the amd64 build of Xubuntu. My Audigy2 has the first alsa sound card slot, making it my default sound card. I am not using PulseAudio. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1247719/+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 1329274] Re: apt-get source fails to warn on unauthenticated packages
Or at least just --force-yes. --assume-yes is not sufficient to bypass the authenticity check without a prompt. I gather there is a desire to avoid prompting. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1329274 Title: apt-get source fails to warn on unauthenticated packages Status in APT: Fix Released Status in “apt” package in Ubuntu: Fix Released Status in “apt” source package in Lucid: Fix Released Status in “apt” source package in Precise: Fix Released Status in “apt” source package in Saucy: Fix Released Status in “apt” source package in Trusty: Fix Released Status in “apt” source package in Utopic: Fix Released Bug description: apt-get source foo will not warn if the repository that foo belongs to has no signature attached. It should fails in this case - this is CVE-2014-0478 To manage notifications about this bug go to: https://bugs.launchpad.net/apt/+bug/1329274/+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 1329274] Re: apt-get source fails to warn on unauthenticated packages
Question: Why are --force-yes and --assume-yes not honored as they are when checking authenticity of binaries? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1329274 Title: apt-get source fails to warn on unauthenticated packages Status in APT: Fix Released Status in “apt” package in Ubuntu: Fix Released Status in “apt” source package in Lucid: Fix Released Status in “apt” source package in Precise: Fix Released Status in “apt” source package in Saucy: Fix Released Status in “apt” source package in Trusty: Fix Released Status in “apt” source package in Utopic: Fix Released Bug description: apt-get source foo will not warn if the repository that foo belongs to has no signature attached. It should fails in this case - this is CVE-2014-0478 To manage notifications about this bug go to: https://bugs.launchpad.net/apt/+bug/1329274/+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 1347859] Re: Introduction of Predictable Network Interface Names (aka biosdevname) breaks working systems
** Description changed: Relatively recent linux distribution upgrades have been causing computers' ethernet devices to be unexpectedly renamed. While I understand that consistent device naming solves problems on some systems (mostly multi-NIC servers and a few specialty embedded devices), unilaterally forcing these changes on everyone is causing a lot of frustration. Here are some of the problems I've encountered: - - Interface names that were easily recognized as abbreviations for their device type have been replaced by cryptic names that have no obvious meaning whatsoever. It's easy to guess that eth0 is short for ethernet #0. What the heck is p4p1 supposed to mean? How is a human supposed to guess that the first p stands for "PCI slot", that the second p stands for "port number", and that the whole mysterious string represents an ethernet interface? This new naming convention is inferior to the old one in at least one significant respect: it makes things more difficult to understand. + Interface names that were easily recognized as abbreviations for their + device type have been replaced by cryptic names that have no obvious + meaning whatsoever. It's easy to guess that eth0 is short for ethernet + #0. What the heck is p4p1 supposed to mean? How is a human supposed to + guess that the first p stands for "PCI slot", that the second p stands + for "port number", and that the whole mysterious string represents an + ethernet interface? This new naming convention is inferior to the old + one in at least one significant respect: it makes things more difficult + to understand. One of the more useful examples of consistency that unix-like systems have enjoyed for decades has been thrown out: the extremely well-known ethernet device names. This creates yet another hurtle for users and admins when switching between different operating systems or trying to apply general-purpose unix knowledge. A lot of documentation has been broken. I have no idea how many manuals, forum posts, bug reports, printed instructions, email messages, personal notes, books, and other forms of documentation in the world refer to a unix ethernet device as eth0, but I'll bet the number is huge. All that valuable guidance has just been rendered misleading or even useless to anyone who doesn't keep up with the latest distribution-specific device naming experiments; in other words: the people who need it most. Well-established workflows have been broken. The change trips up users and admins who have for years been getting tasks done quickly with commands that they could recall and execute without a second thought. They are suddenly finding that their workflows no longer work. This interrupts tasks that should have been quick and easy, forcing people figure out why known-good procedures are broken, think about how to modify their memorized commands to work on the affected systems, and train their fingers to type those new commands as quickly as they did the old ones. Beyond being irritating, it can eat up a bunch of time that some of us don't have to spare. Working systems have been broken. Tools and automation scripts, especially those developed for site-specific use, often make the difference between a computer that does real work and a useless generic OS installation. Sometimes they even make the difference between a malfunctioning headless box that can be fixed over the network and an expensive brick. It is quite common for such software to make some minimal assumptions about its runtime environment, like assuming that the name of the only network device that has ever been or will ever be present will not suddenly change after being stable for months or years. There are also applications (e.g. Matlab) and configuration files (e.g. smb.conf, dhclient.conf, isc-dhcp-server) that might depend on references to eth0. Renaming a critical and ubiquitous device like this is so very likely to cause problems that it should never, ever be done in an upgrade without the admin's explicit consent. Sufficient warning of the change was not given. On one of my machines, eth0 was renamed to p4p1 when I upgraded to Ubuntu 14.04 (trusty), yet I don't see any mention of it in the Trusty release notes, nor in any of the notes for releases of the previous several years. Is it buried in fine print someplace that I missed? Having to figure out for myself what changed, why, and how to revert it (in multiple ways on each machine) was a significant waste of my time. Multiply that by all the other people who were affected similarly, and I'll bet we'd get an embarrassing number of needlessly wasted person-months that could have been saved with a simple announcement and link to documentation. - - In short, the way this feature was forced on the world was an irresponsible blunder. It doesn't matter that the change was meant to address som
[Touch-packages] [Bug 1347859] [NEW] Introduction of Predictable Network Interface Names (aka biosdevname) breaks working systems
Public bug reported: Relatively recent linux distribution upgrades have been causing computers' ethernet devices to be unexpectedly renamed. While I understand that consistent device naming solves problems on some systems (mostly multi-NIC servers and a few specialty embedded devices), unilaterally forcing these changes on everyone is causing a lot of frustration. Here are some of the problems I've encountered: Interface names that were easily recognized as abbreviations for their device type have been replaced by cryptic names that have no obvious meaning whatsoever. It's easy to guess that eth0 is short for ethernet #0. What the heck is p4p1 supposed to mean? How is a human supposed to guess that the first p stands for "PCI slot", that the second p stands for "port number", and that the whole mysterious string represents an ethernet interface? This new naming convention is inferior to the old one in at least one significant respect: it makes things more difficult to understand. One of the more useful examples of consistency that unix-like systems have enjoyed for decades has been thrown out: the extremely well-known ethernet device names. This creates yet another hurtle for users and admins when switching between different operating systems or trying to apply general-purpose unix knowledge. A lot of documentation has been broken. I have no idea how many manuals, forum posts, bug reports, printed instructions, email messages, personal notes, books, and other forms of documentation in the world refer to a unix ethernet device as eth0, but I'll bet the number is huge. All that valuable guidance has just been rendered misleading or even useless to anyone who doesn't keep up with the latest distribution-specific device naming experiments; in other words: the people who need it most. Well-established workflows have been broken. The change trips up users and admins who have for years been getting tasks done quickly with commands that they could recall and execute without a second thought. They are suddenly finding that their workflows no longer work. This interrupts tasks that should have been quick and easy, forcing people figure out why known-good procedures are broken, think about how to modify their memorized commands to work on the affected systems, and train their fingers to type those new commands as quickly as they did the old ones. Beyond being irritating, it can eat up a bunch of time that some of us don't have to spare. Working systems have been broken. Tools and automation scripts, especially those developed for site-specific use, often make the difference between a computer that does real work and a useless generic OS installation. Sometimes they even make the difference between a malfunctioning headless box that can be fixed over the network and an expensive brick. It is quite common for such software to make some minimal assumptions about its runtime environment, like assuming that the name of the only network device that has ever been or will ever be present will not suddenly change after being stable for months or years. There are also applications (e.g. Matlab) and configuration files (e.g. smb.conf, dhclient.conf, isc-dhcp-server) that might depend on references to eth0. Renaming a critical and ubiquitous device like this is so very likely to cause problems that it should never, ever be done in an upgrade without the admin's explicit consent. Sufficient warning of the change was not given. On one of my machines, eth0 was renamed to p4p1 when I upgraded to Ubuntu 14.04 (trusty), yet I don't see any mention of it in the Trusty release notes, nor in any of the notes for releases of the previous several years. Is it buried in fine print someplace that I missed? Having to figure out for myself what changed, why, and how to revert it (in multiple ways on each machine) was a significant waste of my time. Multiply that by all the other people who were affected similarly, and I'll bet we'd get an embarrassing number of needlessly wasted person-months that could have been saved with a simple announcement and link to documentation. In short, the way this feature was forced on the world was an irresponsible blunder. It doesn't matter that the change was meant to address some other problem. Breaking working systems is far worse than allowing that problem to remain until someone opts in to a fix. This concept is so important that anyone who doesn't get it really has no business committing code to an operating system used by so many other people. I am filing this bug report against multiple projects because more than one is now overriding the kernel's device names, because each project must be reconfigured in a different way in order to disable this behavior, and because I believe the overall failure here lies not only in careless feature implementation but also in careless deployment. If the people involved in developing, integrating, testing, distributing, and using this new behavio
[Touch-packages] [Bug 1286836] Re: package libpostproc52 6:0.8.10-0ubuntu0.13.10.1 failed to install/upgrade: libpostproc52:amd64 6:0.git20120821-4 (Multi-Arch: no) is not co-installable with libpostp
Here's a cleaner variation of the workaround: sudo dpkg --purge --force-depends libpostproc52 sudo apt-get install libpostproc52 sudo apt-mark auto libpostproc52 The first line purges the package without removing any of the packages that depend on it. (This is fine, since we're going to reinstall the dependency immediately.) The second line reinstalls the package. The third line marks the package as automatically-installed (as it is in a stock ubuntu system), so the system knows to treat it as a dependency rather than something the user manually installed. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libav in Ubuntu. https://bugs.launchpad.net/bugs/1286836 Title: package libpostproc52 6:0.8.10-0ubuntu0.13.10.1 failed to install/upgrade: libpostproc52:amd64 6:0.git20120821-4 (Multi-Arch: no) is not co-installable with libpostproc52 which has multiple installed instances Status in “libav” package in Ubuntu: Confirmed Status in “libpostproc” package in Ubuntu: Confirmed Bug description: - ProblemType: Package DistroRelease: Ubuntu 14.04 Package: libpostproc52 6:0.8.10-0ubuntu0.13.10.1 ProcVersionSignature: Ubuntu 3.13.0-14.34-generic 3.13.5 Uname: Linux 3.13.0-14-generic x86_64 ApportVersion: 2.13.2-0ubuntu5 Architecture: amd64 Date: Mon Mar 3 00:57:47 2014 Dependencies: gcc-4.9-base 4.9-20140222-0ubuntu1 libavutil51 6:0.8.10-0ubuntu0.13.10.1 [origin: unknown] libc6 2.19-0ubuntu2 libgcc1 1:4.9-20140222-0ubuntu1 multiarch-support 2.19-0ubuntu2 ErrorMessage: libpostproc52:amd64 6:0.git20120821-4 (Multi-Arch: no) is not co-installable with libpostproc52 which has multiple installed instances InstallationDate: Installed on 2013-12-12 (79 days ago) InstallationMedia: Ubuntu 13.10 "Saucy Salamander" - Release amd64 (20131016.1) SourcePackage: libav Title: package libpostproc52 6:0.8.10-0ubuntu0.13.10.1 failed to install/upgrade: libpostproc52:amd64 6:0.git20120821-4 (Multi-Arch: no) is not co-installable with libpostproc52 which has multiple installed instances UpgradeStatus: Upgraded to trusty on 2014-03-02 (0 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libav/+bug/1286836/+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