Bug#1003071: logs
And again... bugreport_nouveau_syslog.txt.xz Description: application/xz
Bug#1003071: logs
Oops, trying to send the file again.
Bug#1003071: logs
Sorry, I forgot the attachment. Here it is.
Bug#1003071: xserver-xorg-video-nouveau: Bad memory deallocation inside nouveau kernel module, leading to freezes
Package: xserver-xorg-video-nouveau Version: 1:1.0.17-1 Severity: important Screen completely freezes after some amount of starting GUI applications and interacting with their windows. A reliable way to trigger this bug is to run applications with big amount of UI elements. For example, start Thunderbird and LibreOffice (in this order) at the same time. It will probaly freeze after an attempt to start LibreOffice. If not, open a dozen of new documents in LibreOffice, try to rearrange windows on screen, change virtual desktops several times, open a web browser... Eventually after all this fuzzing the screen will freeze. How it looks like: there are frames of windows on screen with unrendered internal part. The instead of internal part of these windows there are often parts of image, which was on screen before freeze. No reaction on any keyboard interaction, even on trying to change to virtual terminal with Ctrl-Alt-F1. At the same time, mouse pointer in most cases still can be moved on screen, but there is no reaction on pressing mouse buttons. After some time (5-15 minutes) the computer may unfreeze, but will freeze again shortly after few attempts to interacts with it. At the same time, computer remains accessible over SSH and can be cleanly shut down with ACPI Power-Off button. Examining syslog showed huge amount of warnings and stack traces from kernel related to erroneous memory deallocations. See attachment. Additional details: - Freezes occure regardless of whether Debian is run as Xen host, or without Xen. - Freezes started after upgrading from Buster to Bullseye. - Blacklisting nouveau in /etc/modprobe.d/ remove freezes. (But for this workaround I also need to turn on integrated GPU in BIOS and connect screen to DVI port on motherboard to make X working again.) -- Package-specific info: X server symlink status: lrwxrwxrwx 1 root root 13 Oct 22 2016 /etc/X11/X -> /usr/bin/Xorg -rwxr-xr-x 1 root root 274 Dec 16 19:08 /usr/bin/Xorg VGA-compatible devices on PCI bus: -- 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation G92 [GeForce 9800 GT] [10de:0614] (rev a2) /etc/X11/xorg.conf does not exist. Contents of /etc/X11/xorg.conf.d: - total 4 -rw-r--r-- 1 root root 226 Jan 20 2019 90-xpra-virtual.conf /etc/modprobe.d contains no KMS configuration files. Kernel version (/proc/version): --- Linux version 5.10.0-10-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.84-1 (2021-12-08) Xorg X server log files on system: -- -rw-r--r-- 1 rootroot15548 Mar 18 2018 /var/log/Xorg.2.log -rw-r--r-- 1 useruser37608 May 3 2019 /home/user/.local/share/xorg/Xorg.1.log -rw-r--r-- 1 rootroot42217 Mar 13 2021 /var/log/Xorg.1.log -rw-r--r-- 1 rootroot60330 Jan 3 15:05 /var/log/Xorg.0.log Contents of most recent Xorg X server log file (/var/log/Xorg.0.log): - [39.172] X.Org X Server 1.20.11 X Protocol Version 11, Revision 0 [39.172] Build Operating System: linux Debian [39.172] Current Operating System: Linux mishascomp 5.10.0-10-amd64 #1 SMP Debian 5.10.84-1 (2021-12-08) x86_64 [39.172] Kernel command line: BOOT_IMAGE=/vmlinuz-5.10.0-10-amd64 root=/dev/mapper/main-rootfs ro quiet video=uvesafb:mode_option=1680x1050-24,mtrr=3,scroll=ywrap apparmor=1 security=apparmor [39.172] Build Date: 16 December 2021 05:08:23PM [39.172] xorg-server 2:1.20.11-1+deb11u1 (https://www.debian.org/support) [39.172] Current version of pixman: 0.40.0 [39.172]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [39.172] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [39.172] (==) Log file: "/var/log/Xorg.0.log", Time: Mon Jan 3 14:45:40 2022 [39.260] (==) Using config directory: "/etc/X11/xorg.conf.d" [39.260] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [39.740] (==) No Layout section. Using the first Screen section. [39.740] (==) No screen section available. Using defaults. [39.740] (**) |-->Screen "Default Screen Section" (0) [39.740] (**) | |-->Monitor "" [39.742] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [39.742] (==) Automatically adding devices [39.742] (==) Automatically enabling devices [39.742] (==) Automatically adding GPU devices [39.742] (==) Max clients allowed: 256, resource mask: 0x1f [39.824] (WW) The directory "/usr/share/fonts/X11/cyrillic"
Bug#956712: Bug 956712 (emacs in Debian Stable)
On 28.06.20 05:23, R S Chakravarti wrote: > Hi, > I don't have a deep knowledge of the OS but I was surprised to see a bug > reported in > this binary package which is a metapackage. I already had emacs-lucid > installed when > I installed emacs. Since package emacs contains only documentation, the > reported bug > shouldn't affect me. It seems to me that it ought to pertain to > emacs-gtk or emacs- > lucid. Would you please let me know if I am right? > Best wishes, > RSC. Yes, you are actually right, this bug should not belong to the emacs metapackage, but to one of its dependencies. It's my mistake. I suppose, that the actual bug may reside in emacs-common or in emacs-bin-common, on which emacs-gtk and emacs-lucid depend, but I am not sure. And no, the emacs metapackage depends on emacs-gtk, emacs-lucid or emacs-nox, so your installation is very likely affected. Thank you for noticing. Heenec
Bug#956712: emacs: https to plain http downgrade after unhandled GNUTLS_E_AGAIN error in TLS1.3 connection
Package: emacs Version: 1:26.1+1-3.2+deb10u1 Severity: grave Tags: security Justification: user security hole Dear Maintainer, When I have tried to install a package from the GNU ELPA repository, I received a "Bad Request" error. Searching on the Internet for a solution of this problem led me to this bugreport at debbugs.gnu.org: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34341 I have confirmed, that the bug reported there can be reproduced in my emacs installation, and that the workaround mentioned there (disabling TLS1.3) works. But while playing around with this bug I noticed, that for some reason after breaking the TLS1.3 connection it makes second connection with plain http to the port 443 (sic!). Steps to reproduce: 1) Run emacs 2) Open scratchpad with "C-x b *scratch*" 3) Write the following snippet and execute it by positioning cursor after the last ")" and pressing C-j. ``` (switch-to-buffer (url-retrieve-synchronously "https://duckduckgo.com";) (buffer-string)) ``` Results: A new buffer with following content is opened: ``` HTTP/1.1 400 Bad Request Server: nginx Date: Fri, 02 Apr 2020 12:54:12 GMT Content-Type: text/html; charset=UTF-8 Content-Length: 248 Connection: close X-XSS-Protection: 1;mode=block X-Content-Type-Options: nosniff Referrer-Policy: origin Expect-CT: max-age=0 400 The plain HTTP request was sent to HTTPS port 400 Bad Request The plain HTTP request was sent to HTTPS port nginx # ``` Also if network traffic was captured with Wireshark, it can be seen, that breaking of the TLS1.3 connection follows with a plain http request to port 443 on the same IP address. And the result of this http request is returned by the url-retrieve-synchronously function. The same behaviour is seen in network captures of (failing) emacs package installation process. Althogh the bug mentioned in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34341 seems to be currently fixed in upstream emacs 26.3 and 27.1, the related patch fixes wrong handling of GNUTLS_E_AGAIN error, but not this fallback from https to plain http. It suggests, that this behaviour may be triggered by other exceptions. Heenec -- System Information: Debian Release: 10.3 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-8-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages emacs depends on: ii emacs-gtk 1:26.1+1-3.2+deb10u1 emacs recommends no packages. emacs suggests no packages. -- no debconf information
Bug#712451: [pkg-apparmor] Bug#712451: Please support AppArmor network rules
intrigeri: > FWIW, this is now mentioned in the manpage that documents the policy > language: apparmor.d(5) Maybe I have not read the manual thoroughly enough, but I have not found mentions of features that does not work in Debian yet. Maybe such notice should be placed in "Network Rules" section of the manual? Or in "KNOWN BUGS"? So that newcomers will not be misguided (like me). Okay, it's my bad that I have not checked explicitly if it works. But IMO there is an issue with documentation if you can't understand from it what is supposed to be working and what is not. By the way, ping under apparmor fails with "ping: socket: Operation not permitted", while wget or curl works pretty well under the same profile. Don't know if it is supposed to be like it. Heenec 0x4B12C0FAA12F367B.asc Description: application/pgp-keys
