[Touch-packages] [Bug 1849544] [NEW] package initramfs-tools 0.133ubuntu10 failed to install/upgrade: installed initramfs-tools package post-installation script subprocess returned error exit status 1
Public bug reported: problem occurred becauuse symlink /initrd.imgpointed to old disco initrd, resolved by forcibly recreating it, for now...? ProblemType: Package DistroRelease: Ubuntu 19.10 Package: initramfs-tools 0.133ubuntu10 ProcVersionSignature: Ubuntu 5.3.0-19.20-generic 5.3.1 Uname: Linux 5.3.0-19-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu8 Architecture: amd64 Date: Mon Oct 21 17:24:50 2019 ErrorMessage: installed initramfs-tools package post-installation script subprocess returned error exit status 1 InstallationDate: Installed on 2018-02-20 (610 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214) PackageArchitecture: all Python3Details: /usr/bin/python3.7, Python 3.7.5rc1, python3-minimal, 3.7.5-1 PythonDetails: /usr/bin/python2.7, Python 2.7.17rc1, python-minimal, 2.7.17-1 RelatedPackageVersions: dpkg 1.19.7ubuntu2 apt 1.9.4 SourcePackage: initramfs-tools Title: package initramfs-tools 0.133ubuntu10 failed to install/upgrade: installed initramfs-tools package post-installation script subprocess returned error exit status 1 UpgradeStatus: Upgraded to eoan on 2019-10-21 (2 days ago) ** Affects: initramfs-tools (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-package eoan -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1849544 Title: package initramfs-tools 0.133ubuntu10 failed to install/upgrade: installed initramfs-tools package post-installation script subprocess returned error exit status 1 Status in initramfs-tools package in Ubuntu: New Bug description: problem occurred becauuse symlink /initrd.imgpointed to old disco initrd, resolved by forcibly recreating it, for now...? ProblemType: Package DistroRelease: Ubuntu 19.10 Package: initramfs-tools 0.133ubuntu10 ProcVersionSignature: Ubuntu 5.3.0-19.20-generic 5.3.1 Uname: Linux 5.3.0-19-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu8 Architecture: amd64 Date: Mon Oct 21 17:24:50 2019 ErrorMessage: installed initramfs-tools package post-installation script subprocess returned error exit status 1 InstallationDate: Installed on 2018-02-20 (610 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214) PackageArchitecture: all Python3Details: /usr/bin/python3.7, Python 3.7.5rc1, python3-minimal, 3.7.5-1 PythonDetails: /usr/bin/python2.7, Python 2.7.17rc1, python-minimal, 2.7.17-1 RelatedPackageVersions: dpkg 1.19.7ubuntu2 apt 1.9.4 SourcePackage: initramfs-tools Title: package initramfs-tools 0.133ubuntu10 failed to install/upgrade: installed initramfs-tools package post-installation script subprocess returned error exit status 1 UpgradeStatus: Upgraded to eoan on 2019-10-21 (2 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1849544/+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 1841915] Re: black screen, unresponsive, after logout from gnome Wayland session
as of this morning's updates, this problem seems to have disappeared. I've been able to log out and back in several times to my ubuntu wayland session, at least on my i915 machine (the dell laptop). nb: this morning's updates updated gnome-session-bin and ubuntu-session to 3.33.92-1ubuntu1, gdm3 to 3.33.92-2ubuntu1, but mutter and gnome- shell remain at 3.33.91.. (Also and probably not coincidentally seeing some unrelated dash-or-ubuntudock issues, but i'll wait to see if they're resolved when gnome-shell goes up to 3.33.92 too.) -- 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/1841915 Title: black screen, unresponsive, after logout from gnome Wayland session Status in gdm3 package in Ubuntu: Confirmed Status in gnome-shell package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: on logout the screen is black, the system is unresponsive and has to be restarted. (Untested by me yet, but I expect ssh-ing in and restarting gdm would work.) I believe this may be already reported upstream here: https://bugzilla.redhat.com/show_bug.cgi?id=1745554 That's why I've reported this against gdm3 even though I honestly don't know if it might be a gnome-shell, gnome-session or mutter based error. (FWIW without the upstream bug to link to I'd maybe suspect gnome-shell first.) NB: This machine's conf has AutomaticLogin enabled, but another machine also on 19.10 does not, and it's showing the same thing. On *this* machine I found that the *first* time I logged out, it was OK, but not the second time. On the other machine, it fails first time too. It's as if the gdm login screen can appear exactly once. That (and being on gnome 3.33) is why I don't think this is a dupe of #1824588. Nothing appears in /var/crash as a result of this. ProblemType: Bug DistroRelease: Ubuntu 19.10 Package: gdm3 3.33.90-1ubuntu1 ProcVersionSignature: Ubuntu 5.2.0-13.14-generic 5.2.8 Uname: Linux 5.2.0-13-generic x86_64 ApportVersion: 2.20.11-0ubuntu7 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Thu Aug 29 10:51:22 2019 InstallationDate: Installed on 2018-09-11 (351 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214) SourcePackage: gdm3 UpgradeStatus: Upgraded to eoan on 2019-07-16 (43 days ago) mtime.conffile..etc.gdm3.custom.conf: 2019-07-17T00:07:04.528641 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1841915/+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 1841915] Re: black screen, unresponsive, after logout from gnome Wayland session
My point regarding gnome-session-wayland.target is that if we're seeing different filenames for that file (assuming they're functionally the same) and mine definitely comes from gnome-session-bin, does that suggest we're running different gnome-session-bin versions? And seeing as you're not reproducing an issue i'm seeing regarding the ending of a gnome session... does that difference in what file you're expecting me to have there and the file i *assure* you is actually there... signify anything? -- 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/1841915 Title: black screen, unresponsive, after logout from gnome Wayland session Status in gdm3 package in Ubuntu: Confirmed Status in gnome-shell package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: on logout the screen is black, the system is unresponsive and has to be restarted. (Untested by me yet, but I expect ssh-ing in and restarting gdm would work.) I believe this may be already reported upstream here: https://bugzilla.redhat.com/show_bug.cgi?id=1745554 That's why I've reported this against gdm3 even though I honestly don't know if it might be a gnome-shell, gnome-session or mutter based error. (FWIW without the upstream bug to link to I'd maybe suspect gnome-shell first.) NB: This machine's conf has AutomaticLogin enabled, but another machine also on 19.10 does not, and it's showing the same thing. On *this* machine I found that the *first* time I logged out, it was OK, but not the second time. On the other machine, it fails first time too. It's as if the gdm login screen can appear exactly once. That (and being on gnome 3.33) is why I don't think this is a dupe of #1824588. Nothing appears in /var/crash as a result of this. ProblemType: Bug DistroRelease: Ubuntu 19.10 Package: gdm3 3.33.90-1ubuntu1 ProcVersionSignature: Ubuntu 5.2.0-13.14-generic 5.2.8 Uname: Linux 5.2.0-13-generic x86_64 ApportVersion: 2.20.11-0ubuntu7 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Thu Aug 29 10:51:22 2019 InstallationDate: Installed on 2018-09-11 (351 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214) SourcePackage: gdm3 UpgradeStatus: Upgraded to eoan on 2019-07-16 (43 days ago) mtime.conffile..etc.gdm3.custom.conf: 2019-07-17T00:07:04.528641 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1841915/+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 1841915] Re: black screen, unresponsive, after logout from gnome Wayland session
minor contextual note: It took me a little while to get the other machine, ssh in (offending ssh key to resolve), call up this page to remind me of the exact commands. The point of which is to say, these weren't taken *immediately* after the logout, but at least a minute later, certainly beyond that timeout discussed earlier. Also therefore that that ssh session started *after* the hang event, didn't log in in advance. -- 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/1841915 Title: black screen, unresponsive, after logout from gnome Wayland session Status in gdm3 package in Ubuntu: Confirmed Status in gnome-shell package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: on logout the screen is black, the system is unresponsive and has to be restarted. (Untested by me yet, but I expect ssh-ing in and restarting gdm would work.) I believe this may be already reported upstream here: https://bugzilla.redhat.com/show_bug.cgi?id=1745554 That's why I've reported this against gdm3 even though I honestly don't know if it might be a gnome-shell, gnome-session or mutter based error. (FWIW without the upstream bug to link to I'd maybe suspect gnome-shell first.) NB: This machine's conf has AutomaticLogin enabled, but another machine also on 19.10 does not, and it's showing the same thing. On *this* machine I found that the *first* time I logged out, it was OK, but not the second time. On the other machine, it fails first time too. It's as if the gdm login screen can appear exactly once. That (and being on gnome 3.33) is why I don't think this is a dupe of #1824588. Nothing appears in /var/crash as a result of this. ProblemType: Bug DistroRelease: Ubuntu 19.10 Package: gdm3 3.33.90-1ubuntu1 ProcVersionSignature: Ubuntu 5.2.0-13.14-generic 5.2.8 Uname: Linux 5.2.0-13-generic x86_64 ApportVersion: 2.20.11-0ubuntu7 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Thu Aug 29 10:51:22 2019 InstallationDate: Installed on 2018-09-11 (351 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214) SourcePackage: gdm3 UpgradeStatus: Upgraded to eoan on 2019-07-16 (43 days ago) mtime.conffile..etc.gdm3.custom.conf: 2019-07-17T00:07:04.528641 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1841915/+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 1841915] Re: black screen, unresponsive, after logout from gnome Wayland session
journalctl -b output as attached loginctl as below: rachel in ~ at rainbow ➜ loginctl SESSION UID USER SEAT TTY 1 1000 rachel seat0 tty2 3 1000 rachel pts/0 2 sessions listed. rachel in ~ at rainbow ➜ loginctl show-session 1 Id=1 User=1000 Name=rachel Timestamp=Tue 2019-09-03 14:30:40 BST TimestampMonotonic=20750725 VTNr=2 Seat=seat0 TTY=tty2 Remote=no Service=gdm-autologin Scope=session-1.scope Leader=5228 Audit=1 Type=wayland Class=user Active=yes State=closing IdleHint=no IdleSinceHint=0 IdleSinceHintMonotonic=0 LockedHint=no rachel in ~ at rainbow ➜ loginctl show-session 3 Id=3 User=1000 Name=rachel Timestamp=Tue 2019-09-03 14:31:47 BST TimestampMonotonic=87793987 VTNr=0 TTY=pts/0 Remote=yes RemoteHost=192.168.1.109 Service=sshd Scope=session-3.scope Leader=7048 Audit=3 Type=tty Class=user Active=yes State=active IdleHint=no IdleSinceHint=1567517624629274 IdleSinceHintMonotonic=205041051 LockedHint=no ** Attachment added: "jctl.log" https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1841915/+attachment/5286446/+files/jctl.log -- 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/1841915 Title: black screen, unresponsive, after logout from gnome Wayland session Status in gdm3 package in Ubuntu: Confirmed Status in gnome-shell package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: on logout the screen is black, the system is unresponsive and has to be restarted. (Untested by me yet, but I expect ssh-ing in and restarting gdm would work.) I believe this may be already reported upstream here: https://bugzilla.redhat.com/show_bug.cgi?id=1745554 That's why I've reported this against gdm3 even though I honestly don't know if it might be a gnome-shell, gnome-session or mutter based error. (FWIW without the upstream bug to link to I'd maybe suspect gnome-shell first.) NB: This machine's conf has AutomaticLogin enabled, but another machine also on 19.10 does not, and it's showing the same thing. On *this* machine I found that the *first* time I logged out, it was OK, but not the second time. On the other machine, it fails first time too. It's as if the gdm login screen can appear exactly once. That (and being on gnome 3.33) is why I don't think this is a dupe of #1824588. Nothing appears in /var/crash as a result of this. ProblemType: Bug DistroRelease: Ubuntu 19.10 Package: gdm3 3.33.90-1ubuntu1 ProcVersionSignature: Ubuntu 5.2.0-13.14-generic 5.2.8 Uname: Linux 5.2.0-13-generic x86_64 ApportVersion: 2.20.11-0ubuntu7 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Thu Aug 29 10:51:22 2019 InstallationDate: Installed on 2018-09-11 (351 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214) SourcePackage: gdm3 UpgradeStatus: Upgraded to eoan on 2019-07-16 (43 days ago) mtime.conffile..etc.gdm3.custom.conf: 2019-07-17T00:07:04.528641 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1841915/+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 1841915] Re: black screen, unresponsive, after logout from gnome Wayland session
It is definitely /usr/lib/systemd/user-gnome-session-wayland.target. dpkg -S on that file gives gnome-session-bin which is on version 3.33.90-2ubuntu2. dpkg -S on the .service file gives no match. This problem didn't start on upgrade to the 5.2 kernels, which happened a few weeks(?) earlier, but immediately when gnome 3.33 dropped. will get the gdm debugging stuff... (had to spend some time in windows doing that for which i'm paid ;-) -- 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/1841915 Title: black screen, unresponsive, after logout from gnome Wayland session Status in gdm3 package in Ubuntu: Confirmed Status in gnome-shell package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: on logout the screen is black, the system is unresponsive and has to be restarted. (Untested by me yet, but I expect ssh-ing in and restarting gdm would work.) I believe this may be already reported upstream here: https://bugzilla.redhat.com/show_bug.cgi?id=1745554 That's why I've reported this against gdm3 even though I honestly don't know if it might be a gnome-shell, gnome-session or mutter based error. (FWIW without the upstream bug to link to I'd maybe suspect gnome-shell first.) NB: This machine's conf has AutomaticLogin enabled, but another machine also on 19.10 does not, and it's showing the same thing. On *this* machine I found that the *first* time I logged out, it was OK, but not the second time. On the other machine, it fails first time too. It's as if the gdm login screen can appear exactly once. That (and being on gnome 3.33) is why I don't think this is a dupe of #1824588. Nothing appears in /var/crash as a result of this. ProblemType: Bug DistroRelease: Ubuntu 19.10 Package: gdm3 3.33.90-1ubuntu1 ProcVersionSignature: Ubuntu 5.2.0-13.14-generic 5.2.8 Uname: Linux 5.2.0-13-generic x86_64 ApportVersion: 2.20.11-0ubuntu7 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Thu Aug 29 10:51:22 2019 InstallationDate: Installed on 2018-09-11 (351 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214) SourcePackage: gdm3 UpgradeStatus: Upgraded to eoan on 2019-07-16 (43 days ago) mtime.conffile..etc.gdm3.custom.conf: 2019-07-17T00:07:04.528641 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1841915/+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 1841915] Re: black screen, unresponsive, after logout from gnome Wayland session
With --systemd removed as directed I still ended up stuck on a black screen, except this time it had a flashing white text cursor in the top left. (BTW reboots occurred between each test, somewhat perforce...) -- 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/1841915 Title: black screen, unresponsive, after logout from gnome Wayland session Status in gdm3 package in Ubuntu: Confirmed Status in gnome-shell package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: on logout the screen is black, the system is unresponsive and has to be restarted. (Untested by me yet, but I expect ssh-ing in and restarting gdm would work.) I believe this may be already reported upstream here: https://bugzilla.redhat.com/show_bug.cgi?id=1745554 That's why I've reported this against gdm3 even though I honestly don't know if it might be a gnome-shell, gnome-session or mutter based error. (FWIW without the upstream bug to link to I'd maybe suspect gnome-shell first.) NB: This machine's conf has AutomaticLogin enabled, but another machine also on 19.10 does not, and it's showing the same thing. On *this* machine I found that the *first* time I logged out, it was OK, but not the second time. On the other machine, it fails first time too. It's as if the gdm login screen can appear exactly once. That (and being on gnome 3.33) is why I don't think this is a dupe of #1824588. Nothing appears in /var/crash as a result of this. ProblemType: Bug DistroRelease: Ubuntu 19.10 Package: gdm3 3.33.90-1ubuntu1 ProcVersionSignature: Ubuntu 5.2.0-13.14-generic 5.2.8 Uname: Linux 5.2.0-13-generic x86_64 ApportVersion: 2.20.11-0ubuntu7 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Thu Aug 29 10:51:22 2019 InstallationDate: Installed on 2018-09-11 (351 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214) SourcePackage: gdm3 UpgradeStatus: Upgraded to eoan on 2019-07-16 (43 days ago) mtime.conffile..etc.gdm3.custom.conf: 2019-07-17T00:07:04.528641 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1841915/+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 1841915] Re: black screen, unresponsive, after logout from gnome Wayland session
I tried (just now) deliberately leaving it longer than 30 seconds to come back after a logout. In fact left it longer than 60 seconds. Nothing happening. I wasn't logged in via ssh as well at the time (I hadn't thought the systemd --user instance was related to the ssh session before so presumably might be confusing matters) so there's nothing more to report than that the screen remained resolutely black. There is no /usr/lib/systemd/user/gnome-session-wayland.service file on this system. There is a .target file though which is presumably the one. As the presumably-default timeout didn't seem to be honoured here there didn't seem a lot of point in adding a shorter one so I left the file alone. I'll try the change to /usr/share/wayland-sessions/ubuntu- wayland.desktop (the only file in that directory) and report back in the next comment... -- 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/1841915 Title: black screen, unresponsive, after logout from gnome Wayland session Status in gdm3 package in Ubuntu: Confirmed Status in gnome-shell package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: on logout the screen is black, the system is unresponsive and has to be restarted. (Untested by me yet, but I expect ssh-ing in and restarting gdm would work.) I believe this may be already reported upstream here: https://bugzilla.redhat.com/show_bug.cgi?id=1745554 That's why I've reported this against gdm3 even though I honestly don't know if it might be a gnome-shell, gnome-session or mutter based error. (FWIW without the upstream bug to link to I'd maybe suspect gnome-shell first.) NB: This machine's conf has AutomaticLogin enabled, but another machine also on 19.10 does not, and it's showing the same thing. On *this* machine I found that the *first* time I logged out, it was OK, but not the second time. On the other machine, it fails first time too. It's as if the gdm login screen can appear exactly once. That (and being on gnome 3.33) is why I don't think this is a dupe of #1824588. Nothing appears in /var/crash as a result of this. ProblemType: Bug DistroRelease: Ubuntu 19.10 Package: gdm3 3.33.90-1ubuntu1 ProcVersionSignature: Ubuntu 5.2.0-13.14-generic 5.2.8 Uname: Linux 5.2.0-13-generic x86_64 ApportVersion: 2.20.11-0ubuntu7 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Thu Aug 29 10:51:22 2019 InstallationDate: Installed on 2018-09-11 (351 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214) SourcePackage: gdm3 UpgradeStatus: Upgraded to eoan on 2019-07-16 (43 days ago) mtime.conffile..etc.gdm3.custom.conf: 2019-07-17T00:07:04.528641 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1841915/+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 1827099] Re: package shared-mime-info 1.10-1 failed to install/upgrade: triggers looping, abandoned
ditto upgrading in two steps bionic->cosmic->disco -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to shared-mime-info in Ubuntu. https://bugs.launchpad.net/bugs/1827099 Title: package shared-mime-info 1.10-1 failed to install/upgrade: triggers looping, abandoned Status in shared-mime-info package in Ubuntu: Confirmed Bug description: Crash at the end of upgrade to 19.04 ProblemType: Package DistroRelease: Ubuntu 19.04 Package: shared-mime-info 1.10-1 ProcVersionSignature: Ubuntu 4.18.0-18.19-generic 4.18.20 Uname: Linux 4.18.0-18-generic x86_64 ApportVersion: 2.20.10-0ubuntu27 Architecture: amd64 Date: Tue Apr 30 21:07:35 2019 ErrorMessage: triggers looping, abandoned InstallationDate: Installed on 2015-10-28 (1280 days ago) InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Release amd64 (20151021) Python3Details: /usr/bin/python3.6, Python 3.6.8, python3-minimal, 3.6.7-1~18.10 PythonDetails: /usr/bin/python2.7, Python 2.7.16, python-minimal, 2.7.16-1 RelatedPackageVersions: dpkg 1.19.6ubuntu1 apt 1.8.0 SourcePackage: shared-mime-info Title: package shared-mime-info 1.10-1 failed to install/upgrade: triggers looping, abandoned UpgradeStatus: Upgraded to disco on 2019-04-30 (0 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/shared-mime-info/+bug/1827099/+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 1818517] Re: "Network Login" browser does not remember cookies
trying to get that screenshot was how i discovered it *does* appear to be retaining stuff for a while at least. :-) I'll try to do so next time I'm there. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1818517 Title: "Network Login" browser does not remember cookies Status in network-manager package in Ubuntu: Incomplete Bug description: This is with respect to the gnome-shell-portal-helper, part of the gnome-shell package, which opens its own browser window to prompt for a wifi hotspot login. It all works fine except one little papercut: Could it remember cookies? So when I go back to the same hotspot most days I don't have to click OK to accept cookies every time before I can actually click to go online. It's possible I suppose they don't all use cookies. The hotspot in question is a BT wifi hotspot, so probably quite common in GB anyway. Desired behaviour, hate to say, is like Windows: It actually remembered my choice from before and just logged me in right away. ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: gnome-shell 3.31.90-1ubuntu1 ProcVersionSignature: Ubuntu 4.19.0-13.14-generic 4.19.20 Uname: Linux 4.19.0-13-generic x86_64 ApportVersion: 2.20.10-0ubuntu21 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Mon Mar 4 14:05:46 2019 DisplayManager: gdm3 InstallationDate: Installed on 2018-09-11 (173 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214) SourcePackage: gnome-shell UpgradeStatus: Upgraded to disco on 2019-01-13 (49 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1818517/+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 1818517] Re: "Network Login" browser does not remember cookies
actually i think cookies are being held for at least a while, as, sitting in the cafe, I can log out and in, and even reboot, and get logged directly back into the hotspot. But when I come back the next day I'm asked if I even want to accept cookies. It's that being asked to accept cookies every day [that I go there] that annoys me, not whether or not it actually logs me in or i have to click on a button to connect. But in Windows, for instance, it remembered me even though I hadn't booted up windows at the cafe for *months*. so i'm guessing there is cookie retention going on, but on a rather short timeout. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1818517 Title: "Network Login" browser does not remember cookies Status in network-manager package in Ubuntu: Incomplete Bug description: This is with respect to the gnome-shell-portal-helper, part of the gnome-shell package, which opens its own browser window to prompt for a wifi hotspot login. It all works fine except one little papercut: Could it remember cookies? So when I go back to the same hotspot most days I don't have to click OK to accept cookies every time before I can actually click to go online. It's possible I suppose they don't all use cookies. The hotspot in question is a BT wifi hotspot, so probably quite common in GB anyway. Desired behaviour, hate to say, is like Windows: It actually remembered my choice from before and just logged me in right away. ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: gnome-shell 3.31.90-1ubuntu1 ProcVersionSignature: Ubuntu 4.19.0-13.14-generic 4.19.20 Uname: Linux 4.19.0-13-generic x86_64 ApportVersion: 2.20.10-0ubuntu21 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Mon Mar 4 14:05:46 2019 DisplayManager: gdm3 InstallationDate: Installed on 2018-09-11 (173 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214) SourcePackage: gnome-shell UpgradeStatus: Upgraded to disco on 2019-01-13 (49 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1818517/+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 1818517] Re: "Network Login" browser does not remember cookies
i mean literally http web cookies from the portal page. if you ignore the network login app (as was the case before it worked reliably), it shows up in your normal browser. This does remember cookies, so you don't get asked if you want to accept cookies every time you go there. What the portal does when it's presented with the cookie it gave you on your last visit is, i think, a matter for the portal. My guess is that it's probably *it* that would auto-connect you under whatever circumstances it sees fit. Otherwise you just get the normal "Click to connect" button. I think *all* this needs is the support for, and storage of, HTTP cookies from the portal, in whatever's providing the browser window component of the Network Login app. My talk of auto-login stuff was just confusing the matter, ignore it. :-) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1818517 Title: "Network Login" browser does not remember cookies Status in network-manager package in Ubuntu: Incomplete Bug description: This is with respect to the gnome-shell-portal-helper, part of the gnome-shell package, which opens its own browser window to prompt for a wifi hotspot login. It all works fine except one little papercut: Could it remember cookies? So when I go back to the same hotspot most days I don't have to click OK to accept cookies every time before I can actually click to go online. It's possible I suppose they don't all use cookies. The hotspot in question is a BT wifi hotspot, so probably quite common in GB anyway. Desired behaviour, hate to say, is like Windows: It actually remembered my choice from before and just logged me in right away. ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: gnome-shell 3.31.90-1ubuntu1 ProcVersionSignature: Ubuntu 4.19.0-13.14-generic 4.19.20 Uname: Linux 4.19.0-13-generic x86_64 ApportVersion: 2.20.10-0ubuntu21 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Mon Mar 4 14:05:46 2019 DisplayManager: gdm3 InstallationDate: Installed on 2018-09-11 (173 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214) SourcePackage: gnome-shell UpgradeStatus: Upgraded to disco on 2019-01-13 (49 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1818517/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1814262] Re: Wired interface gets impossibly high metric 20100
Follow up comment on the upstream bug pointed to a commit where it suggests the rp_filter default should actually now be 2 rather than 1: https://github.com/systemd/systemd/commit/230450d4e4f1f5fc9fa4295ed9185eea5b6ea16e Think at this point I need to just let you guys talk amongst yourself. :-) For me, my fix for now is to uninstall the connectivity-check package, which disables the functionality. I'm not going to mess about changing procps defaults. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1814262 Title: Wired interface gets impossibly high metric 20100 Status in network-manager package in Ubuntu: New Bug description: Actually this might be a heisenbug. I've had an issue with this all morning since network-manager got an update this morning, but just now *while this bug was being submitted* it decided to correct itself. What I was getting was, on a machine (Dell XPS 13 9370) with WiFi and a (Caldigit) Thunderbolt 3 dock with an ethernet port: After the network-manager update I noticed everything was slower than I was used to, and in gnome-shell the network icon showing was the WiFi one, not the wired one. Looking at the output of route, or route -n for simplicity, I would see this: rachel@rainbow:~$ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 0.0.0.0 192.168.1.254 0.0.0.0 UG60000 wlp2s0 0.0.0.0 192.168.1.254 0.0.0.0 UG20100 00 enp63s0 169.254.0.0 0.0.0.0 255.255.0.0 U 1000 00 wlp2s0 192.168.1.0 0.0.0.0 255.255.255.0 U 10000 enp63s0 192.168.1.0 0.0.0.0 255.255.255.0 U 60000 wlp2s0 So the metric on the default route on enp63s0 had 20,000 mysteriously added to it, which would obviously make it extremely low-priority. The system was choosing the wifi connection instead, which isn't that great in my office, hence observable slowness. Now, this morning, this seemed to be the sticky situation. It didn't show any sign of changing, whatever I did, after restarts of network- manager, undock/redock, reboots, etc. I could change it manually with ifmetric (and it would work), but that was about it. I would have reported the bug then, but I had to go out. When I got back I plugged in and initially saw the same thing again (that's where the above snippet was pasted from). But *while* the ubuntu-bug network-manager command was running, I noticed the gnome-shell network icon switch to wired, checked again, and saw: rachel@rainbow:~$ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 0.0.0.0 192.168.1.254 0.0.0.0 UG10000 enp63s0 0.0.0.0 192.168.1.254 0.0.0.0 UG20600 00 wlp2s0 169.254.0.0 0.0.0.0 255.255.0.0 U 1000 00 wlp2s0 192.168.1.0 0.0.0.0 255.255.255.0 U 10000 enp63s0 192.168.1.0 0.0.0.0 255.255.255.0 U 60000 wlp2s0 So now the wifi connection has 20,000 added to it, which may still be wrong? But I wouldn't otherwise have noticed it because the system is again *behaving* as expected. This all seemed to happen after the network-manager upgrade (from 1.12.6-0ubuntu4 to 1.15.2-0ubuntu1) this morning. I can't say if these metric+20,000 values were present before then, because I didn't have any cause to go looking at it, it always just worked. Could it be some issue with how the newer network-manager, or one of its associated packages, is figuring out the metrics on new connections? Like it's running some new heuristic to determine which one should really be the preferred? If it's like it was just now, when it fixed itself after a minute or so, that's not really a problem, but if it's like it was this morning when it just seemed to be stuck with the ethernet connection at 20100, it is. ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: network-manager 1.15.2-0ubuntu1 ProcVersionSignature: Ubuntu 4.18.0-13.14-generic 4.18.17 Uname: Linux 4.18.0-13-generic x86_64 ApportVersion: 2.20.10-0ubuntu19 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Fri Feb 1 13:15:06 2019 IfupdownConfig: # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback InstallationDate: Installed on 2018-09-11 (142 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214) IpRoute: default via 192.168.1.254 dev wlp2s0 proto dhcp metric 600 default via 192.168.1.254 dev enp63s0 proto dhcp metric 20100 169.254.0.0/16 dev wlp2s0 scope link metric 1000
[Touch-packages] [Bug 1814262] Re: Wired interface gets impossibly high metric 20100
Reporting back on this:
The opinion there seems to be that the problem is down to the sys
net.ipv4.conf.*.rp_filter values being set to 1 instead of defaulting to
0. This is done in the procps package, and I'm guessing is the way it is
as a protection against IP spoofing. kernel doc page I was pointed to
says:
Current recommended practice in RFC3704 is to enable strict mode
to prevent IP spoofing from DDos attacks. If using asymmetric routing
or other complicated routing, then loose mode is recommended.
The max value from conf/{all,interface}/rp_filter is used
when doing source validation on the {interface}.
Default value is 0. Note that some distributions enable it
in startup scripts.
Presumably Ubuntu enables by default (I can see it does, in a file in
the procps package) and Red Hat, where it seems the NetworkManager
maintainers sit, does not.
This is going to have to be argued out between procps and network-
manager maintainers I guess. You can have IP spoofing protection or you
can have connectivity checking. Choose one, or argue who should fix it.
:-) Personally, at least for now, my solution is to remove the
connectivity-check package, which was presumably brought in by
something, and keep the procps defaults.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1814262
Title:
Wired interface gets impossibly high metric 20100
Status in network-manager package in Ubuntu:
New
Bug description:
Actually this might be a heisenbug. I've had an issue with this all
morning since network-manager got an update this morning, but just now
*while this bug was being submitted* it decided to correct itself.
What I was getting was, on a machine (Dell XPS 13 9370) with WiFi and
a (Caldigit) Thunderbolt 3 dock with an ethernet port: After the
network-manager update I noticed everything was slower than I was used
to, and in gnome-shell the network icon showing was the WiFi one, not
the wired one.
Looking at the output of route, or route -n for simplicity, I would
see this:
rachel@rainbow:~$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric RefUse Iface
0.0.0.0 192.168.1.254 0.0.0.0 UG60000 wlp2s0
0.0.0.0 192.168.1.254 0.0.0.0 UG20100 00
enp63s0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 00 wlp2s0
192.168.1.0 0.0.0.0 255.255.255.0 U 10000
enp63s0
192.168.1.0 0.0.0.0 255.255.255.0 U 60000 wlp2s0
So the metric on the default route on enp63s0 had 20,000 mysteriously
added to it, which would obviously make it extremely low-priority. The
system was choosing the wifi connection instead, which isn't that
great in my office, hence observable slowness.
Now, this morning, this seemed to be the sticky situation. It didn't
show any sign of changing, whatever I did, after restarts of network-
manager, undock/redock, reboots, etc. I could change it manually with
ifmetric (and it would work), but that was about it.
I would have reported the bug then, but I had to go out. When I got
back I plugged in and initially saw the same thing again (that's where
the above snippet was pasted from). But *while* the ubuntu-bug
network-manager command was running, I noticed the gnome-shell network
icon switch to wired, checked again, and saw:
rachel@rainbow:~$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric RefUse Iface
0.0.0.0 192.168.1.254 0.0.0.0 UG10000
enp63s0
0.0.0.0 192.168.1.254 0.0.0.0 UG20600 00 wlp2s0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 00 wlp2s0
192.168.1.0 0.0.0.0 255.255.255.0 U 10000
enp63s0
192.168.1.0 0.0.0.0 255.255.255.0 U 60000 wlp2s0
So now the wifi connection has 20,000 added to it, which may still be
wrong? But I wouldn't otherwise have noticed it because the system is
again *behaving* as expected.
This all seemed to happen after the network-manager upgrade (from
1.12.6-0ubuntu4 to 1.15.2-0ubuntu1) this morning. I can't say if these
metric+20,000 values were present before then, because I didn't have
any cause to go looking at it, it always just worked. Could it be some
issue with how the newer network-manager, or one of its associated
packages, is figuring out the metrics on new connections? Like it's
running some new heuristic to determine which one should really be the
preferred? If it's like it was just now, when it fixed itself after a
minute or so, that's not really a problem, but if it's like it was
this morning
[Touch-packages] [Bug 1815036] [NEW] uri defined for connectivity check does not have IPv6 address
Public bug reported: As per subject. This package defines the file /usr/lib/NetworkManager/conf.d/20-connectivity-ubuntu.conf, which defines the uri for the connectivity check to be http://connectivity- check.ubuntu.com This hostname does not resolve to an IPv6 address. Therefore, even if the user has fully working IPv6, the connectivity check for IPv6 will fail. As a result, the IPv6 default routes will be heavily deprioritised (ie: having 2 added to the metric) rendering them effectively inoperable absent a deliberate effort to use IPv6-only addresses. NB: This was discovered by-the-by during reporting of bug #1814262 upstream at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/116#note_114448 It seems to be irrelevant to the main thrust of that bug, which is that IPv4 wired routes are not being identified as working correctly. In fact, when I switch to network-manager-config-connectivity-debian, the hostname defined there *does* have a working IPv6 address, and the issue actually being reported in that other bug does not affect the IPv6 routes, only the IPv4 ones. The bug here probably doesn't need any change made to the package itself, but rather to the networking of the actual target URL. It needs an IPv6 () DNS record, and for it to function on that address. I note in passing the debian connectivity check URL resolves to several IP addresses - four IPv4 addresses and 3 IPv6 addresses, presumably geographically diverse. (It's actually a CNAME to static.debian.org) This looks like it would be a more reliable target for connectivity checks. The ubuntu URL only resolves to a single IPv4 address. ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: network-manager-config-connectivity-ubuntu 1.15.2-0ubuntu1 ProcVersionSignature: Ubuntu 4.19.0-12.13-generic 4.19.18 Uname: Linux 4.19.0-12-generic x86_64 ApportVersion: 2.20.10-0ubuntu20 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Thu Feb 7 12:35:24 2019 IfupdownConfig: # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback InstallationDate: Installed on 2018-09-11 (148 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214) IpRoute: default via 192.168.1.254 dev enp63s0 proto dhcp metric 100 default via 192.168.1.254 dev wlp2s0 proto dhcp metric 20600 169.254.0.0/16 dev wlp2s0 scope link metric 1000 192.168.1.0/24 dev enp63s0 proto kernel scope link src 192.168.1.106 metric 100 192.168.1.0/24 dev wlp2s0 proto kernel scope link src 192.168.1.101 metric 600 NetworkManager.state: [main] NetworkingEnabled=true WirelessEnabled=true WWANEnabled=true PackageArchitecture: all SourcePackage: network-manager UpgradeStatus: Upgraded to disco on 2019-01-13 (24 days ago) nmcli-nm: RUNNING VERSION STATE STARTUP CONNECTIVITY NETWORKING WIFI-HW WIFI WWAN-HW WWAN running 1.15.2 connected started full enabled enabled enabled enabled enabled ** Affects: network-manager (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug disco -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1815036 Title: uri defined for connectivity check does not have IPv6 address Status in network-manager package in Ubuntu: New Bug description: As per subject. This package defines the file /usr/lib/NetworkManager/conf.d/20-connectivity-ubuntu.conf, which defines the uri for the connectivity check to be http://connectivity- check.ubuntu.com This hostname does not resolve to an IPv6 address. Therefore, even if the user has fully working IPv6, the connectivity check for IPv6 will fail. As a result, the IPv6 default routes will be heavily deprioritised (ie: having 2 added to the metric) rendering them effectively inoperable absent a deliberate effort to use IPv6-only addresses. NB: This was discovered by-the-by during reporting of bug #1814262 upstream at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/116#note_114448 It seems to be irrelevant to the main thrust of that bug, which is that IPv4 wired routes are not being identified as working correctly. In fact, when I switch to network-manager-config-connectivity-debian, the hostname defined there *does* have a working IPv6 address, and the issue actually being reported in that other bug does not affect the IPv6 routes, only the IPv4 ones. The bug here probably doesn't need any change made to the package itself, but rather to the networking of the actual target URL. It needs an IPv6 () DNS record, and for it to function on that address. I note in passing the debian connectivity check URL resolves to several IP addresses - four IPv4 addresses and 3 IPv6 addresses, presumably geographically diverse. (It's actually a CNAME to static.debian.org)
[Touch-packages] [Bug 1814262] Re: Wired interface gets impossibly high metric 20100
As it recurred again today and showed no signs of correcting itself like it did on Friday, I went ahead and reported it upstream, here: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/116 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1814262 Title: Wired interface gets impossibly high metric 20100 Status in network-manager package in Ubuntu: New Bug description: Actually this might be a heisenbug. I've had an issue with this all morning since network-manager got an update this morning, but just now *while this bug was being submitted* it decided to correct itself. What I was getting was, on a machine (Dell XPS 13 9370) with WiFi and a (Caldigit) Thunderbolt 3 dock with an ethernet port: After the network-manager update I noticed everything was slower than I was used to, and in gnome-shell the network icon showing was the WiFi one, not the wired one. Looking at the output of route, or route -n for simplicity, I would see this: rachel@rainbow:~$ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 0.0.0.0 192.168.1.254 0.0.0.0 UG60000 wlp2s0 0.0.0.0 192.168.1.254 0.0.0.0 UG20100 00 enp63s0 169.254.0.0 0.0.0.0 255.255.0.0 U 1000 00 wlp2s0 192.168.1.0 0.0.0.0 255.255.255.0 U 10000 enp63s0 192.168.1.0 0.0.0.0 255.255.255.0 U 60000 wlp2s0 So the metric on the default route on enp63s0 had 20,000 mysteriously added to it, which would obviously make it extremely low-priority. The system was choosing the wifi connection instead, which isn't that great in my office, hence observable slowness. Now, this morning, this seemed to be the sticky situation. It didn't show any sign of changing, whatever I did, after restarts of network- manager, undock/redock, reboots, etc. I could change it manually with ifmetric (and it would work), but that was about it. I would have reported the bug then, but I had to go out. When I got back I plugged in and initially saw the same thing again (that's where the above snippet was pasted from). But *while* the ubuntu-bug network-manager command was running, I noticed the gnome-shell network icon switch to wired, checked again, and saw: rachel@rainbow:~$ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 0.0.0.0 192.168.1.254 0.0.0.0 UG10000 enp63s0 0.0.0.0 192.168.1.254 0.0.0.0 UG20600 00 wlp2s0 169.254.0.0 0.0.0.0 255.255.0.0 U 1000 00 wlp2s0 192.168.1.0 0.0.0.0 255.255.255.0 U 10000 enp63s0 192.168.1.0 0.0.0.0 255.255.255.0 U 60000 wlp2s0 So now the wifi connection has 20,000 added to it, which may still be wrong? But I wouldn't otherwise have noticed it because the system is again *behaving* as expected. This all seemed to happen after the network-manager upgrade (from 1.12.6-0ubuntu4 to 1.15.2-0ubuntu1) this morning. I can't say if these metric+20,000 values were present before then, because I didn't have any cause to go looking at it, it always just worked. Could it be some issue with how the newer network-manager, or one of its associated packages, is figuring out the metrics on new connections? Like it's running some new heuristic to determine which one should really be the preferred? If it's like it was just now, when it fixed itself after a minute or so, that's not really a problem, but if it's like it was this morning when it just seemed to be stuck with the ethernet connection at 20100, it is. ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: network-manager 1.15.2-0ubuntu1 ProcVersionSignature: Ubuntu 4.18.0-13.14-generic 4.18.17 Uname: Linux 4.18.0-13-generic x86_64 ApportVersion: 2.20.10-0ubuntu19 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Fri Feb 1 13:15:06 2019 IfupdownConfig: # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback InstallationDate: Installed on 2018-09-11 (142 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214) IpRoute: default via 192.168.1.254 dev wlp2s0 proto dhcp metric 600 default via 192.168.1.254 dev enp63s0 proto dhcp metric 20100 169.254.0.0/16 dev wlp2s0 scope link metric 1000 192.168.1.0/24 dev enp63s0 proto kernel scope link src 192.168.1.106 metric 100 192.168.1.0/24 dev wlp2s0 proto kernel scope link src 192.168.1.101 metric 600 NetworkManager.state: [main] NetworkingEnabled=true WirelessEnabled=true
Re: [Touch-packages] [Bug 1814262] Re: Wired interface gets impossibly high metric 20100
Noted. I see there's no report of anything similar already, and if it was the sort of problem it looked like to me, people would be screaming blue murder about it, so I think I'll wait and see if it recurs or becomes an ongoing problem, rather than a one-off. Maybe my LAN was having a bad hair day... -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1814262 Title: Wired interface gets impossibly high metric 20100 Status in network-manager package in Ubuntu: New Bug description: Actually this might be a heisenbug. I've had an issue with this all morning since network-manager got an update this morning, but just now *while this bug was being submitted* it decided to correct itself. What I was getting was, on a machine (Dell XPS 13 9370) with WiFi and a (Caldigit) Thunderbolt 3 dock with an ethernet port: After the network-manager update I noticed everything was slower than I was used to, and in gnome-shell the network icon showing was the WiFi one, not the wired one. Looking at the output of route, or route -n for simplicity, I would see this: rachel@rainbow:~$ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 0.0.0.0 192.168.1.254 0.0.0.0 UG60000 wlp2s0 0.0.0.0 192.168.1.254 0.0.0.0 UG20100 00 enp63s0 169.254.0.0 0.0.0.0 255.255.0.0 U 1000 00 wlp2s0 192.168.1.0 0.0.0.0 255.255.255.0 U 10000 enp63s0 192.168.1.0 0.0.0.0 255.255.255.0 U 60000 wlp2s0 So the metric on the default route on enp63s0 had 20,000 mysteriously added to it, which would obviously make it extremely low-priority. The system was choosing the wifi connection instead, which isn't that great in my office, hence observable slowness. Now, this morning, this seemed to be the sticky situation. It didn't show any sign of changing, whatever I did, after restarts of network- manager, undock/redock, reboots, etc. I could change it manually with ifmetric (and it would work), but that was about it. I would have reported the bug then, but I had to go out. When I got back I plugged in and initially saw the same thing again (that's where the above snippet was pasted from). But *while* the ubuntu-bug network-manager command was running, I noticed the gnome-shell network icon switch to wired, checked again, and saw: rachel@rainbow:~$ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 0.0.0.0 192.168.1.254 0.0.0.0 UG10000 enp63s0 0.0.0.0 192.168.1.254 0.0.0.0 UG20600 00 wlp2s0 169.254.0.0 0.0.0.0 255.255.0.0 U 1000 00 wlp2s0 192.168.1.0 0.0.0.0 255.255.255.0 U 10000 enp63s0 192.168.1.0 0.0.0.0 255.255.255.0 U 60000 wlp2s0 So now the wifi connection has 20,000 added to it, which may still be wrong? But I wouldn't otherwise have noticed it because the system is again *behaving* as expected. This all seemed to happen after the network-manager upgrade (from 1.12.6-0ubuntu4 to 1.15.2-0ubuntu1) this morning. I can't say if these metric+20,000 values were present before then, because I didn't have any cause to go looking at it, it always just worked. Could it be some issue with how the newer network-manager, or one of its associated packages, is figuring out the metrics on new connections? Like it's running some new heuristic to determine which one should really be the preferred? If it's like it was just now, when it fixed itself after a minute or so, that's not really a problem, but if it's like it was this morning when it just seemed to be stuck with the ethernet connection at 20100, it is. ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: network-manager 1.15.2-0ubuntu1 ProcVersionSignature: Ubuntu 4.18.0-13.14-generic 4.18.17 Uname: Linux 4.18.0-13-generic x86_64 ApportVersion: 2.20.10-0ubuntu19 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Fri Feb 1 13:15:06 2019 IfupdownConfig: # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback InstallationDate: Installed on 2018-09-11 (142 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214) IpRoute: default via 192.168.1.254 dev wlp2s0 proto dhcp metric 600 default via 192.168.1.254 dev enp63s0 proto dhcp metric 20100 169.254.0.0/16 dev wlp2s0 scope link metric 1000 192.168.1.0/24 dev enp63s0 proto kernel scope link src 192.168.1.106 metric 100 192.168.1.0/24 dev wlp2s0 proto kernel scope link src 192.168.1.101
[Touch-packages] [Bug 1814262] [NEW] Wired interface gets impossibly high metric 20100
Public bug reported: Actually this might be a heisenbug. I've had an issue with this all morning since network-manager got an update this morning, but just now *while this bug was being submitted* it decided to correct itself. What I was getting was, on a machine (Dell XPS 13 9370) with WiFi and a (Caldigit) Thunderbolt 3 dock with an ethernet port: After the network- manager update I noticed everything was slower than I was used to, and in gnome-shell the network icon showing was the WiFi one, not the wired one. Looking at the output of route, or route -n for simplicity, I would see this: rachel@rainbow:~$ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 0.0.0.0 192.168.1.254 0.0.0.0 UG60000 wlp2s0 0.0.0.0 192.168.1.254 0.0.0.0 UG20100 00 enp63s0 169.254.0.0 0.0.0.0 255.255.0.0 U 1000 00 wlp2s0 192.168.1.0 0.0.0.0 255.255.255.0 U 10000 enp63s0 192.168.1.0 0.0.0.0 255.255.255.0 U 60000 wlp2s0 So the metric on the default route on enp63s0 had 20,000 mysteriously added to it, which would obviously make it extremely low-priority. The system was choosing the wifi connection instead, which isn't that great in my office, hence observable slowness. Now, this morning, this seemed to be the sticky situation. It didn't show any sign of changing, whatever I did, after restarts of network- manager, undock/redock, reboots, etc. I could change it manually with ifmetric (and it would work), but that was about it. I would have reported the bug then, but I had to go out. When I got back I plugged in and initially saw the same thing again (that's where the above snippet was pasted from). But *while* the ubuntu-bug network- manager command was running, I noticed the gnome-shell network icon switch to wired, checked again, and saw: rachel@rainbow:~$ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 0.0.0.0 192.168.1.254 0.0.0.0 UG10000 enp63s0 0.0.0.0 192.168.1.254 0.0.0.0 UG20600 00 wlp2s0 169.254.0.0 0.0.0.0 255.255.0.0 U 1000 00 wlp2s0 192.168.1.0 0.0.0.0 255.255.255.0 U 10000 enp63s0 192.168.1.0 0.0.0.0 255.255.255.0 U 60000 wlp2s0 So now the wifi connection has 20,000 added to it, which may still be wrong? But I wouldn't otherwise have noticed it because the system is again *behaving* as expected. This all seemed to happen after the network-manager upgrade (from 1.12.6-0ubuntu4 to 1.15.2-0ubuntu1) this morning. I can't say if these metric+20,000 values were present before then, because I didn't have any cause to go looking at it, it always just worked. Could it be some issue with how the newer network-manager, or one of its associated packages, is figuring out the metrics on new connections? Like it's running some new heuristic to determine which one should really be the preferred? If it's like it was just now, when it fixed itself after a minute or so, that's not really a problem, but if it's like it was this morning when it just seemed to be stuck with the ethernet connection at 20100, it is. ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: network-manager 1.15.2-0ubuntu1 ProcVersionSignature: Ubuntu 4.18.0-13.14-generic 4.18.17 Uname: Linux 4.18.0-13-generic x86_64 ApportVersion: 2.20.10-0ubuntu19 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Fri Feb 1 13:15:06 2019 IfupdownConfig: # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback InstallationDate: Installed on 2018-09-11 (142 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214) IpRoute: default via 192.168.1.254 dev wlp2s0 proto dhcp metric 600 default via 192.168.1.254 dev enp63s0 proto dhcp metric 20100 169.254.0.0/16 dev wlp2s0 scope link metric 1000 192.168.1.0/24 dev enp63s0 proto kernel scope link src 192.168.1.106 metric 100 192.168.1.0/24 dev wlp2s0 proto kernel scope link src 192.168.1.101 metric 600 NetworkManager.state: [main] NetworkingEnabled=true WirelessEnabled=true WWANEnabled=true RfKill: 1: phy0: Wireless LAN Soft blocked: no Hard blocked: no SourcePackage: network-manager UpgradeStatus: Upgraded to disco on 2019-01-13 (18 days ago) nmcli-dev: DEVICE TYPE STATE IP4-CONNECTIVITY IP6-CONNECTIVITY DBUS-PATH CONNECTION CON-UUID CON-PATH wlp2s0 wifi connected full limited /org/freedesktop/NetworkManager/Devices/2 Strange Noises ae54-3c3d-4714-8bf5-7e56bb7249c6 /org/freedesktop/NetworkManager/ActiveConnection/2 enp63s0 ethernet
[Touch-packages] [Bug 1712866] Re: icons from qt applications disappear after screen lock/sleep
FWIW I have *not* seen this since upgrading to Bionic. It was probably fixed sooner, when they said it was, but at some point I gave up on Artful because of various gnome-shell problems including this, went back to Mac, and tried again with a fresh Bionic install, where they almost all seem to have been fixed. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to qtbase-opensource-src in Ubuntu. https://bugs.launchpad.net/bugs/1712866 Title: icons from qt applications disappear after screen lock/sleep Status in gnome-shell-extension-appindicator package in Ubuntu: Fix Released Status in qtbase-opensource-src package in Ubuntu: Fix Released Status in gnome-shell-extension-appindicator source package in Artful: Fix Released Bug description: [Impact] Indicators of some Qt apps are not showing after unlocking the screen or shell restart. [Test case] - Login to 17.10 - launch dropbox (if not already launched) - Launch telegram (snap version or without libappindicator support) - Observe icons in taskbar - Lock screen with Super+L - Unlock screen - Icons should still be there [Possible regressions] Icons that should be hidden could be visible instead The fix doesn't apply to snapped applications In the Ubuntu Xorg session, with the Ubuntu Appindicator extension enabled, the tray icons for QT apps (in my case, both owncloud-client from the Ubuntu repos and enpass, from their own repo) show up after first logging in. But once the screen has been left idle long enough to be put to sleep, and is then woken up (I don't actually have screen *lock* enabled, but it still goes comes back to the clock screen and a further gesture is needed to scroll that up to get the desktop), then the icons for those QT apps are gone. Non-QT apps (eg: in my case hexchat, from the ubuntu repos) remain. For a while and due to inattention it seemed more random than that, but I'm fairly sure now it's just the display sleep/wake thing that kills it. The applications are still running in the background (so for instance enpass is still available via the browser extension), and can be seen in the process list. It's just the icons that have disappeared. If I then kill those apps (from the commandline with 'kill [pid]' because there's no other interface to do it from) and relaunch them, they reappear back in the appindicator area. ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: gnome-shell-extension-appindicator 17.10 ProcVersionSignature: Ubuntu 4.12.0-11.12-generic 4.12.5 Uname: Linux 4.12.0-11-generic x86_64 NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia ApportVersion: 2.20.6-0ubuntu7 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Thu Aug 24 17:12:43 2017 Dependencies: InstallationDate: Installed on 2017-07-30 (24 days ago) InstallationMedia: Ubuntu-GNOME 17.04 "Zesty Zapus" - Release amd64 (20170412) PackageArchitecture: all SourcePackage: gnome-shell-extension-appindicator UpgradeStatus: Upgraded to artful on 2017-08-22 (2 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-shell-extension-appindicator/+bug/1712866/+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 1768831] Re: package initramfs-tools 0.130ubuntu3 failed to install/upgrade: installed initramfs-tools package post-installation script subprocess returned error exit status 1
belately thought of trying: running sudo update-initramfs -k all -c produced no errors for both currently installed kernels: rachel@spitfire:~$ sudo update-initramfs -k all -c update-initramfs: Generating /boot/initrd.img-4.15.0-21-generic update-initramfs: Generating /boot/initrd.img-4.15.0-20-generic FWIW... -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1768831 Title: package initramfs-tools 0.130ubuntu3 failed to install/upgrade: installed initramfs-tools package post-installation script subprocess returned error exit status 1 Status in initramfs-tools package in Ubuntu: New Bug description: kernel upgrade appeared to go OK actually; on the *second* reboot after that, this appeared after login. ProblemType: Package DistroRelease: Ubuntu 18.04 Package: initramfs-tools 0.130ubuntu3 ProcVersionSignature: Ubuntu 4.15.0-21.22-generic 4.15.17 Uname: Linux 4.15.0-21-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.9-0ubuntu7 Architecture: amd64 Date: Fri Apr 27 13:37:48 2018 ErrorMessage: installed initramfs-tools package post-installation script subprocess returned error exit status 1 InstallationDate: Installed on 2018-02-20 (71 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214) PackageArchitecture: all Python3Details: /usr/bin/python3.6, Python 3.6.5, python3-minimal, 3.6.5-3 PythonDetails: /usr/bin/python2.7, Python 2.7.15rc1, python-minimal, 2.7.15~rc1-1 RelatedPackageVersions: dpkg 1.19.0.5ubuntu2 apt 1.6.1 SourcePackage: initramfs-tools Title: package initramfs-tools 0.130ubuntu3 failed to install/upgrade: installed initramfs-tools package post-installation script subprocess returned error exit status 1 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1768831/+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 1768831] [NEW] package initramfs-tools 0.130ubuntu3 failed to install/upgrade: installed initramfs-tools package post-installation script subprocess returned error exit status 1
Public bug reported: kernel upgrade appeared to go OK actually; on the *second* reboot after that, this appeared after login. ProblemType: Package DistroRelease: Ubuntu 18.04 Package: initramfs-tools 0.130ubuntu3 ProcVersionSignature: Ubuntu 4.15.0-21.22-generic 4.15.17 Uname: Linux 4.15.0-21-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.9-0ubuntu7 Architecture: amd64 Date: Fri Apr 27 13:37:48 2018 ErrorMessage: installed initramfs-tools package post-installation script subprocess returned error exit status 1 InstallationDate: Installed on 2018-02-20 (71 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214) PackageArchitecture: all Python3Details: /usr/bin/python3.6, Python 3.6.5, python3-minimal, 3.6.5-3 PythonDetails: /usr/bin/python2.7, Python 2.7.15rc1, python-minimal, 2.7.15~rc1-1 RelatedPackageVersions: dpkg 1.19.0.5ubuntu2 apt 1.6.1 SourcePackage: initramfs-tools Title: package initramfs-tools 0.130ubuntu3 failed to install/upgrade: installed initramfs-tools package post-installation script subprocess returned error exit status 1 UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: initramfs-tools (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-package bionic -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1768831 Title: package initramfs-tools 0.130ubuntu3 failed to install/upgrade: installed initramfs-tools package post-installation script subprocess returned error exit status 1 Status in initramfs-tools package in Ubuntu: New Bug description: kernel upgrade appeared to go OK actually; on the *second* reboot after that, this appeared after login. ProblemType: Package DistroRelease: Ubuntu 18.04 Package: initramfs-tools 0.130ubuntu3 ProcVersionSignature: Ubuntu 4.15.0-21.22-generic 4.15.17 Uname: Linux 4.15.0-21-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.9-0ubuntu7 Architecture: amd64 Date: Fri Apr 27 13:37:48 2018 ErrorMessage: installed initramfs-tools package post-installation script subprocess returned error exit status 1 InstallationDate: Installed on 2018-02-20 (71 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214) PackageArchitecture: all Python3Details: /usr/bin/python3.6, Python 3.6.5, python3-minimal, 3.6.5-3 PythonDetails: /usr/bin/python2.7, Python 2.7.15rc1, python-minimal, 2.7.15~rc1-1 RelatedPackageVersions: dpkg 1.19.0.5ubuntu2 apt 1.6.1 SourcePackage: initramfs-tools Title: package initramfs-tools 0.130ubuntu3 failed to install/upgrade: installed initramfs-tools package post-installation script subprocess returned error exit status 1 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1768831/+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 1733567] [NEW] apport fails to send crash reports
Public bug reported: There's an ongoing issue with gnome-shell crashing during or on exit from screen lock. I am no longer able to report when this happens because apport silently refuses to send the bug report. If the automatic whoopsie dialog opens at all (it doesn't, often), and I click to send the report, the window closes, and that's it. If I try to use apport-cli to send a specific .crash file, it shows me the menu, I type S to send the report, and apport-cli exits immediately, and again there's no further action. The crashes may be similar to those posted before, although this being an ongoing and unfixed issue (eg: bug #1723620, bug #1723615), one would expect to be able to send updated bug reports at least to show that, eg: a newer version of the affected packages didn't fix it, or to add a new observation (in this case that despite the crash my login session was not ended by it, which is new). At the very least one would expect to see either the list of possible duplicates, or at very *very* least, a message saying that it's been submitted alreadyk or that my version of the affected package is obsolete (it isn't, although I see apport itself is getting an upgrade, but this problem has already persisted through a few apport upgrades). But there's nothing, no feedback at all, it just exits. I wonder also if what's failed here is the ability to open a new browser window, but if so it affects both google chrome and firefox, when each is set to be the default browser. Also, *this* bug, initiated by typing "ubuntu-bug apport", was submitted just fine, but this bug is not the result of an actual *crash* (ie: resulting in a .crash file). ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: apport 2.20.7-0ubuntu3.4 ProcVersionSignature: Ubuntu 4.13.0-17.20-generic 4.13.8 Uname: Linux 4.13.0-17-generic x86_64 NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia ApportLog: ERROR: apport (pid 7178) Tue Nov 21 11:05:18 2017: called for pid 24462, signal 11, core limit 0, dump mode 1 ERROR: apport (pid 7178) Tue Nov 21 11:05:18 2017: executable: /usr/bin/gnome-shell (command line "/usr/bin/gnome-shell") ERROR: apport (pid 7178) Tue Nov 21 11:05:18 2017: debug: session gdbus call: (true,) ERROR: apport (pid 7178) Tue Nov 21 11:06:06 2017: wrote report /var/crash/_usr_bin_gnome-shell.1000.crash ApportVersion: 2.20.7-0ubuntu3.4 Architecture: amd64 CurrentDesktop: GNOME Date: Tue Nov 21 11:15:54 2017 InstallationDate: Installed on 2017-07-30 (113 days ago) InstallationMedia: Ubuntu-GNOME 17.04 "Zesty Zapus" - Release amd64 (20170412) PackageArchitecture: all SourcePackage: apport UpgradeStatus: Upgraded to artful on 2017-08-22 (90 days ago) ** Affects: apport (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug artful -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apport in Ubuntu. https://bugs.launchpad.net/bugs/1733567 Title: apport fails to send crash reports Status in apport package in Ubuntu: New Bug description: There's an ongoing issue with gnome-shell crashing during or on exit from screen lock. I am no longer able to report when this happens because apport silently refuses to send the bug report. If the automatic whoopsie dialog opens at all (it doesn't, often), and I click to send the report, the window closes, and that's it. If I try to use apport-cli to send a specific .crash file, it shows me the menu, I type S to send the report, and apport-cli exits immediately, and again there's no further action. The crashes may be similar to those posted before, although this being an ongoing and unfixed issue (eg: bug #1723620, bug #1723615), one would expect to be able to send updated bug reports at least to show that, eg: a newer version of the affected packages didn't fix it, or to add a new observation (in this case that despite the crash my login session was not ended by it, which is new). At the very least one would expect to see either the list of possible duplicates, or at very *very* least, a message saying that it's been submitted alreadyk or that my version of the affected package is obsolete (it isn't, although I see apport itself is getting an upgrade, but this problem has already persisted through a few apport upgrades). But there's nothing, no feedback at all, it just exits. I wonder also if what's failed here is the ability to open a new browser window, but if so it affects both google chrome and firefox, when each is set to be the default browser. Also, *this* bug, initiated by typing "ubuntu-bug apport", was submitted just fine, but this bug is not the result of an actual *crash* (ie: resulting in a .crash file). ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: apport 2.20.7-0ubuntu3.4 ProcVersionSignature: Ubuntu 4.13.0-17.20-generic 4.13.8 Uname: Linux 4.13.0-17-generic x86_64
[Touch-packages] [Bug 1720331] [NEW] Whoopsie continually relaunching
Public bug reported: Today for the first time, and coincidentally looking for a different setting, I went to the Settings->Privacy dialogue. I was also (coincidentally for a different reason, relating to #1720149) already tailing /var/log/syslog to a terminal. Immediately on opening that dialogue, the syslog tail flooded with whoopsie continually relaunching, causing enough work to raise the fan speeds. This is a representative section from towards the end of me letting it, before I killed the service, with some necessary viciousness. Specifically systemctl stop whoopsie (didn't stop it) systemctl disable whoopsie (didn't stop it) (find pid for whoopsie's root process and kill it) (that stopped it) Also for good measure ensured the automatic bug reporting option in the privacy settings dialog was set to manual, which I think was done anyway when I disabled whoopsie, though the dialog wasn't on top at the time for me to be sure. It had been set to automatic when I first opened the dialog. Snippet from syslog attached. It was just repeating this continually for several minutes before I stopped it. ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: whoopsie 0.2.58 ProcVersionSignature: Ubuntu 4.13.0-12.13-generic 4.13.3 Uname: Linux 4.13.0-12-generic x86_64 NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia ApportVersion: 2.20.7-0ubuntu1 Architecture: amd64 CrashReports: 664:1000:119:0:2017-09-25 18:16:58.760134901 +0100:2017-09-25 18:16:58.760134901 +0100:/var/crash/_opt_google_chrome_chrome.1000.upload 640:1000:119:102847031:2017-09-27 20:28:45.352315425 +0100:2017-09-28 09:02:32.195212507 +0100:/var/crash/_usr_bin_gnome-shell.1000.crash 640:1000:119:34020328:2017-09-25 18:16:57.656132936 +0100:2017-09-25 18:16:58.760134901 +0100:/var/crash/_opt_google_chrome_chrome.1000.crash 600:111:119:0:2017-09-25 18:16:59.348145502 +0100:2017-09-25 18:16:59.348145502 +0100:/var/crash/_opt_google_chrome_chrome.1000.uploaded CurrentDesktop: GNOME Date: Fri Sep 29 10:00:34 2017 InstallationDate: Installed on 2017-07-30 (60 days ago) InstallationMedia: Ubuntu-GNOME 17.04 "Zesty Zapus" - Release amd64 (20170412) RelatedPackageVersions: apport-noui N/A SourcePackage: whoopsie UpgradeStatus: Upgraded to artful on 2017-08-22 (37 days ago) ** Affects: whoopsie (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug artful autoreport-false ** Attachment added: "syslog-snippet" https://bugs.launchpad.net/bugs/1720331/+attachment/4958534/+files/syslog-snippet -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to whoopsie in Ubuntu. https://bugs.launchpad.net/bugs/1720331 Title: Whoopsie continually relaunching Status in whoopsie package in Ubuntu: New Bug description: Today for the first time, and coincidentally looking for a different setting, I went to the Settings->Privacy dialogue. I was also (coincidentally for a different reason, relating to #1720149) already tailing /var/log/syslog to a terminal. Immediately on opening that dialogue, the syslog tail flooded with whoopsie continually relaunching, causing enough work to raise the fan speeds. This is a representative section from towards the end of me letting it, before I killed the service, with some necessary viciousness. Specifically systemctl stop whoopsie (didn't stop it) systemctl disable whoopsie (didn't stop it) (find pid for whoopsie's root process and kill it) (that stopped it) Also for good measure ensured the automatic bug reporting option in the privacy settings dialog was set to manual, which I think was done anyway when I disabled whoopsie, though the dialog wasn't on top at the time for me to be sure. It had been set to automatic when I first opened the dialog. Snippet from syslog attached. It was just repeating this continually for several minutes before I stopped it. ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: whoopsie 0.2.58 ProcVersionSignature: Ubuntu 4.13.0-12.13-generic 4.13.3 Uname: Linux 4.13.0-12-generic x86_64 NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia ApportVersion: 2.20.7-0ubuntu1 Architecture: amd64 CrashReports: 664:1000:119:0:2017-09-25 18:16:58.760134901 +0100:2017-09-25 18:16:58.760134901 +0100:/var/crash/_opt_google_chrome_chrome.1000.upload 640:1000:119:102847031:2017-09-27 20:28:45.352315425 +0100:2017-09-28 09:02:32.195212507 +0100:/var/crash/_usr_bin_gnome-shell.1000.crash 640:1000:119:34020328:2017-09-25 18:16:57.656132936 +0100:2017-09-25 18:16:58.760134901 +0100:/var/crash/_opt_google_chrome_chrome.1000.crash 600:111:119:0:2017-09-25 18:16:59.348145502 +0100:2017-09-25 18:16:59.348145502 +0100:/var/crash/_opt_google_chrome_chrome.1000.uploaded CurrentDesktop: GNOME Date: Fri Sep 29 10:00:34 2017 InstallationDate: Installed on 2017-07-30 (60 days ago) InstallationMedia:
[Touch-packages] [Bug 1591157] Re: webbrowser-app does not honour scale setting on HiDPI display
confirmed that environment variable set before opening the app works. Whose project do we complain at that QT apps don't (or rather, only inconsistently) follow this setting? (For instance, when I set that in my ~/.profile, a different QT5 app, in which originally *some* of its widgets are scaled correctly, and some tiny, now has those former ones twice as big and the others normal-size.) FWIW I put this in my ~/.profile: QT_DEVICE_PIXEL_RATIO=$(gsettings get org.gnome.desktop.interface scaling-factor | cut -f2 -d' ') export QT_DEVICE_PIXEL_RATIO Obviously not ideal though. And I'm not even sure that's the correct setting, seeing as it's an integer value, and shows an int even when scaling factor in the display prefs is set to a fractional value. But it fixes it for now so I can use webapp-container for TweetDeck, and that's where I came in. ;-) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-ui-toolkit in Ubuntu. https://bugs.launchpad.net/bugs/1591157 Title: webbrowser-app does not honour scale setting on HiDPI display Status in Oxide: Invalid Status in ubuntu-ui-toolkit package in Ubuntu: New Status in webbrowser-app package in Ubuntu: Invalid Bug description: The attached screenshot should say it all, showing it in comparison with Firefox and, indeed, the rest of the Unity desktop. Basically, on a 4K display, with a native resolution of 3840x2160, but with the scaling factor set to 2, and Scale all window contents set on, *most* of the unity desktop these days respects this; it nearly all works. webbrowser-app seems to have no awareness of it at all, and thus its windows show up tiny. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: webbrowser-app 0.23+16.04.20160413-0ubuntu1 ProcVersionSignature: Ubuntu 4.4.0-22.40-generic 4.4.8 Uname: Linux 4.4.0-22-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.1 Architecture: amd64 CurrentDesktop: Unity Date: Fri Jun 10 12:55:30 2016 InstallationDate: Installed on 2016-03-30 (71 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Beta amd64 (20160323) SourcePackage: webbrowser-app UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/oxide/+bug/1591157/+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 1591157] [NEW] webbrowser-app does not honour scale setting on HiDPI display
Public bug reported: The attached screenshot should say it all, showing it in comparison with Firefox and, indeed, the rest of the Unity desktop. Basically, on a 4K display, with a native resolution of 3840x2160, but with the scaling factor set to 2, and Scale all window contents set on, *most* of the unity desktop these days respects this; it nearly all works. webbrowser-app seems to have no awareness of it at all, and thus its windows show up tiny. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: webbrowser-app 0.23+16.04.20160413-0ubuntu1 ProcVersionSignature: Ubuntu 4.4.0-22.40-generic 4.4.8 Uname: Linux 4.4.0-22-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.1 Architecture: amd64 CurrentDesktop: Unity Date: Fri Jun 10 12:55:30 2016 InstallationDate: Installed on 2016-03-30 (71 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Beta amd64 (20160323) SourcePackage: webbrowser-app UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: webbrowser-app (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug xenial ** Attachment added: "Screenshot showing unscaled webbrowser-app alongside scaled everything else." https://bugs.launchpad.net/bugs/1591157/+attachment/4681034/+files/webbrowser.png -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to webbrowser-app in Ubuntu. https://bugs.launchpad.net/bugs/1591157 Title: webbrowser-app does not honour scale setting on HiDPI display Status in webbrowser-app package in Ubuntu: New Bug description: The attached screenshot should say it all, showing it in comparison with Firefox and, indeed, the rest of the Unity desktop. Basically, on a 4K display, with a native resolution of 3840x2160, but with the scaling factor set to 2, and Scale all window contents set on, *most* of the unity desktop these days respects this; it nearly all works. webbrowser-app seems to have no awareness of it at all, and thus its windows show up tiny. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: webbrowser-app 0.23+16.04.20160413-0ubuntu1 ProcVersionSignature: Ubuntu 4.4.0-22.40-generic 4.4.8 Uname: Linux 4.4.0-22-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.1 Architecture: amd64 CurrentDesktop: Unity Date: Fri Jun 10 12:55:30 2016 InstallationDate: Installed on 2016-03-30 (71 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Beta amd64 (20160323) SourcePackage: webbrowser-app UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/webbrowser-app/+bug/1591157/+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
