Bug#1011026: linux-headers-amd64: cannot install/upgrade to 5.17.6 on amd64
Package: linux-headers-amd64
Version: 5.17.6-1
Severity: normal
linux-headers-amd64=5.17.6-1 depends on linux-headers-5.17.0-2-amd64=5.17.6-1,
but there's only 5.17.6-1+b1 in the amd64 archive as of today.
This results in:
# apt install linux-headers-5.17.0-2-amd64
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages will be REMOVED:
linux-headers-amd64 (5.17.6-1)
The following packages will be upgraded:
linux-headers-5.17.0-2-amd64 (5.17.6-1 => 5.17.6-1+b1)
1 upgraded, 0 newly installed, 1 to remove and 84 not upgraded.
Need to get 963 kB of archives.
After this operation, 12.3 kB disk space will be freed.
On another Debian instance, where linux-headers-amd64 is still at
5.17.3-1, it looks like this:
# apt install linux-image-amd64 linux-headers-amd64
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
linux-headers-amd64 : Depends: linux-headers-5.17.0-2-amd64 (= 5.17.6-1)
but it is not going to be installed
E: Unable to correct problems, you have held broken packages.
# apt policy linux-headers-5.17.0-2-amd64
linux-headers-5.17.0-2-amd64:
Installed: (none)
Candidate: 5.17.6-1+b1
Version table:
5.17.6-1+b1 990
500 https://deb.debian.org/debian unstable/main amd64 Packages
-- System Information:
Debian Release: bookworm/sid
APT prefers stable-security
APT policy: (990, 'stable-security'), (990, 'testing'), (500,
'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500,
'unstable'), (500, 'stable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.17.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_USER, TAINT_WARN
Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages linux-headers-amd64 depends on:
ii linux-headers-5.17.0-2-amd64 5.17.6-1
linux-headers-amd64 recommends no packages.
linux-headers-amd64 suggests no packages.
-- no debconf information
--
Tomáš "liskin" ("Pivník") Janoušek, https://lisk.in/
Bug#934781: firmware-iwlwifi: iwl4965: Microcode SW error detected
Hi, On Fri, Dec 13, 2019 at 03:29:23PM +1030, Andrew Bettison wrote: > As an experiment, I downloaded the tarball from > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tag/?h=20190815 > (as recommended in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939262 > ), and manually copied its intel/* and iwlwifi-* files into /lib/firmware > (overwriting the ones installed by the firmware-iwlwifi package). > > After rebooting kernel 5.3.0-2 (amd64) I still get "iwlwifi: Microcode SW > error" messages accompanied by "ieee80211 phy0: Hardware restart was > requested" during periods of high Wi-Fi throughput, but they do not cause > the Wi-Fi to hang. So the newer firmware appears to rectify the worst part > of the problem (Wi-Fi freeze) but does not fully resolve the problem. Can you perhaps try the current version as well? There's been one additional change to iwlwifi firmwares since then: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=40e4162adfc91390f6fbbd8269f9439832af1dde (I haven't tested either, I just downgraded to 20190502-1. Don't have the mental budget to deal with another broken thing now.) -- Tomáš Janoušek, a.k.a. Pivník, a.k.a. Liskni_si, http://work.lisk.in/
Bug#942881: Audio on Lenovo X1 Carbon 5th generation stopped working after upgrade to linux-image-5.3.0-1-amd64 ("No response from codec")
Hi Ansgar, On Fri, Oct 25, 2019 at 10:59:09AM +0200, Ansgar wrote: > I tried running `sign-file` manually and can reproduce the truncated > file with Debian's production key. I also tried signing the same key > with a test key instead of the production key: then the signature is 256 > bytes long, just as with any other file... > > `strace -e write sign-file` reports only a single call to `write()` > which writes the entire file in one go. The return value also matches > the number of bytes asked to be written in every case. Cool, thanks for reproducing the issue! Just one question: when you say production key, does that mean a hardware security module like Ben mentioned, or can you reproduce this with a fully software implementation? Provided the latter, that means there exists an input to sign-file that produces an invalid (shorter) signature, and it's likely we can find another combination of key/module that also fails, and that can be made public (as opposed to the Debian production key). I don't have the computing resources for this, but if we're sure the reproducer exists, someone at LKML might. Otherwise I'm afraid you might need to dig a bit deeper. :-) -- Tomáš Janoušek, a.k.a. Pivník, a.k.a. Liskni_si, http://work.lisk.in/
Bug#942881: Audio on Lenovo X1 Carbon 5th generation stopped working after upgrade to linux-image-5.3.0-1-amd64 ("No response from codec")
Hi, On Fri, Oct 25, 2019 at 09:45:55AM +0200, Ansgar wrote: > Tomas Janousek suggested in https://bugs.debian.org/942881#41 that the > file might be truncated and two bytes missing. I think that might be > the problem, but with three bytes missing: > > src:linux-signed-amd64/5.3.7+1 has for linux-image-5.3.0-1-amd64 a total > of 3568 detached signatures: one is 1378 bytes (kernel itself), then > 3566 module signatures at 396 bytes each, then one module signature for > snd-hda-codec-hdmi.ko.sig which is only 393 bytes. That is very > suspicious... Not really. That's just the ASN.1. For 256 byte octet string, the length field is one byte longer than for 255 or 254 bytes. Yesterday I got one more idea: we've ruled out padding, but maybe a zero byte in the middle would somehow get lost. So I tried all the ways one could place two zero bytes into the 254 byte string, and got nothing. -- Tomáš Janoušek, a.k.a. Pivník, a.k.a. Liskni_si, http://work.lisk.in/
Bug#939441: firmware-iwlwifi: Microcode SW error detected / Error sending REPLY_ADD_STA: time out after 2000ms
Hi, On Thu, Sep 05, 2019 at 10:09:21AM +0930, Andrew Bettison wrote: > During heavy Wi-Fi use (rsync), every few seconds (see first kern.log > extract): > > Microcode SW error detected. Restarting 0x200. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934781#10. The 20190717 version of iwlwifi firmware is simply broken, Debian must upgrade (or downgrade) to a version that works: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939262 -- Tomáš Janoušek, a.k.a. Pivník, a.k.a. Liskni_si, http://work.lisk.in/
Bug#942563: linux-image-5.2.0-3-amd64: iwlwifi continously restarts
Hi, On Fri, Oct 18, 2019 at 09:36:07AM +0200, Kamil Jońca wrote: > wifi card continously restarted and wifi almost does not work > [...] See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934781#10. The 20190717 version of iwlwifi firmware is simply broken, Debian must upgrade (or downgrade) to a version that works: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939262 -- Tomáš Janoušek, a.k.a. Pivník, a.k.a. Liskni_si, http://work.lisk.in/
Bug#943355: audio broken
Hi, On Wed, Oct 23, 2019 at 08:02:27PM +0100, jnq...@gmail.com wrote: > I installed a weeks worth of updates to my Sid install yesterday and > having done so my audio output has been broken. > [...] The module signature of snd-hda-codec-hdmi is broken, see #942881. -- Tomáš Janoušek, a.k.a. Pivník, a.k.a. Liskni_si, http://work.lisk.in/
Bug#942881: Audio on Lenovo X1 Carbon 5th generation stopped working after upgrade to linux-image-5.3.0-1-amd64 ("No response from codec")
Hi again, On Tue, Oct 22, 2019 at 11:59:03PM +0200, Tomas Janousek wrote: > There seems to be a workaround: > > options snd_hda_intel probe_mask=1 > > I'm not getting errors with this and audio works. I have a feeling that HDMI > audio will not work, however, because there's no "input: HDA Intel PCH HDMI" > in dmesg any more. :-( We got a reply from https://bugzilla.kernel.org/show_bug.cgi?id=205293: > Do you have HDMI HD-audio codec driver module available on your system? > The log message (showing "Generic") indicate that it's the generic driver > being bound, not the HDMI codec driver. However unlikely that suggestion sounds, it's spot on: # modprobe snd-hda-codec-hdmi modprobe: ERROR: could not insert 'snd_hda_codec_hdmi': Key was rejected by service Indeed, when I modprobe --force snd-hda-codec-hdmi and then rmmod/modprobe snd-hda-intel, everything's fine again, including HDMI profiles. So the new modprobe.d workaround is: install snd-hda-codec-hdmi /sbin/modprobe --ignore-install --force-modversion snd-hda-codec-hdmi And there's something horribly wrong with the Debian build of modules, it seems. I wonder what else is broken on this system because of a badly signed module... :-/ -- Tomáš Janoušek, a.k.a. Pivník, a.k.a. Liskni_si, http://work.lisk.in/
Bug#942881: Audio on Lenovo X1 Carbon 5th generation stopped working after upgrade to linux-image-5.3.0-1-amd64 ("No response from codec")
Hi,
On Tue, Oct 22, 2019 at 09:47:32PM +0300, Josh Triplett wrote:
> After upgrading to linux-image-5.3.0-1-amd64, I get messages like those
> seen in the log ("No response from codec, resetting bus" and "Unable to
> sync register"), and eventually a WARN. The mixer doesn't show the audio
> device at all.
>
> This didn't happen with the previous kernel, namely:
> Oct 21 21:04:28 s kernel: Linux version 5.2.0-3-amd64
> (debian-kernel@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-23)) #1 SMP
> Debian 5.2.17-1 (2019-10-06)
I can confirm the same behaviour with ThinkPad T25.
There seems to be a workaround:
options snd_hda_intel probe_mask=1
I'm not getting errors with this and audio works. I have a feeling that HDMI
audio will not work, however, because there's no "input: HDA Intel PCH HDMI"
in dmesg any more. :-(
--
Tomáš Janoušek, a.k.a. Pivník, a.k.a. Liskni_si, http://work.lisk.in/
Bug#934781: firmware-iwlwifi: iwl4965: Microcode SW error detected
Hi, On Fri, Aug 02, 2019 at 08:50:01PM +0200, Thorsten Glaser wrote: > Package: firmware-iwlwifi > Version: 20190717-1 > Severity: normal > > My WLAN just crashed, no load (an ssh session and some chat). I'm experiencing a similar problem with 8265 and kernel 5.2.7 -- I got the microcode sw error today, and my wifi has been reconnecting very often lately. And I even got a "kernel: list_del corruption", which may be unrelated, but all the reconnecting probably makes it easier to trigger. Anyway... It seems we're not alone at all: https://bugzilla.redhat.com/show_bug.cgi?id=1733369 https://forums.opensuse.org/showthread.php/537165-Wifi-randomly-dies-iwlwifi-Microcode-SW-error-detected https://bugs.archlinux.org/task/63117 https://forum.manjaro.org/t/linux-firmware-201907-breaks-iwlwifi/96529 -- Tomáš Janoušek, a.k.a. Pivník, a.k.a. Liskni_si, http://work.lisk.in/
Bug#904441: linux-image-4.17.0-1-amd64: system disk stopped during boot
Hi again, On Sun, Jul 29, 2018 at 11:52:10AM +0200, Tomas Janousek wrote: > Unfortunately, the above code doesn't prevent laptop-mode-tools, tlp nor > custom udev rules from enabling runtime-pm for devices so if you use any of > that, you might be having runtime-pm enabled on devices that don't support it, > and therefore get hangs. LKML doesn't disappoint, I reported the above yesterday and there's a patch today: https://patchwork.kernel.org/patch/10548975/ :-) -- Tomáš Janoušek, a.k.a. Pivník, a.k.a. Liskni_si, http://work.lisk.in/
Bug#904441: linux-image-4.17.0-1-amd64: system disk stopped during boot
Hi Julian, On Fri, Jul 27, 2018 at 09:31:42PM +1000, Julian Calaby wrote: > > Does adding the kernel parameter "ahci.mobile_lpm_policy=1" avoid this? > > No, booting with that parameter makes no difference. Can you try "dm_mod.use_blk_mq=0 scsi_mod.use_blk_mq=0" as well? Block multiqueue was enabled in debian's 4.17 (https://salsa.debian.org/kernel-team/linux/commit/049487d8822c141bef503b024e73db55e2a695ff) but there's no support for runtime power management yet: https://github.com/torvalds/linux/blob/a26fb01c2879ed7026e6cbd78bb701912d249eef/block/blk-core.c#L3765 Unfortunately, the above code doesn't prevent laptop-mode-tools, tlp nor custom udev rules from enabling runtime-pm for devices so if you use any of that, you might be having runtime-pm enabled on devices that don't support it, and therefore get hangs. See https://github.com/rickysarraf/laptop-mode-tools/issues/123 for more details. -- Tomáš Janoušek, a.k.a. Pivník, a.k.a. Liskni_si, http://work.lisk.in/
