Bug#895874: Same bug still present, same fix, in bullseye
I can confirm the same bug and the same solution (libmailtools-perl) present in debian 11 bullseye... --Simon
Bug#968402: WPA3 failures in bullseye still...
I'm noticing bullseye still failing to connect to WPA3 where the server and client driver and wpasupplicant should all support it. I'm wondering if issues above are more around this issue:- https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/638 Apparently 1.30.2 network-manager should sort this, but that is too new for the version in bullseye. Currently building a backport to test =). --Simon
Bug#996290: Fix tested successfully, correct for bullseye?
I can conform that applying https://github.com/irssi/irssi/commit/db2fed to the irssi_1.2.3-1 debian source, builds and works on debian bullseye i386 and amd64. I have found no regressions, use 'saved' TLS+SASL network configs *and* ad-hoc TLS network configs, both of which now work fine in face of disconnects, as opposed to only the former. I am of the view this is worthy of a routine update to the irssi package as SSL in IRC is increasingly used/encouraged/needed for certain auth types, and manually /connect 'ing is not at all a rare configuration, as well as the point that this is a relatively simple fix to a relatively annoying and confusing problem! This ad-hoc TLS config has been fine in previous debian releases, just not now, all of a sudden, bullseye regression essentially!. This could go into bullseye-updates for next point release, in my view. I'd like to hear from maintainer, and happy to post package files if useful for others to view/help test. --Simon
Bug#962003: *ERROR* Failed to wait for idle; VT'd may hang
On 17/07/2021 15.04, Simon Josefsson wrote: > Hi. I just installed Debian bullseye daily today (linux-image-amd64 > version 5.10.40-1), and ran into this problem on a Lenovo X201. The > message repeats every other second or so. I don't notice any other I believe, the messages/behaviour was slowing the system or so, not just giving messages, at least I have seen this on X201T. The workaround is to boot with kernel parameter intel_iommu=igfx_off e.g. set in /etc/default/grub GRUB_CMDLINE_LINUX_DEFAULT="intel_iommu=igfx_off" and then re-run sudo update-grub and reboot. [I tend to remove "quiet splash" but you could of course have GRUB_CMDLINE_LINUX_DEFAULT="quiet splash intel_iommu=igfx_off" Playing the Git-Bisect game would be helpful if somebody could find *exactly* where the problem was introduced .. --Simon
Bug#899086: xserver-xorg-video-amdgpu: completely fails to detect AMD RX 550 (which uses the Polaris 12 chipset) unless firmware-amd-graphics package installed
Alan and bug 899086, Please try testing if this situation is improved or fixed in debian testing (to soon become bullseye) images, similarly to as you did before. In fact the cdimage address you linked seems to be still exactly correct!. I'd like to see bug-report either closed or updated for bullseye. Given all the changes/massive improvements in amdgpu modesetting I expect the situation to be considerably improved, at least!. --Simon
Bug#890357: Graphical issues with an RX 480
Can you confirm this issue is/is-not relevant any more on either of:- * Debian Bullseye (testing) * Debian Buster (stable) with the backported version of kernel (5.10.0-0.bpo.7) installed. Amdgpu has improved a long way since the time this bug report was created, and would be good to get the bug closed or issue forwarded upstream if still relevant. --simon
Bug#892982: system freeze after lock screen/switched off monitors/spontaneously
I can confirm the buster-backports now offers kernel 5.10.0-0.bpo.7-amd64 .. Please test this following notes on previous bug pointer. Can the bug now be closed, if that works, or doesn't -- I don't think there is an X.org bug here. --Simon
Bug#942318: xserver-xorg-video-amdgpu: VGA output is not detected in Radeon R7 (Carrizo) only the HDMI works. Motherboard MSI A68HM-E33 v2
Julian and bug 942318, buster-backports now provides kernel 5.10.0-0.bpo.7 via the buster-backports linux-image-amd64 linux-headers-amd64 packages. Please confirm if this solves the issue for you, and close the bug. --Simon
Bug#970574: xserver-xorg-video-amdgpu: ABI changed (24.0 to 24.1) but not the dependencies
GSR, Buster now has xserver-xorg-core version 2:1.20.4-1+deb10u3 [in-between the versions you quoted] and bullseye now has a newer newer 2:1.20.11-1 version. Given the date of your bug-report, it looks like you had the old 2018 version of the xorg-xserver package even though the buster package tas been updated twice since then to 2019 and 2020 versions. See Changelog:- https://metadata.ftp-master.debian.org/changelogs//main/x/xorg-server/xorg-server_1.20.4-1+deb10u3_changelog In short, I think this bug report should now be closed unless there is an apparent issue specifically in buster or bullseye now [??] ? --Simon
Bug#974581: np longer able to set native resolution of Dell U3014
Dear Janusz linux-image-amd64 linux-headers-amd64 have now come out in version 5.10.0-0.bpo.7 in buster-backports. Please confirm the issue is solved for you (or not) by using that kernel as above, so the bug report can be prgressed or closed. --Simon
Bug#900087: AMD RX 550 often locks up
I would generally say this looks like problems more in kernel and firmware land, than bugs in the xserver driver to me... I would, generally note a lot of wider AMD instability/issues (that Alan) talks about improved a lot in 5.8-ubuntu and 5.10-debian (bullseye and buster-backports) kernels. Even 5.4-ubuntu kernels still have problem with some newer Ryzen systems. In short, I'd recommend testing debian buster-backports version of linux-image-amd64 linux-headers-amd64 and report back on this bug. In particular -- can this bug now be closed, anyhow? How could debian warn users to update BIOS/firmware? --Simon
Bug#942318: xserver-xorg-video-amdgpu: VGA output is not detected in Radeon R7 (Carrizo) only the HDMI works. Motherboard MSI A68HM-E33 v2
I can say, I understood a limitation of amdgpu kernel driver has been not supporting VGA/analogue outputs in some (or all?) cases. I understood this is part of the reason it is not the default driver over radeon for some cards. However, given many other other experiences and bugreports with amdgpu modesetting problems, and looking at this bug, I would recommend trying newer kernel in buster:- enable backports https://backports.debian.org/Instructions/ apt-get -t buster-backports install linux-image-amd64 linux-headers-amd64 This should get you a 5.10 series kernel which could well behave better for you (let us know!). --Simon p.s. the backports kernel is lagging behind a little, hopefully 5.10.0-0.bpo.6 and 5.10.0-0.bpo.7 will come out soon.
Bug#892982: system freeze after lock screen/switched off moniturs/spontaneously
I have had first-hand experience of these Xorg crashes and lockups in combination with either sleep or un-powering monitors. I would 100% agree with Hermann that this is highly likely to be improved with kernel update. In short, I would go to *at least* the buster-backports kernel i.e. https://backports.debian.org/Instructions/ apt-get -t buster-backports install linux-image-amd64 linux-headers-amd64 Over the recent 5.10 debian kernel provisions, I have seen incremental improvement in this issue, to the point that now this seems to have gone away. I still experience complex MST monitor arrangement reordering the displayport- virtual numbers (fixed with xrandr script) but NO LONGER crashes needing reboot or restart-X11 like before... In any case, please report back how 5.10 series kernel does/does-not avoid the issue occuring for you. --Simon p.s. The buster-backports kernel [5.10.0-0.bpo.5-amd64] is lagging behind a little. Hopefully .bpo.6 and .bpo.7 will come out soon. I notice debian-deriv MXlinux have put out their own 5.10.0-7mx kernel already.
Bug#974581: np longer able to set native resolution of Dell U3014
Given some other experiences with amdgpu modesetting problems, and looking at this bug, I would say:- 1) Please try updating all packages and reboot and try again, kernel should be now 4.19.0-16 2) Secondly, enable backports https://backports.debian.org/Instructions/ and then:- apt-get -t buster-backports install linux-image-amd64 linux-headers-amd64 This should get you a 5.10 series kernel. My strong experience with amdgpu has been that a whole lot of modesetting, sleep, etc etc. issues are massively improved in 5.10 kernel series of late, irrespective of the xserver-xorg version in use. NB: At boot-time, in normal cases, GRUB menu should allow you to 'select' which kernel you boot into i.e you should be able to select between 5.10.0.bpo.?? and 4.19.0-16 kernel. I note, the backports kernel is lagging behind a little, hopefully 5.10.0-0.bpo.6 and 5.10.0-0.bpo.7 will come out soon. --Simon
Bug#987388: Crash of amdgpu on Debian 11 Bullseye
Dear all on this bug, I would like to briefly point out these crashes are showing kernel errors, the kernel / amdgpu modesetting seems to be a very significant part of the problem if I am not mistaken, this bug being against the X-server component. I would say, from the deb-10 / MX19.4 side of things with a GCN1.1 series amdgpu card, updated 5.10 kernels (i.e. backports of deb11 bullseye kernels) have incrementally improved problems with crashing, resuming from sleep, and so-on. With 5.10.0-7 I seem to be able to reliably unpower and repower monitors and manage to keep X working without crash and just xrandr fix up monitor layout. Similar applies to sleep/resume situation!. I know the kernel amdgpu modesetting driver is a huge part of that work. In short, I would highly recommend trying different kernels on your deb11 testing machines and see how that affects your situation, and in any case report which kernels are in use in the crash scenario. Debian11 bullseye currently has 5.10.0-6 and I understand the 5.10.0-7 packages are to hit bullseye soon (through hard freeze). 5.10.0-7 is in sid and can be manually downloaded, or installed via *temporary* adding sid to sources.list and then removing from sources (or pinning to avoid all packages going to sid). https://packages.debian.org/search?keywords=linux-image-5.10.0-7-amd64 Also, I would note, testing the older linux-image-4.19.0-16 may be worthwhile, I get impression this (buster) kernel should nonetheless 'work' with bullseye and may assist with the 'it used to work' scenario. Hope that helps, --Simon
Bug#984696: courier-mta 1.0.14-2 on bullseye (also 1.0.16-2) not startable/dpkg configurable.
Package: courier-mta Version: 1.0.16-2 Severity: grave Justification: renders package unusable On current debian bullseye, courier-mta is not startable, looks like some kind of problem in init scripts (but could be executables/environment), as per system info and console log below. Even with all courier packages purged, /etc/courier /???/lib/courier directories completely removed, and start from scratch, installation of courier-base is OK but installing courier-mta consistently fails. This is reproducible on a buster system upgraded to bullseye (i386 and sysvinit-core and no usrmerge) e.g.:- Preconfiguring packages ... Selecting previously unselected package courier-mta. (Reading database ... 42620 files and directories currently installed.) Preparing to unpack .../courier-mta_1.0.14-2_i386.deb ... Adding 'diversion of /usr/bin/addcr to /usr/bin/addcr.ucspi-tcp by courier-mta' Adding 'diversion of /usr/share/man/man1/addcr.1.gz to /usr/share/man/man1/addcr.ucspi-tcp.1.gz by courier-mta' Unpacking courier-mta (1.0.14-2) ... Setting up courier-mta (1.0.14-2) ... update-alternatives: using /usr/bin/lockmail.courier to provide /usr/bin/lockmail (lockmail) in auto mode update-alternatives: using /usr/bin/preline.courier to provide /usr/bin/preline (preline) in auto mode /etc/courier/esmtpd.pem.pem already exists. dpkg: error processing package courier-mta (--configure): installed courier-mta package post-installation script subprocess returned error exit status 1 Processing triggers for man-db (2.9.4-2) ... Errors were encountered while processing: courier-mta E: Sub-process /usr/bin/dpkg returned an error code (1) ALSO (though not quite the same) on a current debian amd64 bullseye chroot (not upgraded) systemd-based host system as well. In that circumstance you get various "Running in chroot, ignoring request." messages for start (which otherwise passes even if mta may not be started), but similar error shows up upon trying to remove/purge courier-mta instead, with error:- Removing courier-mta (1.0.14-2) ... Running in chroot, ignoring request. Stopping Courier MSA server: esmtpd-msa. invoke-rc.d: initscript courier-msa, action "stop" failed. dpkg: error processing package courier-mta (--remove): installed courier-mta package pre-removal script subprocess returned error exit status 1 dpkg: too many errors, stopping locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory Running in chroot, ignoring request. Running in chroot, ignoring request. Running in chroot, ignoring request. Running in chroot, ignoring request. Running in chroot, ignoring request. Errors were encountered while processing: courier-mta Processing was halted because there were too many errors. System info below is from trying the sid/second version (just the courier packages) but exactly the same failure happens either way. This clearly needs looking at for bullseye release. **NB** Have discovered that, at least for the case of new-installing courier-mta 1.0.16-2, adding "exit 0" on the end of /etc/init.d/courier-msa *seems* to be sufficient to allow dpkg configure to work, and courier-mta then seems to start okay. I have considered the non-systemd and non-usrmerge (mkdir path) bugs I could find for courier-mta but these don't seem to apply to this circumstance. This clearly makes the package unusable on bullseye and needs looking at for release. Lots of courier-mta users will be "upgrade" case, I strongly suspect, so working for upgrade cases in older configs is especially important! --Simon -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 4.19.0-14-686-pae (SMP w/2 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages courier-mta depends on: ii courier-authlib0.71.1-1 ii courier-base 1.0.16-2 ii debconf [debconf-2.0] 1.5.74 ii libc6 2.31-9 ii libcourier-unicode42.1.2-2 ii libgcc-s1 10.2.1-6 ii libgdbm6 1.19-2 ii libidn11 1.33-3 ii libnet-cidr-perl 0.20-1 ii libperl5.325.32.1-2 ii libstdc++6 10.2.1-6 ii perl 5.32.1-2 ii sysvinit-utils 2.96-6 ii wget 1.21-1 courier-mta recommends no packages. Versions of
Bug#962003: Bug found still present In current debian Kernels
> Please do test as well the yesterday uploaded 5.8.7-1 but I suspect > the bug is still present there. Yes, indeed. > To isolate the issue it might be worth trying to bisect were the issue > is introduced and ideally then reported upstream. Confirmed between 5.4.19-1 and 5.5.13-1. > Some hints are in > https://wiki.debian.org/DebianKernelReportingBugs#Identifying_when_the_bug_was_introduced "You can find older versions of the kernel in various locations, including http://snapshot.debian.org.; Where else are these "various locations" !?!? Can they be linked onto above wiki page? In this case some earlier 5.5's would be clearly useful test-cases. Another point that I'd like to see on above page, is -- clear information on where kernel bugs *should* be filed or *are* filed with explanation. I.e. src:linux linux-image-amd64 linux-image-VERSION-amd64 and so-on and so-forth!. Another point that I'd like to see on above page, is clear information what to do to search for existing kernel bugs, as "reportbug kernel" would NOT find 962003 for me, this is related to the above confusion really. --Simon
Bug#962003: Bug found still present In current debian Kernels
Bug still present, affects for-example X201-Tablet, similar hardware to T410 with Intel Graphics variant. Affects at least debian kernels:- 5.6.0-2-amd64 5.6.14-2 5.7.0-2-amd64 5.7.10-1 5.7.0-3-amd64 5.7.17-1 --Simon
Bug#650692: Clarification: 3.1.6-1.2+squeeze1
I had intended this bug report to cover the squeeze version (3.1.6-1.2+squeeze1) rather than the exact version on my bugreport system at the time, although the bug-megadata does not seem to reflect this ;-(. --Simon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516307: CGI scripts on mini-httpd
I can confirm the same problem in Debian Squeeze6.0, mini-httpd 1.19-9.2, just discovered it myself... --Simon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
