[Desktop-packages] [Bug 1975660] [NEW] Disabling fprintd.service prevents boot
Public bug reported: Disabling fprintd.service prevents boot. System: Ubuntu Desktop 22.04 Behavior: Rebooting immediately after disabling and masking fprintd.service, fails. A series of [DEPEND] messages scroll past in tty1 early in the boot process, too quickly to read but that appear to be mount units failing for want of a dependency. Consistently, the last message to appear in tty1 is: [ OK ] Reached Target Printer Support Expected behavior: No disruption in boot process from the deletion of an irrelevant service for which no hardware exists. Unfortunately, no further information is available because the machine resists booting. - While booted to a separate partition, I deleted the symlink in /etc/systemd/system to /dev/null, but boot failed thereafter in the same way. - I chrooted into the partition to attempt to re-enable the unit but the command failed by reason of being in a chroot environment. - The partition's syslog has no entries containing DEPEND, probably because they occurred before rsyslog could receive input from the kernel ring buffer. ** Affects: fprintd (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to fprintd in Ubuntu. https://bugs.launchpad.net/bugs/1975660 Title: Disabling fprintd.service prevents boot Status in fprintd package in Ubuntu: New Bug description: Disabling fprintd.service prevents boot. System: Ubuntu Desktop 22.04 Behavior: Rebooting immediately after disabling and masking fprintd.service, fails. A series of [DEPEND] messages scroll past in tty1 early in the boot process, too quickly to read but that appear to be mount units failing for want of a dependency. Consistently, the last message to appear in tty1 is: [ OK ] Reached Target Printer Support Expected behavior: No disruption in boot process from the deletion of an irrelevant service for which no hardware exists. Unfortunately, no further information is available because the machine resists booting. - While booted to a separate partition, I deleted the symlink in /etc/systemd/system to /dev/null, but boot failed thereafter in the same way. - I chrooted into the partition to attempt to re-enable the unit but the command failed by reason of being in a chroot environment. - The partition's syslog has no entries containing DEPEND, probably because they occurred before rsyslog could receive input from the kernel ring buffer. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/fprintd/+bug/1975660/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1970072] Re: Frequent GPU Resets (and GUI Freeze) by gsd-media-keys
Regarding 22.04, please advise what reason exists to think it might be better. Also, please advise why I should spend days reinstalling because of someone else's failure instead of the failure being addressed. Besides, note https://bugs.launchpad.net/subiquity/+bug/1970140. The 22.04 server installer fails. Some idiot thought to implement kernel video drivers in the live iso, and further, to switch to nouveau without disabling kernel mode setting, and further, not to provide any boot alternatives, and further, to provide no documentation (the server reference is for 20.04. One cannot imagine a more sublime or humiliating failure, for all to see. I'll need a reason to take the time even to download the ISO. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-shell in Ubuntu. https://bugs.launchpad.net/bugs/1970072 Title: Frequent GPU Resets (and GUI Freeze) by gsd-media-keys Status in gnome-shell package in Ubuntu: Incomplete Bug description: A fresh install of Ubuntu 20.04.4 has GUI freezes frequently (i.e., a dozen times daily) at inconsistent intervals and times, and not obviously in response to any particular user input. The system then is unresponsive to user input, although the mouse cursor does continue to move about. The syslog messages reveal the message from gsd-media-keys "[GFX1]: Device reset due to WR context" The freeze also is preceded by often hundreds of pulseaudio messages related to latency issues, notwithstanding that no audio is playing. Often, gdm-x-session messages appear referencing the NVIDIA GPU and "WAIT". The pulseaudio message "setting avail_min=87496" often is the last message and if not, one of the last, before the reboot. Also common before is a gnome-shell message "Ignored exception from dbus method: Gio.DBusError: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name com.gonzaarcr.appmenu was not provided by any .service files", which precedes the pulseaudio messages. Happy to provide any other information but would welcome some guidance because I'm on day 11 or 12 of this installation and wearing out my welcome at Google. Ubuntu 20.04.4 LTS apt-cache returns: Installed: 3.36.9-0ubuntu0.20.04.2 Candidate: 3.36.9-0ubuntu0.20.04.2 Version table: *** 3.36.9-0ubuntu0.20.04.2 500 500 http://us.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 100 /var/lib/dpkg/status 3.36.4-1ubuntu1~20.04.2 500 500 http://security.ubuntu.com/ubuntu focal-security/main amd64 Packages 3.36.1-5ubuntu1 500 500 http://us.archive.ubuntu.com/ubuntu focal/main amd64 Packages Expected behavior: Stability, especially from the fourth release of a LTS. Behavior: Persistent GUI freezes ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: gnome-shell 3.36.9-0ubuntu0.20.04.2 ProcVersionSignature: Ubuntu 5.13.0-40.45~20.04.1-generic 5.13.19 Uname: Linux 5.13.0-40-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu27.23 Architecture: amd64 CasperMD5CheckResult: skip Date: Sat Apr 23 16:26:45 2022 DisplayManager: gdm3 GsettingsChanges: InstallationDate: Installed on 2022-04-09 (14 days ago) InstallationMedia: Ubuntu 20.04.3 LTS "Focal Fossa" - Release amd64 (20210819) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash RelatedPackageVersions: mutter-common 3.36.9-0ubuntu0.20.04.2 SourcePackage: gnome-shell UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1970072/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1970072] Re: Frequent GPU Resets (and GUI Freeze) by gsd-media-keys
Trying the attachment again. The interface won't allow designation of more than one. ** Attachment added: "lspci.txt" https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1970072/+attachment/5584043/+files/lspci.txt -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-shell in Ubuntu. https://bugs.launchpad.net/bugs/1970072 Title: Frequent GPU Resets (and GUI Freeze) by gsd-media-keys Status in gnome-shell package in Ubuntu: Incomplete Bug description: A fresh install of Ubuntu 20.04.4 has GUI freezes frequently (i.e., a dozen times daily) at inconsistent intervals and times, and not obviously in response to any particular user input. The system then is unresponsive to user input, although the mouse cursor does continue to move about. The syslog messages reveal the message from gsd-media-keys "[GFX1]: Device reset due to WR context" The freeze also is preceded by often hundreds of pulseaudio messages related to latency issues, notwithstanding that no audio is playing. Often, gdm-x-session messages appear referencing the NVIDIA GPU and "WAIT". The pulseaudio message "setting avail_min=87496" often is the last message and if not, one of the last, before the reboot. Also common before is a gnome-shell message "Ignored exception from dbus method: Gio.DBusError: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name com.gonzaarcr.appmenu was not provided by any .service files", which precedes the pulseaudio messages. Happy to provide any other information but would welcome some guidance because I'm on day 11 or 12 of this installation and wearing out my welcome at Google. Ubuntu 20.04.4 LTS apt-cache returns: Installed: 3.36.9-0ubuntu0.20.04.2 Candidate: 3.36.9-0ubuntu0.20.04.2 Version table: *** 3.36.9-0ubuntu0.20.04.2 500 500 http://us.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 100 /var/lib/dpkg/status 3.36.4-1ubuntu1~20.04.2 500 500 http://security.ubuntu.com/ubuntu focal-security/main amd64 Packages 3.36.1-5ubuntu1 500 500 http://us.archive.ubuntu.com/ubuntu focal/main amd64 Packages Expected behavior: Stability, especially from the fourth release of a LTS. Behavior: Persistent GUI freezes ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: gnome-shell 3.36.9-0ubuntu0.20.04.2 ProcVersionSignature: Ubuntu 5.13.0-40.45~20.04.1-generic 5.13.19 Uname: Linux 5.13.0-40-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu27.23 Architecture: amd64 CasperMD5CheckResult: skip Date: Sat Apr 23 16:26:45 2022 DisplayManager: gdm3 GsettingsChanges: InstallationDate: Installed on 2022-04-09 (14 days ago) InstallationMedia: Ubuntu 20.04.3 LTS "Focal Fossa" - Release amd64 (20210819) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash RelatedPackageVersions: mutter-common 3.36.9-0ubuntu0.20.04.2 SourcePackage: gnome-shell UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1970072/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1970072] Re: Frequent GPU Resets (and GUI Freeze) by gsd-media-keys
Regarding the file request, please see attached. ** Attachment added: "prevboot.txt" https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1970072/+attachment/5584042/+files/prevboot.txt -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-shell in Ubuntu. https://bugs.launchpad.net/bugs/1970072 Title: Frequent GPU Resets (and GUI Freeze) by gsd-media-keys Status in gnome-shell package in Ubuntu: Incomplete Bug description: A fresh install of Ubuntu 20.04.4 has GUI freezes frequently (i.e., a dozen times daily) at inconsistent intervals and times, and not obviously in response to any particular user input. The system then is unresponsive to user input, although the mouse cursor does continue to move about. The syslog messages reveal the message from gsd-media-keys "[GFX1]: Device reset due to WR context" The freeze also is preceded by often hundreds of pulseaudio messages related to latency issues, notwithstanding that no audio is playing. Often, gdm-x-session messages appear referencing the NVIDIA GPU and "WAIT". The pulseaudio message "setting avail_min=87496" often is the last message and if not, one of the last, before the reboot. Also common before is a gnome-shell message "Ignored exception from dbus method: Gio.DBusError: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name com.gonzaarcr.appmenu was not provided by any .service files", which precedes the pulseaudio messages. Happy to provide any other information but would welcome some guidance because I'm on day 11 or 12 of this installation and wearing out my welcome at Google. Ubuntu 20.04.4 LTS apt-cache returns: Installed: 3.36.9-0ubuntu0.20.04.2 Candidate: 3.36.9-0ubuntu0.20.04.2 Version table: *** 3.36.9-0ubuntu0.20.04.2 500 500 http://us.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 100 /var/lib/dpkg/status 3.36.4-1ubuntu1~20.04.2 500 500 http://security.ubuntu.com/ubuntu focal-security/main amd64 Packages 3.36.1-5ubuntu1 500 500 http://us.archive.ubuntu.com/ubuntu focal/main amd64 Packages Expected behavior: Stability, especially from the fourth release of a LTS. Behavior: Persistent GUI freezes ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: gnome-shell 3.36.9-0ubuntu0.20.04.2 ProcVersionSignature: Ubuntu 5.13.0-40.45~20.04.1-generic 5.13.19 Uname: Linux 5.13.0-40-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu27.23 Architecture: amd64 CasperMD5CheckResult: skip Date: Sat Apr 23 16:26:45 2022 DisplayManager: gdm3 GsettingsChanges: InstallationDate: Installed on 2022-04-09 (14 days ago) InstallationMedia: Ubuntu 20.04.3 LTS "Focal Fossa" - Release amd64 (20210819) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash RelatedPackageVersions: mutter-common 3.36.9-0ubuntu0.20.04.2 SourcePackage: gnome-shell UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1970072/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1969782] Re: action-middle-click-titlebar 'toggle-maximize-vertically' instead does 'toggle-maximize'
Except that I'm experiencing the issue with X, not Wayland. Also, Ubuntu 20.04, not Fedora ** This bug is no longer a duplicate of bug 1698083 Maximize vertically/horizontally doesn't work (in some apps) if configured via middle-click -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-shell in Ubuntu. https://bugs.launchpad.net/bugs/1969782 Title: action-middle-click-titlebar 'toggle-maximize-vertically' instead does 'toggle-maximize' Status in gnome-shell package in Ubuntu: New Bug description: Simply, configuring the middle mouse button in dconf-editor to maximize a window vertically when its title bar is middle-clicked, causes the window instead to maximize fully. In dconf-editor, the setting is /org/gnome/desktop/wm/preferences/action-middle-click-titlebar. The misbehaving setting is 'toggle-maximize-vertically'. The 'toggle-maximize' setting works correctly. Ubuntu 20.04.4 gnome-shell 3.36.9-0ubuntu0.20.04.2 Expected behavior: Configuring the middle mouse button to maximize vertically would cause the window to maximize vertically. Behavior: Configuring the middle mouse button to maximize vertically instead causes the window to maximize fully, i.e., both vertically and horizontally. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: gnome-shell 3.36.9-0ubuntu0.20.04.2 ProcVersionSignature: Ubuntu 5.13.0-40.45~20.04.1-generic 5.13.19 Uname: Linux 5.13.0-40-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu27.23 Architecture: amd64 CasperMD5CheckResult: skip Date: Thu Apr 21 06:50:07 2022 DisplayManager: gdm3 GsettingsChanges: InstallationDate: Installed on 2022-04-09 (12 days ago) InstallationMedia: Ubuntu 20.04.3 LTS "Focal Fossa" - Release amd64 (20210819) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash RelatedPackageVersions: mutter-common 3.36.9-0ubuntu0.20.04.2 SourcePackage: gnome-shell UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1969782/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1969782] Re: action-middle-click-titlebar 'toggle-maximize-vertically' instead does 'toggle-maximize'
This actually is not a duplicate bug because I have successfully mapped ctrl-alt-v to maximize the active window. This bug concerns the gsettings configuration of the middle mouse button. Specifically, that the selected option behaves as another. FYI, this arose because the interface no longer maximizes vertically when the top edge of a window is dragged to the top of the screen. ** This bug is no longer a duplicate of bug 1698083 Maximize vertically/horizontally doesn't work (in some apps) -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-shell in Ubuntu. https://bugs.launchpad.net/bugs/1969782 Title: action-middle-click-titlebar 'toggle-maximize-vertically' instead does 'toggle-maximize' Status in gnome-shell package in Ubuntu: New Bug description: Simply, configuring the middle mouse button in dconf-editor to maximize a window vertically when its title bar is middle-clicked, causes the window instead to maximize fully. In dconf-editor, the setting is /org/gnome/desktop/wm/preferences/action-middle-click-titlebar. The misbehaving setting is 'toggle-maximize-vertically'. The 'toggle-maximize' setting works correctly. Ubuntu 20.04.4 gnome-shell 3.36.9-0ubuntu0.20.04.2 Expected behavior: Configuring the middle mouse button to maximize vertically would cause the window to maximize vertically. Behavior: Configuring the middle mouse button to maximize vertically instead causes the window to maximize fully, i.e., both vertically and horizontally. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: gnome-shell 3.36.9-0ubuntu0.20.04.2 ProcVersionSignature: Ubuntu 5.13.0-40.45~20.04.1-generic 5.13.19 Uname: Linux 5.13.0-40-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu27.23 Architecture: amd64 CasperMD5CheckResult: skip Date: Thu Apr 21 06:50:07 2022 DisplayManager: gdm3 GsettingsChanges: InstallationDate: Installed on 2022-04-09 (12 days ago) InstallationMedia: Ubuntu 20.04.3 LTS "Focal Fossa" - Release amd64 (20210819) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash RelatedPackageVersions: mutter-common 3.36.9-0ubuntu0.20.04.2 SourcePackage: gnome-shell UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1969782/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1970078] [NEW] pulseaudio loops through configuration, logging tens of thousands of messages
Public bug reported: While no audio at all is playing, pulseaudio loops through its configuration and also loops through complaints about latency, generating tens of thousands of messages per hour, writing constantly to disk and bringing system performance to a crawl, culminating in a GUI freeze. Something, either the nvidia driver, gnome-shell/gnome-session, or xorg, is preventing pulseaudio from connecting to the default audio device because it often fails with a SIGFPE. Ubuntu Desktop 20.04.4 pulseaudio 1:13.99.1-1ubuntu3.13 Expected behavior: stability Behavior: 6-10 GUI freezes daily at random times and intervals. Happy to answer any questions but I don't know where to start. I'm on day 12 of an involuntary reinstall of 20.04 by reason of catastrophic hardware failure and have exhausted all avenues. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: pulseaudio 1:13.99.1-1ubuntu3.13 ProcVersionSignature: Ubuntu 5.13.0-40.45~20.04.1-generic 5.13.19 Uname: Linux 5.13.0-40-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu27.23 Architecture: amd64 CasperMD5CheckResult: skip Date: Sat Apr 23 21:52:07 2022 InstallationDate: Installed on 2022-04-09 (14 days ago) InstallationMedia: Ubuntu 20.04.3 LTS "Focal Fossa" - Release amd64 (20210819) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon. SourcePackage: pulseaudio UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 05/08/2015 dmi.bios.release: 4.6 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 1704 dmi.board.asset.tag: To be filled by O.E.M. dmi.board.name: P9X79-E WS dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: Rev 1.xx dmi.chassis.asset.tag: Asset-1234567890 dmi.chassis.type: 3 dmi.chassis.vendor: Chassis Manufacture dmi.chassis.version: Chassis Version dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr1704:bd05/08/2015:br4.6:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnP9X79-EWS:rvrRev1.xx:cvnChassisManufacture:ct3:cvrChassisVersion:skuSKU: dmi.product.family: To be filled by O.E.M. dmi.product.name: System Product Name dmi.product.sku: SKU dmi.product.version: System Version dmi.sys.vendor: System manufacturer modified.conffile..etc.pulse.daemon.conf: [modified] mtime.conffile..etc.pulse.daemon.conf: 2022-04-21T10:29:58.184759 ** Affects: pulseaudio (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug focal -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1970078 Title: pulseaudio loops through configuration, logging tens of thousands of messages Status in pulseaudio package in Ubuntu: New Bug description: While no audio at all is playing, pulseaudio loops through its configuration and also loops through complaints about latency, generating tens of thousands of messages per hour, writing constantly to disk and bringing system performance to a crawl, culminating in a GUI freeze. Something, either the nvidia driver, gnome-shell/gnome-session, or xorg, is preventing pulseaudio from connecting to the default audio device because it often fails with a SIGFPE. Ubuntu Desktop 20.04.4 pulseaudio 1:13.99.1-1ubuntu3.13 Expected behavior: stability Behavior: 6-10 GUI freezes daily at random times and intervals. Happy to answer any questions but I don't know where to start. I'm on day 12 of an involuntary reinstall of 20.04 by reason of catastrophic hardware failure and have exhausted all avenues. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: pulseaudio 1:13.99.1-1ubuntu3.13 ProcVersionSignature: Ubuntu 5.13.0-40.45~20.04.1-generic 5.13.19 Uname: Linux 5.13.0-40-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu27.23 Architecture: amd64 CasperMD5CheckResult: skip Date: Sat Apr 23 21:52:07 2022 InstallationDate: Installed on 2022-04-09 (14 days ago) InstallationMedia: Ubuntu 20.04.3 LTS "Focal Fossa" - Release amd64 (20210819) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon. SourcePackage: pulseaudio UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 05/08/2015 dmi.bios.release: 4.6 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 1704 dmi.board.asset.tag: To be filled by O.E.M. dmi.board.name: P9X79-E WS dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: Rev 1.xx dmi.chassis.asset.tag: Asset-1234567890 dmi.chassis.type: 3
[Desktop-packages] [Bug 1919071] Re: Gsd media keys crashed SIGSEGV
I have a very similar issue. See https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1970072 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-settings-daemon in Ubuntu. https://bugs.launchpad.net/bugs/1919071 Title: Gsd media keys crashed SIGSEGV Status in gnome-settings-daemon package in Ubuntu: Confirmed Bug description: Hi there Extremely new user and a newly built pc. I’ve experienced some crashes / system locks and am hoping for some tips and thoughts to help me out. The error message I received last night is as follows: Executable gsd-media-keys Package gnome settings daemon 3.36.q Title gsd media keys crashed with SIGSEGV in tcache get() I’m on app version 2.20.11-0ubuntu27.16 On AMD with integrated graphics I wondered if it was to do with the usb wireless HP keyboard? However this morning I had Firefox crash. I am currently using WiFi via my ASUS B450 onboard WiFi which again I wondered might be the cause? Appreciate some help. I’m a little experienced with hardware and PCs albeit very, very new to Ubuntu and Linux! Appreciated To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1919071/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1970072] [NEW] Frequent GPU Resets (and GUI Freeze) by gsd-media-keys
Public bug reported: A fresh install of Ubuntu 20.04.4 has GUI freezes frequently (i.e., a dozen times daily) at inconsistent intervals and times, and not obviously in response to any particular user input. The system then is unresponsive to user input, although the mouse cursor does continue to move about. The syslog messages reveal the message from gsd-media-keys "[GFX1]: Device reset due to WR context" The freeze also is preceded by often hundreds of pulseaudio messages related to latency issues, notwithstanding that no audio is playing. Often, gdm-x-session messages appear referencing the NVIDIA GPU and "WAIT". The pulseaudio message "setting avail_min=87496" often is the last message and if not, one of the last, before the reboot. Also common before is a gnome-shell message "Ignored exception from dbus method: Gio.DBusError: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name com.gonzaarcr.appmenu was not provided by any .service files", which precedes the pulseaudio messages. Happy to provide any other information but would welcome some guidance because I'm on day 11 or 12 of this installation and wearing out my welcome at Google. Ubuntu 20.04.4 LTS apt-cache returns: Installed: 3.36.9-0ubuntu0.20.04.2 Candidate: 3.36.9-0ubuntu0.20.04.2 Version table: *** 3.36.9-0ubuntu0.20.04.2 500 500 http://us.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 100 /var/lib/dpkg/status 3.36.4-1ubuntu1~20.04.2 500 500 http://security.ubuntu.com/ubuntu focal-security/main amd64 Packages 3.36.1-5ubuntu1 500 500 http://us.archive.ubuntu.com/ubuntu focal/main amd64 Packages Expected behavior: Stability, especially from the fourth release of a LTS. Behavior: Persistent GUI freezes ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: gnome-shell 3.36.9-0ubuntu0.20.04.2 ProcVersionSignature: Ubuntu 5.13.0-40.45~20.04.1-generic 5.13.19 Uname: Linux 5.13.0-40-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu27.23 Architecture: amd64 CasperMD5CheckResult: skip Date: Sat Apr 23 16:26:45 2022 DisplayManager: gdm3 GsettingsChanges: InstallationDate: Installed on 2022-04-09 (14 days ago) InstallationMedia: Ubuntu 20.04.3 LTS "Focal Fossa" - Release amd64 (20210819) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash RelatedPackageVersions: mutter-common 3.36.9-0ubuntu0.20.04.2 SourcePackage: gnome-shell UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: gnome-shell (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug focal -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-shell in Ubuntu. https://bugs.launchpad.net/bugs/1970072 Title: Frequent GPU Resets (and GUI Freeze) by gsd-media-keys Status in gnome-shell package in Ubuntu: New Bug description: A fresh install of Ubuntu 20.04.4 has GUI freezes frequently (i.e., a dozen times daily) at inconsistent intervals and times, and not obviously in response to any particular user input. The system then is unresponsive to user input, although the mouse cursor does continue to move about. The syslog messages reveal the message from gsd-media-keys "[GFX1]: Device reset due to WR context" The freeze also is preceded by often hundreds of pulseaudio messages related to latency issues, notwithstanding that no audio is playing. Often, gdm-x-session messages appear referencing the NVIDIA GPU and "WAIT". The pulseaudio message "setting avail_min=87496" often is the last message and if not, one of the last, before the reboot. Also common before is a gnome-shell message "Ignored exception from dbus method: Gio.DBusError: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name com.gonzaarcr.appmenu was not provided by any .service files", which precedes the pulseaudio messages. Happy to provide any other information but would welcome some guidance because I'm on day 11 or 12 of this installation and wearing out my welcome at Google. Ubuntu 20.04.4 LTS apt-cache returns: Installed: 3.36.9-0ubuntu0.20.04.2 Candidate: 3.36.9-0ubuntu0.20.04.2 Version table: *** 3.36.9-0ubuntu0.20.04.2 500 500 http://us.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 100 /var/lib/dpkg/status 3.36.4-1ubuntu1~20.04.2 500 500 http://security.ubuntu.com/ubuntu focal-security/main amd64 Packages 3.36.1-5ubuntu1 500 500 http://us.archive.ubuntu.com/ubuntu focal/main amd64 Packages Expected behavior: Stability, especially from the fourth release of a LTS. Behavior: Persistent GUI freezes ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: gnome-shell 3.36.9-0ubuntu0.20.04.2 ProcVersionSignature: Ubuntu 5.13.0-40.45~20.04.1-generic 5.13.19 Uname: Linux 5.13.0-40-generic
[Desktop-packages] [Bug 1969782] [NEW] action-middle-click-titlebar 'toggle-maximize-vertically' instead does 'toggle-maximize'
Public bug reported: Simply, configuring the middle mouse button in dconf-editor to maximize a window vertically when its title bar is middle-clicked, causes the window instead to maximize fully. In dconf-editor, the setting is /org/gnome/desktop/wm/preferences/action-middle-click-titlebar. The misbehaving setting is 'toggle-maximize-vertically'. The 'toggle-maximize' setting works correctly. Ubuntu 20.04.4 gnome-shell 3.36.9-0ubuntu0.20.04.2 Expected behavior: Configuring the middle mouse button to maximize vertically would cause the window to maximize vertically. Behavior: Configuring the middle mouse button to maximize vertically instead causes the window to maximize fully, i.e., both vertically and horizontally. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: gnome-shell 3.36.9-0ubuntu0.20.04.2 ProcVersionSignature: Ubuntu 5.13.0-40.45~20.04.1-generic 5.13.19 Uname: Linux 5.13.0-40-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu27.23 Architecture: amd64 CasperMD5CheckResult: skip Date: Thu Apr 21 06:50:07 2022 DisplayManager: gdm3 GsettingsChanges: InstallationDate: Installed on 2022-04-09 (12 days ago) InstallationMedia: Ubuntu 20.04.3 LTS "Focal Fossa" - Release amd64 (20210819) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash RelatedPackageVersions: mutter-common 3.36.9-0ubuntu0.20.04.2 SourcePackage: gnome-shell UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: gnome-shell (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug focal -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-shell in Ubuntu. https://bugs.launchpad.net/bugs/1969782 Title: action-middle-click-titlebar 'toggle-maximize-vertically' instead does 'toggle-maximize' Status in gnome-shell package in Ubuntu: New Bug description: Simply, configuring the middle mouse button in dconf-editor to maximize a window vertically when its title bar is middle-clicked, causes the window instead to maximize fully. In dconf-editor, the setting is /org/gnome/desktop/wm/preferences/action-middle-click-titlebar. The misbehaving setting is 'toggle-maximize-vertically'. The 'toggle-maximize' setting works correctly. Ubuntu 20.04.4 gnome-shell 3.36.9-0ubuntu0.20.04.2 Expected behavior: Configuring the middle mouse button to maximize vertically would cause the window to maximize vertically. Behavior: Configuring the middle mouse button to maximize vertically instead causes the window to maximize fully, i.e., both vertically and horizontally. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: gnome-shell 3.36.9-0ubuntu0.20.04.2 ProcVersionSignature: Ubuntu 5.13.0-40.45~20.04.1-generic 5.13.19 Uname: Linux 5.13.0-40-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu27.23 Architecture: amd64 CasperMD5CheckResult: skip Date: Thu Apr 21 06:50:07 2022 DisplayManager: gdm3 GsettingsChanges: InstallationDate: Installed on 2022-04-09 (12 days ago) InstallationMedia: Ubuntu 20.04.3 LTS "Focal Fossa" - Release amd64 (20210819) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash RelatedPackageVersions: mutter-common 3.36.9-0ubuntu0.20.04.2 SourcePackage: gnome-shell UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1969782/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1960601] Re: Ubuntu 20.04 stopped detecting HP LaserJet P2055dn after this morning's update
@till-kamppeter, I'm not certain what you mean by the "upstream source." The printer auto-installed when I installed Ubuntu 20.04 shortly after its release. After your post, I did: # apt purge cups cups-client cups-bsd # apt purge hplip hpijs printer-driver-gutenprint # apt autoremove # reboot # apt install cups cups-client cups-bsd # apt install printer-driver-gutenprint printer-driver-hpcups printer-driver-hpijs printer-driver-postscript-hp # reboot # journalctl -b 0 and got >2000 consecutive entries reading: AVC apparmor="DENIED" operation="create" profile="snap.hplip-printer- app.hplip-printer-app-server" pid=2211 comm="hplip-printer-a" family="inet" sock_type="stream" protocol=0 requested_mask="create" denied_mask="create" AppArmor is not expressly configured (meaning no one here manually configured it) on this system. I'd guess this is what's at work but don't know. Please advise. Otherwise, regarding snap, I don't code around others' steaming piles. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1960601 Title: Ubuntu 20.04 stopped detecting HP LaserJet P2055dn after this morning's update Status in cups package in Ubuntu: New Bug description: I printed yesterday. I updated Ubuntu 20.04.3 this morning. The system now does not detect the HP LaserJet P2055dn to which it has been connected for years. The output of the command "apt-cache policy cups" is: cups: Installed: 2.3.1-9ubuntu1.1 Candidate: 2.3.1-9ubuntu1.1 Version table: *** 2.3.1-9ubuntu1.1 500 500 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 500 http://archive.ubuntu.com/ubuntu focal-security/main amd64 Packages 100 /var/lib/dpkg/status 2.3.1-9ubuntu1 500 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages What I expected to happen was to print a document. Then, for the system to recognize the printer when I tried to reinstall it. What happened instead was that printing failed. Settings > Printers > Additional Printer Settings vomited an error message saying that the printer may not be connected. The print job hung on "Processing" for 5-10 minutes before I terminated it. I deleted the printer on the system and the system would / could not detect the device. No obvious means exists to install a printer driver for a specified printer, which is an astonishing design failure for the platform. I have rebooted the system and the printer multiple times throughout this process. I also attempted to update the system but no updates are available. All the wiring and power is as before. The system recognizes any number of other USB devices connected to it, including scanners, etc., that are freshly powered on. Power cycling the HP printer has no effect on lsusb output. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: cups 2.3.1-9ubuntu1.1 ProcVersionSignature: Ubuntu 5.4.0-99.112-generic 5.4.162 Uname: Linux 5.4.0-99-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu27.21 Architecture: amd64 CasperMD5CheckResult: pass CupsErrorLog: E [11/Feb/2022:00:00:13 -0800] Unable to open listen socket for address [v1.::1]:631 - Address family not supported by protocol. E [11/Feb/2022:00:10:42 -0800] [Client 27] Returning HTTP Forbidden for CUPS-Add-Modify-Printer (ipp://localhost/printers/HP-LaserJet-P2055dn) from localhost E [11/Feb/2022:00:17:48 -0800] [Client 1329757] Returning IPP client-error-document-format-not-supported for Print-Job (ipp://localhost:631/printers/CUPS-BRF-Printer) from localhost. CurrentDesktop: ubuntu:GNOME CurrentDmesg: Error: command ['dmesg'] failed with exit code 1: dmesg: read kernel buffer failed: Operation not permitted Date: Fri Feb 11 00:44:52 2022 InstallationDate: Installed on 2020-08-20 (539 days ago) InstallationMedia: Ubuntu-Server 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731) KernLog: Lpstat: device for CUPS-BRF-Printer: cups-brf:/ MachineType: System manufacturer System Product Name Papersize: letter PpdFiles: Error: command ['fgrep', '-H', '*NickName', '/etc/cups/ppd/CUPS-BRF-Printer.ppd'] failed with exit code 2: grep: /etc/cups/ppd/CUPS-BRF-Printer.ppd: Permission denied ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-99-generic root=UUID=94757e46-a814-4c27-b3a5-4ff139bd211d ro ipv6.disable=1 nomodeset ipv6.disable=1 SourcePackage: cups UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 02/19/2014 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 1602 dmi.board.asset.tag: To be filled by O.E.M. dmi.board.name: P9X79-E WS dmi.board.vendor: ASUSTeK
[Desktop-packages] [Bug 1960601] [NEW] Ubuntu 20.04 stopped detecting HP LaserJet P2055dn after this morning's update
Public bug reported: I printed yesterday. I updated Ubuntu 20.04.3 this morning. The system now does not detect the HP LaserJet P2055dn to which it has been connected for years. The output of the command "apt-cache policy cups" is: cups: Installed: 2.3.1-9ubuntu1.1 Candidate: 2.3.1-9ubuntu1.1 Version table: *** 2.3.1-9ubuntu1.1 500 500 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 500 http://archive.ubuntu.com/ubuntu focal-security/main amd64 Packages 100 /var/lib/dpkg/status 2.3.1-9ubuntu1 500 500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages What I expected to happen was to print a document. Then, for the system to recognize the printer when I tried to reinstall it. What happened instead was that printing failed. Settings > Printers > Additional Printer Settings vomited an error message saying that the printer may not be connected. The print job hung on "Processing" for 5-10 minutes before I terminated it. I deleted the printer on the system and the system would / could not detect the device. No obvious means exists to install a printer driver for a specified printer, which is an astonishing design failure for the platform. I have rebooted the system and the printer multiple times throughout this process. I also attempted to update the system but no updates are available. All the wiring and power is as before. The system recognizes any number of other USB devices connected to it, including scanners, etc., that are freshly powered on. Power cycling the HP printer has no effect on lsusb output. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: cups 2.3.1-9ubuntu1.1 ProcVersionSignature: Ubuntu 5.4.0-99.112-generic 5.4.162 Uname: Linux 5.4.0-99-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu27.21 Architecture: amd64 CasperMD5CheckResult: pass CupsErrorLog: E [11/Feb/2022:00:00:13 -0800] Unable to open listen socket for address [v1.::1]:631 - Address family not supported by protocol. E [11/Feb/2022:00:10:42 -0800] [Client 27] Returning HTTP Forbidden for CUPS-Add-Modify-Printer (ipp://localhost/printers/HP-LaserJet-P2055dn) from localhost E [11/Feb/2022:00:17:48 -0800] [Client 1329757] Returning IPP client-error-document-format-not-supported for Print-Job (ipp://localhost:631/printers/CUPS-BRF-Printer) from localhost. CurrentDesktop: ubuntu:GNOME CurrentDmesg: Error: command ['dmesg'] failed with exit code 1: dmesg: read kernel buffer failed: Operation not permitted Date: Fri Feb 11 00:44:52 2022 InstallationDate: Installed on 2020-08-20 (539 days ago) InstallationMedia: Ubuntu-Server 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731) KernLog: Lpstat: device for CUPS-BRF-Printer: cups-brf:/ MachineType: System manufacturer System Product Name Papersize: letter PpdFiles: Error: command ['fgrep', '-H', '*NickName', '/etc/cups/ppd/CUPS-BRF-Printer.ppd'] failed with exit code 2: grep: /etc/cups/ppd/CUPS-BRF-Printer.ppd: Permission denied ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-99-generic root=UUID=94757e46-a814-4c27-b3a5-4ff139bd211d ro ipv6.disable=1 nomodeset ipv6.disable=1 SourcePackage: cups UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 02/19/2014 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 1602 dmi.board.asset.tag: To be filled by O.E.M. dmi.board.name: P9X79-E WS dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: Rev 1.xx dmi.chassis.asset.tag: Asset-1234567890 dmi.chassis.type: 3 dmi.chassis.vendor: Chassis Manufacture dmi.chassis.version: Chassis Version dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr1602:bd02/19/2014:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnP9X79-EWS:rvrRev1.xx:cvnChassisManufacture:ct3:cvrChassisVersion: dmi.product.family: To be filled by O.E.M. dmi.product.name: System Product Name dmi.product.sku: SKU dmi.product.version: System Version dmi.sys.vendor: System manufacturer ** Affects: cups (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug focal third-party-packages uec-images -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1960601 Title: Ubuntu 20.04 stopped detecting HP LaserJet P2055dn after this morning's update Status in cups package in Ubuntu: New Bug description: I printed yesterday. I updated Ubuntu 20.04.3 this morning. The system now does not detect the HP LaserJet P2055dn to which it has been connected for years. The output of the command "apt-cache policy cups" is: cups: Installed: 2.3.1-9ubuntu1.1 Candidate: 2.3.1-9ubuntu1.1 Version table: *** 2.3.1-9ubuntu1.1 500 500 http://archive.ubuntu.com/ubuntu
[Desktop-packages] [Bug 1892973] Re: [nvidia] Repeated screen freezes with GeForce GT 640 (GK107)
Try nvidia-graphics-driver-390. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-shell in Ubuntu. https://bugs.launchpad.net/bugs/1892973 Title: [nvidia] Repeated screen freezes with GeForce GT 640 (GK107) Status in gnome-shell package in Ubuntu: Invalid Status in nvidia-graphics-drivers-440 package in Ubuntu: Confirmed Status in nvidia-graphics-drivers-450 package in Ubuntu: Confirmed Bug description: Ubuntu 20.04.01, gnome-shell 3.36.4, nvidia-driver-450, nvidia- driver-440. Both drivers expressly support the hardware. All varieties of desktop environment (Xorg, Gnome Classic, Ubuntu) Bug summary Screen hangs randomly and iretrievably with the only possibility of recovery being a a hard system reset. Sometimes this is triggered by activity (launching or using gnome-settings; resizing a window; using Nautilus), sometimes, not. No session lasts more than five minutes. No combination of keystrokes will yield a terminal of any kind. The hang also interrupts System Monitor output, so no information regarding use of system resources is available. Steps to reproduce 1. Install gnome-session. 2. Reboot. 3. Use graphical applications. What happened] The screen froze irretrievably. Screen hangs randomly and iretrievably with the only possibility of recovery being a a hard system reset. Sometimes this is triggered by activity (launching or using gnome-settings; resizing a window; using Nautilus), sometimes, not. No session lasts more than five minutes. No combination of keystrokes will yield a terminal of any kind. The hang also interrupts System Monitor output, so no information regarding use of system resources is available. A hard system reset and consequent reboot yields a variety of outcomes. Sometimes, a normal gdm login. Sometimes, a black screen with an inverted-black mouse cursor/pointer/arrow that moves. Sometimes an entirely black screen. Sometimes, not even a hard system reset is sufficient and the system has to be booted into recovery mode, the existing driver removed, and another installed, before rebooting again. With nvidia-driver-440, fewer hangs but the monitor resolution can't be set to its capacity. I don't get it. GNOME hangs have been extensively documented for ten years. The drivers expressly support the hardware. This package is part of an Ubuntu LTS release. Is gnome-session intended to be serious, functional, production software subjected to rigorous and competent quality control? This is a serious question because I have a business to run and can't be sucked down some random technical rabbit hole just to do daily work. Is GNOME just a cute code project intended as a resume line for people looking for real work? What kind of quality control processes are in place that allow ancient failures, extensively reported, to persist? Is anyone at GNOME able and willing to put on their big-boy pants to get a reliable package suitable for production deployments, released? The command cat /var/log/syslog | grep gnome-session reveals fundamental errors in implementing systemd syntax and references/calls to nonexistent binaries. See the gnome-sesion units in /usr/lib/systemd/user. Maybe getting this right would be a first step to helping the developers understand the environment better. Please see man systemd. Source is, astonishingly, a hybrid of C and Javascript, which doubtless presents a QC nightmare. Has anyone given this any thought? What does it take to get this package to work today? - What is the procedure? What commands must be run? - Why doesn't GNOME simply include these commands in a script, just to make it easier? Does anyone there know how? - Why doesn't GNOME simply compile these commands into the package so it works in the first place? - Will a different graphics card matter? - Which one? - Why, if the drivers support the existing hardware, according to the documentation if not the function? Can this package be made to work today? If not, will this package be ready for production use in the next Ubuntu release (i.e., 20.04.02)? If not, what alternatives exist for production use? These are all serious questions. It is astonishing that this package has been released to the public. It getting out the door poses an existential reputational threat to the GNOME project. Any help in getting this package to work would be most gratefully appreciated. What did you expect to happen I expected the screen not to freeze. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1892973/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help :
[Desktop-packages] [Bug 1892973] Re: gnome-session fails, and fails, and fails yet again
Some additional information: When the boot sequence is - GRUB boot to recovery mode - Drop to root prompt - Remove a driver and install a driver - Exit root prompt (Ctrl-D) - Resume normal boot as per the recovery mode menu Then the display comes up at a degraded resolution (1024x768) but no gnome-session hang occurs in response to some of the reliable triggers (typically, attempting to launch Firefox, Google Chrome, or navigate gnome-settings). Booting normally (via restart or hard-reset) brings up the display at maximum resolution and gnome-session hangs immediately on one of the reliable triggers. I noted this previously. To test whether resolution is the issue, I booted normally. gnome-settings hangs gnome-session, so instead, I ran ```xrandr -s 1024x768``` which was immediately effective. I then accessed gnome-settings and it triggered another gnome-session hang. The conclusion is that degraded screen resolution itself does not prevent gnome-session hangs. Reviewing /var/log/syslog and the systemd journal, as well as /var/log/Xorg.0.log reveals that gdm3 recognizes the monitor by manufacturer and model and correctly picks up its configuration capabilities when the system boots normally. This does not occur, however, when one boots first to recovery mode, changes drivers, and resumes normal boot. To test whether a recovery mode session alone prevented a gnome-session hang, I then booted to recovery mode, did NOT change drivers, then resumed normal boot. Interestingly, the display came up in high resolution notwithstanding the prior xrandr reconfiguration. /var/log/Xorg.0.log reflected that gdm3 did identify the monitor. And, most importantly, the reliable triggers immediately caused a gnome- session hang. The conclusion, then, is that a recovery mode session alone does not prevent a gnome-session hang. One must change the driver during that recovery mode session, to prevent it (albeit at the cost of degraded screen resolution). To test whether simply removing and installing the same driver during a recovery mode session would be sufficient to avoid a gnome-session hang, I experimented with that. On resuming normal boot, the screen came up at full resolution and the usual triggers produced a gnome-session hang. The conclusion, then, is that a change of drivers is necessary during a recovery mode session to prevent a gnome-session hang after resuming normal boot from recovery mode. Again, this is at the cost of degraded screen resolution, and the protection will not persist through a normal boot. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-shell in Ubuntu. https://bugs.launchpad.net/bugs/1892973 Title: gnome-session fails, and fails, and fails yet again Status in gnome-shell package in Ubuntu: Incomplete Bug description: Ubuntu 20.04.01, gnome-shell 3.36.4, nvidia-driver-450, nvidia- driver-440. Both drivers expressly support the hardware. All varieties of desktop environment (Xorg, Gnome Classic, Ubuntu) Bug summary Screen hangs randomly and iretrievably with the only possibility of recovery being a a hard system reset. Sometimes this is triggered by activity (launching or using gnome-settings; resizing a window; using Nautilus), sometimes, not. No session lasts more than five minutes. No combination of keystrokes will yield a terminal of any kind. The hang also interrupts System Monitor output, so no information regarding use of system resources is available. Steps to reproduce 1. Install gnome-session. 2. Reboot. 3. Use graphical applications. What happened] The screen froze irretrievably. Screen hangs randomly and iretrievably with the only possibility of recovery being a a hard system reset. Sometimes this is triggered by activity (launching or using gnome-settings; resizing a window; using Nautilus), sometimes, not. No session lasts more than five minutes. No combination of keystrokes will yield a terminal of any kind. The hang also interrupts System Monitor output, so no information regarding use of system resources is available. A hard system reset and consequent reboot yields a variety of outcomes. Sometimes, a normal gdm login. Sometimes, a black screen with an inverted-black mouse cursor/pointer/arrow that moves. Sometimes an entirely black screen. Sometimes, not even a hard system reset is sufficient and the system has to be booted into recovery mode, the existing driver removed, and another installed, before rebooting again. With nvidia-driver-440, fewer hangs but the monitor resolution can't be set to its capacity. I don't get it. GNOME hangs have been extensively documented for ten years. The drivers expressly support the hardware. This package is part of an Ubuntu LTS release. Is gnome-session intended to be serious, functional, production software subjected to rigorous and competent
[Desktop-packages] [Bug 1892973] Re: gnome-session fails, and fails, and fails yet again
Thanks for responding. Some delays in responding because of client demands, then because the storage configuration of the machine was incomplete and the debug files couldn't be networked, then because the incessant gnome-session hangs required a hard-reset at nearly every step along the way. The delays provided some information, however. First, I booted to recovery mode, removed nvidia-driver-440, installed nvidia-driver-450 (the recommended one, per the ubuntu-drivers devices output), exited recovery, and continued the boot (NOT another hard- reset). Here, the resolution was 1024x768, not the full resolution of the monitor, in logging in under all available desktop managers (Xorg, Classic, and Ubuntu). The machine experienced NO gnome session freezes over 8-10 hours with occasional interaction in between client calls. THEN, I did a normal reboot at the end of the day, specified Xorg on login. The resolution now was back to normal but I immediately right- clicked to launch display settings and this triggered a gnome-session freeze. Through a series of hard-resets, the machine continued several other random freezes. Today, I had reconfigured storage to, among other things, mount /tmp to /tmpfs, the consequence of which obviously is to flush /tmp on every reboot. The machine experienced no gnome-session hangs. I then ran apt update and apt full-upgrade, which triggered updates of what appeared to be nvidia-driver-450 and all of its dependencies. The machine then promptly experienced a gnome-session hang. Hard-reset, black screen. Hard-reset, Xorg login, generate the debug files (attached). Run apport-collect 1892973. Launching Firefox to authorize triggers a gnome-session hang. Hard-reset, Xorg login. Launching Firefox triggers a gnome-session hang. Hard-reset, Xorg login. Copy debug files to this machine (a functional Windows laptop) and make this entry. The requested debug files, to the extent of the machine's ability to generate them, are attached. I ended up generating several prior-boot journal logs for all of the foregoing gnome-session hangs, and attach them in a ZIP archive because the interface will only let me attach one file. The files include: - prevboot-1 (first prevboot) - prevboot-2 (the boot preceeding prevboot-1) - prevboot-1128-* (boots involving Firefox-induced hangs and one preceding) - prevboot-1135-1 (boot involving a Firefox-induced hang). Obviously, the machine is incapable of authorizing for apport-collect. I should add that attempting to launch Google Chrome also triggers a gnome-session hang. No files exist in /var/crash. ** Attachment added: "Zip archive of debug files" https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1892973/+attachment/5405535/+files/documents.zip -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-shell in Ubuntu. https://bugs.launchpad.net/bugs/1892973 Title: gnome-session fails, and fails, and fails yet again Status in gnome-shell package in Ubuntu: Incomplete Bug description: Ubuntu 20.04.01, gnome-shell 3.36.4, nvidia-driver-450, nvidia- driver-440. Both drivers expressly support the hardware. All varieties of desktop environment (Xorg, Gnome Classic, Ubuntu) Bug summary Screen hangs randomly and iretrievably with the only possibility of recovery being a a hard system reset. Sometimes this is triggered by activity (launching or using gnome-settings; resizing a window; using Nautilus), sometimes, not. No session lasts more than five minutes. No combination of keystrokes will yield a terminal of any kind. The hang also interrupts System Monitor output, so no information regarding use of system resources is available. Steps to reproduce 1. Install gnome-session. 2. Reboot. 3. Use graphical applications. What happened] The screen froze irretrievably. Screen hangs randomly and iretrievably with the only possibility of recovery being a a hard system reset. Sometimes this is triggered by activity (launching or using gnome-settings; resizing a window; using Nautilus), sometimes, not. No session lasts more than five minutes. No combination of keystrokes will yield a terminal of any kind. The hang also interrupts System Monitor output, so no information regarding use of system resources is available. A hard system reset and consequent reboot yields a variety of outcomes. Sometimes, a normal gdm login. Sometimes, a black screen with an inverted-black mouse cursor/pointer/arrow that moves. Sometimes an entirely black screen. Sometimes, not even a hard system reset is sufficient and the system has to be booted into recovery mode, the existing driver removed, and another installed, before rebooting again. With nvidia-driver-440, fewer hangs but the monitor resolution can't be set to its capacity. I don't get it. GNOME hangs have been extensively documented for ten
[Desktop-packages] [Bug 1892973] [NEW] gnome-session fails, and fails, and fails yet again
Public bug reported: Ubuntu 20.04.01, gnome-shell 3.36.4, nvidia-driver-450, nvidia- driver-440. Both drivers expressly support the hardware. All varieties of desktop environment (Xorg, Gnome Classic, Ubuntu) Bug summary Screen hangs randomly and iretrievably with the only possibility of recovery being a a hard system reset. Sometimes this is triggered by activity (launching or using gnome-settings; resizing a window; using Nautilus), sometimes, not. No session lasts more than five minutes. No combination of keystrokes will yield a terminal of any kind. The hang also interrupts System Monitor output, so no information regarding use of system resources is available. Steps to reproduce 1. Install gnome-session. 2. Reboot. 3. Use graphical applications. What happened] The screen froze irretrievably. Screen hangs randomly and iretrievably with the only possibility of recovery being a a hard system reset. Sometimes this is triggered by activity (launching or using gnome-settings; resizing a window; using Nautilus), sometimes, not. No session lasts more than five minutes. No combination of keystrokes will yield a terminal of any kind. The hang also interrupts System Monitor output, so no information regarding use of system resources is available. A hard system reset and consequent reboot yields a variety of outcomes. Sometimes, a normal gdm login. Sometimes, a black screen with an inverted-black mouse cursor/pointer/arrow that moves. Sometimes an entirely black screen. Sometimes, not even a hard system reset is sufficient and the system has to be booted into recovery mode, the existing driver removed, and another installed, before rebooting again. With nvidia-driver-440, fewer hangs but the monitor resolution can't be set to its capacity. I don't get it. GNOME hangs have been extensively documented for ten years. The drivers expressly support the hardware. This package is part of an Ubuntu LTS release. Is gnome-session intended to be serious, functional, production software subjected to rigorous and competent quality control? This is a serious question because I have a business to run and can't be sucked down some random technical rabbit hole just to do daily work. Is GNOME just a cute code project intended as a resume line for people looking for real work? What kind of quality control processes are in place that allow ancient failures, extensively reported, to persist? Is anyone at GNOME able and willing to put on their big-boy pants to get a reliable package suitable for production deployments, released? The command cat /var/log/syslog | grep gnome-session reveals fundamental errors in implementing systemd syntax and references/calls to nonexistent binaries. See the gnome-sesion units in /usr/lib/systemd/user. Maybe getting this right would be a first step to helping the developers understand the environment better. Please see man systemd. Source is, astonishingly, a hybrid of C and Javascript, which doubtless presents a QC nightmare. Has anyone given this any thought? What does it take to get this package to work today? - What is the procedure? What commands must be run? - Why doesn't GNOME simply include these commands in a script, just to make it easier? Does anyone there know how? - Why doesn't GNOME simply compile these commands into the package so it works in the first place? - Will a different graphics card matter? - Which one? - Why, if the drivers support the existing hardware, according to the documentation if not the function? Can this package be made to work today? If not, will this package be ready for production use in the next Ubuntu release (i.e., 20.04.02)? If not, what alternatives exist for production use? These are all serious questions. It is astonishing that this package has been released to the public. It getting out the door poses an existential reputational threat to the GNOME project. Any help in getting this package to work would be most gratefully appreciated. What did you expect to happen I expected the screen not to freeze. ** Affects: gnome-shell (Ubuntu) Importance: Undecided Status: New ** Tags: 20.04 gnome-session gnome-shell nvidia xorg ** Information type changed from Private Security to Public ** Tags added: 20.04 gnome-session gnome-shell nvidia xorg -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-shell in Ubuntu. https://bugs.launchpad.net/bugs/1892973 Title: gnome-session fails, and fails, and fails yet again Status in gnome-shell package in Ubuntu: New Bug description: Ubuntu 20.04.01, gnome-shell 3.36.4, nvidia-driver-450, nvidia- driver-440. Both drivers expressly support the hardware. All varieties of desktop environment (Xorg, Gnome Classic, Ubuntu) Bug summary Screen hangs randomly and iretrievably with the only possibility of recovery being a a hard system reset. Sometimes this is
