Bug#1069102: linux-image-6.1.0-20-amd64 and cifs mount problem on some folders which get hidden on shares

2024-04-17 Thread Kari Lempiäinen
Hi,

I think I spoke too soon. I removed  'noserverino' options from all my cifs 
mounts yesterday and u/remounted them. From last night syslog I can still find 
the "directory entry name would overflow frame end of buf" entries.

I have options like this in my fstab:
//mercury/backups/mnt/backups   cifs   
credentials=/etc/smbcredentials,uid=kari,gid=kari,_netdev,dir_mode=0775,file_mode=0775,noperm,vers=3.0
 0  0

Regards,
Kari




From: Kari Lempiäinen 
Sent: 17 April 2024 14:29
To: Salvatore Bonaccorso ; 1069...@bugs.debian.org 
<1069...@bugs.debian.org>
Cc: Manfred Larcher ; 1069...@bugs.debian.org 
<1069...@bugs.debian.org>; sub...@bugs.debian.org 
Subject: Re: Bug#1069102: linux-image-6.1.0-20-amd64 and cifs mount problem on 
some folders which get hidden on shares

Hi,

I can confirm that removing the 'noserverino' mount option fixed the problem 
for me. Unfortunately, I don't have suitable environment at the moment for 
testing kernel-fixes...

Best regads,
Kari


From: Salvatore Bonaccorso 
Sent: 16 April 2024 23:49
To: 1069...@bugs.debian.org <1069...@bugs.debian.org>
Cc: Manfred Larcher ; 1069...@bugs.debian.org 
<1069...@bugs.debian.org>; Kari Lempiäinen ; 
sub...@bugs.debian.org 
Subject: Re: Bug#1069102: linux-image-6.1.0-20-amd64 and cifs mount problem on 
some folders which get hidden on shares

Hi,

On Tue, Apr 16, 2024 at 05:46:33PM +0200, Salvatore Bonaccorso wrote:
> Control: tags -1 + moreinfo
>
> Hi
>
>
> On Tue, Apr 16, 2024 at 02:17:49PM +0200, Manfred Larcher wrote:
> > Package: src:linux
> > Version: 6.1.85-1
> > Severity: important
> >
> > Dear Maintainer,
> >
> >* What led up to the situation?
> > kernel update from version 6.1.0-18 to 6.1.0-20
> >
> >* What exactly did you do (or not do) that was effective (or
> >  ineffective)?
> > out system mounted a samba share via autofs (cifs) and we tried to access
> > some files and directories
> >
> >* What was the outcome of this action?
> > the mount point of our share is /srv/samba/shares/company and the directory
> > it/MIJ had another directory "digitale kommunikation" which did not shop up
> > on the computer which mounted the samba share. before the kernel update it
> > did and when we renamed the file to "digitale_kommunikation" or to "digitalo
> > kommunikation" we could see it.
> > in the syslog we found the following messages:
> > CIFS: VFS: directory entry name would overflow frame end of buf ...
> > we could move that direcotry into another directory and it was useable, we
> > created another directory it/abc and created the "digitale kommunikation"
> > inside and it was hidden again. after switching back to kernel 6.1.0-20
> > everything was ok.
> > upgrade to kernel 6.5.0-0.deb12.4-amd64 package was ok too.
> >
> >* What outcome did you expect instead?
> > we expected to just see the "digitale kommunikation" directory as before.
>
> Can you share details on how the cifs mounts are done? Which mount
> options are used?
>
> Were you able to find a minimal reproducing case which would help
> debug the issue on non production systems?

Can you confirm you are seeing the issue only if mounting with using
'noserverino' mount option?

Would you be in the position of building a kernel with a commit
reverted and verify the issue is gone with it?

If you follow
https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#id-1.6.6.4
with the attached patch, you should be able to get a kernel image to
test with.

Regards,
Salvatore


Bug#1061445: linux-image-6.7-cloud-amd64: Built CONFIG_VIRTIO_BLK into kernel

2024-04-17 Thread Noah Meyerhans
On Wed, Apr 03, 2024 at 06:26:46PM +0200, Paul Menzel wrote:
> Sorry, I have the feeling we talk past each other. I do not want to create
> an initrd. I want to boot *without* an initrd, and the only missing piece is
> building VIRTIO_BLK into the Linux kernel.
> 
> Ubuntu also builds this into their “kvm” flavour [1].
> 
> If you think, that is unnecessary, could you please elaborate, how I would
> achieve the goal with virtiofs?

The cloud kernel generally targets VM guests on the Microsoft Azure and
Amazon EC2 cloud environments, neither of which benefit from VIRTIO_BLK
driver being statically linked as you describe.  I think that's the
primary reason for reluctance to make your requested change.

For background, the Azure and AWS clouds present well-defined device
models, making it straightforward for us to construct targeted kernel
configs for them.

noah



Processed: bug 1069092 is forwarded to https://lore.kernel.org/linux-cifs/zibcsoc0yf_i8...@eldamar.lan/ ...

2024-04-17 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> forwarded 1069092 
> https://lore.kernel.org/linux-cifs/zibcsoc0yf_i8...@eldamar.lan/
Bug #1069092 [src:linux] Kernel 6.1.85-1 breaking CIFS mounts?
Bug #1069102 [src:linux] linux-image-6.1.0-20-amd64 and cifs mount problem on 
some folders which get hidden on shares
Set Bug forwarded-to-address to 
'https://lore.kernel.org/linux-cifs/zibcsoc0yf_i8...@eldamar.lan/'.
Set Bug forwarded-to-address to 
'https://lore.kernel.org/linux-cifs/zibcsoc0yf_i8...@eldamar.lan/'.
> tags 1069092 - moreinfo
Bug #1069092 [src:linux] Kernel 6.1.85-1 breaking CIFS mounts?
Bug #1069102 [src:linux] linux-image-6.1.0-20-amd64 and cifs mount problem on 
some folders which get hidden on shares
Removed tag(s) moreinfo.
Removed tag(s) moreinfo.
> tags 1069092 + upstream
Bug #1069092 [src:linux] Kernel 6.1.85-1 breaking CIFS mounts?
Bug #1069102 [src:linux] linux-image-6.1.0-20-amd64 and cifs mount problem on 
some folders which get hidden on shares
Added tag(s) upstream.
Added tag(s) upstream.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1069092: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069092
1069102: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069102
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#1069200: linux-image-6.1.0-20-amd64: Intel AX201 bluetooth broken

2024-04-17 Thread Rob
Package: src:linux
Version: 6.1.85-1
Severity: normal
X-Debbugs-Cc: spottyfadedgira...@gmail.com

Dear Maintainer,

Intel AX201 bluetooth is not working on this new kernel.  It still does work if
I boot the previous kernel (linux-image-6.1.0-18-amd64).
dmesg output contains:
[2.126027] bluetooth hci0: firmware: failed to load intel/ibt-19-0-4.sfi
(-2)
[2.126046] bluetooth hci0: firmware: failed to load intel/ibt-19-0-4.sfi
(-2)
[2.126058] Bluetooth: hci0: Failed to load Intel firmware file
intel/ibt-19-0-4.sfi (-2)

I confirmed that I do have these firmware files.






-- Package-specific info:
** Version:
Linux version 6.1.0-20-amd64 (debian-kernel@lists.debian.org) (gcc-12 (Debian 
12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP 
PREEMPT_DYNAMIC Debian 6.1.85-1 (2024-04-11)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-6.1.0-20-amd64 
root=UUID=f15f88ca-67cd-44bb-9cb1-62dff39b0565 ro

** Not tainted

** Kernel log:
[5.654067] Bluetooth: RFCOMM ver 1.11
[5.657832] NET: Registered PF_ALG protocol family
[5.671143] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[5.671160] Bluetooth: BNEP filters: protocol multicast
[5.671181] Bluetooth: BNEP socket layer initialized
[5.697873] NET: Registered PF_QIPCRTR protocol family
[6.189292] ppdev: user-space parallel port driver
[6.194602] lp: driver loaded but no devices found
[6.201168] fuse: init (API version 7.37)
[6.206920] device-mapper: core: CONFIG_IMA_DISABLE_HTABLE is disabled. 
Duplicate IMA measurements will not be recorded in the IMA log.
[6.208094] device-mapper: uevent: version 1.0.3
[6.209241] device-mapper: ioctl: 4.47.0-ioctl (2022-07-28) initialised: 
dm-de...@redhat.com
[6.213587] loop: module loaded
[6.392303] EXT4-fs (nvme0n1p2): mounted filesystem with ordered data mode. 
Quota mode: none.
[6.439442] Not activating Mandatory Access Control as /sbin/tomoyo-init 
does not exist.
[6.516739] systemd[1]: systemd 252.22-1~deb12u1 running in system mode 
(+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL 
+ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP 
+LIBFDISK +PCRE2 -PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD 
-BPF_FRAMEWORK -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified)
[6.516838] systemd[1]: Detected architecture x86-64.
[6.517898] systemd[1]: Hostname set to .
[6.821371] systemd[1]: Queued start job for default target graphical.target.
[6.835608] systemd[1]: Created slice machine.slice - Virtual Machine and 
Container Slice.
[6.836070] systemd[1]: Created slice system-getty.slice - Slice 
/system/getty.
[6.836323] systemd[1]: Created slice system-modprobe.slice - Slice 
/system/modprobe.
[6.836548] systemd[1]: Created slice system-systemd\x2dfsck.slice - Slice 
/system/systemd-fsck.
[6.836714] systemd[1]: Created slice user.slice - User and Session Slice.
[6.836790] systemd[1]: Started systemd-ask-password-wall.path - Forward 
Password Requests to Wall Directory Watch.
[6.836947] systemd[1]: Set up automount proc-sys-fs-binfmt_misc.automount - 
Arbitrary Executable File Formats File System Automount Point.
[6.837158] systemd[1]: Expecting device 
dev-disk-by\x2duuid-1D90\x2dCD7D.device - /dev/disk/by-uuid/1D90-CD7D...
[6.837305] systemd[1]: Expecting device 
dev-disk-by\x2duuid-4ca01065\x2d49ff\x2d479b\x2db073\x2dc79746edffcd.device - 
/dev/disk/by-uuid/4ca01065-49ff-479b-b073-c79746edffcd...
[6.837391] systemd[1]: Reached target integritysetup.target - Local 
Integrity Protected Volumes.
[6.837475] systemd[1]: Reached target nss-user-lookup.target - User and 
Group Name Lookups.
[6.837583] systemd[1]: Reached target remote-fs.target - Remote File 
Systems.
[6.837615] systemd[1]: Reached target slices.target - Slice Units.
[6.837716] systemd[1]: Reached target swap.target - Swaps.
[6.837783] systemd[1]: Reached target veritysetup.target - Local Verity 
Protected Volumes.
[6.837824] systemd[1]: Reached target virt-guest-shutdown.target - Libvirt 
guests shutdown.
[6.837945] systemd[1]: Listening on dm-event.socket - Device-mapper event 
daemon FIFOs.
[6.838079] systemd[1]: Listening on lvm2-lvmpolld.socket - LVM2 poll daemon 
socket.
[6.838175] systemd[1]: Listening on syslog.socket - Syslog Socket.
[6.838266] systemd[1]: Listening on systemd-fsckd.socket - fsck to fsckd 
communication Socket.
[6.838333] systemd[1]: Listening on systemd-initctl.socket - initctl 
Compatibility Named Pipe.
[6.838508] systemd[1]: Listening on systemd-journald-audit.socket - Journal 
Audit Socket.
[6.838594] systemd[1]: Listening on systemd-journald-dev-log.socket - 
Journal Socket (/dev/log).
[6.838694] systemd[1]: Listening on systemd-journald.socket - Journal 
Socket.
[6.838922] systemd[1]: Listening on systemd-udevd-control.socket - udev 
Control Socket.
[6.839014] systemd[1]: 

Bug#1069082: Confirm bug

2024-04-17 Thread Hank Barta
(Resending using "plain text mode due to misunderstanding Google
settings to accomplish this.)

I can confirm that I have experienced this on a Debian Bookworm
install but am unable to duplicate it at the moment. The kernel
installed is

```text
hbarta@sutyzam:~$ uname -a
Linux sutyzam 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1
(2024-02-01) x86_64 GNU/Linux
hbarta@sutyzam:~$
```

In addition to the changing MAC, I recall that the device name
(presently `enx0050b6239f84`) was also changing. That seems to make
sense as the device name was derived from the MAC address
`00:50:b6:23:9f:84`.

I was able to work around this using a .link file in
`/etc/systemd/network` and matching on the driver, reported by
`ethtool` as:

```text
root@sutyzam:~# ethtool -i enx0050b6239f84
driver: ax88179_178a
version: 6.1.0-18-amd64
firmware-version:
expansion-rom-version:
bus-info: 2-1.3:1.0
supports-statistics: no
supports-test: no
supports-eeprom-access: yes
supports-register-dump: no
supports-priv-flags: no
root@sutyzam:~#
```

`lsusb` reports it as

```text
root@sutyzam:~# ethtool -i enx0050b6239f84
driver: ax88179_178a
version: 6.1.0-18-amd64
firmware-version:
expansion-rom-version:
bus-info: 2-1.3:1.0
supports-statistics: no
supports-test: no
supports-eeprom-access: yes
supports-register-dump: no
supports-priv-flags: no
root@sutyzam:~#
```

And this is the "Amazon Basics" USB3/1Gb adapter.

best,


-- 
Beautiful Sunny Winfield



Bug#1069082: Confirm bug

2024-04-17 Thread Hank Barta
I can confirm that I have experienced this on a Debian Bookworm install but
am unable to duplicate it at the moment. The kernel installed is

```text
hbarta@sutyzam:~$ uname -a
Linux sutyzam 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1
(2024-02-01) x86_64 GNU/Linux
hbarta@sutyzam:~$
```

In addition to the changing MAC, I recall that the device name (presently
`enx0050b6239f84`) was also changing. That seems to make sense as the
device name was derived from the MAC address `00:50:b6:23:9f:84`.

I was able to work around this using a .link file in `/etc/systemd/network`
and matching on the driver, reported by `ethtool` as:

```text
root@sutyzam:~# ethtool -i enx0050b6239f84
driver: ax88179_178a
version: 6.1.0-18-amd64
firmware-version:
expansion-rom-version:
bus-info: 2-1.3:1.0
supports-statistics: no
supports-test: no
supports-eeprom-access: yes
supports-register-dump: no
supports-priv-flags: no
root@sutyzam:~#
```

`lsusb` reports it as

```text
root@sutyzam:~# ethtool -i enx0050b6239f84
driver: ax88179_178a
version: 6.1.0-18-amd64
firmware-version:
expansion-rom-version:
bus-info: 2-1.3:1.0
supports-statistics: no
supports-test: no
supports-eeprom-access: yes
supports-register-dump: no
supports-priv-flags: no
root@sutyzam:~#
```

And this is the "Amazon Basics" USB3/1Gb adapter.

best,

-- 
Beautiful Sunny Winfield


Bug#1069102: linux-image-6.1.0-20-amd64 and cifs mount problem on some folders which get hidden on shares

2024-04-17 Thread Kari Lempiäinen
Hi,

I can confirm that removing the 'noserverino' mount option fixed the problem 
for me. Unfortunately, I don't have suitable environment at the moment for 
testing kernel-fixes...

Best regads,
Kari


From: Salvatore Bonaccorso 
Sent: 16 April 2024 23:49
To: 1069...@bugs.debian.org <1069...@bugs.debian.org>
Cc: Manfred Larcher ; 1069...@bugs.debian.org 
<1069...@bugs.debian.org>; Kari Lempiäinen ; 
sub...@bugs.debian.org 
Subject: Re: Bug#1069102: linux-image-6.1.0-20-amd64 and cifs mount problem on 
some folders which get hidden on shares

Hi,

On Tue, Apr 16, 2024 at 05:46:33PM +0200, Salvatore Bonaccorso wrote:
> Control: tags -1 + moreinfo
>
> Hi
>
>
> On Tue, Apr 16, 2024 at 02:17:49PM +0200, Manfred Larcher wrote:
> > Package: src:linux
> > Version: 6.1.85-1
> > Severity: important
> >
> > Dear Maintainer,
> >
> >* What led up to the situation?
> > kernel update from version 6.1.0-18 to 6.1.0-20
> >
> >* What exactly did you do (or not do) that was effective (or
> >  ineffective)?
> > out system mounted a samba share via autofs (cifs) and we tried to access
> > some files and directories
> >
> >* What was the outcome of this action?
> > the mount point of our share is /srv/samba/shares/company and the directory
> > it/MIJ had another directory "digitale kommunikation" which did not shop up
> > on the computer which mounted the samba share. before the kernel update it
> > did and when we renamed the file to "digitale_kommunikation" or to "digitalo
> > kommunikation" we could see it.
> > in the syslog we found the following messages:
> > CIFS: VFS: directory entry name would overflow frame end of buf ...
> > we could move that direcotry into another directory and it was useable, we
> > created another directory it/abc and created the "digitale kommunikation"
> > inside and it was hidden again. after switching back to kernel 6.1.0-20
> > everything was ok.
> > upgrade to kernel 6.5.0-0.deb12.4-amd64 package was ok too.
> >
> >* What outcome did you expect instead?
> > we expected to just see the "digitale kommunikation" directory as before.
>
> Can you share details on how the cifs mounts are done? Which mount
> options are used?
>
> Were you able to find a minimal reproducing case which would help
> debug the issue on non production systems?

Can you confirm you are seeing the issue only if mounting with using
'noserverino' mount option?

Would you be in the position of building a kernel with a commit
reverted and verify the issue is gone with it?

If you follow
https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#id-1.6.6.4
with the attached patch, you should be able to get a kernel image to
test with.

Regards,
Salvatore


Bug#1069092: Bug#1069102: linux-image-6.1.0-20-amd64 and cifs mount problem on some folders which get hidden on shares

2024-04-17 Thread Salvatore Bonaccorso


On Tue, Apr 16, 2024 at 10:49:54PM +0200, Salvatore Bonaccorso wrote:
> Hi,
> 
> On Tue, Apr 16, 2024 at 05:46:33PM +0200, Salvatore Bonaccorso wrote:
> > Control: tags -1 + moreinfo
> > 
> > Hi
> > 
> > 
> > On Tue, Apr 16, 2024 at 02:17:49PM +0200, Manfred Larcher wrote:
> > > Package: src:linux
> > > Version: 6.1.85-1
> > > Severity: important
> > > 
> > > Dear Maintainer,
> > > 
> > >* What led up to the situation?
> > > kernel update from version 6.1.0-18 to 6.1.0-20
> > > 
> > >* What exactly did you do (or not do) that was effective (or
> > >  ineffective)?
> > > out system mounted a samba share via autofs (cifs) and we tried to access
> > > some files and directories
> > > 
> > >* What was the outcome of this action?
> > > the mount point of our share is /srv/samba/shares/company and the 
> > > directory
> > > it/MIJ had another directory "digitale kommunikation" which did not shop 
> > > up
> > > on the computer which mounted the samba share. before the kernel update it
> > > did and when we renamed the file to "digitale_kommunikation" or to 
> > > "digitalo
> > > kommunikation" we could see it.
> > > in the syslog we found the following messages:
> > > CIFS: VFS: directory entry name would overflow frame end of buf ...
> > > we could move that direcotry into another directory and it was useable, we
> > > created another directory it/abc and created the "digitale kommunikation"
> > > inside and it was hidden again. after switching back to kernel 6.1.0-20
> > > everything was ok.
> > > upgrade to kernel 6.5.0-0.deb12.4-amd64 package was ok too.
> > > 
> > >* What outcome did you expect instead?
> > > we expected to just see the "digitale kommunikation" directory as before.
> > 
> > Can you share details on how the cifs mounts are done? Which mount
> > options are used?
> > 
> > Were you able to find a minimal reproducing case which would help
> > debug the issue on non production systems?
> 
> Can you confirm you are seeing the issue only if mounting with using
> 'noserverino' mount option?
> 
> Would you be in the position of building a kernel with a commit
> reverted and verify the issue is gone with it?
> 
> If you follow
> https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#id-1.6.6.4
> with the attached patch, you should be able to get a kernel image to
> test with.

I'm able to reproduce the behaviour on a test machine, when using
noserverino mount option, but I'm yet trying to further reduce the
testcase to be able to report upstream. The issue happens as well
already in 6.1.82.

Regards,
Salvatore



Processed: found 1069102 in 6.1.82-1

2024-04-17 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> found 1069102 6.1.82-1
Bug #1069102 [src:linux] linux-image-6.1.0-20-amd64 and cifs mount problem on 
some folders which get hidden on shares
Bug #1069092 [src:linux] Kernel 6.1.85-1 breaking CIFS mounts?
Marked as found in versions linux/6.1.82-1.
Marked as found in versions linux/6.1.82-1.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1069092: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069092
1069102: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069102
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems