Bug#990165: perf: allow using other versions than the running kernel
Package: linux-base Version: 4.6 Severity: normal Tags: patch Hi, The perf wrapper script in Debian requires the perf binary of the running kernel. However, there's not really a good reason for this; perf has a stable ABI, and even though it's distributed and built with the kernel, you can freely mix and match versions (I've done so, a lot). There may still be reasons why people prefer to keep the versions matched, but perf shouldn't just give up and die if it can't find the right version. I've made a patch that makes this a bit more flexible; it first tries to find a matching version, and if it doesn't exist, it simply picks the newest one it can find. (If that's older than the kernel, it gives a warning, since there may be new features the user would want to upgrade for, but it doesn't die.) Hopefully this should be safe, while being a lot less annoying when running a newer or self-compiled kernel. :-) --- linux-base-4.6.orig/bin/perf2018-07-20 03:35:21.0 +0200 +++ linux-base-4.6/bin/perf 2021-06-22 00:15:59.618443368 +0200 @@ -10,9 +10,11 @@ ;; esac shopt -s execfail -exec "perf_$version" "$@" +if [ -x "/usr/bin/perf_$version" ]; then +exec "perf_$version" "$@" +fi -# Not found? Tell the user which package to install. +# Not found? Find out which version to install. case "$version" in 3.* | 4.0 | 4.0.*) package=linux-tools-$version @@ -21,5 +23,16 @@ package=linux-perf-$version ;; esac + +# See if we have a usable alternative available. +perfversion="$( linux-version sort --reverse $( echo /usr/bin/perf_* | sed "s,/usr/bin/perf_,,g" ) | head -n 1 )" +if [ -x "/usr/bin/perf_$perfversion" ]; then +if linux-version compare "$perfversion" lt "$version"; then +echo >&2 "W: perf_$perfversion is older than the running kernel, consider installing $package." +fi +exec "perf_$perfversion" "$@" +fi + +# Still nothing? Tell the user. echo >&2 "E: $package is not installed." exit 1 -- System Information: Debian Release: 11.0 APT prefers stable-debug APT policy: (500, 'stable-debug'), (500, 'testing'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.12.8 (SMP w/40 CPU threads) Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), LANGUAGE=en_NO:en_US:en_GB:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages linux-base depends on: ii debconf [debconf-2.0] 1.5.75 linux-base recommends no packages. linux-base suggests no packages. -- debconf-show failed
Processed: your mail
Processing commands for cont...@bugs.debian.org: > found 983818 5.10.40-1 Bug #983818 [src:linux] linux-image-5.10.0-3-arm64: often fails to bring up eth0 / dwmac_rk module Marked as found in versions linux/5.10.40-1. > thanks Stopping processing here. Please contact me if you need assistance. -- 983818: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983818 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#990106:
Thanks! I installed linux-image-5.9.0-0.bpo.5-amd64 and instantly reproduced the issue. For reference: the amplifier is a Denon AVR-X500. I just purchased a Denon AVR-X1000 as replacement, I will confirm whether the issue is fixed as soon as I receive it. At this point I'm 99% sure it's the amplifier though.
Bug#990123: [buster regression] iptables-netflow-dkms: No more compiles since linux-*-4.19.0-17-*: "implicit declaration of function ‘ref_module’" (Upstream kernel API regression in 4.19.191?)
Control: reassign -1 iptables-netflow-dkms
Control: found -1 2.3-5
Control: notfound -1 2.5.1-2
Hi Salvatore,
Salvatore Bonaccorso wrote:
> On Mon, Jun 21, 2021 at 01:33:01PM +0200, Axel Beckert wrote:
> > Since kernel packages linux-{image,headers}-4.19.0-17-*, at least with
> > -amd64 and -i686-pae, iptables-netflow-dkms no more compiles its kernel
> > module upon kernel installation:
> >
> > In file included from /var/lib/dkms/ipt-netflow/2.3/build/ipt_NETFLOW.c:75:
> > /var/lib/dkms/ipt-netflow/2.3/build/ipt_NETFLOW.c: In function
> > ‘register_ct_events’:
> > /var/lib/dkms/ipt-netflow/2.3/build/compat.h:173:21: error: implicit
> > declaration of function ‘ref_module’; did you mean ‘use_module’?
> > [-Werror=implicit-function-declaration]
> > # define use_module ref_module
> > ^~
> > /var/lib/dkms/ipt-netflow/2.3/build/ipt_NETFLOW.c:5399:3: note: in
> > expansion of macro ‘use_module’
> >use_module(THIS_MODULE, netlink_m);
> >^~
> >
> > Reading the kernel changelog, there are a few very suspicious entries
> > listed under upstream version 4.19.191:
> >
> > - modules: mark ref_module static
> > - modules: mark find_symbol static
> > - modules: mark each_symbol_section static
> >
> > One of the commits above (8745aa4e resp. 7ef5264d) states:
> >
> > ref_module isn't used anywhere outside of module.c.
> >
> > Which is only seems true if you ignore any third-party kernel modules
> > out there.
[…]
> 7ef5264de773 ("modules: mark ref_module static") indeed is likely to
> cause the issue, or basically the patchset around that.
Thanks for that confirmation.
> That initially landed in 5.9-rc1,
Right, I saw that the list of tags including that change on Github. I
though wondered why 2.5.1-2 works in Sid/Bullseye but not on Buster —
but probably because the current #ifdefs just don't expect that fix
being needed for any kernel before 5.9.
> There is some background here:
>
> https://lore.kernel.org/lkml/20200730061027.29472-1-...@lst.de/
> https://lore.kernel.org/stable/ymxnxqzcp0g1f...@kroah.com/
Thanks for that! I didn't really expected license enforcing to be the
background. With that background I do understand that change much
more. :-)
> That said, upstream won't really revert those changes.
Understandable. I'm though surprised that this got backported. But I
guess the pain without it is bigger than this one precise cut.
> So in my biased view, what would be needed for buster indeed would be
> an equivalent approach in buster for iptables-netflow unbreaking this
> regression similar as done in 2.5.1-1 wit the
>
> cherry-pick-adfc6318-fix-compilation-for-5.9-workaround-ref_module-unexport.patch
Thanks for pointing out that this patch is already in 2.5.1-1.
I actually forgot that I had to solve this already once in the past
(probably because the solution was submitted as pull request upstream
against 2.5.1) and since 2.5.1-2 didn't work on buster either, I
didn't expect it to be more or less fixed already. But in the end it's
hopefully just replacing
#if LINUX_VERSION_CODE < KERNEL_VERSION(5,9,0)
with a bit more complex condition including further constraints.
> I had no time to check if the patch applies and what changes need to
> be done,
No need to worry. That's not your job but mine. :-)
> but basically what was added there fo fix compilation with Linux 5.9
> (which introduced the above changes initially) would need as well
> for the 4.19.y stable series.
Ack.
Thanks again.
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
signature.asc
Description: PGP signature
Processed: Re: Bug#990123: [buster regression] iptables-netflow-dkms: No more compiles since linux-*-4.19.0-17-*: "implicit declaration of function ‘ref_module’" (Upstream kernel API regression in 4.1
Processing control commands: > reassign -1 iptables-netflow-dkms Bug #990123 [iptables-netflow-dkms,linux-headers-4.19.0-17-amd64,linux-headers-4.19.0-17-i686-pae] [buster regression] iptables-netflow-dkms: No more compiles since linux-*-4.19.0-17-*: "implicit declaration of function ‘ref_module’" (Upstream kernel API regression in 4.19.191?) Warning: Unknown package 'linux-headers-4.19.0-17-i686-pae' Bug reassigned from package 'iptables-netflow-dkms,linux-headers-4.19.0-17-amd64,linux-headers-4.19.0-17-i686-pae' to 'iptables-netflow-dkms'. No longer marked as found in versions linux/4.19.194-1, iptables-netflow/2.3-5, and iptables-netflow/2.5.1-2. Ignoring request to alter fixed versions of bug #990123 to the same values previously set > found -1 2.3-5 Bug #990123 [iptables-netflow-dkms] [buster regression] iptables-netflow-dkms: No more compiles since linux-*-4.19.0-17-*: "implicit declaration of function ‘ref_module’" (Upstream kernel API regression in 4.19.191?) Marked as found in versions iptables-netflow/2.3-5. > notfound -1 2.5.1-2 Bug #990123 [iptables-netflow-dkms] [buster regression] iptables-netflow-dkms: No more compiles since linux-*-4.19.0-17-*: "implicit declaration of function ‘ref_module’" (Upstream kernel API regression in 4.19.191?) Ignoring request to alter found versions of bug #990123 to the same values previously set -- 990123: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990123 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: reassign 990162 to src:linux
Processing commands for cont...@bugs.debian.org: > reassign 990162 src:linux 5.10.28-1 Bug #990162 [linux-image-5.10.0-6-amd64] power consumption regression Warning: Unknown package 'linux-image-5.10.0-6-amd64' Bug reassigned from package 'linux-image-5.10.0-6-amd64' to 'src:linux'. No longer marked as found in versions linux-signed-amd64/5.10.28+1. Ignoring request to alter fixed versions of bug #990162 to the same values previously set Bug #990162 [src:linux] power consumption regression Marked as found in versions linux/5.10.28-1. > thanks Stopping processing here. Please contact me if you need assistance. -- 990162: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990162 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#990123: [buster regression] iptables-netflow-dkms: No more compiles since linux-*-4.19.0-17-*: "implicit declaration of function ‘ref_module’" (Upstream kernel API regression in 4.19.191?)
Control: affects -1 + release.debian.org
Hi Axel,
On Mon, Jun 21, 2021 at 01:33:01PM +0200, Axel Beckert wrote:
> Package:
> iptables-netflow-dkms,linux-headers-4.19.0-17-amd64,linux-headers-4.19.0-17-i686-pae
> Severity: serious
> Version: iptables-netflow/2.3-5
> Version: iptables-netflow/2.5.1-2
> Version: linux/4.19.194-1
> Tags: buster
> Forwarded: https://github.com/aabc/ipt-netflow/issues/177
>
> Since kernel packages linux-{image,headers}-4.19.0-17-*, at least with
> -amd64 and -i686-pae, iptables-netflow-dkms no more compiles its kernel
> module upon kernel installation:
>
> In file included from /var/lib/dkms/ipt-netflow/2.3/build/ipt_NETFLOW.c:75:
> /var/lib/dkms/ipt-netflow/2.3/build/ipt_NETFLOW.c: In function
> ‘register_ct_events’:
> /var/lib/dkms/ipt-netflow/2.3/build/compat.h:173:21: error: implicit
> declaration of function ‘ref_module’; did you mean ‘use_module’?
> [-Werror=implicit-function-declaration]
> # define use_module ref_module
> ^~
> /var/lib/dkms/ipt-netflow/2.3/build/ipt_NETFLOW.c:5399:3: note: in expansion
> of macro ‘use_module’
>use_module(THIS_MODULE, netlink_m);
>^~
>
> Reading the kernel changelog, there are a few very suspicious entries
> listed under upstream version 4.19.191:
>
> - modules: mark ref_module static
> - modules: mark find_symbol static
> - modules: mark each_symbol_section static
>
> One of the commits above (8745aa4e resp. 7ef5264d) states:
>
> ref_module isn't used anywhere outside of module.c.
>
> Which is only seems true if you ignore any third-party kernel modules
> out there.
>
> So why is the kernel API suddenly removing API-code used by third-party
> modules inmidst a stable update? This looks like a regression to me. I
> thought that stable updates only change the ABI, but not the API. (Well,
> at least upstream and in Debian. :-)
>
> I also tried the iptables-netflow-dkms 2.5.1-2 from Bullseye on Buster,
> but it fails to build the kernel module for 4.19.0-17-* when as well.
>
> 2.5.1-2 though still works fine on Sid/Bullseye, hence marked as found
> in the version in Sid, but tagged buster. In case this causes issues in
> the BTS or the release team scripts, please rather remove 2.5.1-2 from
> the "found" versions instead of removing the buster tag — unless the
> same regression gets introduced into Sid and Bullseye as well.
>
> Debian kernel maintainers: If this 3rd-party-module-breaking regression
> was really intended and won't be fixed, please reassign the bug to
> iptables-netflow-dkms only.
>
> I also reported this issue to iptables-netflow upstream at
> https://github.com/aabc/ipt-netflow/issues/177 as I think it at least
> should update the version based ifdef checks in something which looks
> like a similar issue in kernel 5.13, see
> https://github.com/aabc/ipt-netflow/commit/5aae3791922bd3df878605b15e83ea48a4bd096c
> which is part of iptables-netflow upstream's 2.6 release, not yet
> packaged due to the freeze for bullseye.
>
> I'll try and see if I can get that fix backported to the package in
> buster (and if needed, later to the one in bullseye as well) and will
> see if it actually helps in this case, too.
>
> JFTR: dkms from buster-backports (as reported below) is only installed
> as I needed it for the iptables-netflow-dkms package from bullseye. It
> happened with dkms from buster before as well.
7ef5264de773 ("modules: mark ref_module static") indeed is likely to
cause the issue, or basically the patchset around that. That initially
landed in 5.9-rc1, and recently got backported upstream to 4.19.191.
There is some background here:
https://lore.kernel.org/lkml/20200730061027.29472-1-...@lst.de/
and
https://lore.kernel.org/stable/ymxnxqzcp0g1f...@kroah.com/
That said, upstream won't really revert those changes.
So in my biased view, what would be needed for buster indeed would be
an equivalent approach in buster for iptables-netflow unbreaking this
regression similar as done in 2.5.1-1 wit the
cherry-pick-adfc6318-fix-compilation-for-5.9-workaround-ref_module-unexport.patch
patch.
I had no time to check if the patch applies and what changes need to
be done, but basically what was added there fo fix compilation with
Linux 5.9 (which introduced the above changes initially) would need as
well for the 4.19.y stable series.
Regards,
Salvatore
Processed: Re: Bug#990123: [buster regression] iptables-netflow-dkms: No more compiles since linux-*-4.19.0-17-*: "implicit declaration of function ‘ref_module’" (Upstream kernel API regression in 4.1
Processing control commands: > affects -1 + release.debian.org Bug #990123 [iptables-netflow-dkms,linux-headers-4.19.0-17-amd64,linux-headers-4.19.0-17-i686-pae] [buster regression] iptables-netflow-dkms: No more compiles since linux-*-4.19.0-17-*: "implicit declaration of function ‘ref_module’" (Upstream kernel API regression in 4.19.191?) Warning: Unknown package 'linux-headers-4.19.0-17-i686-pae' Added indication that 990123 affects release.debian.org Warning: Unknown package 'linux-headers-4.19.0-17-i686-pae' -- 990123: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990123 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#990140: upgrade-reports: lxc-attach does not start with apparmor problem after ugrade to 10.10
Hi Paul, thanks for your immediate response. Your assumption is right, booting into kernel 4.19.0-16 causes lxc-attach to behave as expected, no more apparmor related errors. Cheers Bernd Am 21.06.21 um 19:06 schrieb Paul Gevers: Hi Bernd, Thanks for your report. On 21-06-2021 18:04, Bernd Breuer wrote: after the recent upgrade to Buster 10.10 (including a kernel upgrade) the command 'lxc-attach' (out of the Linux Container (lxc) set of commands), typed in like "sudo lxc-attach " stopped working with the error message "lxc-attach: : lsm/lsm.c: lsm_process_label_set_at: 174 Operation not permitted - Failed to set AppArmor label "unconfined" The conainer itself is starting, but apparmor related config lines like "lxc.apparmor.profile = unconfined" produce the above mentioned error, also on another machine after the same packages upgrade. I expect lxc-attach to provide me a root shell in the running lxc-container like it was the case before the recent upgrade. As we didn't upgrade lxc during the point release, this *may* be caused by the updated Linux kernel. What happens if you reboot using the previous kernel? Paul
Processed: duplicate
Processing commands for cont...@bugs.debian.org:
> # try two
> forcemerge 990072 990140
Bug #990072 {Done: Salvatore Bonaccorso } [src:linux]
lxc-attach fails after debian 10.10 update
Bug #990075 {Done: Salvatore Bonaccorso } [src:linux]
lxc-attach fails after debian 10.10 update
Bug #990089 {Done: Salvatore Bonaccorso } [src:linux]
linux-image-4.19.0-17-amd64: lxc-attach fails with Failed to set AppArmor label
unconfined
Bug #990107 {Done: Salvatore Bonaccorso } [src:linux]
linux-image-4.19.0-17-amd64: lxc-attach Operation not permitted - Failed to set
AppArmor label
Bug #990140 [src:linux] upgrade-reports: lxc-attach does not start with
apparmor problem after ugrade to 10.10
Severity set to 'serious' from 'normal'
Marked Bug as done
Added indication that 990140 affects release.debian.org,lxc
Marked as fixed in versions linux/4.19.194-2.
Marked as found in versions linux/4.19.194-1.
Added tag(s) upstream, buster, moreinfo, fixed-upstream, and confirmed.
Bug #990075 {Done: Salvatore Bonaccorso } [src:linux]
lxc-attach fails after debian 10.10 update
Bug #990089 {Done: Salvatore Bonaccorso } [src:linux]
linux-image-4.19.0-17-amd64: lxc-attach fails with Failed to set AppArmor label
unconfined
Bug #990107 {Done: Salvatore Bonaccorso } [src:linux]
linux-image-4.19.0-17-amd64: lxc-attach Operation not permitted - Failed to set
AppArmor label
Merged 990072 990075 990089 990107 990140
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
990072: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990072
990075: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990075
990089: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990089
990107: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990107
990140: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990140
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Processed (with 1 error): duplicate
Processing commands for cont...@bugs.debian.org: > reassign 990140 src:linux Bug #990140 [upgrade-reports] upgrade-reports: lxc-attach does not start with apparmor problem after ugrade to 10.10 Bug reassigned from package 'upgrade-reports' to 'src:linux'. Ignoring request to alter found versions of bug #990140 to the same values previously set Ignoring request to alter fixed versions of bug #990140 to the same values previously set > force-merge 990072 990140 Unknown command or malformed arguments to command. > thanks Stopping processing here. Please contact me if you need assistance. -- 990140: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990140 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Re: Bug#990140: upgrade-reports: lxc-attach does not start with apparmor problem after ugrade to 10.10
Hi Bernd, Thanks for your report. On 21-06-2021 18:04, Bernd Breuer wrote: > after the recent upgrade to Buster 10.10 (including a kernel upgrade) the > command 'lxc-attach' (out of the Linux Container (lxc) set of commands), > typed in like > > "sudo lxc-attach " > > stopped working with the error message > > "lxc-attach: : lsm/lsm.c: lsm_process_label_set_at: 174 > Operation not permitted - Failed to set AppArmor label "unconfined" > > The conainer itself is starting, but apparmor related config lines like > > "lxc.apparmor.profile = unconfined" > > produce the above mentioned error, also on another machine after the > same packages upgrade. > > I expect lxc-attach to provide me a root shell in the running lxc-container > like it was the case before the recent upgrade. As we didn't upgrade lxc during the point release, this *may* be caused by the updated Linux kernel. What happens if you reboot using the previous kernel? Paul OpenPGP_signature Description: OpenPGP digital signature
Any interest in a patch porting Ubuntu's VLAN= cmdline option for Debian initramfs-tools?
Good morning, [I have searched the list archives and the debian bugzilla, but not got any hits on this being discussed already. If it has, apologies, I missed it.] I make extensive use of Debian on single board computers, and have a use case to run them diskless over a VLAN using nbd-server & dnsmasq to provide DHCP, TFTP and NBD. (SDCARDs are impractical due to the maintenance costs due to poor reliability over time in harsh environments.) Unfortunately, the Debian initramfs-tools does not support configuring a VLAN from the kernel command line. I have patched it to add the flag, "vlan=eth0.775:eth0", as Ubuntu ( https://manpages.ubuntu.com/manpages/impish/man7/initramfs-tools.7.html), without some of its ugly s390 compatibility bits. The patch would be small, maybe 10 lines, just to init and scripts/function (+more lines for the documentation). Would this be of interest? If so I'll follow the instructions here: https://salsa.debian.org/kernel-team/initramfs-tools/blob/master/docs/maintainer-notes.md and send you a proper patch. Thanks Matthew Dr. Matthew A. Swabey – Director Bechtel Innovation Design Center, Purdue University, USA Room BIDC 225 | (765) 494-8655 | maswa...@purdue.edu
Processed: found 990123 in iptables-netflow/2.3-5, found 990123 in iptables-netflow/2.5.1-2 ...
Processing commands for cont...@bugs.debian.org: > # Version tracking seems to not have worked properly in the initial bug > submission > found 990123 iptables-netflow/2.3-5 Bug #990123 [iptables-netflow-dkms,linux-headers-4.19.0-17-amd64,linux-headers-4.19.0-17-i686-pae] [buster regression] iptables-netflow-dkms: No more compiles since linux-*-4.19.0-17-*: "implicit declaration of function ‘ref_module’" (Upstream kernel API regression in 4.19.191?) Warning: Unknown package 'linux-headers-4.19.0-17-i686-pae' Marked as found in versions iptables-netflow/2.3-5. Warning: Unknown package 'linux-headers-4.19.0-17-i686-pae' > found 990123 iptables-netflow/2.5.1-2 Bug #990123 [iptables-netflow-dkms,linux-headers-4.19.0-17-amd64,linux-headers-4.19.0-17-i686-pae] [buster regression] iptables-netflow-dkms: No more compiles since linux-*-4.19.0-17-*: "implicit declaration of function ‘ref_module’" (Upstream kernel API regression in 4.19.191?) Warning: Unknown package 'linux-headers-4.19.0-17-i686-pae' Marked as found in versions iptables-netflow/2.5.1-2. Warning: Unknown package 'linux-headers-4.19.0-17-i686-pae' > found 990123 linux/4.19.194-1 Bug #990123 [iptables-netflow-dkms,linux-headers-4.19.0-17-amd64,linux-headers-4.19.0-17-i686-pae] [buster regression] iptables-netflow-dkms: No more compiles since linux-*-4.19.0-17-*: "implicit declaration of function ‘ref_module’" (Upstream kernel API regression in 4.19.191?) Warning: Unknown package 'linux-headers-4.19.0-17-i686-pae' Marked as found in versions linux/4.19.194-1. Warning: Unknown package 'linux-headers-4.19.0-17-i686-pae' > thanks Stopping processing here. Please contact me if you need assistance. -- 990123: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990123 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#990127: mt76x0 crashes repeatedly
Package: firmware-misc-nonfree Version: 20190114-2 kernel module: mt76x0 Severity: serious Following an update recently, this driver stopped working correctly. I can now only get a working WiFi connection for a few seconds after reboot, or after waiting several minutes, making anything that requires the internet almost impossible. This was working fine until the update. Once the interface is up, the driver crashes almost immediately. It does not matter whether I use NetworkManager or do things manually with /etc/network/interfaces and then ifup. The same trace is seen in the logs and dmesg repeatedly. I have ruled out hardware issues. uname -a : Linux hope 4.19.0-16-amd64 #1 SMP Debian 4.19.181-1 (2021-03-19) x86_64 GNU/Linux # modinfo mt76x0 filename: /lib/modules/4.19.0-16-amd64/kernel/drivers/net/wireless/mediatek/mt76/mt76x0/mt76x0.ko license:GPL firmware: mediatek/mt7610u.bin alias: usb:v0E8Dp7650d*dc*dsc*dp*icFFisc02ipFFin* alias: usb:v0E8Dp7630d*dc*dsc*dp*icFFisc02ipFFin* alias: usb:v2357p0105d*dc*dsc*dp*ic*isc*ip*in* alias: usb:v0DF6p0079d*dc*dsc*dp*ic*isc*ip*in* alias: usb:v7392pC711d*dc*dsc*dp*ic*isc*ip*in* alias: usb:v20F4p806Bd*dc*dsc*dp*ic*isc*ip*in* alias: usb:v293Cp5702d*dc*dsc*dp*ic*isc*ip*in* alias: usb:v057Cp8502d*dc*dsc*dp*ic*isc*ip*in* alias: usb:v04BBp0951d*dc*dsc*dp*ic*isc*ip*in* alias: usb:v07B8p7610d*dc*dsc*dp*ic*isc*ip*in* alias: usb:v0586p3425d*dc*dsc*dp*ic*isc*ip*in* alias: usb:v2001p3D02d*dc*dsc*dp*ic*isc*ip*in* alias: usb:v2019pAB31d*dc*dsc*dp*ic*isc*ip*in* alias: usb:v0DF6p0075d*dc*dsc*dp*ic*isc*ip*in* alias: usb:v0B05p17DBd*dc*dsc*dp*ic*isc*ip*in* alias: usb:v0B05p17D1d*dc*dsc*dp*ic*isc*ip*in* alias: usb:v148Fp760Ad*dc*dsc*dp*ic*isc*ip*in* alias: usb:v148Fp761Ad*dc*dsc*dp*ic*isc*ip*in* alias: usb:v7392pB711d*dc*dsc*dp*ic*isc*ip*in* alias: usb:v7392pA711d*dc*dsc*dp*ic*isc*ip*in* alias: usb:v0E8Dp7610d*dc*dsc*dp*ic*isc*ip*in* alias: usb:v13B1p003Ed*dc*dsc*dp*ic*isc*ip*in* alias: usb:v148Fp7610d*dc*dsc*dp*ic*isc*ip*in* depends:mac80211,mt76,cfg80211,usbcore retpoline: Y intree: Y name: mt76x0 vermagic: 4.19.0-16-amd64 SMP mod_unload modversions sig_id: PKCS#7 signer: Debian Secure Boot CA sig_key:4B:6E:F5:AB:CA:66:98:25:17:8E:05:2C:84:66:7C:CB:C0:53:1F:8C sig_hashalgo: sha256 signature: 58:62:E3:A8:7F:B6:04:24:F1:68:8E:F0:B1:AF:0B:34:8A:66:2D:A1: 59:54:49:75:B2:52:7F:FF:5D:6B:34:C5:D6:9F:5E:51:33:C3:57:BE: 38:8C:24:36:D7:C4:BE:1C:2F:62:FC:9C:A1:37:5C:04:17:59:57:0B: 35:A5:6A:9A:2B:1B:3F:D1:E3:78:CD:50:72:8E:8B:2B:3B:FF:DE:2A: FC:8A:F6:A1:BF:FE:2B:52:8D:F8:6D:4D:73:2E:D6:09:5D:4A:EB:11: D4:26:89:78:77:D9:BB:04:E6:C4:9A:5A:35:8E:1A:14:BA:84:D7:BF: 97:AB:0F:5F:A7:3E:D0:DF:DD:E2:75:F1:9E:2C:2A:48:09:AD:FF:D1: 9C:9E:61:45:44:D2:2E:DD:CE:7E:C8:96:D5:F7:A1:82:CA:33:F9:87: 5A:C8:FB:30:2B:36:45:12:2C:21:E4:23:CD:02:C5:69:93:B4:7E:A9: FD:BF:A0:CA:A2:A7:FD:B5:F1:CC:C8:F2:44:A1:23:33:C0:32:3A:B6: 2E:6A:27:B8:C7:86:91:30:4A:E5:AC:14:51:50:B0:89:09:BC:31:EB: E4:F3:27:51:63:10:29:A0:BB:3C:94:21:33:BE:0C:C7:47:56:08:BC: 4F:A2:FF:38:FF:D5:4C:DF:2C:A8:64:94:3D:6E:F3:6D # Relevant extract from dmesg: [ 996.874969] mt76x0 1-5:1.0: Error: send MCU cmd failed:-71 [ 996.875010] mt76x0 1-5:1.0: Error: MCU response pre-completed! [ 996.885414] mt76x0 1-5:1.0: Error: send MCU cmd failed:-71 [ 997.007009] mt76x0 1-5:1.0: Vendor request req:07 off:1798 failed:-71 [ 997.275141] mt76x0 1-5:1.0: Vendor request req:07 off:1718 failed:-71 [ 997.275154] [ cut here ] [ 997.275202] WARNING: CPU: 1 PID: 147 at drivers/net/wireless/mediatek/mt76/mt76x0/mac.c:55 mt76_mac_fill_tx_status.isra.2+0x29e/0x2e0 [mt76x0] [ 997.275203] Modules linked in: arc4 mt76x0 mt76 mac80211 cfg80211 bnep nfnetlink_queue nfnetlink_log bluetooth drbg ansi_cprng ecdh_generic cpufreq_powersave cpufreq_conservative cpufreq_userspace zram zsmalloc nf_log_ipv6 nf_log_ipv4 nf_log_common nft_limit nft_counter xt_LOG xt_limit ipt_REJECT nf_reject_ipv4 xt_tcpudp xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_multiport nft_compat nf_tables nfnetlink binfmt_misc edac_mce_amd snd_hda_codec_realtek kvm_amd snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_intel snd_hda_codec ccp snd_hda_core rng_core snd_hwdep kvm eeepc_wmi joydev asus_wmi snd_pcm snd_timer sparse_keymap sg snd rfkill irqbypass soundcore wmi_bmof pcspkr sp5100_tco k10temp evdev pcc_cpufreq acpi_cpufreq cuse fuse it87 hwmon_vid parport_pc ppdev lp parport ip_tables [ 997.275240] x_tables autofs4 ext4 crc16 mbcache jbd2 fscrypto ecb
linux_4.19.194-2_source.changes ACCEPTED into proposed-updates->stable-new, proposed-updates
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 21 Jun 2021 10:46:20 +0200 Source: linux Architecture: source Version: 4.19.194-2 Distribution: buster Urgency: medium Maintainer: Debian Kernel Team Changed-By: Salvatore Bonaccorso Closes: 990072 Changes: linux (4.19.194-2) buster; urgency=medium . * proc: Track /proc/$pid/attr/ opener mm_struct (Closes: #990072) Checksums-Sha1: 197a08de95c8661cdb7c14713b0a4fc165a41fb5 191615 linux_4.19.194-2.dsc eb08a00d3ed97ef32d59a46aa3c1224133764a6d 3377504 linux_4.19.194-2.debian.tar.xz 1f61d4c822b5f77c75425eec1a786d9f864871e4 6228 linux_4.19.194-2_source.buildinfo Checksums-Sha256: e759f51d7cc10c866bf795d051971bbbea7c2a886cc93c49a58ed1c1af0e5d69 191615 linux_4.19.194-2.dsc 770c22a92b290c2e8a890ac601f3e5c4315c82caea23df1b8f52ddfba6a81d22 3377504 linux_4.19.194-2.debian.tar.xz f12f2297dc47c399b77df462cc1d15e4e5df63aed2aa6e0a92ddccba5ec10439 6228 linux_4.19.194-2_source.buildinfo Files: 61bf3b824d9a8bcffac3fb89dca7a9ae 191615 kernel optional linux_4.19.194-2.dsc f5b16a9030ba3519efd4b6f515cb1cef 3377504 kernel optional linux_4.19.194-2.debian.tar.xz 4615001c65912a634283b5bfae1b872d 6228 kernel optional linux_4.19.194-2_source.buildinfo -BEGIN PGP SIGNATURE- iQKmBAEBCgCQFiEERkRAmAjBceBVMd3uBUy48xNDz0QFAmDQUoxfFIAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDQ2 NDQ0MDk4MDhDMTcxRTA1NTMxRERFRTA1NENCOEYzMTM0M0NGNDQSHGNhcm5pbEBk ZWJpYW4ub3JnAAoJEAVMuPMTQ89Ej8YQAJnwb2gKzmax4KkIqjxViZfmKOTu2GVe YbsXcB8cQqBhZEvA+KKQ+FpmvyNM0qP1QvO0FhEWCY9DHP3IEXjgeMyPLkhAFE2L KHpw4vLtpUr/a/VcTmgkYb3/z+/OODxo/YF+/3M4GZrTJnSMZhmrMqm0K3m0nHer QmvEKtSPbkLAUjZ+aqqsGFLBmV/tL7EAWtdlLWWQUgDJQPH1o8FQ/ZdECcCVUAf2 EHLgI8frO6nI7T7q8AujfBxped3tbqUQtNXHqEpTyfccHy5HylE1NssTGEPTUFfJ 1zTbN+qGlKxw/6a0s3kx32qARCmBwAih0mO13BxYz5m5w2MVYOgUmlEOiv0YbgaU 9KNnEN43hdzHRA4VHlWRdShCexOt0eL+jOnvewqHcdgv8nsIKLugyWBqH1uHOOP/ Ghog68DsiGkEz5ppc8Cp8vc45fSzEpImTuNEAh6Y2EHhymIHDoR+PfhSGQZHHef2 1DUG8v+AksSw9eb1yIiiWKAvvCqPuFYVtHFbPmxr3MFtb1eV3Z5qVtsqyv9Rs2JG oI9fdDfI9bGI1CplqJhKJI61YWlHv+gK5T7XiS5DvZACQWvoHvZvKSRtcqQMJb2O Rmsqg0ImvqP47ALglk2B6jVU+1+c6Ji0LO2Lf6Xdk54JdPYvJD1fLzhU2LDBrrHk SZ5k/UuWx+Si =PBMw -END PGP SIGNATURE- Thank you for your contribution to Debian.
Bug#990107: marked as done (linux-image-4.19.0-17-amd64: lxc-attach Operation not permitted - Failed to set AppArmor label)
Your message dated Mon, 21 Jun 2021 12:02:07 +
with message-id
and subject line Bug#990072: fixed in linux 4.19.194-2
has caused the Debian Bug report #990072,
regarding linux-image-4.19.0-17-amd64: lxc-attach Operation not permitted -
Failed to set AppArmor label
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
990072: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990072
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: src:linux
Version: 4.19.194-1
Severity: normal
Since upgrading to linux-image-4.19.0-17-amd64 from
linux-image-4.19.0-16-amd64, I can no longer enter my lxc container with
the command 'lxc-attach'. It fails with the message:
lxc-attach: shire: lsm/lsm.c: lsm_process_label_set_at: 174 Operation
not permitted - Failed to set AppArmor label
"lxc-shire_//&:lxc-shire_<-var-lib-lxc>:
unconfined"
Reverting to linux-image-4.19.0-16-amd64 version 4.19.181-1 (the
previous kernel) fixes the issue.
The lxc config for this container is the following:
lxc.include = /usr/share/lxc/config/common.conf
lxc.include = /usr/share/lxc/config/userns.conf
lxc.arch = linux64
lxc.apparmor.profile = generated
lxc.apparmor.allow_nesting = 1
lxc.idmap = u 0 10 90
lxc.idmap = g 0 10 90
lxc.rootfs.path = dir:/var/lib/lxc/shire/rootfs
lxc.uts.name = shire
lxc.net.0.type = empty
lxc.mount.entry=/data/home home none bind 0 0
lxc.mount.entry=/data/mail var/mail none bind 0 0
And the auto-generated AppArmor profile:
#include
profile "lxc-shire_"
flags=(attach_disconnected,mediate_deleted) {
### Base profile
capability,
dbus,
file,
network,
umount,
# Allow us to receive signals from anywhere.
signal (receive),
# Allow us to send signals to ourselves
signal peer=@{profile_name},
# Allow other processes to read our /proc entries, futexes, perf
tracing and
# kcmp for now (they will need 'read' in the first place).
Administrators can
# override with:
# deny ptrace (readby) ...
ptrace (readby),
# Allow other processes to trace us by default (they will need 'trace' in
# the first place). Administrators can override with:
# deny ptrace (tracedby) ...
ptrace (tracedby),
# Allow us to ptrace ourselves
ptrace peer=@{profile_name},
# ignore DENIED message on / remount
deny mount options=(ro, remount) -> /,
deny mount options=(ro, remount, silent) -> /,
# allow tmpfs mounts everywhere
mount fstype=tmpfs,
# allow hugetlbfs mounts everywhere
mount fstype=hugetlbfs,
# allow mqueue mounts everywhere
mount fstype=mqueue,
# allow fuse mounts everywhere
mount fstype=fuse,
mount fstype=fuse.*,
# deny access under /proc/bus to avoid e.g. messing with pci devices
directly
deny @{PROC}/bus/** wklx,
# deny writes in /proc/sys/fs but allow binfmt_misc to be mounted
mount fstype=binfmt_misc -> /proc/sys/fs/binfmt_misc/,
deny @{PROC}/sys/fs/** wklx,
# allow efivars to be mounted, writing to it will be blocked though
mount fstype=efivarfs -> /sys/firmware/efi/efivars/,
# block some other dangerous paths
deny @{PROC}/kcore rwklx,
deny @{PROC}/sysrq-trigger rwklx,
# deny writes in /sys except for /sys/fs/cgroup, also allow
# fusectl, securityfs and debugfs to be mounted there (read-only)
mount fstype=fusectl -> /sys/fs/fuse/connections/,
mount fstype=securityfs -> /sys/kernel/security/,
mount fstype=debugfs -> /sys/kernel/debug/,
deny mount fstype=debugfs -> /var/lib/ureadahead/debugfs/,
mount fstype=proc -> /proc/,
mount fstype=sysfs -> /sys/,
mount options=(rw, nosuid, nodev, noexec, remount) -> /sys/,
deny /sys/firmware/efi/efivars/** rwklx,
# note, /sys/kernel/security/** handled below
mount options=(ro, nosuid, nodev, noexec, remount, strictatime) ->
/sys/fs/cgroup/,
# deny reads from debugfs
deny /sys/kernel/debug/{,**} rwklx,
# allow paths to be made slave, shared, private or unbindable
# FIXME: This currently doesn't work due to the apparmor parser
treating those as allowing all mounts.
# mount options=(rw,make-slave) -> **,
# mount options=(rw,make-rslave) -> **,
# mount options=(rw,make-shared) -> **,
# mount options=(rw,make-rshared) -> **,
# mount options=(rw,make-private) -> **,
# mount options=(rw,make-rprivate) -> **,
# mount options=(rw,make-unbindable) -> **,
# mount options=(rw,make-runbindable) -> **,
# allow bind-mounts of anything except /proc, /sys and /dev
mount options=(rw,bind) /[^spd]*{,/**},
mount options=(rw,bind) /d[^e]*{,/**},
mount options=(rw,bind) /de[^v]*{,/**},
mount options=(rw,bin
Bug#990089: marked as done (linux-image-4.19.0-17-amd64: lxc-attach fails with Failed to set AppArmor label unconfined)
Your message dated Mon, 21 Jun 2021 12:02:07 + with message-id and subject line Bug#990072: fixed in linux 4.19.194-2 has caused the Debian Bug report #990072, regarding linux-image-4.19.0-17-amd64: lxc-attach fails with Failed to set AppArmor label unconfined to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 990072: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990072 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: src:linux Version: 4.19.194-1 Severity: normal Dear Maintainer, After upgrading from linux-image-4.19.0-16-amd64 to linux-image-4.19.0-17-amd64 attaching an unprivileged linux container fails with the message: lxc-attach: debian-buster-amd64-basic: lsm/lsm.c: lsm_process_label_set_at: 174 Operation not permitted - Failed to set AppArmor label "unconfined" Rebooting into linux-image-4.19.0-16-amd64 with no other changes, the lxc system works as expected. Regrads, Mark Grant -- Package-specific info: ** Version: Linux version 4.19.0-17-amd64 (debian-kernel@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.194-1 (2021-06-10) ** Command line: BOOT_IMAGE=/vmlinuz-4.19.0-17-amd64 root=/dev/mapper/priam--vg-root ro ** Not tainted ** Kernel log: [ 14.211487] snd_hda_codec_realtek hdaudioC0D0: Rear Mic=0x18 [ 14.211554] snd_hda_codec_realtek hdaudioC0D0: Line=0x1a [ 14.351839] input: HDA Intel PCH Front Mic as /devices/pci:00/:00:1f.3/sound/card0/input10 [ 14.351896] input: HDA Intel PCH Rear Mic as /devices/pci:00/:00:1f.3/sound/card0/input11 [ 14.351941] input: HDA Intel PCH Line as /devices/pci:00/:00:1f.3/sound/card0/input12 [ 14.351981] input: HDA Intel PCH Line Out as /devices/pci:00/:00:1f.3/sound/card0/input13 [ 14.352023] input: HDA Intel PCH Front Headphone as /devices/pci:00/:00:1f.3/sound/card0/input14 [ 14.352071] input: HDA Intel PCH HDMI/DP,pcm=3 as /devices/pci:00/:00:1f.3/sound/card0/input15 [ 14.352116] input: HDA Intel PCH HDMI/DP,pcm=7 as /devices/pci:00/:00:1f.3/sound/card0/input16 [ 14.352164] input: HDA Intel PCH HDMI/DP,pcm=8 as /devices/pci:00/:00:1f.3/sound/card0/input17 [ 14.352214] input: HDA Intel PCH HDMI/DP,pcm=9 as /devices/pci:00/:00:1f.3/sound/card0/input18 [ 14.352257] input: HDA Intel PCH HDMI/DP,pcm=10 as /devices/pci:00/:00:1f.3/sound/card0/input19 [ 14.562406] EXT4-fs (dm-2): mounted filesystem with ordered data mode. Opts: errors=remount-ro [ 14.743100] EXT4-fs (sda1): mounting ext2 file system using the ext4 subsystem [ 14.815334] EXT4-fs (sda1): mounted filesystem without journal. Opts: (null) [ 15.862180] audit: type=1400 audit(1624175633.583:2): apparmor="STATUS" operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=651 comm="apparmor_parser" [ 15.864947] audit: type=1400 audit(1624175633.583:3): apparmor="STATUS" operation="profile_load" profile="unconfined" name="nvidia_modprobe//kmod" pid=651 comm="apparmor_parser" [ 15.876271] audit: type=1400 audit(1624175633.595:4): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/bin/man" pid=650 comm="apparmor_parser" [ 15.879040] audit: type=1400 audit(1624175633.595:5): apparmor="STATUS" operation="profile_load" profile="unconfined" name="man_filter" pid=650 comm="apparmor_parser" [ 15.881633] audit: type=1400 audit(1624175633.595:6): apparmor="STATUS" operation="profile_load" profile="unconfined" name="man_groff" pid=650 comm="apparmor_parser" [ 15.916140] audit: type=1400 audit(1624175633.635:7): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/bin/lxc-start" pid=654 comm="apparmor_parser" [ 15.920983] audit: type=1400 audit(1624175633.639:8): apparmor="STATUS" operation="profile_load" profile="unconfined" name="virt-aa-helper" pid=649 comm="apparmor_parser" [ 15.972116] audit: type=1400 audit(1624175633.691:9): apparmor="STATUS" operation="profile_load" profile="unconfined" name="lxc-container-default" pid=659 comm="apparmor_parser" [ 15.975071] audit: type=1400 audit(1624175633.691:10): apparmor="STATUS" operation="profile_load" profile="unconfined" name="lxc-container-default-cgns" pid=659 comm="apparmor_parser" [ 15.977826] audit: type=1400 audit(1624175633.691:11): apparmor="STATUS" operation="profile_load" profile="unconfined" name="lxc-container-default-with-mounting" pid=659 comm="apparmor_parser" [ 16.845248] usb 1-8: reset high-speed USB device number 3 using xhci_hcd [ 17.604508] new mount o
Bug#990072: marked as done (lxc-attach fails after debian 10.10 update)
Your message dated Mon, 21 Jun 2021 12:02:07 + with message-id and subject line Bug#990072: fixed in linux 4.19.194-2 has caused the Debian Bug report #990072, regarding lxc-attach fails after debian 10.10 update to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 990072: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990072 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: lxc Version: 1:3.1.0+really3.0.3-8 Severity: grave Justification: renders package unusable Dear Maintainer, Applied latest apt updates (debian 10.10) and rebooted. After reboot, lxc-attach doesn't work. from /var/log/apt/history.log: Start-Date: 2021-06-19 12:27:42 Commandline: apt-get dist-upgrade Requested-By: matthew (1011) Install: linux-headers-4.19.0-17-common:amd64 (4.19.194-1, automatic), linux-headers-4.19.0-17-amd64:amd64 (4.19.194-1, automatic), linux-image-4.19.0-17-amd64:amd64 (4.19.194-1, automatic) Upgrade: libapt-inst2.0:amd64 (1.8.2.2, 1.8.2.3), apt:amd64 (1.8.2.2, 1.8.2.3), mariadb-common:amd64 (1:10.3.27-0+deb10u1, 1:10.3.29-0+deb10u1), linux-compiler-gcc-8-x86:amd64 (4.19.181-1, 4.19.194-1), libklibc:amd64 (2.0.6-1, 2.0.6-1+deb10u1), libcpupower1:amd64 (4.19.181-1, 4.19.194-1), libapt-pkg5.0:amd64 (1.8.2.2, 1.8.2.3), shim-helpers-amd64-signed:amd64 (1+15+1533136590.3beb971+7+deb10u1, 1+15.4+5~deb10u1), linux-image-amd64:amd64 (4.19+105+deb10u11, 4.19+105+deb10u12), libgcrypt20:amd64 (1.8.4-5, 1.8.4-5+deb10u1), linux-headers-amd64:amd64 (4.19+105+deb10u11, 4.19+105+deb10u12), libhogweed4:amd64 (3.4.1-1, 3.4.1-1+deb10u1), apt-utils:amd64 (1.8.2.2, 1.8.2.3), shim-unsigned:amd64 (15+1533136590.3beb971-7+deb10u1, 15.4-5~deb10u1), shim-signed:amd64 (1.33+15+1533136590.3beb971-7, 1.36~1+deb10u1+15.4-5~deb10u1), libnettle6:amd64 (3.4.1-1, 3.4.1-1+deb10u1), libxml2:amd64 (2.9.4+dfsg1-7+deb10u1, 2.9.4+dfsg1-7+deb10u2), libmariadb3:amd64 (1:10.3.27-0+deb10u1, 1:10.3.29-0+deb10u1), libgnutls30:amd64 (3.6.7-4+deb10u6, 3.6.7-4+deb10u7), linux-kbuild-4.19:amd64 (4.19.181-1, 4.19.194-1), klibc-utils:amd64 (2.0.6-1, 2.0.6-1+deb10u1), libglib2.0-0:amd64 (2.58.3-2+deb10u2, 2.58.3-2+deb10u3), shim-signed-common:amd64 (1.33+15+1533136590.3beb971-7, 1.36~1+deb10u1+15.4-5~deb10u1), linux-cpupower:amd64 (4.19.181-1, 4.19.194-1), base-files:amd64 (10.3+deb10u9, 10.3+deb10u10) End-Date: 2021-06-19 12:29:41 $ lxc-attach mar-mon1 lxc-attach: mar-mon1: lsm/lsm.c: lsm_process_label_set_at: 174 Operation not permitted - Failed to set AppArmor label "lxc-mar-mon1_//&:lxc-mar-mon1_<-var-lib-lxc>:unconfined" The lxc-config file contains lxc.apparmor.profile = generated lxc.apparmor.allow_nesting = 1 The generated apparmor seems unchanged when I compare it to containers on a server I didn't reboot. I did reboot 2 servers after this debian update, and both have this problem. -- System Information: Debian Release: 10.10 APT prefers stable APT policy: (500, 'stable'), (90, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-17-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_UNSIGNED_MODULE 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 /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lxc depends on: ii debconf [debconf-2.0] 1.5.71 ii libc6 2.28-10 ii libcap21:2.25-2 ii libgnutls303.6.7-4+deb10u7 ii liblxc11:3.1.0+really3.0.3-8 ii libseccomp22.3.3-4 ii libselinux12.8-1+b1 ii lsb-base 10.2019051400 Versions of packages lxc recommends: ii apparmor 2.13.2-10 ii bridge-utils 1.6-2 pn debootstrap ii dirmngr2.2.12-1+deb10u1 pn dnsmasq-base ii gnupg 2.2.12-1+deb10u1 ii iproute2 4.20.0-2+deb10u1 ii iptables 1.8.2-4 pn libpam-cgfs pn lxc-templates ii lxcfs 3.0.3-2 ii openssl1.1.1d-0+deb10u6 pn rsync pn uidmap Versions of packages lxc suggests: pn btrfs-progs pn lvm2 pn python3-lxc -- debconf information excluded --- End Message --- --- Begin Message --- Source: linux Source-Version: 4.19.194-2 Done: Salvatore Bonaccorso We believe that the bug you reported is fixed in the latest version of linux, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments ple
Bug#990075: marked as done (lxc-attach fails after debian 10.10 update)
Your message dated Mon, 21 Jun 2021 12:02:07 + with message-id and subject line Bug#990072: fixed in linux 4.19.194-2 has caused the Debian Bug report #990072, regarding lxc-attach fails after debian 10.10 update to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 990072: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990072 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: lxc Version: 1:3.1.0+really3.0.3-8 Severity: grave Justification: renders package unusable Dear Maintainer, Applied latest apt updates (debian 10.10) and rebooted. After reboot, lxc-attach doesn't work. from /var/log/apt/history.log: Start-Date: 2021-06-19 12:27:42 Commandline: apt-get dist-upgrade Requested-By: matthew (1011) Install: linux-headers-4.19.0-17-common:amd64 (4.19.194-1, automatic), linux-headers-4.19.0-17-amd64:amd64 (4.19.194-1, automatic), linux-image-4.19.0-17-amd64:amd64 (4.19.194-1, automatic) Upgrade: libapt-inst2.0:amd64 (1.8.2.2, 1.8.2.3),apt:amd64 (1.8.2.2, 1.8.2.3), mariadb-common:amd64 (1:10.3.27-0+deb10u1, 1:10.3.29-0+deb10u1), linux-compiler-gcc-8-x86:amd64 (4.19.181-1, 4.19.194-1), libklibc:amd64 (2.0.6-1, 2.0.6-1+deb10u1), libcpupower1:amd64 (4.19.181-1, 4.19.194-1), libapt-pkg5.0:amd64 (1.8.2.2, 1.8.2.3), shim-helpers-amd64-signed:amd64 (1+15+1533136590.3beb971+7+deb10u1, 1+15.4+5~deb10u1), linux-image-amd64:amd64 (4.19+105+deb10u11, 4.19+105+deb10u12), libgcrypt20:amd64 (1.8.4-5, 1.8.4-5+deb10u1), linux-headers-amd64:amd64 (4.19+105+deb10u11, 4.19+105+deb10u12), libhogweed4:amd64 (3.4.1-1, 3.4.1-1+deb10u1), apt-utils:amd64 (1.8.2.2, 1.8.2.3), shim-unsigned:amd64 (15+1533136590.3beb971-7+deb10u1, 15.4-5~deb10u1), shim-signed:amd64 (1.33+15+1533136590.3beb971-7, 1.36~1+deb10u1+15.4-5~deb10u1), libnettle6:amd64 (3.4.1-1, 3.4.1-1+deb10u1), libxml2:amd64 (2.9.4+dfsg1-7+deb10u1, 2.9.4+dfsg1-7+deb10u2), libmariadb3:amd64 (1:10.3.27-0+deb10u1, 1:10.3.29-0+deb10u1), libgnutls30:amd64 (3.6.7-4+deb10u6, 3.6.7-4+deb10u7), linux-kbuild-4.19:amd64 (4.19.181-1, 4.19.194-1), klibc-utils:amd64 (2.0.6-1, 2.0.6-1+deb10u1), libglib2.0-0:amd64 (2.58.3-2+deb10u2, 2.58.3-2+deb10u3), shim-signed-common:amd64 (1.33+15+1533136590.3beb971-7, 1.36~1+deb10u1+15.4-5~deb10u1), linux-cpupower:amd64 (4.19.181-1, 4.19.194-1), base-files:amd64 (10.3+deb10u9, 10.3+deb10u10) End-Date: 2021-06-19 12:29:41 $ lxc-attach mar-mon1 lxc-attach: mar-mon1: lsm/lsm.c: lsm_process_label_set_at: 174 Operation not permitted - Failed to set AppArmor label "lxc-mar-mon1_//&:lxc-mar-mon1_<-var-lib-lxc>:unconfined" The lxc-config file contains lxc.apparmor.profile = generated lxc.apparmor.allow_nesting = 1 The generated apparmor seems unchanged when I compare it to containers on a server I didn't reboot. I did reboot 2 servers after this debian update, and both have this problem. -- System Information: Debian Release: 10.10 APT prefers stable APT policy: (500, 'stable'), (90, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-17-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_UNSIGNED_MODULE 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 /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lxc depends on: ii debconf [debconf-2.0] 1.5.71 ii libc6 2.28-10 ii libcap21:2.25-2 ii libgnutls303.6.7-4+deb10u7 ii liblxc11:3.1.0+really3.0.3-8 ii libseccomp22.3.3-4 ii libselinux12.8-1+b1 ii lsb-base 10.2019051400 Versions of packages lxc recommends: ii apparmor 2.13.2-10 ii bridge-utils 1.6-2 pn debootstrap ii dirmngr2.2.12-1+deb10u1 pn dnsmasq-base ii gnupg 2.2.12-1+deb10u1 ii iproute2 4.20.0-2+deb10u1 ii iptables 1.8.2-4 pn libpam-cgfs pn lxc-templates ii lxcfs 3.0.3-2 ii openssl1.1.1d-0+deb10u6 pn rsync pn uidmap Versions of packages lxc suggests: pn btrfs-progs pn lvm2 pn python3-lxc --- End Message --- --- Begin Message --- Source: linux Source-Version: 4.19.194-2 Done: Salvatore Bonaccorso We believe that the bug you reported is fixed in the latest version of linux, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 990...@bugs.d
Bug#982270: Re Bug#982270 (installer can not find an ehternet driver for CuBox-i4Pro)
> Pushed a fix to git: > > https://salsa.debian.org/kernel-team/linux/-/commit/f952b94621847732b3ed96a74babb89b6a1862f6 Wow! Thanks! At least I now know I'm not crazy... Any idea how long it will be before the fix is in something I can download and install with? Enjoy! Rick
Bug#883194: please convert mountstats and nfsiostat scripts to Python3
On maandag 21 juni 2021 13:20:46 CEST Drew Parsons wrote: > I was surprised to see python2 pulled in on a new bullseye > installation using nfs. > > It's a trivial patch of course to update the hashbangs for mountstats > and nfsiostat in nfs-common 1:1.3.4-5 to python3. https://salsa.debian.org/kernel-team/nfs-utils/-/merge_requests/4 has been submitted 9 months ago, which does exactly that. signature.asc Description: This is a digitally signed message part.
Bug#990123: [buster regression] iptables-netflow-dkms: No more compiles since linux-*-4.19.0-17-*: "implicit declaration of function ‘ref_module’" (Upstream kernel API regression in 4.19.191?)
Package:
iptables-netflow-dkms,linux-headers-4.19.0-17-amd64,linux-headers-4.19.0-17-i686-pae
Severity: serious
Version: iptables-netflow/2.3-5
Version: iptables-netflow/2.5.1-2
Version: linux/4.19.194-1
Tags: buster
Forwarded: https://github.com/aabc/ipt-netflow/issues/177
Since kernel packages linux-{image,headers}-4.19.0-17-*, at least with
-amd64 and -i686-pae, iptables-netflow-dkms no more compiles its kernel
module upon kernel installation:
In file included from /var/lib/dkms/ipt-netflow/2.3/build/ipt_NETFLOW.c:75:
/var/lib/dkms/ipt-netflow/2.3/build/ipt_NETFLOW.c: In function
‘register_ct_events’:
/var/lib/dkms/ipt-netflow/2.3/build/compat.h:173:21: error: implicit
declaration of function ‘ref_module’; did you mean ‘use_module’?
[-Werror=implicit-function-declaration]
# define use_module ref_module
^~
/var/lib/dkms/ipt-netflow/2.3/build/ipt_NETFLOW.c:5399:3: note: in expansion of
macro ‘use_module’
use_module(THIS_MODULE, netlink_m);
^~
Reading the kernel changelog, there are a few very suspicious entries
listed under upstream version 4.19.191:
- modules: mark ref_module static
- modules: mark find_symbol static
- modules: mark each_symbol_section static
One of the commits above (8745aa4e resp. 7ef5264d) states:
ref_module isn't used anywhere outside of module.c.
Which is only seems true if you ignore any third-party kernel modules
out there.
So why is the kernel API suddenly removing API-code used by third-party
modules inmidst a stable update? This looks like a regression to me. I
thought that stable updates only change the ABI, but not the API. (Well,
at least upstream and in Debian. :-)
I also tried the iptables-netflow-dkms 2.5.1-2 from Bullseye on Buster,
but it fails to build the kernel module for 4.19.0-17-* when as well.
2.5.1-2 though still works fine on Sid/Bullseye, hence marked as found
in the version in Sid, but tagged buster. In case this causes issues in
the BTS or the release team scripts, please rather remove 2.5.1-2 from
the "found" versions instead of removing the buster tag — unless the
same regression gets introduced into Sid and Bullseye as well.
Debian kernel maintainers: If this 3rd-party-module-breaking regression
was really intended and won't be fixed, please reassign the bug to
iptables-netflow-dkms only.
I also reported this issue to iptables-netflow upstream at
https://github.com/aabc/ipt-netflow/issues/177 as I think it at least
should update the version based ifdef checks in something which looks
like a similar issue in kernel 5.13, see
https://github.com/aabc/ipt-netflow/commit/5aae3791922bd3df878605b15e83ea48a4bd096c
which is part of iptables-netflow upstream's 2.6 release, not yet
packaged due to the freeze for bullseye.
I'll try and see if I can get that fix backported to the package in
buster (and if needed, later to the one in bullseye as well) and will
see if it actually helps in this case, too.
JFTR: dkms from buster-backports (as reported below) is only installed
as I needed it for the iptables-netflow-dkms package from bullseye. It
happened with dkms from buster before as well.
-- System Information:
Debian Release: 10.10
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 'stable'),
(400, 'proposed-updates-debug'), (400, 'proposed-updates')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-12-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled
Versions of packages iptables-netflow-dkms depends on:
ii dkms2.8.4-3~bpo10+1
ii libc6 2.28-10
ii libc6-dev 2.28-10
ii libxtables-dev 1.8.2-4
ii pkg-config 0.29-6
Versions of packages iptables-netflow-dkms recommends:
ii iptables 1.8.2-4
Versions of packages iptables-netflow-dkms suggests:
ii irqtop 2.3-5
ii nfdump 1.6.17-1
-- no debconf information
Bug#883194: please convert mountstats and nfsiostat scripts to Python3
Package: nfs-common Followup-For: Bug #883194 X-Debbugs-Cc: debian-rele...@lists.debian.org I was surprised to see python2 pulled in on a new bullseye installation using nfs. It's a trivial patch of course to update the hashbangs for mountstats and nfsiostat in nfs-common 1:1.3.4-5 to python3. As far as I can see the scripts are python3 compatible. Upstream history at http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=history;f=tools/mountstats/mountstats.py;hb=d1683f356bd920d93f2db007902b2c46f97a2e49 http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=history;f=tools/nfs-iostat/nfs-iostat.py;hb=d1683f356bd920d93f2db007902b2c46f97a2e49 indicates the scripts were patched in July 2014 to work with python3 Should Bug#883194 be considered RC and the patch applied now?
Bug#990089: linux-image-4.19.0-17-amd64: lxc-attach fails with Failed to set AppArmor label unconfined
Hi, On Mon, Jun 21, 2021 at 10:24:31AM +0100, Gmail wrote: > Salvatore, > > On Sun, 2021-06-20 at 20:39 +0200, Salvatore Bonaccorso wrote: > > Hi Mark, > > > > On Sun, Jun 20, 2021 at 10:44:29AM +0100, Mark Grant wrote: > > > Package: src:linux > > > Version: 4.19.194-1 > > > Severity: normal > > > > > > Dear Maintainer, > > > > > > After upgrading from linux-image-4.19.0-16-amd64 to linux-image- > > > 4.19.0-17-amd64 > > > attaching an unprivileged linux container fails with the message: > > > lxc-attach: debian-buster-amd64-basic: lsm/lsm.c: > > > lsm_process_label_set_at: 174 > > > Operation not permitted - Failed to set AppArmor label "unconfined" > > > Rebooting into linux-image-4.19.0-16-amd64 with no other changes, > > > the lxc > > > system works as expected. > > > > I think this is the same issue as in #990072, would you be able to > > test the patch as commited > > https://salsa.debian.org/kernel-team/linux/-/commit/d3fc7c8514bed949d8797cfd3a50a1bed95629c0 > > ? > > > I can confirm that the patch fixed the problem. Many thanks. Again, thanks. An update is pending and will be released once we have the builds. Regards, Salvatore
Bug#986822: BUG#986822 Broadwell SST CATPT Sound module
problem resolved, i think. new sof firmware update came out, not sure its arrival was more than a coincidence 1 - disabling all intel vitrualisation options in the helix bios was enough to allow the fw to load thus pavucontrol was now seeing input bars moving but no sound output. 2 - ran alsactl -U init after i noticed ucm errors when running alsactl init. 3 - aplay -l now sees all 3 cards when docked and 2 when tablet only. 4 - alsamixer still showed the correct hw but a lot of outputs were muted, by enabling and disabling them all in sequence enabling the front dac enabled sount from the rt256 card and headphone socket. I'm doing basic checks like detaching and reattaching to see if that affects the sound, so far ok Only noticeable thing is the fw gets reloaded 3 or 4 times a session, but doesn't seem to affect anything . If i have not commented more in a week feel free to close the bug. On Tue, 15 Jun 2021 at 11:43, Dekks Herton wrote: > Hi Vincent > > I'll kill the pipewire server, i would uninstall the packages but they are > hard deps for gnome now. > > Is the fw file catpt is trying to load the correct one? Is there new fw > files that come with catpt that have been forgotten? > Is there a listiing for the error codes -110 and -2, are they missing > files or read permission issues? > > Regards. > > > > > On Sun, 13 Jun 2021 at 18:08, Vincent Blut wrote: > >> Hi, >> >> Le 2021-06-05 08:31, Dekks Herton a écrit : >> > Hi >> > >> > Additional alsa-info script output >> >> From a quick look, alsa-info reports that you're running both PipeWire and >> PulseAudio sound servers. While it may not be the root cause of your >> issue, >> if you want to stick with the former, please disable the latter: >> $ sudo systemctl --user disable --now pulseaudio.service pulseaudio.socket >> >> Note though that using PipeWire as a substitute to PulseAudio/JACK/ALSA in >> Debian 11 is considered experimental. >> >> Cheers, >> Vincent >> >
Bug#990089: linux-image-4.19.0-17-amd64: lxc-attach fails with Failed to set AppArmor label unconfined
Salvatore, On Sun, 2021-06-20 at 20:39 +0200, Salvatore Bonaccorso wrote: > Hi Mark, > > On Sun, Jun 20, 2021 at 10:44:29AM +0100, Mark Grant wrote: > > Package: src:linux > > Version: 4.19.194-1 > > Severity: normal > > > > Dear Maintainer, > > > > After upgrading from linux-image-4.19.0-16-amd64 to linux-image- > > 4.19.0-17-amd64 > > attaching an unprivileged linux container fails with the message: > > lxc-attach: debian-buster-amd64-basic: lsm/lsm.c: > > lsm_process_label_set_at: 174 > > Operation not permitted - Failed to set AppArmor label "unconfined" > > Rebooting into linux-image-4.19.0-16-amd64 with no other changes, > > the lxc > > system works as expected. > > I think this is the same issue as in #990072, would you be able to > test the patch as commited > https://salsa.debian.org/kernel-team/linux/-/commit/d3fc7c8514bed949d8797cfd3a50a1bed95629c0 > ? > I can confirm that the patch fixed the problem. Many thanks. Regards, Mark > Regards, > Salvatore
linux_4.19.194-2_source.changes ACCEPTED into proposed-updates->stable-new
Mapping buster to stable. Mapping stable to proposed-updates. Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 21 Jun 2021 10:46:20 +0200 Source: linux Architecture: source Version: 4.19.194-2 Distribution: buster Urgency: medium Maintainer: Debian Kernel Team Changed-By: Salvatore Bonaccorso Closes: 990072 Changes: linux (4.19.194-2) buster; urgency=medium . * proc: Track /proc/$pid/attr/ opener mm_struct (Closes: #990072) Checksums-Sha1: 197a08de95c8661cdb7c14713b0a4fc165a41fb5 191615 linux_4.19.194-2.dsc eb08a00d3ed97ef32d59a46aa3c1224133764a6d 3377504 linux_4.19.194-2.debian.tar.xz 1f61d4c822b5f77c75425eec1a786d9f864871e4 6228 linux_4.19.194-2_source.buildinfo Checksums-Sha256: e759f51d7cc10c866bf795d051971bbbea7c2a886cc93c49a58ed1c1af0e5d69 191615 linux_4.19.194-2.dsc 770c22a92b290c2e8a890ac601f3e5c4315c82caea23df1b8f52ddfba6a81d22 3377504 linux_4.19.194-2.debian.tar.xz f12f2297dc47c399b77df462cc1d15e4e5df63aed2aa6e0a92ddccba5ec10439 6228 linux_4.19.194-2_source.buildinfo Files: 61bf3b824d9a8bcffac3fb89dca7a9ae 191615 kernel optional linux_4.19.194-2.dsc f5b16a9030ba3519efd4b6f515cb1cef 3377504 kernel optional linux_4.19.194-2.debian.tar.xz 4615001c65912a634283b5bfae1b872d 6228 kernel optional linux_4.19.194-2_source.buildinfo -BEGIN PGP SIGNATURE- iQKmBAEBCgCQFiEERkRAmAjBceBVMd3uBUy48xNDz0QFAmDQUoxfFIAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDQ2 NDQ0MDk4MDhDMTcxRTA1NTMxRERFRTA1NENCOEYzMTM0M0NGNDQSHGNhcm5pbEBk ZWJpYW4ub3JnAAoJEAVMuPMTQ89Ej8YQAJnwb2gKzmax4KkIqjxViZfmKOTu2GVe YbsXcB8cQqBhZEvA+KKQ+FpmvyNM0qP1QvO0FhEWCY9DHP3IEXjgeMyPLkhAFE2L KHpw4vLtpUr/a/VcTmgkYb3/z+/OODxo/YF+/3M4GZrTJnSMZhmrMqm0K3m0nHer QmvEKtSPbkLAUjZ+aqqsGFLBmV/tL7EAWtdlLWWQUgDJQPH1o8FQ/ZdECcCVUAf2 EHLgI8frO6nI7T7q8AujfBxped3tbqUQtNXHqEpTyfccHy5HylE1NssTGEPTUFfJ 1zTbN+qGlKxw/6a0s3kx32qARCmBwAih0mO13BxYz5m5w2MVYOgUmlEOiv0YbgaU 9KNnEN43hdzHRA4VHlWRdShCexOt0eL+jOnvewqHcdgv8nsIKLugyWBqH1uHOOP/ Ghog68DsiGkEz5ppc8Cp8vc45fSzEpImTuNEAh6Y2EHhymIHDoR+PfhSGQZHHef2 1DUG8v+AksSw9eb1yIiiWKAvvCqPuFYVtHFbPmxr3MFtb1eV3Z5qVtsqyv9Rs2JG oI9fdDfI9bGI1CplqJhKJI61YWlHv+gK5T7XiS5DvZACQWvoHvZvKSRtcqQMJb2O Rmsqg0ImvqP47ALglk2B6jVU+1+c6Ji0LO2Lf6Xdk54JdPYvJD1fLzhU2LDBrrHk SZ5k/UuWx+Si =PBMw -END PGP SIGNATURE- Thank you for your contribution to Debian.
Processing of linux_4.19.194-2_source.changes
linux_4.19.194-2_source.changes uploaded successfully to localhost along with the files: linux_4.19.194-2.dsc linux_4.19.194-2.debian.tar.xz linux_4.19.194-2_source.buildinfo Greetings, Your Debian queue daemon (running on host usper.debian.org)
Bug#990106:
On maandag 21 juni 2021 03:14:47 CEST Davide Beatrici wrote: > I reproduced the problem on 5.10.0-6 as well > I believe the relay in the amplifier is going bad It maybe useful to try a 5.9.x kernel as well, to properly rule out the kernel as the source of the issues. Difference between -6 and -7 aren't that big. You should be able to find that on https://snapshot.debian.org/ signature.asc Description: This is a digitally signed message part.
Bug#990072: Update
Hi Matthew, On Sun, Jun 20, 2021 at 11:14:57PM -0400, Matthew Darwin wrote: > kernel 4.19.194-1a~test resolved the issue > > Applied > https://lore.kernel.org/stable/20210614102643.875096...@linuxfoundation.org/ > using the process described at > https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html Many thanks for confirming. Regards, Salvatore
Processed: bug 990008 is forwarded to https://bugzilla.kernel.org/show_bug.cgi?id=213481
Processing commands for cont...@bugs.debian.org: > forwarded 990008 https://bugzilla.kernel.org/show_bug.cgi?id=213481 Bug #990008 [src:linux] linux-image-5.10.0-7-amd64: e1000e driver fails to load after upgrade to bullseye from buster Set Bug forwarded-to-address to 'https://bugzilla.kernel.org/show_bug.cgi?id=213481'. > thanks Stopping processing here. Please contact me if you need assistance. -- 990008: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990008 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: bug 990008 is forwarded to https://bugzilla.kernel.org/show_bug.cgi?id=213481, tagging 990008
Processing commands for cont...@bugs.debian.org: > forwarded 990008 https://bugzilla.kernel.org/show_bug.cgi?id=213481 Bug #990008 [src:linux] linux-image-5.10.0-7-amd64: e1000e driver fails to load after upgrade to bullseye from buster Ignoring request to change the forwarded-to-address of bug#990008 to the same value > tags 990008 + upstream Bug #990008 [src:linux] linux-image-5.10.0-7-amd64: e1000e driver fails to load after upgrade to bullseye from buster Added tag(s) upstream. > thanks Stopping processing here. Please contact me if you need assistance. -- 990008: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990008 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
linux-image-4.19.0-17-amd64: bug in ath10k driver for QCA6174 wifi card
Hi all, starting from Debian Buster (on older kernels it works, on newer kernels it fails), I have a problem with the Wi-Fi connection of my PC: When I connect a Huawei P Smart smartphone to the same wireless network my PC is on, my Wi-Fi card hangs indefinitely, thus causing a disconnection, and I have to force restart it. I performed a git bisect on the linux kernel git repo finding the commit that caused the problem, and it is the commit: e3def6f7ddf88636febb12e1e3e86387a4ce5452 If I revert the changes introduced by this commit, my bug does not happen anymore. I also filed a bug to the ath10k driver mailing list, which contains a little bit more details: http://lists.infradead.org/pipermail/ath10k/2021-June/012693.html Note that in this bug I use a newer kernel, to show that the problem was not fixed by newer versions of the driver. I am afraid this may be related to a bug in the firmware, because after that commit, the size of the htt_rx_desc structure changes, but the driver tells the device about the memory layout of htt_rx_desc at runtime, therefore it could be that in the firmware there is some hardcoded value that makes things fail. But really this is only handwaving, I tried sniffing the network with wireshark but I could not find anything strange, even if there must be something because this bug is only triggered by a specific model of smartphone, I tried with two different Huawei P Smart 2019 and both trigger the bug. Thanks in advance. Sincerely, Francesco Magliocca
