[Bug 2065047] Re: df -h reports resource unavailable for CIFS mounts
*** This bug is a duplicate of bug 2060780 *** https://bugs.launchpad.net/bugs/2060780 Hi JB2Cool, Yes, you are correct. You are seeing the exact same as bug 2060780, that was introduced between 5.15.0-101 and 5.15.0-102 and fixed in 5.15.0-105. For AWS, the fix is in: $ git log --grep "smb3: Replace smb2pdu 1-element arrays with flex-arrays" Ubuntu-aws-5.15.0-1* commit 9f1d43ea8e5f7e49485eb2e3288524af2fb5a5d5 Author: Kees Cook Date: Fri Feb 17 16:24:40 2023 -0800 smb3: Replace smb2pdu 1-element arrays with flex-arrays ... $ git describe --contains 9f1d43ea8e5f7e49485eb2e3288524af2fb5a5d5 Ubuntu-aws-5.15.0-1060.66~247 Please upgrade to 5.15.0-1060-aws or later. Thanks, Matthew ** This bug has been marked a duplicate of bug 2060780 CIFS stopped working/is unstable with kernel update to 5.15.0-102.112 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2065047 Title: df -h reports resource unavailable for CIFS mounts To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-signed-aws-5.15/+bug/2065047/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2064291] Re: Ubuntu 24.04 crashed multiple times
Hi Bernard, These are userspace application crashes. Try and wait for a kernel crash to occur. Thanks, Matthew -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2064291 Title: Ubuntu 24.04 crashed multiple times To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2064291/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2064291] Re: Ubuntu 24.04 crashed multiple times
Hi Bernard, The crash seems to bring your system down before the logs are able to be written to disk, so there is no oops present in your dmesg. Its pretty common. Would you be able to capture a kernel crashdump (kdump). Follow the instructions in: https://ubuntu.com/server/docs/kernel-crash-dump All you really need to do is: $ sudo apt install linux-crashdump Say yes twice. Then reboot. Attempt to open app center or something to cause the crash. When the system crashes, it will take a minute or so, as it copies the system memory to a file. When the system comes back, see if there is a crashdump in /var/crash/ If there is, see if there is a dmesg.log in that folder. If there is, upload that file. You don't have to upload the whole kdump. Thanks, Matthew -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2064291 Title: Ubuntu 24.04 crashed multiple times To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2064291/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2064999] [NEW] Prevent soft lockups during IOMMU streaming DMA mapping by limiting nvme max_hw_sectors_kb to cache optimised size
slow to a halt
and soft or hardlockups occur, waiting for iova_rbtree_lock.
A test kernel is available in the following ppa:
https://launchpad.net/~mruffell/+archive/ubuntu/sf374805-test
If you install the kernel and leave it running, the soft lockups will no
longer occur.
[Where problems could occur]
We are changing the value of max_hw_sectors_kb for NVMe devices, for
systems with IOMMU enabled. For those without IOMMU or IOMMU disabled,
it will remain the same as it is now.
The value is the minimum between the maximum supported by hardware, and
the largest that fits into cache. For some workloads, this might have a
small impact on performance, due to the need to split up larger IOVA
allocations into multiple smaller ones, but there should be a larger net
gain due to IOVA allocations now fitting into the cache, and completing
much faster than a single large one.
If a regression were to occur, users could disable the IOMMU as a
workaround.
** Affects: linux (Ubuntu)
Importance: Undecided
Status: Fix Released
** Affects: linux (Ubuntu Jammy)
Importance: Medium
Assignee: Matthew Ruffell (mruffell)
Status: In Progress
** Tags: jammy sts
** Also affects: linux (Ubuntu Jammy)
Importance: Undecided
Status: New
** Changed in: linux (Ubuntu)
Status: New => Fix Released
** Changed in: linux (Ubuntu Jammy)
Status: New => In Progress
** Changed in: linux (Ubuntu Jammy)
Importance: Undecided => Medium
** Changed in: linux (Ubuntu Jammy)
Assignee: (unassigned) => Matthew Ruffell (mruffell)
** Tags added: jammy sts
** Description changed:
- BugLink: https://bugs.launchpad.net/bugs/
+ BugLink: https://bugs.launchpad.net/bugs/2064999
[Impact]
On systems with IOMMU enabled, every streaming DMA mapping involves an IOVA
to be allocated and freed. For small mappings, IOVA sizes are normally cached,
so IOVA allocations complete in a reasonable time. For larger mappings, things
can be significantly slower to the point where softlockups occur due to lock
contention
on iova_rbtree_lock.
- commit 9257b4a206fc ("iommu/iova: introduce per-cpu caching to iova
allocation")
+ commit 9257b4a206fc ("iommu/iova: introduce per-cpu caching to iova
allocation")
introduced a scalable IOVA cache mechanism, that helps increase performance up
- to 128kb mappings.
+ to 128kb mappings.
On systems that do larger streaming DMA mappings, e.g. a NVMe device
with:
/sys/block/nvme0n1/queue/max_hw_sectors_kb
2048
The 2048kb mapping takes significantly longer, causing lock contention on the
iova_rbtree_lock, as other resources such as ethernet NICs are also trying to
acquire the lock.
We hit the following soft lockup:
watchdog: BUG: soft lockup - CPU#60 stuck for 24s!
CPU: 60 PID: 608304 Comm: segment-merger- Tainted: PW EL
5.15.0-76-generic #83~20.04.1-Ubuntu
RIP: 0010:_raw_spin_unlock_irqrestore+0x25/0x30
Call Trace:
-
- fq_flush_timeout+0x82/0xc0
- ? fq_ring_free+0x170/0x170
- call_timer_fn+0x2e/0x120
- run_timer_softirq+0x433/0x4c0
- ? lapic_next_event+0x21/0x30
- ? clockevents_program_event+0xab/0x130
- __do_softirq+0xdd/0x2ee
- irq_exit_rcu+0x7d/0xa0
- sysvec_apic_timer_interrupt+0x80/0x90
-
-
- asm_sysvec_apic_timer_interrupt+0x1b/0x20
+
+ fq_flush_timeout+0x82/0xc0
+ ? fq_ring_free+0x170/0x170
+ call_timer_fn+0x2e/0x120
+ run_timer_softirq+0x433/0x4c0
+ ? lapic_next_event+0x21/0x30
+ ? clockevents_program_event+0xab/0x130
+ __do_softirq+0xdd/0x2ee
+ irq_exit_rcu+0x7d/0xa0
+ sysvec_apic_timer_interrupt+0x80/0x90
+
+
+ asm_sysvec_apic_timer_interrupt+0x1b/0x20
RIP: 0010:_raw_spin_unlock_irqrestore+0x25/0x30
...
- alloc_iova+0x1d8/0x1f0
- alloc_iova_fast+0x5c/0x3a0
- iommu_dma_alloc_iova.isra.0+0x128/0x170
- ? __kmalloc+0x1ab/0x4b0
- iommu_dma_map_sg+0x1a4/0x4c0
- __dma_map_sg_attrs+0x72/0x80
- dma_map_sg_attrs+0xe/0x20
- nvme_map_data+0xde/0x800 [nvme]
- ? recalibrate_cpu_khz+0x10/0x10
- ? ktime_get+0x46/0xc0
- nvme_queue_rq+0xaf/0x1f0 [nvme]
- ? __update_load_avg_se+0x2a2/0x2c0
- __blk_mq_try_issue_directly+0x15b/0x200
- blk_mq_request_issue_directly+0x51/0xa0
- blk_mq_try_issue_list_directly+0x7f/0xf0
- blk_mq_sched_insert_requests+0xa4/0xf0
- blk_mq_flush_plug_list+0x103/0x1c0
- blk_flush_plug_list+0xe3/0x110
- blk_mq_submit_bio+0x29d/0x600
- __submit_bio+0x1e5/0x220
- ? ext4_inode_block_valid+0x9f/0xc0
- submit_bio_noacct+0xac/0x2c0
- ? xa_load+0x61/0xa0
- submit_bio+0x50/0x140
- ext4_mpage_readpages+0x6a2/0xe20
- ? __mod_lruvec_page_state+0x6b/0xb0
- ext4_readahead+0x37/0x40
- read_pages+0x95/0x280
- page_cache_ra_unbounded+0x161/0x220
- do_page_cache_ra+0x3d/0x50
- ondemand_readahead+0x137/0x330
- page_cache_async_ra+0xa6/0xd0
- filemap_get_pages+0x224/0x660
- ? filemap_get_pages+0x9e/0x660
- filemap_read+0xbe/0x410
- generic_file_read_iter+0xe5/0x150
- ext4_file_read_iter+0x5b/0x1
[Bug 2064827] Re: [5.19.0-1030-lowlatency] BUG: kernel NULL pointer dereference, address: 00000000000006b1
Hi Sophi, The 5.19 HWE kernel for Jammy is no longer supported. Its support period was for the lifetime of the 22.10 Kinetic Kudu release, which is now end of life. Can you upgrade to a supported kernel, e.g. the latest 5.15 Jammy kernel or the current 6.5 HWE kernel, and retry? Is there any reason you are using the -lowlatency variant? $ sudo apt install linux-lowlatency-hwe-22.04 $ sudo reboot $ uname -rv 6.5.0-28-lowlatency #29.1~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Thu Apr 4 17:17:55 UTC or $ sudo apt install linux-generic-hwe-22.04 for the -generic variant. Thanks, Matthew -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2064827 Title: [5.19.0-1030-lowlatency] BUG: kernel NULL pointer dereference, address: 06b1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2064827/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Kernel-packages] [Bug 2060919] Re: cifs: Copying file to same directory results in page fault
Hi everyone, Thank you for testing, and its great to hear that it fixes the issue. The Jammy HWE kernel is still queued up to be built, it should be built over the next few days. You can keep an eye on it at https://kernel.ubuntu.com/reports/kernel-stable-board/ Regardless, we should be on track to release s2024.04.01 on the week of 13th May, so around two weeks time, as per https://kernel.ubuntu.com/. I will write back once the kernel has been released, in about two weeks. Thanks, Matthew -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2060919 Title: cifs: Copying file to same directory results in page fault Status in linux package in Ubuntu: Invalid Status in linux source package in Mantic: Fix Committed Bug description: BugLink: https://bugs.launchpad.net/bugs/2060919 [Impact] Copying or modifying a file to the same directory within a cifs mount results in a page fault, and the process that initiated the copy being killed. This could be cp, nautilus, etc. This results in the following oops: BUG: unable to handle page fault for address: fffe #PF: supervisor read access in kernel mode #PF: error_code(0x) - not-present page PGD f45a3f067 P4D f45a3f067 PUD f45a41067 PMD 0 Oops: [#1] PREEMPT SMP NOPTI CPU: 0 PID: 28103 Comm: Thread (pooled) Tainted: P OE 6.5.0-27-generic #28-Ubuntu RIP: 0010:cifs_flush_folio+0x41/0xf0 [cifs] Code: 49 89 cd 31 c9 41 54 49 89 f4 48 c1 ee 0c 53 48 83 ec 08 48 8b 7f 30 44 89 45 d4 e8 79 b3 23 f1 48 89 c3 31 c0 48 85 db 74 77 <48> 8b 13 b8 00 10 00 00 f7 c2 00 00 01 00 74 10 0f b6 4b 51 48 d3 RSP: 0018:aab6865ffbf8 EFLAGS: 00010282 RAX: RBX: fffe RCX: RDX: RSI: RDI: RBP: aab6865ffc28 R08: 0001 R09: R10: 00023854 R11: R12: R13: aab6865ffc78 R14: 906675d8aed0 R15: aab6865ffc70 FS: 7bd4d594b6c0() GS:90753f80() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: fffe CR3: 00017022a000 CR4: 00750ef0 PKRU: 5554 Call Trace: ? show_regs+0x6d/0x80 ? __die+0x24/0x80 ? page_fault_oops+0x99/0x1b0 ? kernelmode_fixup_or_oops+0xb2/0x140 ? __bad_area_nosemaphore+0x1a5/0x2c0 ? bad_area_nosemaphore+0x16/0x30 ? do_kern_addr_fault+0x7b/0xa0 ? exc_page_fault+0x1a4/0x1b0 ? asm_exc_page_fault+0x27/0x30 ? cifs_flush_folio+0x41/0xf0 [cifs] ? cifs_flush_folio+0x37/0xf0 [cifs] cifs_remap_file_range+0x172/0x660 [cifs] do_clone_file_range+0x101/0x2d0 vfs_clone_file_range+0x3f/0x150 ioctl_file_clone+0x52/0xc0 do_vfs_ioctl+0x68f/0x910 ? __fget_light+0xa5/0x120 __x64_sys_ioctl+0x7d/0xf0 do_syscall_64+0x59/0x90 ? kmem_cache_free+0x22/0x3e0 ? putname+0x5b/0x80 ? exit_to_user_mode_prepare+0x30/0xb0 ? syscall_exit_to_user_mode+0x37/0x60 ? do_syscall_64+0x68/0x90 ? do_syscall_64+0x68/0x90 ? do_syscall_64+0x68/0x90 There is no known workaround. [Fix] The stacktrace is very similar to a regression reported to upstream 6.1.y: https://lore.kernel.org/linux- mm/a76b370f93cb928c049b94e1fde0d2da506dfcb2.ca...@amazon.com/T/ The thread mentions that: commit 7b2404a886f8b91250c31855d287e632123e1746 Author: David Howells Date: Fri Dec 1 00:22:00 2023 + Subject: cifs: Fix flushing, invalidation and file size with copy_file_range() Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7b2404a886f8b91250c31855d287e632123e1746 introduced the issue to Debian's 6.1 kernel. This got backported to Ubuntu in: commit 3adbe2ccd8b9b8fde93e03958d6176945794d288 Author: David Howells Date: Fri Dec 1 00:22:00 2023 + Subject: cifs: Fix flushing, invalidation and file size with copy_file_range() $ git describe --contains 3adbe2ccd8b9b8fde93e03958d6176945794d288 Ubuntu-6.5.0-20.20~107 Which we have been using for some time now, and is not the culprit. Reading the regression mailing list thread, they mention that things work differently in 6.1: > Yeah. __filemap_get_folio() works differently in v6.1.y. There it returns a > folio or NULL. In 6.7 it returns a folio or a negative error code. The error > check in cifs_flush_folio() needs to change to something like: > > folio = filemap_get_folio(inode->i_mapping, index); > if (!folio) > return -ENOMEM; > > David 6.1.y then got a specific patch to fix the issue in 6.1, which is: commit 21bb2ba4f1ac1e3a57594be62dd74e7b1401b2b1 Author: Steve French Date: Fri Jan 12 23:08:51 2024 -0600 Subject: cifs: fix flushing folio regression for 6.1 backport Link:
[Bug 2060919] Re: cifs: Copying file to same directory results in page fault
Hi everyone, Thank you for testing, and its great to hear that it fixes the issue. The Jammy HWE kernel is still queued up to be built, it should be built over the next few days. You can keep an eye on it at https://kernel.ubuntu.com/reports/kernel-stable-board/ Regardless, we should be on track to release s2024.04.01 on the week of 13th May, so around two weeks time, as per https://kernel.ubuntu.com/. I will write back once the kernel has been released, in about two weeks. Thanks, Matthew -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2060919 Title: cifs: Copying file to same directory results in page fault To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2060919/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Kernel-packages] [Bug 2064291] Re: Ubuntu 24.04 crashed multiple times
Hi Bernard, Can you have a look at your /var/log/kern.log and /var/log/syslog files, and look for what is known as a kernel oops? It looks like some of the examples in this bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2060919 Would you be able to copy and paste any you find into a text file and upload to the bug? I will have a look. Thanks, Matthew -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2064291 Title: Ubuntu 24.04 crashed multiple times Status in linux package in Ubuntu: New Bug description: Ubuntu 24.04 crashed multiple times due to unstable kernel. Crashed 8 times attempting to file this bug report. Recently installed the new updates for 24.04. Steps to reproduce: Open "Show Apps"-Crash, Open Firefox -Crash, Open Terminal -Crash, Setting idle does not crash. Installed synaptic -Crashed 2 times. Check for broken packages - None, no missing dependencies. ProblemType: Bug DistroRelease: Ubuntu 24.04 Package: linux-image-6.8.0-31-generic 6.8.0-31.31 ProcVersionSignature: Ubuntu 6.8.0-31.31-generic 6.8.1 Uname: Linux 6.8.0-31-generic x86_64 ApportVersion: 2.28.1-0ubuntu2 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/seq:b3 1256 F pipewire /dev/snd/controlC0: b3 1260 F wireplumber CRDA: N/A CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Tue Apr 30 09:07:32 2024 InstallationDate: Installed on 2024-04-25 (5 days ago) InstallationMedia: Ubuntu 24.04 LTS "Noble Numbat" - Release amd64 (20240424) IwConfig: lono wireless extensions. enp0s3no wireless extensions. Lsusb: Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 002: ID 80ee:0021 VirtualBox USB Tablet Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Lsusb-t: /: Bus 001.Port 001: Dev 001, Class=root_hub, Driver=ohci-pci/12p, 12M |__ Port 001: Dev 002, If 0, Class=Human Interface Device, Driver=usbhid, 12M /: Bus 002.Port 001: Dev 001, Class=root_hub, Driver=ehci-pci/12p, 480M MachineType: innotek GmbH VirtualBox ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color XDG_RUNTIME_DIR= ProcFB: 0 vmwgfxdrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-6.8.0-31-generic root=UUID=381f85c9-ec76-4686-aaa1-aa5e3673ec82 ro quiet splash RelatedPackageVersions: linux-restricted-modules-6.8.0-31-generic N/A linux-backports-modules-6.8.0-31-generic N/A linux-firmware20240318.git3b128b60-0ubuntu2 RfKill: SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 12/01/2006 dmi.bios.vendor: innotek GmbH dmi.bios.version: VirtualBox dmi.board.name: VirtualBox dmi.board.vendor: Oracle Corporation dmi.board.version: 1.2 dmi.chassis.type: 1 dmi.chassis.vendor: Oracle Corporation dmi.modalias: dmi:bvninnotekGmbH:bvrVirtualBox:bd12/01/2006:svninnotekGmbH:pnVirtualBox:pvr1.2:rvnOracleCorporation:rnVirtualBox:rvr1.2:cvnOracleCorporation:ct1:cvr:sku: dmi.product.family: Virtual Machine dmi.product.name: VirtualBox dmi.product.version: 1.2 dmi.sys.vendor: innotek GmbH To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2064291/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Bug 2064291] Re: Ubuntu 24.04 crashed multiple times
Hi Bernard, Can you have a look at your /var/log/kern.log and /var/log/syslog files, and look for what is known as a kernel oops? It looks like some of the examples in this bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2060919 Would you be able to copy and paste any you find into a text file and upload to the bug? I will have a look. Thanks, Matthew -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2064291 Title: Ubuntu 24.04 crashed multiple times To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2064291/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2060919] Re: cifs: Copying file to same directory results in page fault
Hi everyone, The kernel team has built the patch into the s2024.04.1 SRU cycle, as 6.5.0-35-generic. An ETA for this is the week of 13th of May, as per https://kernel.ubuntu.com/ Would anyone be able to help test the kernel by installing 6.5.0-35-generic from -proposed and doing a cifs mount and copying files? Currently only the Mantic kernel is built. The HWE kernel for Jammy hasn't been built yet, but I will write back once it is available. The kernel is currently in the kernel team's proposed2 ppa, instead of the usual -proposed pocket, but you can have a look here: https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/proposed2 Instructions to install (On a mantic system): 1) sudo add-apt-repository ppa:canonical-kernel-team/proposed2 2) sudo apt update 3) sudo apt install linux-image-6.5.0-35-generic linux-modules-6.5.0-35-generic linux-modules-extra-6.5.0-35-generic linux-headers-6.5.0-35-generic 4) sudo rm /etc/apt/sources.list.d/canonical-kernel-team-ubuntu-proposed2-mantic.sources 5) sudo apt update 6) sudo reboot 7) uname -rv 6.5.0-35-generic #35-Ubuntu SMP PREEMPT_DYNAMIC Fri Apr 26 11:23:57 UTC 2024 Let me know if this kernel fixes the issue for you, and if it does, I'll mark the bug as verified. Thanks, Matthew -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2060919 Title: cifs: Copying file to same directory results in page fault To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2060919/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Kernel-packages] [Bug 2060919] Re: cifs: Copying file to same directory results in page fault
Hi everyone, The kernel team has built the patch into the s2024.04.1 SRU cycle, as 6.5.0-35-generic. An ETA for this is the week of 13th of May, as per https://kernel.ubuntu.com/ Would anyone be able to help test the kernel by installing 6.5.0-35-generic from -proposed and doing a cifs mount and copying files? Currently only the Mantic kernel is built. The HWE kernel for Jammy hasn't been built yet, but I will write back once it is available. The kernel is currently in the kernel team's proposed2 ppa, instead of the usual -proposed pocket, but you can have a look here: https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/proposed2 Instructions to install (On a mantic system): 1) sudo add-apt-repository ppa:canonical-kernel-team/proposed2 2) sudo apt update 3) sudo apt install linux-image-6.5.0-35-generic linux-modules-6.5.0-35-generic linux-modules-extra-6.5.0-35-generic linux-headers-6.5.0-35-generic 4) sudo rm /etc/apt/sources.list.d/canonical-kernel-team-ubuntu-proposed2-mantic.sources 5) sudo apt update 6) sudo reboot 7) uname -rv 6.5.0-35-generic #35-Ubuntu SMP PREEMPT_DYNAMIC Fri Apr 26 11:23:57 UTC 2024 Let me know if this kernel fixes the issue for you, and if it does, I'll mark the bug as verified. Thanks, Matthew -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2060919 Title: cifs: Copying file to same directory results in page fault Status in linux package in Ubuntu: Invalid Status in linux source package in Mantic: Fix Committed Bug description: BugLink: https://bugs.launchpad.net/bugs/2060919 [Impact] Copying or modifying a file to the same directory within a cifs mount results in a page fault, and the process that initiated the copy being killed. This could be cp, nautilus, etc. This results in the following oops: BUG: unable to handle page fault for address: fffe #PF: supervisor read access in kernel mode #PF: error_code(0x) - not-present page PGD f45a3f067 P4D f45a3f067 PUD f45a41067 PMD 0 Oops: [#1] PREEMPT SMP NOPTI CPU: 0 PID: 28103 Comm: Thread (pooled) Tainted: P OE 6.5.0-27-generic #28-Ubuntu RIP: 0010:cifs_flush_folio+0x41/0xf0 [cifs] Code: 49 89 cd 31 c9 41 54 49 89 f4 48 c1 ee 0c 53 48 83 ec 08 48 8b 7f 30 44 89 45 d4 e8 79 b3 23 f1 48 89 c3 31 c0 48 85 db 74 77 <48> 8b 13 b8 00 10 00 00 f7 c2 00 00 01 00 74 10 0f b6 4b 51 48 d3 RSP: 0018:aab6865ffbf8 EFLAGS: 00010282 RAX: RBX: fffe RCX: RDX: RSI: RDI: RBP: aab6865ffc28 R08: 0001 R09: R10: 00023854 R11: R12: R13: aab6865ffc78 R14: 906675d8aed0 R15: aab6865ffc70 FS: 7bd4d594b6c0() GS:90753f80() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: fffe CR3: 00017022a000 CR4: 00750ef0 PKRU: 5554 Call Trace: ? show_regs+0x6d/0x80 ? __die+0x24/0x80 ? page_fault_oops+0x99/0x1b0 ? kernelmode_fixup_or_oops+0xb2/0x140 ? __bad_area_nosemaphore+0x1a5/0x2c0 ? bad_area_nosemaphore+0x16/0x30 ? do_kern_addr_fault+0x7b/0xa0 ? exc_page_fault+0x1a4/0x1b0 ? asm_exc_page_fault+0x27/0x30 ? cifs_flush_folio+0x41/0xf0 [cifs] ? cifs_flush_folio+0x37/0xf0 [cifs] cifs_remap_file_range+0x172/0x660 [cifs] do_clone_file_range+0x101/0x2d0 vfs_clone_file_range+0x3f/0x150 ioctl_file_clone+0x52/0xc0 do_vfs_ioctl+0x68f/0x910 ? __fget_light+0xa5/0x120 __x64_sys_ioctl+0x7d/0xf0 do_syscall_64+0x59/0x90 ? kmem_cache_free+0x22/0x3e0 ? putname+0x5b/0x80 ? exit_to_user_mode_prepare+0x30/0xb0 ? syscall_exit_to_user_mode+0x37/0x60 ? do_syscall_64+0x68/0x90 ? do_syscall_64+0x68/0x90 ? do_syscall_64+0x68/0x90 There is no known workaround. [Fix] The stacktrace is very similar to a regression reported to upstream 6.1.y: https://lore.kernel.org/linux- mm/a76b370f93cb928c049b94e1fde0d2da506dfcb2.ca...@amazon.com/T/ The thread mentions that: commit 7b2404a886f8b91250c31855d287e632123e1746 Author: David Howells Date: Fri Dec 1 00:22:00 2023 + Subject: cifs: Fix flushing, invalidation and file size with copy_file_range() Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7b2404a886f8b91250c31855d287e632123e1746 introduced the issue to Debian's 6.1 kernel. This got backported to Ubuntu in: commit 3adbe2ccd8b9b8fde93e03958d6176945794d288 Author: David Howells Date: Fri Dec 1 00:22:00 2023 + Subject: cifs: Fix flushing, invalidation and file size with copy_file_range() $ git describe --contains 3adbe2ccd8b9b8fde93e03958d6176945794d288 Ubuntu-6.5.0-20.20~107 Which we have been using for some time now, and is not the culprit. Reading the regression mailing list thread,
[Bug 2036467] Re: Resizing cloud-images occasionally fails due to superblock checksum mismatch in resize2fs
Hi Krister, Thanks for the heads up about 1.47.1 upstream, it does indeed look like a release is coming soon. It seems Debian unstable already has 1.7.1-rc1: https://packages.debian.org/sid/e2fsprogs When the Ubuntu archive opens for OO, we will merge 1.47.1~rc1-1 from debian unstable, and then submit the patches for SRU to noble, mantic, jammy and focal. Should be a few days. Thanks, Matthew -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2036467 Title: Resizing cloud-images occasionally fails due to superblock checksum mismatch in resize2fs To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-images/+bug/2036467/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2036467] Re: Resizing cloud-images occasionally fails due to superblock checksum mismatch in resize2fs
Attached is a V2 patch for Noble for e2fsprogs. ** Patch added: "Debdiff for e2fsprogs on noble V2" https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/2036467/+attachment/5772258/+files/lp2036467_noble_V2.debdiff ** Patch removed: "Debdiff for e2fsprogs on noble" https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/2036467/+attachment/5738302/+files/lp2036467_noble.debdiff ** Patch removed: "Debdiff for e2fsprogs on lunar" https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/2036467/+attachment/5707894/+files/lp2036467_lunar.debdiff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2036467 Title: Resizing cloud-images occasionally fails due to superblock checksum mismatch in resize2fs To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-images/+bug/2036467/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Touch-packages] [Bug 2036467] Re: Resizing cloud-images occasionally fails due to superblock checksum mismatch in resize2fs
Attached is a V2 patch for Noble for e2fsprogs. ** Patch added: "Debdiff for e2fsprogs on noble V2" https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/2036467/+attachment/5772258/+files/lp2036467_noble_V2.debdiff ** Patch removed: "Debdiff for e2fsprogs on noble" https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/2036467/+attachment/5738302/+files/lp2036467_noble.debdiff ** Patch removed: "Debdiff for e2fsprogs on lunar" https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/2036467/+attachment/5707894/+files/lp2036467_lunar.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/2036467 Title: Resizing cloud-images occasionally fails due to superblock checksum mismatch in resize2fs Status in cloud-images: New Status in e2fsprogs package in Ubuntu: In Progress Status in e2fsprogs source package in Trusty: Won't Fix Status in e2fsprogs source package in Xenial: Won't Fix Status in e2fsprogs source package in Bionic: Won't Fix Status in e2fsprogs source package in Focal: In Progress Status in e2fsprogs source package in Jammy: In Progress Status in e2fsprogs source package in Lunar: Won't Fix Status in e2fsprogs source package in Mantic: In Progress Status in e2fsprogs source package in Noble: In Progress Bug description: [Impact] This is a long running bug plaguing cloud-images, where on a rare occasion resize2fs would fail and the image would not resize to fit the entire disk. Online resizes would fail due to a superblock checksum mismatch, where the superblock in memory differs from what is currently on disk due to changes made to the image. $ resize2fs /dev/nvme1n1p1 resize2fs 1.47.0 (5-Feb-2023) resize2fs: Superblock checksum does not match superblock while trying to open /dev/nvme1n1p1 Couldn't find valid filesystem superblock. Changing the read of the superblock to Direct I/O solves the issue. [Testcase] Start an c5.large instance on AWS, and attach a 60gb gp3 volume for use as a scratch disk. Run the following script, courtesy of Krister Johansen and his team: #!/usr/bin/bash set -euxo pipefail while true do parted /dev/nvme1n1 mklabel gpt mkpart primary 2048s 2099200s sleep .5 mkfs.ext4 /dev/nvme1n1p1 mount -t ext4 /dev/nvme1n1p1 /mnt stress-ng --temp-path /mnt -D 4 & STRESS_PID=$! sleep 1 growpart /dev/nvme1n1 1 resize2fs /dev/nvme1n1p1 kill $STRESS_PID wait $STRESS_PID umount /mnt wipefs -a /dev/nvme1n1p1 wipefs -a /dev/nvme1n1 done Test packages are available in the following ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp2036467-test If you install the test packages, the race no longer occurs. [Where problems could occur] We are changing how resize2fs reads the superblock from underlying disks. If a regression were to occur, resize2fs could fail to resize offline or online volumes. As all cloud-images are online resized during their initial boot, this could have a large impact to public and private clouds should a regression occur. [Other info] Upstream mailing list discussion: https://lore.kernel.org/linux-ext4/20230605225221.ga5...@templeofstupid.com/ https://lore.kernel.org/linux-ext4/20230609042239.ga1436...@mit.edu/ This was fixed in the below commit upstream: commit 43a498e938887956f393b5e45ea6ac79cc5f4b84 Author: Theodore Ts'o Date: Thu, 15 Jun 2023 00:17:01 -0400 Subject: resize2fs: use Direct I/O when reading the superblock for online resizes Link: https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/commit/?id=43a498e938887956f393b5e45ea6ac79cc5f4b84 The commit has not been tagged to any release. All supported Ubuntu releases require this fix, and need to be published in standard non- ESM archives to be picked up in cloud images. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-images/+bug/2036467/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2036467] Re: Resizing cloud-images occasionally fails due to superblock checksum mismatch in resize2fs
Hi Krister, Thanks for the heads up about 1.47.1 upstream, it does indeed look like a release is coming soon. It seems Debian unstable already has 1.7.1-rc1: https://packages.debian.org/sid/e2fsprogs When the Ubuntu archive opens for OO, we will merge 1.47.1~rc1-1 from debian unstable, and then submit the patches for SRU to noble, mantic, jammy and focal. Should be a few days. Thanks, Matthew -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/2036467 Title: Resizing cloud-images occasionally fails due to superblock checksum mismatch in resize2fs Status in cloud-images: New Status in e2fsprogs package in Ubuntu: In Progress Status in e2fsprogs source package in Trusty: Won't Fix Status in e2fsprogs source package in Xenial: Won't Fix Status in e2fsprogs source package in Bionic: Won't Fix Status in e2fsprogs source package in Focal: In Progress Status in e2fsprogs source package in Jammy: In Progress Status in e2fsprogs source package in Lunar: Won't Fix Status in e2fsprogs source package in Mantic: In Progress Status in e2fsprogs source package in Noble: In Progress Bug description: [Impact] This is a long running bug plaguing cloud-images, where on a rare occasion resize2fs would fail and the image would not resize to fit the entire disk. Online resizes would fail due to a superblock checksum mismatch, where the superblock in memory differs from what is currently on disk due to changes made to the image. $ resize2fs /dev/nvme1n1p1 resize2fs 1.47.0 (5-Feb-2023) resize2fs: Superblock checksum does not match superblock while trying to open /dev/nvme1n1p1 Couldn't find valid filesystem superblock. Changing the read of the superblock to Direct I/O solves the issue. [Testcase] Start an c5.large instance on AWS, and attach a 60gb gp3 volume for use as a scratch disk. Run the following script, courtesy of Krister Johansen and his team: #!/usr/bin/bash set -euxo pipefail while true do parted /dev/nvme1n1 mklabel gpt mkpart primary 2048s 2099200s sleep .5 mkfs.ext4 /dev/nvme1n1p1 mount -t ext4 /dev/nvme1n1p1 /mnt stress-ng --temp-path /mnt -D 4 & STRESS_PID=$! sleep 1 growpart /dev/nvme1n1 1 resize2fs /dev/nvme1n1p1 kill $STRESS_PID wait $STRESS_PID umount /mnt wipefs -a /dev/nvme1n1p1 wipefs -a /dev/nvme1n1 done Test packages are available in the following ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp2036467-test If you install the test packages, the race no longer occurs. [Where problems could occur] We are changing how resize2fs reads the superblock from underlying disks. If a regression were to occur, resize2fs could fail to resize offline or online volumes. As all cloud-images are online resized during their initial boot, this could have a large impact to public and private clouds should a regression occur. [Other info] Upstream mailing list discussion: https://lore.kernel.org/linux-ext4/20230605225221.ga5...@templeofstupid.com/ https://lore.kernel.org/linux-ext4/20230609042239.ga1436...@mit.edu/ This was fixed in the below commit upstream: commit 43a498e938887956f393b5e45ea6ac79cc5f4b84 Author: Theodore Ts'o Date: Thu, 15 Jun 2023 00:17:01 -0400 Subject: resize2fs: use Direct I/O when reading the superblock for online resizes Link: https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/commit/?id=43a498e938887956f393b5e45ea6ac79cc5f4b84 The commit has not been tagged to any release. All supported Ubuntu releases require this fix, and need to be published in standard non- ESM archives to be picked up in cloud images. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-images/+bug/2036467/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Bug 2060919] Re: cifs: Copying file to same directory results in page fault
Hi everyone, Thanks for helping to test the test kernel, and I am glad that it fixes the issue. I have written a SRU template and have set it as the description of the bug. I have submitted the revert to the Kernel team mailing list for SRU: Cover Letter: https://lists.ubuntu.com/archives/kernel-team/2024-April/150433.html Patch: https://lists.ubuntu.com/archives/kernel-team/2024-April/150434.html I'll go and have a talk to the kernel team now. This is a regression, yes, but I am not sure if they will be interested in respinning the 2024.04.01 SRU cycle to include the fix, due to it being quite late in the cycle. https://kernel.ubuntu.com/ We just did an emergency respin last week to fix bug 2060780, which was another cifs regression for the 5.15 series, with an unrelated cause. I'll write back with what the kernel team say, and hopefully give you an estimated time of release. If its this SRU cycle, or the next. Thanks, Matthew PS: Peter, I tried Debian 12.5 and I still can't reproduce the issue. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2060919 Title: cifs: Copying file to same directory results in page fault To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2060919/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Kernel-packages] [Bug 2060919] Re: cifs: Copying file to same directory results in page fault
Hi everyone, Thanks for helping to test the test kernel, and I am glad that it fixes the issue. I have written a SRU template and have set it as the description of the bug. I have submitted the revert to the Kernel team mailing list for SRU: Cover Letter: https://lists.ubuntu.com/archives/kernel-team/2024-April/150433.html Patch: https://lists.ubuntu.com/archives/kernel-team/2024-April/150434.html I'll go and have a talk to the kernel team now. This is a regression, yes, but I am not sure if they will be interested in respinning the 2024.04.01 SRU cycle to include the fix, due to it being quite late in the cycle. https://kernel.ubuntu.com/ We just did an emergency respin last week to fix bug 2060780, which was another cifs regression for the 5.15 series, with an unrelated cause. I'll write back with what the kernel team say, and hopefully give you an estimated time of release. If its this SRU cycle, or the next. Thanks, Matthew PS: Peter, I tried Debian 12.5 and I still can't reproduce the issue. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2060919 Title: cifs: Copying file to same directory results in page fault Status in linux package in Ubuntu: Invalid Status in linux source package in Mantic: In Progress Bug description: BugLink: https://bugs.launchpad.net/bugs/2060919 [Impact] Copying or modifying a file to the same directory within a cifs mount results in a page fault, and the process that initiated the copy being killed. This could be cp, nautilus, etc. This results in the following oops: BUG: unable to handle page fault for address: fffe #PF: supervisor read access in kernel mode #PF: error_code(0x) - not-present page PGD f45a3f067 P4D f45a3f067 PUD f45a41067 PMD 0 Oops: [#1] PREEMPT SMP NOPTI CPU: 0 PID: 28103 Comm: Thread (pooled) Tainted: P OE 6.5.0-27-generic #28-Ubuntu RIP: 0010:cifs_flush_folio+0x41/0xf0 [cifs] Code: 49 89 cd 31 c9 41 54 49 89 f4 48 c1 ee 0c 53 48 83 ec 08 48 8b 7f 30 44 89 45 d4 e8 79 b3 23 f1 48 89 c3 31 c0 48 85 db 74 77 <48> 8b 13 b8 00 10 00 00 f7 c2 00 00 01 00 74 10 0f b6 4b 51 48 d3 RSP: 0018:aab6865ffbf8 EFLAGS: 00010282 RAX: RBX: fffe RCX: RDX: RSI: RDI: RBP: aab6865ffc28 R08: 0001 R09: R10: 00023854 R11: R12: R13: aab6865ffc78 R14: 906675d8aed0 R15: aab6865ffc70 FS: 7bd4d594b6c0() GS:90753f80() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: fffe CR3: 00017022a000 CR4: 00750ef0 PKRU: 5554 Call Trace: ? show_regs+0x6d/0x80 ? __die+0x24/0x80 ? page_fault_oops+0x99/0x1b0 ? kernelmode_fixup_or_oops+0xb2/0x140 ? __bad_area_nosemaphore+0x1a5/0x2c0 ? bad_area_nosemaphore+0x16/0x30 ? do_kern_addr_fault+0x7b/0xa0 ? exc_page_fault+0x1a4/0x1b0 ? asm_exc_page_fault+0x27/0x30 ? cifs_flush_folio+0x41/0xf0 [cifs] ? cifs_flush_folio+0x37/0xf0 [cifs] cifs_remap_file_range+0x172/0x660 [cifs] do_clone_file_range+0x101/0x2d0 vfs_clone_file_range+0x3f/0x150 ioctl_file_clone+0x52/0xc0 do_vfs_ioctl+0x68f/0x910 ? __fget_light+0xa5/0x120 __x64_sys_ioctl+0x7d/0xf0 do_syscall_64+0x59/0x90 ? kmem_cache_free+0x22/0x3e0 ? putname+0x5b/0x80 ? exit_to_user_mode_prepare+0x30/0xb0 ? syscall_exit_to_user_mode+0x37/0x60 ? do_syscall_64+0x68/0x90 ? do_syscall_64+0x68/0x90 ? do_syscall_64+0x68/0x90 There is no known workaround. [Fix] The stacktrace is very similar to a regression reported to upstream 6.1.y: https://lore.kernel.org/linux- mm/a76b370f93cb928c049b94e1fde0d2da506dfcb2.ca...@amazon.com/T/ The thread mentions that: commit 7b2404a886f8b91250c31855d287e632123e1746 Author: David Howells Date: Fri Dec 1 00:22:00 2023 + Subject: cifs: Fix flushing, invalidation and file size with copy_file_range() Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7b2404a886f8b91250c31855d287e632123e1746 introduced the issue to Debian's 6.1 kernel. This got backported to Ubuntu in: commit 3adbe2ccd8b9b8fde93e03958d6176945794d288 Author: David Howells Date: Fri Dec 1 00:22:00 2023 + Subject: cifs: Fix flushing, invalidation and file size with copy_file_range() $ git describe --contains 3adbe2ccd8b9b8fde93e03958d6176945794d288 Ubuntu-6.5.0-20.20~107 Which we have been using for some time now, and is not the culprit. Reading the regression mailing list thread, they mention that things work differently in 6.1: > Yeah. __filemap_get_folio() works differently in v6.1.y. There it returns a > folio or NULL. In 6.7 it returns a folio or a negative error code. The error > check in
[Bug 2060919] Re: cifs: Copying file to same directory results in page fault
** Summary changed: - Remote filesystems mounted as CIFS not working after update to Kernel "6.5.0-27-generic #28-Ubuntu" (amd64) or Kernel "6.5.0-1014-raspi #17-Ubuntu" (aarch64). + cifs: Copying file to same directory results in page fault ** Description changed: - Remote filesystems mounted as CIFS are not working after update to - Kernel "6.5.0-27-generic #28-Ubuntu" for x86_64 (and also after updating - to Kernel "6.5.0-1014-raspi #17-Ubuntu" in aarch64). + BugLink: https://bugs.launchpad.net/bugs/2060919 - The remote filesystem is correctly mounted and seems to work but trying - to write data to the filesystem ends in a kernel error exception. After - that error the CIFS filesystem just became unusable. + [Impact] - Previous Kernel version works correctly. + Copying or modifying a file to the same directory within a cifs mount + results in a page fault, and the process that initiated the copy being + killed. This could be cp, nautilus, etc. - = - Example for Kernel "6.5.0-27-generic #28-Ubuntu" (x86_64) - = - # lsb_release -rd - No LSB modules are available. - Description: Ubuntu 23.10 - Release: 23.10 + This results in the following oops: - # uname -a - Linux fpgmsi 6.5.0-27-generic #28-Ubuntu SMP PREEMPT_DYNAMIC Thu Mar 7 18:21:00 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux + BUG: unable to handle page fault for address: fffe + #PF: supervisor read access in kernel mode + #PF: error_code(0x) - not-present page + PGD f45a3f067 P4D f45a3f067 PUD f45a41067 PMD 0 + Oops: [#1] PREEMPT SMP NOPTI + CPU: 0 PID: 28103 Comm: Thread (pooled) Tainted: P OE 6.5.0-27-generic #28-Ubuntu + RIP: 0010:cifs_flush_folio+0x41/0xf0 [cifs] + Code: 49 89 cd 31 c9 41 54 49 89 f4 48 c1 ee 0c 53 48 83 ec 08 48 8b 7f 30 44 89 45 d4 e8 79 b3 23 f1 48 89 c3 31 c0 48 85 db 74 77 <48> 8b 13 b8 00 10 00 00 f7 c2 00 00 01 00 74 10 0f b6 4b 51 48 d3 + RSP: 0018:aab6865ffbf8 EFLAGS: 00010282 + RAX: RBX: fffe RCX: + RDX: RSI: RDI: + RBP: aab6865ffc28 R08: 0001 R09: + R10: 00023854 R11: R12: + R13: aab6865ffc78 R14: 906675d8aed0 R15: aab6865ffc70 + FS: 7bd4d594b6c0() GS:90753f80() knlGS: + CS: 0010 DS: ES: CR0: 80050033 + CR2: fffe CR3: 00017022a000 CR4: 00750ef0 + PKRU: 5554 + Call Trace: + + ? show_regs+0x6d/0x80 + ? __die+0x24/0x80 + ? page_fault_oops+0x99/0x1b0 + ? kernelmode_fixup_or_oops+0xb2/0x140 + ? __bad_area_nosemaphore+0x1a5/0x2c0 + ? bad_area_nosemaphore+0x16/0x30 + ? do_kern_addr_fault+0x7b/0xa0 + ? exc_page_fault+0x1a4/0x1b0 + ? asm_exc_page_fault+0x27/0x30 + ? cifs_flush_folio+0x41/0xf0 [cifs] + ? cifs_flush_folio+0x37/0xf0 [cifs] + cifs_remap_file_range+0x172/0x660 [cifs] + do_clone_file_range+0x101/0x2d0 + vfs_clone_file_range+0x3f/0x150 + ioctl_file_clone+0x52/0xc0 + do_vfs_ioctl+0x68f/0x910 + ? __fget_light+0xa5/0x120 + __x64_sys_ioctl+0x7d/0xf0 + do_syscall_64+0x59/0x90 + ? kmem_cache_free+0x22/0x3e0 + ? putname+0x5b/0x80 + ? exit_to_user_mode_prepare+0x30/0xb0 + ? syscall_exit_to_user_mode+0x37/0x60 + ? do_syscall_64+0x68/0x90 + ? do_syscall_64+0x68/0x90 + ? do_syscall_64+0x68/0x90 - # cat /proc/version_signature - Ubuntu 6.5.0-27.28-generic 6.5.13 + There is no known workaround. - - How to reproduce the problem - - For instance, I'm using KeePassXC (https://launchpad.net/ubuntu/+source/keepassxc) to update a database located at CIFS filesystem. Any change done to that database causes this Kernel error exception: + [Fix] - abr 11 09:34:59 fpgmsi kernel: BUG: unable to handle page fault for address: fffe - abr 11 09:34:59 fpgmsi kernel: #PF: supervisor read access in kernel mode - abr 11 09:34:59 fpgmsi kernel: #PF: error_code(0x) - not-present page - abr 11 09:34:59 fpgmsi kernel: PGD f45a3f067 P4D f45a3f067 PUD f45a41067 PMD 0 - abr 11 09:34:59 fpgmsi kernel: Oops: [#1] PREEMPT SMP NOPTI - abr 11 09:34:59 fpgmsi kernel: CPU: 0 PID: 28103 Comm: Thread (pooled) Tainted: P OE 6.5.0-27-generic #28-Ubuntu - abr 11 09:34:59 fpgmsi kernel: Hardware name: Micro-Star International Co., Ltd. MAG Z690 Codex X5 (MS-B930)/PRO Z690-A WIFI (MS-7D25), BIOS D.50 04/26/2022 - abr 11 09:34:59 fpgmsi kernel: RIP: 0010:cifs_flush_folio+0x41/0xf0 [cifs] - abr 11 09:34:59 fpgmsi kernel: Code: 49 89 cd 31 c9 41 54 49 89 f4 48 c1 ee 0c 53 48 83 ec 08 48 8b 7f 30 44 89 45 d4 e8 79 b3 23 f1 48 89 c3 31 c0 48 85 db 74 77 <48> 8b 13 b8 00 10 00 00 f7 c2 00 00 01 00 74 10 0f b6 4b 51 48 d3 - abr 11 09:34:59 fpgmsi kernel: RSP: 0018:aab6865ffbf8 EFLAGS: 00010282 - abr 11 09:34:59 fpgmsi kernel: RAX:
[Kernel-packages] [Bug 2060919] Re: cifs: Copying file to same directory results in page fault
** Summary changed: - Remote filesystems mounted as CIFS not working after update to Kernel "6.5.0-27-generic #28-Ubuntu" (amd64) or Kernel "6.5.0-1014-raspi #17-Ubuntu" (aarch64). + cifs: Copying file to same directory results in page fault ** Description changed: - Remote filesystems mounted as CIFS are not working after update to - Kernel "6.5.0-27-generic #28-Ubuntu" for x86_64 (and also after updating - to Kernel "6.5.0-1014-raspi #17-Ubuntu" in aarch64). + BugLink: https://bugs.launchpad.net/bugs/2060919 - The remote filesystem is correctly mounted and seems to work but trying - to write data to the filesystem ends in a kernel error exception. After - that error the CIFS filesystem just became unusable. + [Impact] - Previous Kernel version works correctly. + Copying or modifying a file to the same directory within a cifs mount + results in a page fault, and the process that initiated the copy being + killed. This could be cp, nautilus, etc. - = - Example for Kernel "6.5.0-27-generic #28-Ubuntu" (x86_64) - = - # lsb_release -rd - No LSB modules are available. - Description: Ubuntu 23.10 - Release: 23.10 + This results in the following oops: - # uname -a - Linux fpgmsi 6.5.0-27-generic #28-Ubuntu SMP PREEMPT_DYNAMIC Thu Mar 7 18:21:00 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux + BUG: unable to handle page fault for address: fffe + #PF: supervisor read access in kernel mode + #PF: error_code(0x) - not-present page + PGD f45a3f067 P4D f45a3f067 PUD f45a41067 PMD 0 + Oops: [#1] PREEMPT SMP NOPTI + CPU: 0 PID: 28103 Comm: Thread (pooled) Tainted: P OE 6.5.0-27-generic #28-Ubuntu + RIP: 0010:cifs_flush_folio+0x41/0xf0 [cifs] + Code: 49 89 cd 31 c9 41 54 49 89 f4 48 c1 ee 0c 53 48 83 ec 08 48 8b 7f 30 44 89 45 d4 e8 79 b3 23 f1 48 89 c3 31 c0 48 85 db 74 77 <48> 8b 13 b8 00 10 00 00 f7 c2 00 00 01 00 74 10 0f b6 4b 51 48 d3 + RSP: 0018:aab6865ffbf8 EFLAGS: 00010282 + RAX: RBX: fffe RCX: + RDX: RSI: RDI: + RBP: aab6865ffc28 R08: 0001 R09: + R10: 00023854 R11: R12: + R13: aab6865ffc78 R14: 906675d8aed0 R15: aab6865ffc70 + FS: 7bd4d594b6c0() GS:90753f80() knlGS: + CS: 0010 DS: ES: CR0: 80050033 + CR2: fffe CR3: 00017022a000 CR4: 00750ef0 + PKRU: 5554 + Call Trace: + + ? show_regs+0x6d/0x80 + ? __die+0x24/0x80 + ? page_fault_oops+0x99/0x1b0 + ? kernelmode_fixup_or_oops+0xb2/0x140 + ? __bad_area_nosemaphore+0x1a5/0x2c0 + ? bad_area_nosemaphore+0x16/0x30 + ? do_kern_addr_fault+0x7b/0xa0 + ? exc_page_fault+0x1a4/0x1b0 + ? asm_exc_page_fault+0x27/0x30 + ? cifs_flush_folio+0x41/0xf0 [cifs] + ? cifs_flush_folio+0x37/0xf0 [cifs] + cifs_remap_file_range+0x172/0x660 [cifs] + do_clone_file_range+0x101/0x2d0 + vfs_clone_file_range+0x3f/0x150 + ioctl_file_clone+0x52/0xc0 + do_vfs_ioctl+0x68f/0x910 + ? __fget_light+0xa5/0x120 + __x64_sys_ioctl+0x7d/0xf0 + do_syscall_64+0x59/0x90 + ? kmem_cache_free+0x22/0x3e0 + ? putname+0x5b/0x80 + ? exit_to_user_mode_prepare+0x30/0xb0 + ? syscall_exit_to_user_mode+0x37/0x60 + ? do_syscall_64+0x68/0x90 + ? do_syscall_64+0x68/0x90 + ? do_syscall_64+0x68/0x90 - # cat /proc/version_signature - Ubuntu 6.5.0-27.28-generic 6.5.13 + There is no known workaround. - - How to reproduce the problem - - For instance, I'm using KeePassXC (https://launchpad.net/ubuntu/+source/keepassxc) to update a database located at CIFS filesystem. Any change done to that database causes this Kernel error exception: + [Fix] - abr 11 09:34:59 fpgmsi kernel: BUG: unable to handle page fault for address: fffe - abr 11 09:34:59 fpgmsi kernel: #PF: supervisor read access in kernel mode - abr 11 09:34:59 fpgmsi kernel: #PF: error_code(0x) - not-present page - abr 11 09:34:59 fpgmsi kernel: PGD f45a3f067 P4D f45a3f067 PUD f45a41067 PMD 0 - abr 11 09:34:59 fpgmsi kernel: Oops: [#1] PREEMPT SMP NOPTI - abr 11 09:34:59 fpgmsi kernel: CPU: 0 PID: 28103 Comm: Thread (pooled) Tainted: P OE 6.5.0-27-generic #28-Ubuntu - abr 11 09:34:59 fpgmsi kernel: Hardware name: Micro-Star International Co., Ltd. MAG Z690 Codex X5 (MS-B930)/PRO Z690-A WIFI (MS-7D25), BIOS D.50 04/26/2022 - abr 11 09:34:59 fpgmsi kernel: RIP: 0010:cifs_flush_folio+0x41/0xf0 [cifs] - abr 11 09:34:59 fpgmsi kernel: Code: 49 89 cd 31 c9 41 54 49 89 f4 48 c1 ee 0c 53 48 83 ec 08 48 8b 7f 30 44 89 45 d4 e8 79 b3 23 f1 48 89 c3 31 c0 48 85 db 74 77 <48> 8b 13 b8 00 10 00 00 f7 c2 00 00 01 00 74 10 0f b6 4b 51 48 d3 - abr 11 09:34:59 fpgmsi kernel: RSP: 0018:aab6865ffbf8 EFLAGS: 00010282 - abr 11 09:34:59 fpgmsi kernel: RAX:
[Bug 2060780] Re: CIFS stopped working/is unstable with kernel update to 5.15.0-102.112
Hi Axel, Sorry about you getting spammed about all these verifications. The robot that posts these messages looks for the Launchpad bug number in the package changelogs, and just makes a post for every package it sees it in. You might not know, but Ubuntu has slightly over 100 kernels these days, across all series releases. These are split in the primary kernels, like -generic, and then all the derivatives like -aws, -azure, -gcp, -fips, -virtual, and so on, and then including the HWE kernels and their derivatives too. This got fixed in all the 5.15 kernels, so the robot goes crazy and spams those "please verify" comments for all the derivatives. We usually just verify the -generic kernel only, unless it has greater impact to one of those derivatives. There's no further action needed on your part. The fix won't be removed for not verifying a derivative you have never heard of. Hope that clears it up a bit. Thanks, Matthew -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2060780 Title: CIFS stopped working/is unstable with kernel update to 5.15.0-102.112 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2060780/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Kernel-packages] [Bug 2060780] Re: CIFS stopped working/is unstable with kernel update to 5.15.0-102.112
Hi Axel, Sorry about you getting spammed about all these verifications. The robot that posts these messages looks for the Launchpad bug number in the package changelogs, and just makes a post for every package it sees it in. You might not know, but Ubuntu has slightly over 100 kernels these days, across all series releases. These are split in the primary kernels, like -generic, and then all the derivatives like -aws, -azure, -gcp, -fips, -virtual, and so on, and then including the HWE kernels and their derivatives too. This got fixed in all the 5.15 kernels, so the robot goes crazy and spams those "please verify" comments for all the derivatives. We usually just verify the -generic kernel only, unless it has greater impact to one of those derivatives. There's no further action needed on your part. The fix won't be removed for not verifying a derivative you have never heard of. Hope that clears it up a bit. Thanks, Matthew -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2060780 Title: CIFS stopped working/is unstable with kernel update to 5.15.0-102.112 Status in linux package in Ubuntu: Invalid Status in linux source package in Jammy: Fix Released Bug description: Hi, updated some Ubuntu 22.04 systems to lastest available state this morning, which caused CIFS mounts (from various fileservers) to stop working. Kernel was updated to version 5.15.0-102-generic. I can mount the shares without problems (mount -t cifs), but then, df for example tells me: df: /mnt: Resource temporarily unavailable. I'm able to list and browse all the files, but accessing them (even readonly) is very unstable. Sometimes it works and sometimes it just gives me i/o errors. Switching back to 5.15.0-101-generic or 5.15.0-100-generic solves the problem and everything works again as expected. Seems like some bug has been implemented in 5.15.0-102-generic... To reproduce the problem, I started a while loop on one server to write to some file on a specific mounted CIFS share and read it from another one root@:~# while true; do echo "$(date) hallo" >> /mnt/hallo.txt; sleep 1 ; done -bash: /mnt/hallo.txt: Input/output error -bash: /mnt/hallo.txt: Input/output error ^C root@:~$ tail -f /mnt/hallo.txt Tue Apr 9 04:10:52 PM CEST 2024 hallo Tue Apr 9 04:10:53 PM CEST 2024 hallo Tue Apr 9 04:10:54 PM CEST 2024 hallo Tue Apr 9 04:10:55 PM CEST 2024 hallo Tue Apr 9 04:10:56 PM CEST 2024 hallo Tue Apr 9 04:10:57 PM CEST 2024 hallo Tue Apr 9 04:10:58 PM CEST 2024 hallo Tue Apr 9 04:10:59 PM CEST 2024 hallo Tue Apr 9 04:11:00 PM CEST 2024 hallo Tue Apr 9 04:11:01 PM CEST 2024 hallo tail: cannot determine location of '/mnt/hallo.txt'. reverting to polling: Resource temporarily unavailable Tue Apr 9 04:11:04 PM CEST 2024 hallo Tue Apr 9 04:11:05 PM CEST 2024 hallo Tue Apr 9 04:11:06 PM CEST 2024 hallo Tue Apr 9 04:11:07 PM CEST 2024 hallo Tue Apr 9 04:11:08 PM CEST 2024 hallo Tue Apr 9 04:11:09 PM CEST 2024 hallo Tue Apr 9 04:11:10 PM CEST 2024 hallo While doing this, both servers tell me, the resource is unavailable root@:~# df -h /mnt df: /mnt: Resource temporarily unavailable root@:~$ df -h /mnt df: /mnt: Resource temporarily unavailable To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2060780/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Bug 2060919] Re: Remote filesystems mounted as CIFS not working after update to Kernel "6.5.0-27-generic #28-Ubuntu" (amd64) or Kernel "6.5.0-1014-raspi #17-Ubuntu" (aarch64).
** No longer affects: linux-raspi (Ubuntu) ** No longer affects: linux-hwe-6.5 (Ubuntu) ** No longer affects: linux-azure (Ubuntu) ** Also affects: linux (Ubuntu Mantic) Importance: Undecided Status: New ** Changed in: linux (Ubuntu) Assignee: Jose Ogando Justo (joseogando) => (unassigned) ** Changed in: linux (Ubuntu) Status: Confirmed => Invalid ** Changed in: linux (Ubuntu Mantic) Status: New => In Progress ** Changed in: linux (Ubuntu Mantic) Importance: Undecided => High ** Changed in: linux (Ubuntu Mantic) Assignee: (unassigned) => Matthew Ruffell (mruffell) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2060919 Title: Remote filesystems mounted as CIFS not working after update to Kernel "6.5.0-27-generic #28-Ubuntu" (amd64) or Kernel "6.5.0-1014-raspi #17-Ubuntu" (aarch64). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2060919/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Kernel-packages] [Bug 2060919] Re: Remote filesystems mounted as CIFS not working after update to Kernel "6.5.0-27-generic #28-Ubuntu" (amd64) or Kernel "6.5.0-1014-raspi #17-Ubuntu" (aarch64).
** No longer affects: linux-raspi (Ubuntu) ** No longer affects: linux-hwe-6.5 (Ubuntu) ** No longer affects: linux-azure (Ubuntu) ** Also affects: linux (Ubuntu Mantic) Importance: Undecided Status: New ** Changed in: linux (Ubuntu) Assignee: Jose Ogando Justo (joseogando) => (unassigned) ** Changed in: linux (Ubuntu) Status: Confirmed => Invalid ** Changed in: linux (Ubuntu Mantic) Status: New => In Progress ** Changed in: linux (Ubuntu Mantic) Importance: Undecided => High ** Changed in: linux (Ubuntu Mantic) Assignee: (unassigned) => Matthew Ruffell (mruffell) -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-azure in Ubuntu. https://bugs.launchpad.net/bugs/2060919 Title: Remote filesystems mounted as CIFS not working after update to Kernel "6.5.0-27-generic #28-Ubuntu" (amd64) or Kernel "6.5.0-1014-raspi #17-Ubuntu" (aarch64). Status in linux package in Ubuntu: Invalid Status in linux source package in Mantic: In Progress Bug description: Remote filesystems mounted as CIFS are not working after update to Kernel "6.5.0-27-generic #28-Ubuntu" for x86_64 (and also after updating to Kernel "6.5.0-1014-raspi #17-Ubuntu" in aarch64). The remote filesystem is correctly mounted and seems to work but trying to write data to the filesystem ends in a kernel error exception. After that error the CIFS filesystem just became unusable. Previous Kernel version works correctly. = Example for Kernel "6.5.0-27-generic #28-Ubuntu" (x86_64) = # lsb_release -rd No LSB modules are available. Description: Ubuntu 23.10 Release: 23.10 # uname -a Linux fpgmsi 6.5.0-27-generic #28-Ubuntu SMP PREEMPT_DYNAMIC Thu Mar 7 18:21:00 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux # cat /proc/version_signature Ubuntu 6.5.0-27.28-generic 6.5.13 How to reproduce the problem For instance, I'm using KeePassXC (https://launchpad.net/ubuntu/+source/keepassxc) to update a database located at CIFS filesystem. Any change done to that database causes this Kernel error exception: abr 11 09:34:59 fpgmsi kernel: BUG: unable to handle page fault for address: fffe abr 11 09:34:59 fpgmsi kernel: #PF: supervisor read access in kernel mode abr 11 09:34:59 fpgmsi kernel: #PF: error_code(0x) - not-present page abr 11 09:34:59 fpgmsi kernel: PGD f45a3f067 P4D f45a3f067 PUD f45a41067 PMD 0 abr 11 09:34:59 fpgmsi kernel: Oops: [#1] PREEMPT SMP NOPTI abr 11 09:34:59 fpgmsi kernel: CPU: 0 PID: 28103 Comm: Thread (pooled) Tainted: P OE 6.5.0-27-generic #28-Ubuntu abr 11 09:34:59 fpgmsi kernel: Hardware name: Micro-Star International Co., Ltd. MAG Z690 Codex X5 (MS-B930)/PRO Z690-A WIFI (MS-7D25), BIOS D.50 04/26/2022 abr 11 09:34:59 fpgmsi kernel: RIP: 0010:cifs_flush_folio+0x41/0xf0 [cifs] abr 11 09:34:59 fpgmsi kernel: Code: 49 89 cd 31 c9 41 54 49 89 f4 48 c1 ee 0c 53 48 83 ec 08 48 8b 7f 30 44 89 45 d4 e8 79 b3 23 f1 48 89 c3 31 c0 48 85 db 74 77 <48> 8b 13 b8 00 10 00 00 f7 c2 00 00 01 00 74 10 0f b6 4b 51 48 d3 abr 11 09:34:59 fpgmsi kernel: RSP: 0018:aab6865ffbf8 EFLAGS: 00010282 abr 11 09:34:59 fpgmsi kernel: RAX: RBX: fffe RCX: abr 11 09:34:59 fpgmsi kernel: RDX: RSI: RDI: abr 11 09:34:59 fpgmsi kernel: RBP: aab6865ffc28 R08: 0001 R09: abr 11 09:34:59 fpgmsi kernel: R10: 00023854 R11: R12: abr 11 09:34:59 fpgmsi kernel: R13: aab6865ffc78 R14: 906675d8aed0 R15: aab6865ffc70 abr 11 09:34:59 fpgmsi kernel: FS: 7bd4d594b6c0() GS:90753f80() knlGS: abr 11 09:34:59 fpgmsi kernel: CS: 0010 DS: ES: CR0: 80050033 abr 11 09:34:59 fpgmsi kernel: CR2: fffe CR3: 00017022a000 CR4: 00750ef0 abr 11 09:34:59 fpgmsi kernel: PKRU: 5554 abr 11 09:34:59 fpgmsi kernel: Call Trace: abr 11 09:34:59 fpgmsi kernel: abr 11 09:34:59 fpgmsi kernel: ? show_regs+0x6d/0x80 abr 11 09:34:59 fpgmsi kernel: ? __die+0x24/0x80 abr 11 09:34:59 fpgmsi kernel: ? page_fault_oops+0x99/0x1b0 abr 11 09:34:59 fpgmsi kernel: ? kernelmode_fixup_or_oops+0xb2/0x140 abr 11 09:34:59 fpgmsi kernel: ? __bad_area_nosemaphore+0x1a5/0x2c0 abr 11 09:34:59 fpgmsi kernel: ? bad_area_nosemaphore+0x16/0x30 abr 11 09:34:59 fpgmsi kernel: ? do_kern_addr_fault+0x7b/0xa0 abr 11 09:34:59 fpgmsi kernel: ? exc_page_fault+0x1a4/0x1b0 abr 11 09:34:59 fpgmsi kernel: ? asm_exc_page_fault+0x27/0x30 abr 11 09:34:59 fpgmsi kerne
[Kernel-packages] [Bug 2049634] Re: smb: wsize blocks of bytes followed with binary zeros on copy, destroying data
** Changed in: linux (Ubuntu Noble) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2049634 Title: smb: wsize blocks of bytes followed with binary zeros on copy, destroying data Status in linux package in Ubuntu: Fix Released Status in linux source package in Mantic: Fix Released Status in linux source package in Noble: Fix Released Bug description: BugLink: https://bugs.launchpad.net/bugs/2049634 [Impact] Upon installing the 6.5 HWE kernel on Jammy, users with a custom wsize set will see data destruction when copying files from their systems onto a cifs smb mount. wsize defaults to 65535 bytes, but when set to smaller values, like 16850, users will see blocks of 16850 bytes copied over, followed by 3900 binary zeros, followed by the next block of data followed by more binary zeros. This destroys what you are copying, and the data corruption is completely silent. A workaround is to set wsize to a multiple of PAGE_SIZE. [Fix] This was fixed upstream in 6.8-rc5 by the following: commit 4860abb91f3d7fbaf8147d54782149bb1fc45892 Author: Steve French Date: Tue Feb 6 16:34:22 2024 -0600 Subject: smb: Fix regression in writes when non-standard maximum write size negotiated Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4860abb91f3d7fbaf8147d54782149bb1fc45892 This patch has been selected for upstream stable. The patch looks at wsize negotiation from the server, and also what is set on the mount command line, and if not a multiple of PAGE_SIZE, rounds it down, taking care to not be 0. The real corruption bug still exists in netfs/folios subsystems and we are looking for it still, but this solves the immediate data corruption issues on smb. [Testcase] Start two VMs, one for the server, and the other, the client. Server -- $ sudo apt update $ sudo apt upgrade $ sudo apt install samba $ sudo vim /etc/samba/smb.conf server min protocol = NT1 [sambashare] comment = Samba on Ubuntu path = /home/ubuntu/sambashare read only = no browsable = yes $ mkdir ~/sambashare $ sudo smbpasswd -a ubuntu Client -- $ sudo apt update $ sudo apt install cifs-utils $ mkdir ~/share $ sudo mount -t cifs -o username=ubuntu,vers=1.0,wsize=16850 //192.168.122.172/sambashare ~/share $ ( set -o pipefail && head --bytes=$(( 55 * 1000 )) /dev/zero | openssl enc -aes-128-ctr -nosalt -pass "pass:my-seed" -iter 1 | hexdump --no-squeezing --format '40/1 "%02x"' --format '"\n"' >"testdata.txt" ) $ sha256sum testdata.txt 9ec09af020dce3270ea76531141940106f173c7243b7193a553480fb8500b3f2 testdata.txt Now copy the file to the share. Client -- $ cp testdata.txt share/ Server -- $ sha256sum sambashare/testdata.txt 9e573a0aa795f9cd4de4ac684a1c056dbc7d2ba5494d02e71b6225ff5f0fd866 sambashare/testdata.txt The SHA256 hash is different. If you view the file with less, you will find a block of wsize=16850 bytes, then 3900 bytes of binary zeros, followed by another wsize=16850 bytes, then 3900 bytes of binary zeros, etc. An example of a broken file is: https://launchpadlibrarian.net/712573213/testdata-back-from-server.txt [Where problems could occur] We are changing the wsize that the SMB server negotiates or the user explicitly sets on the mount command line to a safe value, if the asked for value was not a multiple of PAGE_SIZE. It is unlikely that any users will notice any difference. If the wsize happens to be rounded down to a significantly smaller number, there may be a small performance impact, e.g. you set wsize=8094 for some reason, it would round down to wsize=4096, and lead to double the writes. At least you have data integrity though. Most users default to wsize=65535, and will have no impact at all. Only those with very old smb 1.0 servers that negotiate down to 16850 will see any difference. If a regression were to occur, it could result in user's wsize being incorrectly set, leading to the underlying netfs/folios data corruption being triggered and causing data corruption. [Other info] The issue was introduced in 6.3-rc1 by: commit d08089f649a0cfb2099c8551ac47eef0cc23fdf2 Author: David Howells Date: Mon Jan 24 21:13:24 2022 + Subject: cifs: Change the I/O paths to use an iterator rather than a page list Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d08089f649a0cfb2099c8551ac47eef0cc23fdf2 Upstream mailing list discussion: https://lore.kernel.org/linux- cifs/6a65b2d1-7596-438a-8ade-2f7526b15...@rd10.de/T/#m22cd9b7289f87cd945978bd7995bcaf1beebfe67 To manage notifications about this bug go to:
[Kernel-packages] [Bug 2060919] Re: Remote filesystems mounted as CIFS not working after update to Kernel "6.5.0-27-generic #28-Ubuntu" (amd64) or Kernel "6.5.0-1014-raspi #17-Ubuntu" (aarch64).
Hi everyone, As promised, I uploaded test kernels to the below ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp2060919-test They are based on 6.5.0-27-generic to keep it simple. It just has "cifs: fix flushing folio regression for 6.1 backport". Thats it. Pretty small patch: commit 9dc02a5b7540d18a69bcbaf8f4fa428e32075b4b (HEAD -> lp2060919-test) Author: Matthew Ruffell Date: Fri Apr 19 17:25:48 2024 +1200 Revert "cifs: fix flushing folio regression for 6.1 backport" This reverts commit 21bb2ba4f1ac1e3a57594be62dd74e7b1401b2b1. diff --git a/fs/smb/client/cifsfs.c b/fs/smb/client/cifsfs.c index 55a6d0296ec8..82313b253463 100644 --- a/fs/smb/client/cifsfs.c +++ b/fs/smb/client/cifsfs.c @@ -1245,7 +1245,7 @@ static int cifs_flush_folio(struct inode *inode, loff_t pos, loff_t *_fstart, lo int rc = 0; folio = filemap_get_folio(inode->i_mapping, index); - if (!folio) + if (IS_ERR(folio)) return 0; size = folio_size(folio); They are going to take about three hours to build, so check back later on. It's close to my EOD, and I can't watch these builds complete. Please note this package is NOT SUPPORTED by Canonical, and is for TESTING PURPOSES ONLY. ONLY Install in a dedicated test environment. Instructions to Install (On a jammy or mantic system): 1) sudo add-apt-repository ppa:mruffell/lp2060919-test 2) sudo apt update 3) sudo apt install linux-image-unsigned-6.5.0-27-generic linux-modules-6.5.0-27-generic linux-modules-extra-6.5.0-27-generic linux-headers-6.5.0-27-generic 4) sudo reboot 5) uname -rv 6.5.0-27.28+TEST2060919v20240419b1 or 6.5.0-27.28~22.04.1+TEST2060919v20240419b1 Make sure the +TEST2060919v20240419b1 is present. Can you let me know if it solves the problem? Additionally, if you could help me create a reproducer that would help immensely. Remember, they still need to build, check the ppa link to make sure it built successfully and is published before installing. About 3 hours from now. Thanks, Matthew -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-hwe-6.5 in Ubuntu. https://bugs.launchpad.net/bugs/2060919 Title: Remote filesystems mounted as CIFS not working after update to Kernel "6.5.0-27-generic #28-Ubuntu" (amd64) or Kernel "6.5.0-1014-raspi #17-Ubuntu" (aarch64). Status in linux package in Ubuntu: Confirmed Status in linux-azure package in Ubuntu: New Status in linux-hwe-6.5 package in Ubuntu: Confirmed Status in linux-raspi package in Ubuntu: Confirmed Bug description: Remote filesystems mounted as CIFS are not working after update to Kernel "6.5.0-27-generic #28-Ubuntu" for x86_64 (and also after updating to Kernel "6.5.0-1014-raspi #17-Ubuntu" in aarch64). The remote filesystem is correctly mounted and seems to work but trying to write data to the filesystem ends in a kernel error exception. After that error the CIFS filesystem just became unusable. Previous Kernel version works correctly. = Example for Kernel "6.5.0-27-generic #28-Ubuntu" (x86_64) = # lsb_release -rd No LSB modules are available. Description: Ubuntu 23.10 Release: 23.10 # uname -a Linux fpgmsi 6.5.0-27-generic #28-Ubuntu SMP PREEMPT_DYNAMIC Thu Mar 7 18:21:00 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux # cat /proc/version_signature Ubuntu 6.5.0-27.28-generic 6.5.13 How to reproduce the problem For instance, I'm using KeePassXC (https://launchpad.net/ubuntu/+source/keepassxc) to update a database located at CIFS filesystem. Any change done to that database causes this Kernel error exception: abr 11 09:34:59 fpgmsi kernel: BUG: unable to handle page fault for address: fffe abr 11 09:34:59 fpgmsi kernel: #PF: supervisor read access in kernel mode abr 11 09:34:59 fpgmsi kernel: #PF: error_code(0x) - not-present page abr 11 09:34:59 fpgmsi kernel: PGD f45a3f067 P4D f45a3f067 PUD f45a41067 PMD 0 abr 11 09:34:59 fpgmsi kernel: Oops: [#1] PREEMPT SMP NOPTI abr 11 09:34:59 fpgmsi kernel: CPU: 0 PID: 28103 Comm: Thread (pooled) Tainted: P OE 6.5.0-27-generic #28-Ubuntu abr 11 09:34:59 fpgmsi kernel: Hardware name: Micro-Star International Co., Ltd. MAG Z690 Codex X5 (MS-B930)/PRO Z690-A WIFI (MS-7D25), BIOS D.50 04/26/2022 abr 11 09:34:59 fpgmsi kernel: RIP: 0010:cifs_flush_folio+0x41/0xf0 [cifs] abr 11 09:34:59 fpgmsi kernel: Code: 49 89 cd 31 c9 41 54 49 89 f4 48 c1 ee 0c 53 48 83 ec 08 48 8b 7f 30 44 89 45 d4 e8 79 b3 23 f1 48 89 c3 31 c0 48 85 db 74 77 <48> 8b 13 b8 00 10 00 00 f7 c2 00 00 01 00 74 10 0f b6 4b 51 48 d3 abr 11 09:34:59 fpgmsi kernel: RSP: 0018:aab686
[Bug 2049634] Re: smb: wsize blocks of bytes followed with binary zeros on copy, destroying data
** Changed in: linux (Ubuntu Noble) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2049634 Title: smb: wsize blocks of bytes followed with binary zeros on copy, destroying data To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2049634/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2060919] Re: Remote filesystems mounted as CIFS not working after update to Kernel "6.5.0-27-generic #28-Ubuntu" (amd64) or Kernel "6.5.0-1014-raspi #17-Ubuntu" (aarch64).
Hi everyone, As promised, I uploaded test kernels to the below ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp2060919-test They are based on 6.5.0-27-generic to keep it simple. It just has "cifs: fix flushing folio regression for 6.1 backport". Thats it. Pretty small patch: commit 9dc02a5b7540d18a69bcbaf8f4fa428e32075b4b (HEAD -> lp2060919-test) Author: Matthew Ruffell Date: Fri Apr 19 17:25:48 2024 +1200 Revert "cifs: fix flushing folio regression for 6.1 backport" This reverts commit 21bb2ba4f1ac1e3a57594be62dd74e7b1401b2b1. diff --git a/fs/smb/client/cifsfs.c b/fs/smb/client/cifsfs.c index 55a6d0296ec8..82313b253463 100644 --- a/fs/smb/client/cifsfs.c +++ b/fs/smb/client/cifsfs.c @@ -1245,7 +1245,7 @@ static int cifs_flush_folio(struct inode *inode, loff_t pos, loff_t *_fstart, lo int rc = 0; folio = filemap_get_folio(inode->i_mapping, index); - if (!folio) + if (IS_ERR(folio)) return 0; size = folio_size(folio); They are going to take about three hours to build, so check back later on. It's close to my EOD, and I can't watch these builds complete. Please note this package is NOT SUPPORTED by Canonical, and is for TESTING PURPOSES ONLY. ONLY Install in a dedicated test environment. Instructions to Install (On a jammy or mantic system): 1) sudo add-apt-repository ppa:mruffell/lp2060919-test 2) sudo apt update 3) sudo apt install linux-image-unsigned-6.5.0-27-generic linux-modules-6.5.0-27-generic linux-modules-extra-6.5.0-27-generic linux-headers-6.5.0-27-generic 4) sudo reboot 5) uname -rv 6.5.0-27.28+TEST2060919v20240419b1 or 6.5.0-27.28~22.04.1+TEST2060919v20240419b1 Make sure the +TEST2060919v20240419b1 is present. Can you let me know if it solves the problem? Additionally, if you could help me create a reproducer that would help immensely. Remember, they still need to build, check the ppa link to make sure it built successfully and is published before installing. About 3 hours from now. Thanks, Matthew -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2060919 Title: Remote filesystems mounted as CIFS not working after update to Kernel "6.5.0-27-generic #28-Ubuntu" (amd64) or Kernel "6.5.0-1014-raspi #17-Ubuntu" (aarch64). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2060919/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2060919] Re: Remote filesystems mounted as CIFS not working after update to Kernel "6.5.0-27-generic #28-Ubuntu" (amd64) or Kernel "6.5.0-1014-raspi #17-Ubuntu" (aarch64).
Hello, I can't actually reproduce the issue, I seem to be missing something. Server -- $ sudo apt update $ sudo apt upgrade $ sudo apt install samba $ sudo vim /etc/samba/smb.conf server min protocol = NT1 [sambashare] comment = Samba on Ubuntu path = /home/ubuntu/sambashare read only = no browsable = yes $ mkdir ~/sambashare $ sudo smbpasswd -a ubuntu Client -- $ sudo apt update $ sudo apt install cifs-utils $ mkdir ~/share $ sudo mount -t cifs -o username=ubuntu //192.168.122.185/sambashare ~/share Password for ubuntu@//192.168.122.185/sambashare: $ mount -l ... //192.168.122.185/sambashare on /home/ubuntu/share type cifs (rw,relatime,vers=3.1.1,cache=strict,username=ubuntu,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.122.185,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1,closetimeo=1) $ ls hallo.txt hello.txt sample.txt sample2.txt $ sudo cp hello.txt hello.txt.1 $ ll total 2097176 drwxr-xr-x 2 root root0 Apr 19 04:46 ./ drwxr-x--- 5 ubuntu ubuntu 4096 Apr 19 03:57 ../ -rwxr-xr-x 1 root root 1960 Apr 19 03:55 hallo.txt* -rwxr-xr-x 1 root root 1960 Apr 19 04:04 hello.txt* -rwxr-xr-x 1 root root 1960 Apr 19 04:46 hello.txt.1* -rwxr-xr-x 1 root root 1073741824 Apr 19 04:01 sample.txt* -rwxr-xr-x 1 root root 1073741824 Apr 19 04:04 sample2.txt* No oops in dmesg. I'm not sure what I'm doing wrong. Maybe you can help. Anyway, I had a look at the stack trace, and it seems to be related to the regression reported here: https://lore.kernel.org/linux- mm/a76b370f93cb928c049b94e1fde0d2da506dfcb2.ca...@amazon.com/T/ But I think its slightly different in the Ubuntu 6.5 kernel. The thread mentions that: commit 7b2404a886f8b91250c31855d287e632123e1746 Author: David Howells Date: Fri Dec 1 00:22:00 2023 + Subject: cifs: Fix flushing, invalidation and file size with copy_file_range() Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7b2404a886f8b91250c31855d287e632123e1746 introduced the issue to Debian's 6.1 kernel. This got backported to Ubuntu in: commit 3adbe2ccd8b9b8fde93e03958d6176945794d288 Author: David Howells Date: Fri Dec 1 00:22:00 2023 + Subject: cifs: Fix flushing, invalidation and file size with copy_file_range() $ git describe --contains 3adbe2ccd8b9b8fde93e03958d6176945794d288 Ubuntu-6.5.0-20.20~107 Which we have been using for some time now. Reading the regression mailing list thread, they mention that things work differently in 6.1: > Yeah. __filemap_get_folio() works differently in v6.1.y. There it returns a > folio or NULL. In 6.7 it returns a folio or a negative error code. The error > check in cifs_flush_folio() needs to change to something like: > > folio = filemap_get_folio(inode->i_mapping, index); > if (!folio) > return -ENOMEM; > > David okay... so 6.1 is different from 6.5. Since we were okay with the patch, we probably didn't need to add anything further. But they fixed 6.1 with: commit 21bb2ba4f1ac1e3a57594be62dd74e7b1401b2b1 Author: Steve French Date: Fri Jan 12 23:08:51 2024 -0600 Subject: cifs: fix flushing folio regression for 6.1 backport Link: https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/mantic/commit/?id=21bb2ba4f1ac1e3a57594be62dd74e7b1401b2b1 Now, Ubuntu kernels in between upstream stable releases get patches from current upstream stable and long term upstream stable trees. We got both 6.1.x and 6.7.x patches recently... so we pulled in this fix, and it landed in: $ git describe --contains 21bb2ba4f1ac1e3a57594be62dd74e7b1401b2b1 Ubuntu-6.5.0-27.28~162 Wow, what a coincidence. I think this patch is probably not needed in 6.5, and causes the issue. How about I build you a test kernel with "cifs: fix flushing folio regression for 6.1 backport" reverted, and then we see if it fixes things? If it does, I will send a revert to the kernel team. If it doesn't then I will have another look. I'll write back once a test kernel is ready. I'll build you both Jammy HWE and Mantic kernels. If you can help me make a reproducer, that would be great. I can test myself then. Thanks, Matthew ** Tags added: seg -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2060919 Title: Remote filesystems mounted as CIFS not working after update to Kernel "6.5.0-27-generic #28-Ubuntu" (amd64) or Kernel "6.5.0-1014-raspi #17-Ubuntu" (aarch64). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2060919/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Kernel-packages] [Bug 2060919] Re: Remote filesystems mounted as CIFS not working after update to Kernel "6.5.0-27-generic #28-Ubuntu" (amd64) or Kernel "6.5.0-1014-raspi #17-Ubuntu" (aarch64).
Hello, I can't actually reproduce the issue, I seem to be missing something. Server -- $ sudo apt update $ sudo apt upgrade $ sudo apt install samba $ sudo vim /etc/samba/smb.conf server min protocol = NT1 [sambashare] comment = Samba on Ubuntu path = /home/ubuntu/sambashare read only = no browsable = yes $ mkdir ~/sambashare $ sudo smbpasswd -a ubuntu Client -- $ sudo apt update $ sudo apt install cifs-utils $ mkdir ~/share $ sudo mount -t cifs -o username=ubuntu //192.168.122.185/sambashare ~/share Password for ubuntu@//192.168.122.185/sambashare: $ mount -l ... //192.168.122.185/sambashare on /home/ubuntu/share type cifs (rw,relatime,vers=3.1.1,cache=strict,username=ubuntu,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.122.185,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1,closetimeo=1) $ ls hallo.txt hello.txt sample.txt sample2.txt $ sudo cp hello.txt hello.txt.1 $ ll total 2097176 drwxr-xr-x 2 root root0 Apr 19 04:46 ./ drwxr-x--- 5 ubuntu ubuntu 4096 Apr 19 03:57 ../ -rwxr-xr-x 1 root root 1960 Apr 19 03:55 hallo.txt* -rwxr-xr-x 1 root root 1960 Apr 19 04:04 hello.txt* -rwxr-xr-x 1 root root 1960 Apr 19 04:46 hello.txt.1* -rwxr-xr-x 1 root root 1073741824 Apr 19 04:01 sample.txt* -rwxr-xr-x 1 root root 1073741824 Apr 19 04:04 sample2.txt* No oops in dmesg. I'm not sure what I'm doing wrong. Maybe you can help. Anyway, I had a look at the stack trace, and it seems to be related to the regression reported here: https://lore.kernel.org/linux- mm/a76b370f93cb928c049b94e1fde0d2da506dfcb2.ca...@amazon.com/T/ But I think its slightly different in the Ubuntu 6.5 kernel. The thread mentions that: commit 7b2404a886f8b91250c31855d287e632123e1746 Author: David Howells Date: Fri Dec 1 00:22:00 2023 + Subject: cifs: Fix flushing, invalidation and file size with copy_file_range() Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7b2404a886f8b91250c31855d287e632123e1746 introduced the issue to Debian's 6.1 kernel. This got backported to Ubuntu in: commit 3adbe2ccd8b9b8fde93e03958d6176945794d288 Author: David Howells Date: Fri Dec 1 00:22:00 2023 + Subject: cifs: Fix flushing, invalidation and file size with copy_file_range() $ git describe --contains 3adbe2ccd8b9b8fde93e03958d6176945794d288 Ubuntu-6.5.0-20.20~107 Which we have been using for some time now. Reading the regression mailing list thread, they mention that things work differently in 6.1: > Yeah. __filemap_get_folio() works differently in v6.1.y. There it returns a > folio or NULL. In 6.7 it returns a folio or a negative error code. The error > check in cifs_flush_folio() needs to change to something like: > > folio = filemap_get_folio(inode->i_mapping, index); > if (!folio) > return -ENOMEM; > > David okay... so 6.1 is different from 6.5. Since we were okay with the patch, we probably didn't need to add anything further. But they fixed 6.1 with: commit 21bb2ba4f1ac1e3a57594be62dd74e7b1401b2b1 Author: Steve French Date: Fri Jan 12 23:08:51 2024 -0600 Subject: cifs: fix flushing folio regression for 6.1 backport Link: https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/mantic/commit/?id=21bb2ba4f1ac1e3a57594be62dd74e7b1401b2b1 Now, Ubuntu kernels in between upstream stable releases get patches from current upstream stable and long term upstream stable trees. We got both 6.1.x and 6.7.x patches recently... so we pulled in this fix, and it landed in: $ git describe --contains 21bb2ba4f1ac1e3a57594be62dd74e7b1401b2b1 Ubuntu-6.5.0-27.28~162 Wow, what a coincidence. I think this patch is probably not needed in 6.5, and causes the issue. How about I build you a test kernel with "cifs: fix flushing folio regression for 6.1 backport" reverted, and then we see if it fixes things? If it does, I will send a revert to the kernel team. If it doesn't then I will have another look. I'll write back once a test kernel is ready. I'll build you both Jammy HWE and Mantic kernels. If you can help me make a reproducer, that would be great. I can test myself then. Thanks, Matthew ** Tags added: seg -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-hwe-6.5 in Ubuntu. https://bugs.launchpad.net/bugs/2060919 Title: Remote filesystems mounted as CIFS not working after update to Kernel "6.5.0-27-generic #28-Ubuntu" (amd64) or Kernel "6.5.0-1014-raspi #17-Ubuntu" (aarch64). Status in linux package in Ubuntu: Confirmed Status in linux-azure package in Ubuntu: New Status in linux-hwe-6.5 package in Ubuntu: Confirmed Status in linux-raspi package in Ubuntu: Confirmed Bug description: Remote filesystems mounted as CIFS are not working after update to Kernel "6.5.0-27-generic #28-Ubuntu" for x86_64 (and also
[Kernel-packages] [Bug 2060780] Re: CIFS stopped working/is unstable with kernel update to 5.15.0-102.112
Hi everyone, 5.15.0-105-generic has been released to -updates now. It fixes the cifs issue. https://launchpad.net/ubuntu/+source/linux/5.15.0-105.115 Please let us know if you find any more issues. Thanks, Matthew -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2060780 Title: CIFS stopped working/is unstable with kernel update to 5.15.0-102.112 Status in linux package in Ubuntu: Invalid Status in linux source package in Jammy: Fix Released Bug description: Hi, updated some Ubuntu 22.04 systems to lastest available state this morning, which caused CIFS mounts (from various fileservers) to stop working. Kernel was updated to version 5.15.0-102-generic. I can mount the shares without problems (mount -t cifs), but then, df for example tells me: df: /mnt: Resource temporarily unavailable. I'm able to list and browse all the files, but accessing them (even readonly) is very unstable. Sometimes it works and sometimes it just gives me i/o errors. Switching back to 5.15.0-101-generic or 5.15.0-100-generic solves the problem and everything works again as expected. Seems like some bug has been implemented in 5.15.0-102-generic... To reproduce the problem, I started a while loop on one server to write to some file on a specific mounted CIFS share and read it from another one root@:~# while true; do echo "$(date) hallo" >> /mnt/hallo.txt; sleep 1 ; done -bash: /mnt/hallo.txt: Input/output error -bash: /mnt/hallo.txt: Input/output error ^C root@:~$ tail -f /mnt/hallo.txt Tue Apr 9 04:10:52 PM CEST 2024 hallo Tue Apr 9 04:10:53 PM CEST 2024 hallo Tue Apr 9 04:10:54 PM CEST 2024 hallo Tue Apr 9 04:10:55 PM CEST 2024 hallo Tue Apr 9 04:10:56 PM CEST 2024 hallo Tue Apr 9 04:10:57 PM CEST 2024 hallo Tue Apr 9 04:10:58 PM CEST 2024 hallo Tue Apr 9 04:10:59 PM CEST 2024 hallo Tue Apr 9 04:11:00 PM CEST 2024 hallo Tue Apr 9 04:11:01 PM CEST 2024 hallo tail: cannot determine location of '/mnt/hallo.txt'. reverting to polling: Resource temporarily unavailable Tue Apr 9 04:11:04 PM CEST 2024 hallo Tue Apr 9 04:11:05 PM CEST 2024 hallo Tue Apr 9 04:11:06 PM CEST 2024 hallo Tue Apr 9 04:11:07 PM CEST 2024 hallo Tue Apr 9 04:11:08 PM CEST 2024 hallo Tue Apr 9 04:11:09 PM CEST 2024 hallo Tue Apr 9 04:11:10 PM CEST 2024 hallo While doing this, both servers tell me, the resource is unavailable root@:~# df -h /mnt df: /mnt: Resource temporarily unavailable root@:~$ df -h /mnt df: /mnt: Resource temporarily unavailable To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2060780/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Bug 2060780] Re: CIFS stopped working/is unstable with kernel update to 5.15.0-102.112
Hi everyone, 5.15.0-105-generic has been released to -updates now. It fixes the cifs issue. https://launchpad.net/ubuntu/+source/linux/5.15.0-105.115 Please let us know if you find any more issues. Thanks, Matthew -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2060780 Title: CIFS stopped working/is unstable with kernel update to 5.15.0-102.112 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2060780/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2059197] Re: mount.nfs: Fix minor version parsing when '-t nfs4' and '-o vers=4.x' are used together
Performing verification for Focal. I started two VMs, one Jammy, which is the nfs server, and one Focal, which is the client. I used the instructions in the testcase sections of this bug, and also bug 2049262. The Focal VM has nfs-common 1:1.3.4-2.5ubuntu3.6 from -updates. Let's try the testcase for this bug, covering the regression. $ sudo mount -t nfs4 -o vers=4.2 -vvv jammy-nfs-server:/ /mnt mount.nfs4: timeout set for Fri Apr 19 03:12:50 2024 mount.nfs4: trying text-based options 'vers=4.2,addr=192.168.122.109,clientaddr=192.168.122.161' $ sudo umount /mnt $ sudo mount -t nfs4 -o vers=4.1 -vvv jammy-nfs-server:/ /mnt mount.nfs4: timeout set for Fri Apr 19 03:13:23 2024 mount.nfs4: trying text-based options 'vers=4.2,addr=192.168.122.109,clientaddr=192.168.122.161' $ sudo umount /mnt $ sudo mount -t nfs4 -o vers=4.0 -vvv jammy-nfs-server:/ /mnt mount.nfs4: timeout set for Fri Apr 19 03:13:30 2024 mount.nfs4: trying text-based options 'vers=4.2,addr=192.168.122.109,clientaddr=192.168.122.161' $ sudo umount /mnt $ sudo mount -t nfs4 -o vers=4,minorversion=2 -vvv jammy-nfs-server:/ /mnt mount.nfs4: timeout set for Fri Apr 19 03:13:36 2024 mount.nfs4: trying text-based options 'minorversion=2,vers=4.2,addr=192.168.122.109,clientaddr=192.168.122.161' $ sudo umount /mnt $ sudo mount -t nfs4 -o vers=4,minorversion=1 -vvv jammy-nfs-server:/ /mnt mount.nfs4: timeout set for Fri Apr 19 03:13:41 2024 mount.nfs4: trying text-based options 'minorversion=1,vers=4.2,addr=192.168.122.109,clientaddr=192.168.122.161' $ sudo umount /mnt $ sudo mount -t nfs4 -o vers=4,minorversion=0 -vvv jammy-nfs-server:/ /mnt mount.nfs4: timeout set for Fri Apr 19 03:13:47 2024 mount.nfs4: trying text-based options 'minorversion=0,vers=4.2,addr=192.168.122.109,clientaddr=192.168.122.161' $ sudo umount /mnt This behaviour is wrong, as even when we specify the minorversion as .1 or .0, we always get .2, no matter what. We can reproduce the issue. I then enabled -proposed, and installed nfs-common 1:1.3.4-2.5ubuntu3.7. Let's retry the testcase. $ sudo mount -t nfs4 -o vers=4.2 -vvv jammy-nfs-server:/ /mnt mount.nfs4: timeout set for Fri Apr 19 03:17:28 2024 mount.nfs4: trying text-based options 'vers=4.2,addr=192.168.122.109,clientaddr=192.168.122.161' $ sudo umount /mnt $ sudo mount -t nfs4 -o vers=4.1 -vvv jammy-nfs-server:/ /mnt mount.nfs4: timeout set for Fri Apr 19 03:17:35 2024 mount.nfs4: trying text-based options 'vers=4.1,addr=192.168.122.109,clientaddr=192.168.122.161' $ sudo umount /mnt $ sudo mount -t nfs4 -o vers=4.0 -vvv jammy-nfs-server:/ /mnt mount.nfs4: timeout set for Fri Apr 19 03:17:40 2024 mount.nfs4: trying text-based options 'vers=4.0,addr=192.168.122.109,clientaddr=192.168.122.161' $ sudo umount /mnt $ sudo mount -t nfs4 -o vers=4,minorversion=2 -vvv jammy-nfs-server:/ /mnt mount.nfs4: timeout set for Fri Apr 19 03:17:48 2024 mount.nfs4: trying text-based options 'vers=4,vers=4.2,addr=192.168.122.109,clientaddr=192.168.122.161' $ sudo umount /mnt $ sudo mount -t nfs4 -o vers=4,minorversion=1 -vvv jammy-nfs-server:/ /mnt mount.nfs4: timeout set for Fri Apr 19 03:17:54 2024 mount.nfs4: trying text-based options 'vers=4,vers=4.1,addr=192.168.122.109,clientaddr=192.168.122.161' $ sudo umount /mnt $ sudo mount -t nfs4 -o vers=4,minorversion=0 -vvv jammy-nfs-server:/ /mnt mount.nfs4: timeout set for Fri Apr 19 03:18:01 2024 mount.nfs4: trying text-based options 'vers=4,vers=4.0,addr=192.168.122.109,clientaddr=192.168.122.161' $ sudo umount /mnt This looks much better. When we specify both '-t nfs4' and '-o vers=4.x' we get the version we asked for. The version in -proposed fixes the issue. Again, I will run through the original testcase for bug, 2049262: $ sudo cat /proc/fs/nfsd/versions -2 +3 +4 +4.1 +4.2 $ sudo mount -o vers=4 -vvv jammy-nfs-server:/ /mnt mount.nfs: timeout set for Fri Apr 19 03:22:14 2024 mount.nfs: trying text-based options 'vers=4.2,addr=192.168.122.109,clientaddr=192.168.122.161' $ sudo umount /mnt $ sudo mount -o vers=4.2 -vvv jammy-nfs-server:/ /mnt mount.nfs: timeout set for Fri Apr 19 03:22:22 2024 mount.nfs: trying text-based options 'vers=4.2,addr=192.168.122.109,clientaddr=192.168.122.161' $ sudo umount /mnt $ sudo mount -o vers=4.1 -vvv jammy-nfs-server:/ /mnt mount.nfs: timeout set for Fri Apr 19 03:22:28 2024 mount.nfs: trying text-based options 'vers=4.1,addr=192.168.122.109,clientaddr=192.168.122.161' $ sudo umount /mnt $ sudo mount -o vers=4.0 -vvv jammy-nfs-server:/ /mnt mount.nfs: timeout set for Fri Apr 19 03:22:34 2024 mount.nfs: trying text-based options 'vers=4.0,addr=192.168.122.109,clientaddr=192.168.122.161' $ sudo umount /mnt Looks OK. $ sudo cat /proc/fs/nfsd/versions -2 +3 +4 -4.0 +4.1 +4.2 $ sudo mount -o vers=4 -vvv jammy-nfs-server:/ /mnt mount.nfs: timeout set for Fri Apr 19 03:24:31 2024 mount.nfs: trying text-based options 'vers=4.2,addr=192.168.122.109,clientaddr=192.168.122.161' $ sudo umount /mnt $ sudo mount -o vers=4.2 -vvv
[Kernel-packages] [Bug 2062113] Re: CIFS SMB does not work on linux-image-5.15.0-102-generic
*** This bug is a duplicate of bug 2060780 *** https://bugs.launchpad.net/bugs/2060780 ** This bug has been marked a duplicate of bug 2060780 CIFS stopped working/is unstable with kernel update to 5.15.0-102.112 -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2062113 Title: CIFS SMB does not work on linux-image-5.15.0-102-generic Status in linux package in Ubuntu: New Bug description: SMB is not working on this kernel version. I keep getting: [error] Resource temporarily unavailable The only way I was able to fix it was downgrading the kernel back to linux-image-5.15.0-101-generic ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: linux-image-5.15.0-102-generic 5.15.0-102.112 ProcVersionSignature: Ubuntu 5.15.0-102.112-generic 5.15.148 Uname: Linux 5.15.0-102-generic x86_64 AlsaVersion: Advanced Linux Sound Architecture Driver Version k5.15.0-102-generic. AplayDevices: Error: [Errno 2] No such file or directory: 'aplay' ApportVersion: 2.20.11-0ubuntu82.5 Architecture: amd64 ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord' AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/by-path', '/dev/snd/controlC0', '/dev/snd/pcmC0D1c', '/dev/snd/pcmC0D0c', '/dev/snd/pcmC0D0p', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1: CRDA: N/A Card0.Amixer.info: Error: [Errno 2] No such file or directory: 'amixer' Card0.Amixer.values: Error: [Errno 2] No such file or directory: 'amixer' CasperMD5CheckResult: pass CloudArchitecture: x86_64 CloudID: none CloudName: none CloudPlatform: none CloudSubPlatform: config Date: Thu Apr 18 04:41:33 2024 InstallationDate: Installed on 2024-04-18 (0 days ago) InstallationMedia: Ubuntu-Server 22.04.2 LTS "Jammy Jellyfish" - Release amd64 (20230217.1) IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig' Lsusb: Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 002: ID 80ee:0021 VirtualBox USB Tablet Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Lsusb-t: /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ohci-pci/12p, 12M |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 12M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/12p, 480M MachineType: innotek GmbH VirtualBox ProcEnviron: TERM=linux PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash ProcFB: 0 svgadrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-102-generic root=UUID=fda03d5c-0b7d-49cd-a9b9-7786964456a7 ro RebootRequiredPkgs: Error: path contained symlinks. RelatedPackageVersions: linux-restricted-modules-5.15.0-102-generic N/A linux-backports-modules-5.15.0-102-generic N/A linux-firmware 20220329.git681281e4-0ubuntu3.29 RfKill: Error: [Errno 2] No such file or directory: 'rfkill' SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 12/01/2006 dmi.bios.vendor: innotek GmbH dmi.bios.version: VirtualBox dmi.board.name: VirtualBox dmi.board.vendor: Oracle Corporation dmi.board.version: 1.2 dmi.chassis.type: 1 dmi.chassis.vendor: Oracle Corporation dmi.modalias: dmi:bvninnotekGmbH:bvrVirtualBox:bd12/01/2006:svninnotekGmbH:pnVirtualBox:pvr1.2:rvnOracleCorporation:rnVirtualBox:rvr1.2:cvnOracleCorporation:ct1:cvr:sku: dmi.product.family: Virtual Machine dmi.product.name: VirtualBox dmi.product.version: 1.2 dmi.sys.vendor: innotek GmbH To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2062113/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Bug 2062113] Re: CIFS SMB does not work on linux-image-5.15.0-102-generic
*** This bug is a duplicate of bug 2060780 *** https://bugs.launchpad.net/bugs/2060780 ** This bug has been marked a duplicate of bug 2060780 CIFS stopped working/is unstable with kernel update to 5.15.0-102.112 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2062113 Title: CIFS SMB does not work on linux-image-5.15.0-102-generic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2062113/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Kernel-packages] [Bug 2060780] Re: CIFS stopped working/is unstable with kernel update to 5.15.0-102.112
Performing verification for Jammy. I started two Jammy VMs. One is a server and the other a client. Server -- $ sudo apt update $ sudo apt upgrade $ sudo apt install samba $ sudo vim /etc/samba/smb.conf [sambashare] comment = Samba on Ubuntu path = /home/ubuntu/sambashare read only = no browsable = yes $ mkdir ~/sambashare $ sudo smbpasswd -a ubuntu Client -- $ sudo apt update $ sudo apt install cifs-utils $ mkdir ~/share $ sudo mount -t cifs -o username=ubuntu //192.168.122.172/sambashare ~/share The client is using 5.15.0-102-generic from updates: $ uname -rv 5.15.0-102-generic #112-Ubuntu SMP Tue Mar 5 16:50:32 UTC 2024 $ sudo -s # while true; do echo "$(date) hallo" >> ./share/hallo.txt; sleep 1 ; done Launch a separate terminal and run: $ df -h ~/share df: /home/ubuntu/share: Resource temporarily unavailable The issue is seen. I then enabled -proposed and installed 5.15.0-105-generic. I had to use the -proposed2 repository due to the packages not being present in the primary archive -proposed repository. https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/proposed2 $ uname -rv 5.15.0-105-generic #115-Ubuntu SMP Mon Apr 15 09:52:04 UTC 2024 $ sudo -s # while true; do echo "$(date) hallo" >> ./share/hallo.txt; sleep 1 ; done $ df -h ~/share FilesystemSize Used Avail Use% Mounted on //192.168.122.247/sambashare 9.6G 2.1G 7.5G 23% /home/ubuntu/share CIFS is back to working again, and we can df the share and see the disk usage. The respun kernel in -proposed fixes the issue, happy to mark verified for Jammy. ** Tags removed: verification-needed-jammy-linux ** Tags added: verification-done-jammy-linux -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2060780 Title: CIFS stopped working/is unstable with kernel update to 5.15.0-102.112 Status in linux package in Ubuntu: Invalid Status in linux source package in Jammy: Fix Committed Bug description: Hi, updated some Ubuntu 22.04 systems to lastest available state this morning, which caused CIFS mounts (from various fileservers) to stop working. Kernel was updated to version 5.15.0-102-generic. I can mount the shares without problems (mount -t cifs), but then, df for example tells me: df: /mnt: Resource temporarily unavailable. I'm able to list and browse all the files, but accessing them (even readonly) is very unstable. Sometimes it works and sometimes it just gives me i/o errors. Switching back to 5.15.0-101-generic or 5.15.0-100-generic solves the problem and everything works again as expected. Seems like some bug has been implemented in 5.15.0-102-generic... To reproduce the problem, I started a while loop on one server to write to some file on a specific mounted CIFS share and read it from another one root@:~# while true; do echo "$(date) hallo" >> /mnt/hallo.txt; sleep 1 ; done -bash: /mnt/hallo.txt: Input/output error -bash: /mnt/hallo.txt: Input/output error ^C root@:~$ tail -f /mnt/hallo.txt Tue Apr 9 04:10:52 PM CEST 2024 hallo Tue Apr 9 04:10:53 PM CEST 2024 hallo Tue Apr 9 04:10:54 PM CEST 2024 hallo Tue Apr 9 04:10:55 PM CEST 2024 hallo Tue Apr 9 04:10:56 PM CEST 2024 hallo Tue Apr 9 04:10:57 PM CEST 2024 hallo Tue Apr 9 04:10:58 PM CEST 2024 hallo Tue Apr 9 04:10:59 PM CEST 2024 hallo Tue Apr 9 04:11:00 PM CEST 2024 hallo Tue Apr 9 04:11:01 PM CEST 2024 hallo tail: cannot determine location of '/mnt/hallo.txt'. reverting to polling: Resource temporarily unavailable Tue Apr 9 04:11:04 PM CEST 2024 hallo Tue Apr 9 04:11:05 PM CEST 2024 hallo Tue Apr 9 04:11:06 PM CEST 2024 hallo Tue Apr 9 04:11:07 PM CEST 2024 hallo Tue Apr 9 04:11:08 PM CEST 2024 hallo Tue Apr 9 04:11:09 PM CEST 2024 hallo Tue Apr 9 04:11:10 PM CEST 2024 hallo While doing this, both servers tell me, the resource is unavailable root@:~# df -h /mnt df: /mnt: Resource temporarily unavailable root@:~$ df -h /mnt df: /mnt: Resource temporarily unavailable To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2060780/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Bug 2060780] Re: CIFS stopped working/is unstable with kernel update to 5.15.0-102.112
Performing verification for Jammy. I started two Jammy VMs. One is a server and the other a client. Server -- $ sudo apt update $ sudo apt upgrade $ sudo apt install samba $ sudo vim /etc/samba/smb.conf [sambashare] comment = Samba on Ubuntu path = /home/ubuntu/sambashare read only = no browsable = yes $ mkdir ~/sambashare $ sudo smbpasswd -a ubuntu Client -- $ sudo apt update $ sudo apt install cifs-utils $ mkdir ~/share $ sudo mount -t cifs -o username=ubuntu //192.168.122.172/sambashare ~/share The client is using 5.15.0-102-generic from updates: $ uname -rv 5.15.0-102-generic #112-Ubuntu SMP Tue Mar 5 16:50:32 UTC 2024 $ sudo -s # while true; do echo "$(date) hallo" >> ./share/hallo.txt; sleep 1 ; done Launch a separate terminal and run: $ df -h ~/share df: /home/ubuntu/share: Resource temporarily unavailable The issue is seen. I then enabled -proposed and installed 5.15.0-105-generic. I had to use the -proposed2 repository due to the packages not being present in the primary archive -proposed repository. https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/proposed2 $ uname -rv 5.15.0-105-generic #115-Ubuntu SMP Mon Apr 15 09:52:04 UTC 2024 $ sudo -s # while true; do echo "$(date) hallo" >> ./share/hallo.txt; sleep 1 ; done $ df -h ~/share FilesystemSize Used Avail Use% Mounted on //192.168.122.247/sambashare 9.6G 2.1G 7.5G 23% /home/ubuntu/share CIFS is back to working again, and we can df the share and see the disk usage. The respun kernel in -proposed fixes the issue, happy to mark verified for Jammy. ** Tags removed: verification-needed-jammy-linux ** Tags added: verification-done-jammy-linux -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2060780 Title: CIFS stopped working/is unstable with kernel update to 5.15.0-102.112 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2060780/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2060780] Re: CIFS stopped working/is unstable with kernel update to 5.15.0-102.112
Hi everyone, the fix will also be available for Focal, as part of it getting the Jammy HWE kernel. It will be released at the same time as Jammy's kernel is released. We got the notification above that the kernel should be in -proposed, but I have been refreshing -proposed all day and the kernel is still not copied in just yet. Once it reaches -proposed, I will test it, and let you know when you can do some testing too. But for the moment, we need to be patient while it gets copied into -proposed. Thanks, Matthew -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2060780 Title: CIFS stopped working/is unstable with kernel update to 5.15.0-102.112 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2060780/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Kernel-packages] [Bug 2060780] Re: CIFS stopped working/is unstable with kernel update to 5.15.0-102.112
Hi everyone, the fix will also be available for Focal, as part of it getting the Jammy HWE kernel. It will be released at the same time as Jammy's kernel is released. We got the notification above that the kernel should be in -proposed, but I have been refreshing -proposed all day and the kernel is still not copied in just yet. Once it reaches -proposed, I will test it, and let you know when you can do some testing too. But for the moment, we need to be patient while it gets copied into -proposed. Thanks, Matthew -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2060780 Title: CIFS stopped working/is unstable with kernel update to 5.15.0-102.112 Status in linux package in Ubuntu: Invalid Status in linux source package in Jammy: Fix Committed Bug description: Hi, updated some Ubuntu 22.04 systems to lastest available state this morning, which caused CIFS mounts (from various fileservers) to stop working. Kernel was updated to version 5.15.0-102-generic. I can mount the shares without problems (mount -t cifs), but then, df for example tells me: df: /mnt: Resource temporarily unavailable. I'm able to list and browse all the files, but accessing them (even readonly) is very unstable. Sometimes it works and sometimes it just gives me i/o errors. Switching back to 5.15.0-101-generic or 5.15.0-100-generic solves the problem and everything works again as expected. Seems like some bug has been implemented in 5.15.0-102-generic... To reproduce the problem, I started a while loop on one server to write to some file on a specific mounted CIFS share and read it from another one root@:~# while true; do echo "$(date) hallo" >> /mnt/hallo.txt; sleep 1 ; done -bash: /mnt/hallo.txt: Input/output error -bash: /mnt/hallo.txt: Input/output error ^C root@:~$ tail -f /mnt/hallo.txt Tue Apr 9 04:10:52 PM CEST 2024 hallo Tue Apr 9 04:10:53 PM CEST 2024 hallo Tue Apr 9 04:10:54 PM CEST 2024 hallo Tue Apr 9 04:10:55 PM CEST 2024 hallo Tue Apr 9 04:10:56 PM CEST 2024 hallo Tue Apr 9 04:10:57 PM CEST 2024 hallo Tue Apr 9 04:10:58 PM CEST 2024 hallo Tue Apr 9 04:10:59 PM CEST 2024 hallo Tue Apr 9 04:11:00 PM CEST 2024 hallo Tue Apr 9 04:11:01 PM CEST 2024 hallo tail: cannot determine location of '/mnt/hallo.txt'. reverting to polling: Resource temporarily unavailable Tue Apr 9 04:11:04 PM CEST 2024 hallo Tue Apr 9 04:11:05 PM CEST 2024 hallo Tue Apr 9 04:11:06 PM CEST 2024 hallo Tue Apr 9 04:11:07 PM CEST 2024 hallo Tue Apr 9 04:11:08 PM CEST 2024 hallo Tue Apr 9 04:11:09 PM CEST 2024 hallo Tue Apr 9 04:11:10 PM CEST 2024 hallo While doing this, both servers tell me, the resource is unavailable root@:~# df -h /mnt df: /mnt: Resource temporarily unavailable root@:~$ df -h /mnt df: /mnt: Resource temporarily unavailable To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2060780/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
Re: pastebinit default target on Ubuntu
I think we should be pointing it back to paste.ubuntu.com, because our existing users expect it will go to a distro owned pastebin, and we should remain consistent. I am also all for keeping user data on IS controlled assets, we don't exactly know who controls dpaste, and if they parse dmesg or ceph logs for call traces etc that might contain juicy data. For the login issue, perhaps we could do a quick entropy test on the uploaded data. Log data is very repetitive, even on long logs, so it will have low entropy. Base64 encoded data will have high entropy. We just reject any high entropy submissions, and remove the login to view requirement. I use pastebinit all the time, and it would be nice to default back to paste.ubuntu.com. Thanks, Matthew On Tue, 16 Apr 2024 at 08:44, Stéphane Graber wrote: > > On Mon, Apr 15, 2024 at 4:14 PM Steve Langasek > wrote: > > > > On Mon, Apr 15, 2024 at 04:48:17PM +0100, Robie Basak wrote: > > > Prior to Noble, the pastebinit command defaulted to paste.ubuntu.com. In > > > Noble, this has changed to dpaste.com due to an upstream change[1]. > > > > > What do Ubuntu developers think the default should be? If it should > > > remain paste.ubuntu.com, we can ask upstream to change it back, or add a > > > delta for now. > > > > > Reason to keep it dpaste.com: > > > > > People have complained that the login requirement makes it unusable for > > > helping Ubuntu users at large who don't necessarily have an Ubuntu SSO > > > account. > > > > > Reason to keep it paste.ubuntu.com: > > > > > I'm not keen on relying on third party services when not necessary, > > > especially ad-supported ones. I have no reason to distrust the current > > > operator, but in general, these things tend to go wrong sooner or later. > > > > > There was more discussion on IRC[2]. > > > > > [1] > > > https://github.com/pastebinit/pastebinit/commit/5c668fb3ed9b4a103eb22b16e603050a539951e0 > > > [2] https://irclogs.ubuntu.com/2024/04/15/%23ubuntu-devel.html#t14:17 > > > > I was not pleased to see the switch to dpaste.com. I've found that it's > > pretty unusable on mobile, and I don't like this pointing to a service we > > don't control. > > > > And if there are issues with the usability of paste.ubuntu.com, uh, we own > > that service? So let's work with our IS team to make it fit for purpose. > > (I don't know why it currently requires a login to *view* paste contents; > > that seems straightforwardly a bug that we should just get sorted.) > > That's because pastebin servers are frequently abused as a way to get > free mass storage. > > It's not very practical to require login to post to a pastebin as the > whole point is for a tool like "pastebinit" to work without needing > user configuration as it's commonly used as a debug tool on cloud > instances and other random servers random than a user's personal > system. > > With that in mind, a bunch of folks noticed that you could abuse a > service like paste.ubuntu.com by pushing large files (base64 encoded > or the like) and then retrieve them with a very trivial amount of html > parsing (if no raw option is offered directly). > > > There are obviously alternatives to this, but they tend to require a > bunch more server side logic, basically trying to find the right set > of restrictions to both poster and reader so that legitimate users can > use the service normally while abusers get sufficiently annoyed to > stay away from it. > > > -- > > Steve Langasek Give me a lever long enough and a Free OS > > Debian Developer to set it on, and I can move the world. > > Ubuntu Developer https://www.debian.org/ > > slanga...@ubuntu.com vor...@debian.org > > -- > > ubuntu-devel mailing list > > ubuntu-devel@lists.ubuntu.com > > Modify settings or unsubscribe at: > > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel > > > > -- > Stéphane > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
[Kernel-packages] [Bug 2060780] Re: CIFS stopped working/is unstable with kernel update to 5.15.0-102.112
The new kernel is tagged as 5.15.0-105-generic, and it is a respin of 5.15.0-103-generic with the fix. https://git.launchpad.net/~ubuntu- kernel/ubuntu/+source/linux/+git/jammy/log/?h=Ubuntu-5.15.0-105.115 It should be available in -proposed soon, the Kernel Team are still rebuilding all the 5.15 derivatives. I'll write back once it is in -proposed for testing. Thanks, Matthew -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2060780 Title: CIFS stopped working/is unstable with kernel update to 5.15.0-102.112 Status in linux package in Ubuntu: Invalid Status in linux source package in Jammy: Fix Committed Bug description: Hi, updated some Ubuntu 22.04 systems to lastest available state this morning, which caused CIFS mounts (from various fileservers) to stop working. Kernel was updated to version 5.15.0-102-generic. I can mount the shares without problems (mount -t cifs), but then, df for example tells me: df: /mnt: Resource temporarily unavailable. I'm able to list and browse all the files, but accessing them (even readonly) is very unstable. Sometimes it works and sometimes it just gives me i/o errors. Switching back to 5.15.0-101-generic or 5.15.0-100-generic solves the problem and everything works again as expected. Seems like some bug has been implemented in 5.15.0-102-generic... To reproduce the problem, I started a while loop on one server to write to some file on a specific mounted CIFS share and read it from another one root@:~# while true; do echo "$(date) hallo" >> /mnt/hallo.txt; sleep 1 ; done -bash: /mnt/hallo.txt: Input/output error -bash: /mnt/hallo.txt: Input/output error ^C root@:~$ tail -f /mnt/hallo.txt Tue Apr 9 04:10:52 PM CEST 2024 hallo Tue Apr 9 04:10:53 PM CEST 2024 hallo Tue Apr 9 04:10:54 PM CEST 2024 hallo Tue Apr 9 04:10:55 PM CEST 2024 hallo Tue Apr 9 04:10:56 PM CEST 2024 hallo Tue Apr 9 04:10:57 PM CEST 2024 hallo Tue Apr 9 04:10:58 PM CEST 2024 hallo Tue Apr 9 04:10:59 PM CEST 2024 hallo Tue Apr 9 04:11:00 PM CEST 2024 hallo Tue Apr 9 04:11:01 PM CEST 2024 hallo tail: cannot determine location of '/mnt/hallo.txt'. reverting to polling: Resource temporarily unavailable Tue Apr 9 04:11:04 PM CEST 2024 hallo Tue Apr 9 04:11:05 PM CEST 2024 hallo Tue Apr 9 04:11:06 PM CEST 2024 hallo Tue Apr 9 04:11:07 PM CEST 2024 hallo Tue Apr 9 04:11:08 PM CEST 2024 hallo Tue Apr 9 04:11:09 PM CEST 2024 hallo Tue Apr 9 04:11:10 PM CEST 2024 hallo While doing this, both servers tell me, the resource is unavailable root@:~# df -h /mnt df: /mnt: Resource temporarily unavailable root@:~$ df -h /mnt df: /mnt: Resource temporarily unavailable To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2060780/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Bug 2060780] Re: CIFS stopped working/is unstable with kernel update to 5.15.0-102.112
The new kernel is tagged as 5.15.0-105-generic, and it is a respin of 5.15.0-103-generic with the fix. https://git.launchpad.net/~ubuntu- kernel/ubuntu/+source/linux/+git/jammy/log/?h=Ubuntu-5.15.0-105.115 It should be available in -proposed soon, the Kernel Team are still rebuilding all the 5.15 derivatives. I'll write back once it is in -proposed for testing. Thanks, Matthew -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2060780 Title: CIFS stopped working/is unstable with kernel update to 5.15.0-102.112 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2060780/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Kernel-packages] [Bug 2061248] Re: kernel 5.15.0-102 - CIFS mount problem (NAS)
*** This bug is a duplicate of bug 2060780 *** https://bugs.launchpad.net/bugs/2060780 Come over to bug 2060780 and talk about it with us there. ** This bug has been marked a duplicate of bug 2060780 CIFS stopped working/is unstable with kernel update to 5.15.0-102.112 -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2061248 Title: kernel 5.15.0-102 - CIFS mount problem (NAS) Status in linux package in Ubuntu: New Bug description: CIFS are regulary mounted via fstab (system has been stable for several years) and everything was fine with .101 but after the 08-apr-2024 kernel update suddenly the NAS shares are often stuck or timed out, unresponsive and not accessible (unavailable). Reverting from .102 to .101 brought everything back to working order as it was before kernel update. Something in the latest kernel 5.15.0-102 is not good for CIFS shares. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2061248/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Bug 2061248] Re: kernel 5.15.0-102 - CIFS mount problem (NAS)
*** This bug is a duplicate of bug 2060780 *** https://bugs.launchpad.net/bugs/2060780 Come over to bug 2060780 and talk about it with us there. ** This bug has been marked a duplicate of bug 2060780 CIFS stopped working/is unstable with kernel update to 5.15.0-102.112 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2061248 Title: kernel 5.15.0-102 - CIFS mount problem (NAS) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2061248/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Kernel-packages] [Bug 2060780] Re: CIFS stopped working/is unstable with kernel update to 5.15.0-102.112
Hi everyone, 5.15.0-104-generic just hit jammy-proposed a couple minutes ago. It isn't available for focal users yet. Can someone please test 5.15.0-104-generic on jammy and let me know if it fixes the issue? Thanks. Instructions to Install (On a mantic system): 1) cat << EOF | sudo tee /etc/apt/sources.list.d/ubuntu-$(lsb_release -cs)-proposed.list # Enable Ubuntu proposed archive deb http://archive.ubuntu.com/ubuntu/ $(lsb_release -cs)-proposed main universe EOF 2) sudo apt update 3) sudo apt install linux-image-5.15.0-104-generic linux-modules-5.15.0-104-generic linux-modules-extra-5.15.0-104-generic linux-headers-5.15.0-104-generic 4) sudo rm /etc/apt/sources.list.d/ubuntu-$(lsb_release -cs)-proposed.list 5) sudo apt update 6) sudo reboot 5.15.0-104-generic #114-Ubuntu SMP Thu Mar 28 15:39:51 UTC 2024 Just a note that 5.15.0-104-generic is a part of the 2024.04.01 SRU cycle, and will likely be released at the end of month, as per https://kernel.ubuntu.com/, and won't be coming out any sooner. Thanks, Matthew -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2060780 Title: CIFS stopped working/is unstable with kernel update to 5.15.0-102.112 Status in linux package in Ubuntu: Confirmed Status in linux source package in Jammy: Fix Committed Bug description: Hi, updated some Ubuntu 22.04 systems to lastest available state this morning, which caused CIFS mounts (from various fileservers) to stop working. Kernel was updated to version 5.15.0-102-generic. I can mount the shares without problems (mount -t cifs), but then, df for example tells me: df: /mnt: Resource temporarily unavailable. I'm able to list and browse all the files, but accessing them (even readonly) is very unstable. Sometimes it works and sometimes it just gives me i/o errors. Switching back to 5.15.0-101-generic or 5.15.0-100-generic solves the problem and everything works again as expected. Seems like some bug has been implemented in 5.15.0-102-generic... To reproduce the problem, I started a while loop on one server to write to some file on a specific mounted CIFS share and read it from another one root@:~# while true; do echo "$(date) hallo" >> /mnt/hallo.txt; sleep 1 ; done -bash: /mnt/hallo.txt: Input/output error -bash: /mnt/hallo.txt: Input/output error ^C root@:~$ tail -f /mnt/hallo.txt Tue Apr 9 04:10:52 PM CEST 2024 hallo Tue Apr 9 04:10:53 PM CEST 2024 hallo Tue Apr 9 04:10:54 PM CEST 2024 hallo Tue Apr 9 04:10:55 PM CEST 2024 hallo Tue Apr 9 04:10:56 PM CEST 2024 hallo Tue Apr 9 04:10:57 PM CEST 2024 hallo Tue Apr 9 04:10:58 PM CEST 2024 hallo Tue Apr 9 04:10:59 PM CEST 2024 hallo Tue Apr 9 04:11:00 PM CEST 2024 hallo Tue Apr 9 04:11:01 PM CEST 2024 hallo tail: cannot determine location of '/mnt/hallo.txt'. reverting to polling: Resource temporarily unavailable Tue Apr 9 04:11:04 PM CEST 2024 hallo Tue Apr 9 04:11:05 PM CEST 2024 hallo Tue Apr 9 04:11:06 PM CEST 2024 hallo Tue Apr 9 04:11:07 PM CEST 2024 hallo Tue Apr 9 04:11:08 PM CEST 2024 hallo Tue Apr 9 04:11:09 PM CEST 2024 hallo Tue Apr 9 04:11:10 PM CEST 2024 hallo While doing this, both servers tell me, the resource is unavailable root@:~# df -h /mnt df: /mnt: Resource temporarily unavailable root@:~$ df -h /mnt df: /mnt: Resource temporarily unavailable To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2060780/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Bug 2060780] Re: CIFS stopped working/is unstable with kernel update to 5.15.0-102.112
Hi everyone, 5.15.0-104-generic just hit jammy-proposed a couple minutes ago. It isn't available for focal users yet. Can someone please test 5.15.0-104-generic on jammy and let me know if it fixes the issue? Thanks. Instructions to Install (On a mantic system): 1) cat << EOF | sudo tee /etc/apt/sources.list.d/ubuntu-$(lsb_release -cs)-proposed.list # Enable Ubuntu proposed archive deb http://archive.ubuntu.com/ubuntu/ $(lsb_release -cs)-proposed main universe EOF 2) sudo apt update 3) sudo apt install linux-image-5.15.0-104-generic linux-modules-5.15.0-104-generic linux-modules-extra-5.15.0-104-generic linux-headers-5.15.0-104-generic 4) sudo rm /etc/apt/sources.list.d/ubuntu-$(lsb_release -cs)-proposed.list 5) sudo apt update 6) sudo reboot 5.15.0-104-generic #114-Ubuntu SMP Thu Mar 28 15:39:51 UTC 2024 Just a note that 5.15.0-104-generic is a part of the 2024.04.01 SRU cycle, and will likely be released at the end of month, as per https://kernel.ubuntu.com/, and won't be coming out any sooner. Thanks, Matthew -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2060780 Title: CIFS stopped working/is unstable with kernel update to 5.15.0-102.112 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2060780/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2059197] Re: mount.nfs: Fix minor version parsing when '-t nfs4' and '-o vers=4.x' are used together
Thanks for pointing out the missing patch Heitor. I was indeed missing it. Please review and sponsor the V2 debdiff. Thanks, Matthew -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2059197 Title: mount.nfs: Fix minor version parsing when '-t nfs4' and '-o vers=4.x' are used together To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/2059197/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2059197] Re: mount.nfs: Fix minor version parsing when '-t nfs4' and '-o vers=4.x' are used together
Sanity testing the test package: https://launchpad.net/~mruffell/+archive/ubuntu/lp2059197-test nfs-common 1:1.3.4-2.5ubuntu3.6+lp2059197v20240411b1 Testcase for this bug, i.e. the regression. $ sudo mount -t nfs4 -o vers=4.2 -vvv jammy-nfs-server:/ /mnt mount.nfs4: timeout set for Thu Apr 11 05:14:52 2024 mount.nfs4: trying text-based options 'vers=4.2,addr=192.168.122.14,clientaddr=192.168.122.249' $ sudo mount -t nfs4 -o vers=4.1 -vvv jammy-nfs-server:/ /mnt mount.nfs4: timeout set for Thu Apr 11 05:10:26 2024 mount.nfs4: trying text-based options 'vers=4.1,addr=192.168.122.14,clientaddr=192.168.122.249' $ sudo mount -t nfs4 -o vers=4.0 -vvv jammy-nfs-server:/ /mnt mount.nfs4: timeout set for Thu Apr 11 05:15:02 2024 mount.nfs4: trying text-based options 'vers=4.0,addr=192.168.122.14,clientaddr=192.168.122.249' $ sudo mount -t nfs4 -o vers=4,minorversion=2 -vvv jammy-nfs-server:/ /mnt mount.nfs4: timeout set for Thu Apr 11 05:15:48 2024 mount.nfs4: trying text-based options 'vers=4,vers=4.2,addr=192.168.122.14,clientaddr=192.168.122.249' $ sudo mount -t nfs4 -o vers=4,minorversion=1 -vvv jammy-nfs-server:/ /mnt mount.nfs4: timeout set for Thu Apr 11 05:13:33 2024 mount.nfs4: trying text-based options 'vers=4,vers=4.1,addr=192.168.122.14,clientaddr=192.168.122.249' $ sudo mount -t nfs4 -o vers=4,minorversion=0 -vvv jammy-nfs-server:/ /mnt mount.nfs4: timeout set for Thu Apr 11 05:15:54 2024 mount.nfs4: trying text-based options 'vers=4,vers=4.0,addr=192.168.122.14,clientaddr=192.168.122.249' Looks OK. Testcase for the original bug, 2049262: $ sudo cat /proc/fs/nfsd/versions -2 +3 +4 +4.1 +4.2 $ sudo mount -o vers=4 -vvv jammy-nfs-server:/ /mnt mount.nfs: timeout set for Thu Apr 11 05:17:55 2024 mount.nfs: trying text-based options 'vers=4.2,addr=192.168.122.14,clientaddr=192.168.122.249' $ sudo umount /mnt $ sudo mount -o vers=4.2 -vvv jammy-nfs-server:/ /mnt mount.nfs: timeout set for Thu Apr 11 05:18:01 2024 mount.nfs: trying text-based options 'vers=4.2,addr=192.168.122.14,clientaddr=192.168.122.249' $ sudo umount /mnt $ sudo mount -o vers=4.1 -vvv jammy-nfs-server:/ /mnt mount.nfs: timeout set for Thu Apr 11 05:18:05 2024 mount.nfs: trying text-based options 'vers=4.1,addr=192.168.122.14,clientaddr=192.168.122.249' $ sudo umount /mnt $ sudo mount -o vers=4.0 -vvv jammy-nfs-server:/ /mnt mount.nfs: timeout set for Thu Apr 11 05:18:12 2024 mount.nfs: trying text-based options 'vers=4.0,addr=192.168.122.14,clientaddr=192.168.122.249' Looks OK. $ sudo cat /proc/fs/nfsd/versions -2 +3 +4 -4.0 +4.1 +4.2 $ sudo mount -o vers=4 -vvv jammy-nfs-server:/ /mnt mount.nfs: timeout set for Thu Apr 11 05:20:40 2024 mount.nfs: trying text-based options 'vers=4.2,addr=192.168.122.14,clientaddr=192.168.122.249' $ sudo umount /mnt $ sudo mount -o vers=4.2 -vvv jammy-nfs-server:/ /mnt mount.nfs: timeout set for Thu Apr 11 05:20:47 2024 mount.nfs: trying text-based options 'vers=4.2,addr=192.168.122.14,clientaddr=192.168.122.249' $ sudo umount /mnt $ sudo mount -o vers=4.1 -vvv jammy-nfs-server:/ /mnt mount.nfs: timeout set for Thu Apr 11 05:20:53 2024 mount.nfs: trying text-based options 'vers=4.1,addr=192.168.122.14,clientaddr=192.168.122.249' $ sudo umount /mnt $ sudo mount -o vers=4.0 -vvv jammy-nfs-server:/ /mnt mount.nfs: timeout set for Thu Apr 11 05:21:02 2024 mount.nfs: trying text-based options 'vers=4.0,addr=192.168.122.14,clientaddr=192.168.122.249' mount.nfs: mount(2): Protocol not supported mount.nfs: Protocol not supported Looks OK. $ sudo cat /proc/fs/nfsd/versions -2 +3 +4 -4.0 +4.1 -4.2 $ sudo mount -o vers=4 -vvv jammy-nfs-server:/ /mnt mount.nfs: timeout set for Thu Apr 11 05:22:32 2024 mount.nfs: trying text-based options 'vers=4.2,addr=192.168.122.14,clientaddr=192.168.122.249' mount.nfs: mount(2): Protocol not supported mount.nfs: trying text-based options 'vers=4.1,addr=192.168.122.14,clientaddr=192.168.122.249' $ sudo umount /mnt $ sudo mount -o vers=4.2 -vvv jammy-nfs-server:/ /mnt mount.nfs: timeout set for Thu Apr 11 05:22:38 2024 mount.nfs: trying text-based options 'vers=4.2,addr=192.168.122.14,clientaddr=192.168.122.249' mount.nfs: mount(2): Protocol not supported mount.nfs: Protocol not supported $ sudo umount /mnt umount: /mnt: not mounted. $ sudo mount -o vers=4.1 -vvv jammy-nfs-server:/ /mnt mount.nfs: timeout set for Thu Apr 11 05:22:44 2024 mount.nfs: trying text-based options 'vers=4.1,addr=192.168.122.14,clientaddr=192.168.122.249' $ sudo umount /mnt $ sudo mount -o vers=4.0 -vvv jammy-nfs-server:/ /mnt mount.nfs: timeout set for Thu Apr 11 05:22:49 2024 mount.nfs: trying text-based options 'vers=4.0,addr=192.168.122.14,clientaddr=192.168.122.249' mount.nfs: mount(2): Protocol not supported mount.nfs: Protocol not supported Looks OK. $ sudo cat /proc/fs/nfsd/versions -2 +3 +4 -4.1 -4.2 $ sudo mount -o vers=4 -vvv jammy-nfs-server:/ /mnt mount.nfs: timeout set for Thu Apr 11 05:23:46 2024 mount.nfs: trying text-based options
[Kernel-packages] [Bug 2060780] Re: CIFS stopped working/is unstable with kernel update to 5.15.0-102.112
Hi everyone, Reading: https://lore.kernel.org/lkml/2024020616.454699-1-kova...@altlinux.org/T/ It seems the issue was introduced in commit 33eae65c6f49770fec7a662935d4eb4a6406d24b Author: Paulo Alcantara Date: Wed Dec 13 12:25:57 2023 -0300 Subject: smb: client: fix OOB in SMB2_query_info_init() Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=33eae65c6f49770fec7a662935d4eb4a6406d24b this was indeed landed in 5.15.0-102-generic: $ git log --grep "smb: client: fix OOB in SMB2_query_info_init()" origin/master-next commit ed30eac9715d0bd5512ee42ca8e8f340d2d9d2d5 ... $ git describe --contains ed30eac9715d0bd5512ee42ca8e8f340d2d9d2d5 Ubuntu-5.15.0-102.112~472 The link mentions it is supposedly fixed in: commit b5d623611c9cda84ebb5e5bd044587955eaf782f Author: Kees Cook Date: Fri Feb 17 16:24:40 2023 -0800 Subject: smb3: Replace smb2pdu 1-element arrays with flex-arrays Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b5d623611c9cda84ebb5e5bd044587955eaf782f Looking at the Jammy kernel tree: $ git log --grep "smb3: Replace smb2pdu 1-element arrays with flex-arrays" origin/master-next commit b5d623611c9cda84ebb5e5bd044587955eaf782f $ git describe --contains b5d623611c9cda84ebb5e5bd044587955eaf782f Ubuntu-5.15.0-104.114~23 It seems it is already applied and tagged in 5.15.0-104-generic. This seems to be built, but not quite in -proposed yet: https://kernel.ubuntu.com/reports/kernel-stable-board/ I will write back as soon as 5.15.0-104-generic is in -proposed, with instructions on how to test it, and see if it fixes the issue. Thanks, Matthew -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2060780 Title: CIFS stopped working/is unstable with kernel update to 5.15.0-102.112 Status in linux package in Ubuntu: Confirmed Status in linux source package in Jammy: Fix Committed Bug description: Hi, updated some Ubuntu 22.04 systems to lastest available state this morning, which caused CIFS mounts (from various fileservers) to stop working. Kernel was updated to version 5.15.0-102-generic. I can mount the shares without problems (mount -t cifs), but then, df for example tells me: df: /mnt: Resource temporarily unavailable. I'm able to list and browse all the files, but accessing them (even readonly) is very unstable. Sometimes it works and sometimes it just gives me i/o errors. Switching back to 5.15.0-101-generic or 5.15.0-100-generic solves the problem and everything works again as expected. Seems like some bug has been implemented in 5.15.0-102-generic... To reproduce the problem, I started a while loop on one server to write to some file on a specific mounted CIFS share and read it from another one root@:~# while true; do echo "$(date) hallo" >> /mnt/hallo.txt; sleep 1 ; done -bash: /mnt/hallo.txt: Input/output error -bash: /mnt/hallo.txt: Input/output error ^C root@:~$ tail -f /mnt/hallo.txt Tue Apr 9 04:10:52 PM CEST 2024 hallo Tue Apr 9 04:10:53 PM CEST 2024 hallo Tue Apr 9 04:10:54 PM CEST 2024 hallo Tue Apr 9 04:10:55 PM CEST 2024 hallo Tue Apr 9 04:10:56 PM CEST 2024 hallo Tue Apr 9 04:10:57 PM CEST 2024 hallo Tue Apr 9 04:10:58 PM CEST 2024 hallo Tue Apr 9 04:10:59 PM CEST 2024 hallo Tue Apr 9 04:11:00 PM CEST 2024 hallo Tue Apr 9 04:11:01 PM CEST 2024 hallo tail: cannot determine location of '/mnt/hallo.txt'. reverting to polling: Resource temporarily unavailable Tue Apr 9 04:11:04 PM CEST 2024 hallo Tue Apr 9 04:11:05 PM CEST 2024 hallo Tue Apr 9 04:11:06 PM CEST 2024 hallo Tue Apr 9 04:11:07 PM CEST 2024 hallo Tue Apr 9 04:11:08 PM CEST 2024 hallo Tue Apr 9 04:11:09 PM CEST 2024 hallo Tue Apr 9 04:11:10 PM CEST 2024 hallo While doing this, both servers tell me, the resource is unavailable root@:~# df -h /mnt df: /mnt: Resource temporarily unavailable root@:~$ df -h /mnt df: /mnt: Resource temporarily unavailable To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2060780/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Bug 2060780] Re: CIFS stopped working/is unstable with kernel update to 5.15.0-102.112
Hi everyone, Reading: https://lore.kernel.org/lkml/2024020616.454699-1-kova...@altlinux.org/T/ It seems the issue was introduced in commit 33eae65c6f49770fec7a662935d4eb4a6406d24b Author: Paulo Alcantara Date: Wed Dec 13 12:25:57 2023 -0300 Subject: smb: client: fix OOB in SMB2_query_info_init() Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=33eae65c6f49770fec7a662935d4eb4a6406d24b this was indeed landed in 5.15.0-102-generic: $ git log --grep "smb: client: fix OOB in SMB2_query_info_init()" origin/master-next commit ed30eac9715d0bd5512ee42ca8e8f340d2d9d2d5 ... $ git describe --contains ed30eac9715d0bd5512ee42ca8e8f340d2d9d2d5 Ubuntu-5.15.0-102.112~472 The link mentions it is supposedly fixed in: commit b5d623611c9cda84ebb5e5bd044587955eaf782f Author: Kees Cook Date: Fri Feb 17 16:24:40 2023 -0800 Subject: smb3: Replace smb2pdu 1-element arrays with flex-arrays Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b5d623611c9cda84ebb5e5bd044587955eaf782f Looking at the Jammy kernel tree: $ git log --grep "smb3: Replace smb2pdu 1-element arrays with flex-arrays" origin/master-next commit b5d623611c9cda84ebb5e5bd044587955eaf782f $ git describe --contains b5d623611c9cda84ebb5e5bd044587955eaf782f Ubuntu-5.15.0-104.114~23 It seems it is already applied and tagged in 5.15.0-104-generic. This seems to be built, but not quite in -proposed yet: https://kernel.ubuntu.com/reports/kernel-stable-board/ I will write back as soon as 5.15.0-104-generic is in -proposed, with instructions on how to test it, and see if it fixes the issue. Thanks, Matthew -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2060780 Title: CIFS stopped working/is unstable with kernel update to 5.15.0-102.112 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2060780/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Kernel-packages] [Bug 2060780] Re: CIFS stopped working/is unstable with kernel update to 5.15.0-102.112
** Also affects: linux (Ubuntu Jammy) Importance: Undecided Status: New ** Changed in: linux (Ubuntu Jammy) Status: New => Fix Committed ** Changed in: linux (Ubuntu Jammy) Importance: Undecided => High ** Tags added: seg -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2060780 Title: CIFS stopped working/is unstable with kernel update to 5.15.0-102.112 Status in linux package in Ubuntu: Confirmed Status in linux source package in Jammy: Fix Committed Bug description: Hi, updated some Ubuntu 22.04 systems to lastest available state this morning, which caused CIFS mounts (from various fileservers) to stop working. Kernel was updated to version 5.15.0-102-generic. I can mount the shares without problems (mount -t cifs), but then, df for example tells me: df: /mnt: Resource temporarily unavailable. I'm able to list and browse all the files, but accessing them (even readonly) is very unstable. Sometimes it works and sometimes it just gives me i/o errors. Switching back to 5.15.0-101-generic or 5.15.0-100-generic solves the problem and everything works again as expected. Seems like some bug has been implemented in 5.15.0-102-generic... To reproduce the problem, I started a while loop on one server to write to some file on a specific mounted CIFS share and read it from another one root@:~# while true; do echo "$(date) hallo" >> /mnt/hallo.txt; sleep 1 ; done -bash: /mnt/hallo.txt: Input/output error -bash: /mnt/hallo.txt: Input/output error ^C root@:~$ tail -f /mnt/hallo.txt Tue Apr 9 04:10:52 PM CEST 2024 hallo Tue Apr 9 04:10:53 PM CEST 2024 hallo Tue Apr 9 04:10:54 PM CEST 2024 hallo Tue Apr 9 04:10:55 PM CEST 2024 hallo Tue Apr 9 04:10:56 PM CEST 2024 hallo Tue Apr 9 04:10:57 PM CEST 2024 hallo Tue Apr 9 04:10:58 PM CEST 2024 hallo Tue Apr 9 04:10:59 PM CEST 2024 hallo Tue Apr 9 04:11:00 PM CEST 2024 hallo Tue Apr 9 04:11:01 PM CEST 2024 hallo tail: cannot determine location of '/mnt/hallo.txt'. reverting to polling: Resource temporarily unavailable Tue Apr 9 04:11:04 PM CEST 2024 hallo Tue Apr 9 04:11:05 PM CEST 2024 hallo Tue Apr 9 04:11:06 PM CEST 2024 hallo Tue Apr 9 04:11:07 PM CEST 2024 hallo Tue Apr 9 04:11:08 PM CEST 2024 hallo Tue Apr 9 04:11:09 PM CEST 2024 hallo Tue Apr 9 04:11:10 PM CEST 2024 hallo While doing this, both servers tell me, the resource is unavailable root@:~# df -h /mnt df: /mnt: Resource temporarily unavailable root@:~$ df -h /mnt df: /mnt: Resource temporarily unavailable To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2060780/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Bug 2060780] Re: CIFS stopped working/is unstable with kernel update to 5.15.0-102.112
** Also affects: linux (Ubuntu Jammy) Importance: Undecided Status: New ** Changed in: linux (Ubuntu Jammy) Status: New => Fix Committed ** Changed in: linux (Ubuntu Jammy) Importance: Undecided => High ** Tags added: seg -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2060780 Title: CIFS stopped working/is unstable with kernel update to 5.15.0-102.112 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2060780/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2060797] Re: df says Resource temporarily unavailable after kernel upgrade to 5.15.0-102
*** This bug is a duplicate of bug 2060780 *** https://bugs.launchpad.net/bugs/2060780 Hi everyone, I will provide updates on the other bug 2060780. ** This bug has been marked a duplicate of bug 2060780 CIFS stopped working/is unstable with kernel update to 5.15.0-102.112 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2060797 Title: df says Resource temporarily unavailable after kernel upgrade to 5.15.0-102 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cifs-utils/+bug/2060797/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2059197] Re: mount.nfs: Fix minor version parsing when '-t nfs4' and '-o vers=4.x' are used together
Attached is a new debdiff which includes the missing patch. I did another look upstream, but I think we are okay now. ** Patch added: "Debdiff for nfs-utils on Focal V2" https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/2059197/+attachment/5763564/+files/lp2059197_focal_V2.debdiff ** Changed in: nfs-utils (Ubuntu Focal) Status: Incomplete => In Progress ** Description changed: [Impact] When specifying both '-t nfs4' and '-o vers=4.x' on the mount command line, mount.nfs ignores any specific version set with '-o vers=4.x' or '-o vers=4,minorversion=x', and simply attempts version negotiation, which due to my recent changes in bug 2049262, would land on the highest supported nfs version, likely 4.2. Users who specify what version they want should get the version they ask for, and thus, this is a regression introduced in 1:1.3.4-2.5ubuntu3.6. A workaround is to drop '-t nfs4' and to use mount.nfs directly instead, i.e.: $ sudo mount.nfs -o vers=4.1 -vvv jammy-nfs-server:/ /mnt [Testcase] Create two VMs, one jammy and one focal. The jammy VM will be the server. Server VM: $ sudo hostnamectl set-hostname jammy-nfs-server $ sudo apt update && sudo apt upgrade -y $ sudo apt install nfs-kernel-server $ sudo mkdir /export $ sudo mkdir /export/users $ sudo mkdir /home/users $ sudo vi /etc/fstab # add the following line: /home/users /export/users none bind 0 0 $ sudo mount -a $ sudo vi /etc/exports # add the following lines: /export 192.168.122.0/24(rw,fsid=0,no_subtree_check,sync) /export/users 192.168.122.0/24(rw,nohide,insecure,no_subtree_check,sync) $ sudo systemctl restart nfs-server.service Focal VM: $ sudo hostnamectl set-hostname focal-nfs-client $ sudo apt update && sudo apt upgrade -y $ sudo apt install nfs-common And then try mounting with both '-t nfs4' and '-o vers=4.1': $ sudo mount -t nfs4 -o vers=4.1 -vvv jammy-nfs-server:/ /mnt mount.nfs4: timeout set for Wed Apr 3 00:51:23 2024 mount.nfs4: trying text-based options 'vers=4.2,addr=192.168.122.217,clientaddr=192.168.122.9' and then try with both '-t nfs4' and '-o vers=4,minorversion=1': $ sudo mount -t nfs4 -o vers=4,minorversion=1 -vvv jammy-nfs-server:/ /mnt mount.nfs4: timeout set for Wed Apr 3 02:19:03 2024 mount.nfs4: trying text-based options 'minorversion=1,vers=4.2,addr=192.168.122.217,clientaddr=192.168.122.9' In each of those mounts, it incorrectly uses protocol version 4.2, instead of requested 4.1. If you install the test packages in the following ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp2059197-test then vers should always be 4.1, instead of 4.2. [Where problems can occur] It is quite clear now that changing version negotiation and parsing is quite problematic, after the number of regressions the previous 1:1.3.4-2.5ubuntu3.6 caused the community, and the sheer number of commits upstream took to resolve lingering issues. We need to be careful, to make sure we don't introduce any further regressions. This time, we are only changing how mount.nfs parses and processes command line arguments for version specification, and not changing version negotiation itself. This could impact NFS clients, when they go to mount NFS filesystems. If a regression were to occur, then users might have to manually mount their NFS filesystems or look into autofs. There should be no breaking changes to any behaviour when mounting NFS filesystems. There are no changes to nfs server. [Other Info] This was fixed multiple times, across the following three commits: commit 1e3ca7fe199531a372bb8e1c1033d8973097be50 Author: NeilBrown Date: Wed Jul 26 13:47:42 2017 -0400 Subject: mount: move handling of "-t nfs4" into nfs_nfs_version() Link: https://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commitdiff;h=1e3ca7fe199531a372bb8e1c1033d8973097be50 - + commit 050153ef6a86ff5ab06ef65be36336824a323779 Author: NeilBrown Date: Wed Jul 26 13:51:51 2017 -0400 Subject: mount: Fix problems with parsing minorversion= Link: https://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commitdiff;h=050153ef6a86ff5ab06ef65be36336824a323779 - + commit 71b807e1a69940beb31fdeb481c2e54509e8bd32 Author: Steve Dickson Date: Thu Mar 1 13:52:47 2018 -0500 Subject: mount.nfs: minorversion setting is being ignored with the -t flag Link: https://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commitdiff;h=71b807e1a69940beb31fdeb481c2e54509e8bd32 + commit 5f32083c759b468f5b0cb9302e4fe2848d37cc5b + From: Steve Dickson + Date: Tue, 10 Apr 2018 10:25:40 -0400 + Subject: mount.nfs: Fix auto protocol negotiation + Link: https://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commitdiff;h=5f32083c759b468f5b0cb9302e4fe2848d37cc5b + Jammy has all of these, and does not need any fixes. -- You received this bug notification
[Bug 2059197] Re: mount.nfs: Fix minor version parsing when '-t nfs4' and '-o vers=4.x' are used together
** Patch removed: "Debdiff for nfs-utils on Focal" https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/2059197/+attachment/5761398/+files/lp2059197_focal.debdiff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2059197 Title: mount.nfs: Fix minor version parsing when '-t nfs4' and '-o vers=4.x' are used together To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/2059197/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Kernel-packages] [Bug 2049634] Re: smb: wsize blocks of bytes followed with binary zeros on copy, destroying data
Hi R. Diez, The 6.5.0-27-generic kernel just got released, so it should make its way to an archive mirror near you in the next couple of hours, and should solve your SMB 1 issue. The 6.8 kernel should be good to go when you get it in the next couple of months. Let us know if you encounter any more SMB 1 issues in the future. Thanks, Matthew -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2049634 Title: smb: wsize blocks of bytes followed with binary zeros on copy, destroying data Status in linux package in Ubuntu: Fix Committed Status in linux source package in Mantic: Fix Released Status in linux source package in Noble: Fix Committed Bug description: BugLink: https://bugs.launchpad.net/bugs/2049634 [Impact] Upon installing the 6.5 HWE kernel on Jammy, users with a custom wsize set will see data destruction when copying files from their systems onto a cifs smb mount. wsize defaults to 65535 bytes, but when set to smaller values, like 16850, users will see blocks of 16850 bytes copied over, followed by 3900 binary zeros, followed by the next block of data followed by more binary zeros. This destroys what you are copying, and the data corruption is completely silent. A workaround is to set wsize to a multiple of PAGE_SIZE. [Fix] This was fixed upstream in 6.8-rc5 by the following: commit 4860abb91f3d7fbaf8147d54782149bb1fc45892 Author: Steve French Date: Tue Feb 6 16:34:22 2024 -0600 Subject: smb: Fix regression in writes when non-standard maximum write size negotiated Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4860abb91f3d7fbaf8147d54782149bb1fc45892 This patch has been selected for upstream stable. The patch looks at wsize negotiation from the server, and also what is set on the mount command line, and if not a multiple of PAGE_SIZE, rounds it down, taking care to not be 0. The real corruption bug still exists in netfs/folios subsystems and we are looking for it still, but this solves the immediate data corruption issues on smb. [Testcase] Start two VMs, one for the server, and the other, the client. Server -- $ sudo apt update $ sudo apt upgrade $ sudo apt install samba $ sudo vim /etc/samba/smb.conf server min protocol = NT1 [sambashare] comment = Samba on Ubuntu path = /home/ubuntu/sambashare read only = no browsable = yes $ mkdir ~/sambashare $ sudo smbpasswd -a ubuntu Client -- $ sudo apt update $ sudo apt install cifs-utils $ mkdir ~/share $ sudo mount -t cifs -o username=ubuntu,vers=1.0,wsize=16850 //192.168.122.172/sambashare ~/share $ ( set -o pipefail && head --bytes=$(( 55 * 1000 )) /dev/zero | openssl enc -aes-128-ctr -nosalt -pass "pass:my-seed" -iter 1 | hexdump --no-squeezing --format '40/1 "%02x"' --format '"\n"' >"testdata.txt" ) $ sha256sum testdata.txt 9ec09af020dce3270ea76531141940106f173c7243b7193a553480fb8500b3f2 testdata.txt Now copy the file to the share. Client -- $ cp testdata.txt share/ Server -- $ sha256sum sambashare/testdata.txt 9e573a0aa795f9cd4de4ac684a1c056dbc7d2ba5494d02e71b6225ff5f0fd866 sambashare/testdata.txt The SHA256 hash is different. If you view the file with less, you will find a block of wsize=16850 bytes, then 3900 bytes of binary zeros, followed by another wsize=16850 bytes, then 3900 bytes of binary zeros, etc. An example of a broken file is: https://launchpadlibrarian.net/712573213/testdata-back-from-server.txt [Where problems could occur] We are changing the wsize that the SMB server negotiates or the user explicitly sets on the mount command line to a safe value, if the asked for value was not a multiple of PAGE_SIZE. It is unlikely that any users will notice any difference. If the wsize happens to be rounded down to a significantly smaller number, there may be a small performance impact, e.g. you set wsize=8094 for some reason, it would round down to wsize=4096, and lead to double the writes. At least you have data integrity though. Most users default to wsize=65535, and will have no impact at all. Only those with very old smb 1.0 servers that negotiate down to 16850 will see any difference. If a regression were to occur, it could result in user's wsize being incorrectly set, leading to the underlying netfs/folios data corruption being triggered and causing data corruption. [Other info] The issue was introduced in 6.3-rc1 by: commit d08089f649a0cfb2099c8551ac47eef0cc23fdf2 Author: David Howells Date: Mon Jan 24 21:13:24 2022 + Subject: cifs: Change the I/O paths to use an iterator rather than a page list Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d08089f649a0cfb2099c8551ac47eef0cc23fdf2 Upstream mailing
[Bug 2049634] Re: smb: wsize blocks of bytes followed with binary zeros on copy, destroying data
Hi R. Diez, The 6.5.0-27-generic kernel just got released, so it should make its way to an archive mirror near you in the next couple of hours, and should solve your SMB 1 issue. The 6.8 kernel should be good to go when you get it in the next couple of months. Let us know if you encounter any more SMB 1 issues in the future. Thanks, Matthew -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2049634 Title: smb: wsize blocks of bytes followed with binary zeros on copy, destroying data To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2049634/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2059197] Re: mount.nfs: Fix minor version parsing when '-t nfs4' and '-o vers=4.x' are used together
Hi Jeff, Again, I apologise for introducing this regression, but we are on our way to getting this fixed. The fixes are: commit 1e3ca7fe199531a372bb8e1c1033d8973097be50 Author: NeilBrown Date: Wed Jul 26 13:47:42 2017 -0400 Subject: mount: move handling of "-t nfs4" into nfs_nfs_version() Link: https://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commitdiff;h=1e3ca7fe199531a372bb8e1c1033d8973097be50 commit 050153ef6a86ff5ab06ef65be36336824a323779 Author: NeilBrown Date: Wed Jul 26 13:51:51 2017 -0400 Subject: mount: Fix problems with parsing minorversion= Link: https://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commitdiff;h=050153ef6a86ff5ab06ef65be36336824a323779 commit 71b807e1a69940beb31fdeb481c2e54509e8bd32 Author: Steve Dickson Date: Thu Mar 1 13:52:47 2018 -0500 Subject: mount.nfs: minorversion setting is being ignored with the -t flag Link: https://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commitdiff;h=71b807e1a69940beb31fdeb481c2e54509e8bd32 I have built these into a test package, if you are interested in taking a look. Please note this package is NOT SUPPORTED by Canonical, and is for TESTING PURPOSES ONLY. ONLY Install in a dedicated test environment. Instructions to install (On a Focal system): 1) sudo add-apt-repository ppa:mruffell/lp2059197-test 2) sudo apt update 3) sudo apt install nfs-common 4) sudo apt-cache policy nfs-common | grep Installed Installed: 1:1.3.4-2.5ubuntu3.6+lp2059197v20240403b1 If you try mount your share with the version specified, it should work. I'll write back once we have a package in -proposed with the fix. Thanks, Matthew -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2059197 Title: mount.nfs: Fix minor version parsing when '-t nfs4' and '-o vers=4.x' are used together To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/2059197/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2059197] Re: Fix minor version parsing when '-t nfs4' and '-o vers=4.x' are used together
Attached is a debdiff for Focal which fixes this issue. ** Summary changed: - Issue with nfs4.0 mounts after upgrade to 3.6 + Fix minor version parsing when '-t nfs4' and '-o vers=4.x' are used together ** Summary changed: - Fix minor version parsing when '-t nfs4' and '-o vers=4.x' are used together + mount.nfs: Fix minor version parsing when '-t nfs4' and '-o vers=4.x' are used together ** Description changed: - Hello, + [Impact] - On Ubuntu Server 20.04.6 LTS with the update of nfs-common package => - "nfs-common/focal-updates 1:1.3.4-2.5ubuntu3.5" to "nfs-common/focal- - updates 1:1.3.4-2.5ubuntu3.6" I started having issues mounting ntf4.0 - volumes. The NFS server supports 4.0, 4.1 and 4.2 + When specifying both '-t nfs4' and '-o vers=4.x' on the mount command + line, mount.nfs ignores any specific version set with '-o vers=4.x' or + '-o vers=4,minorversion=x', and simply attempts version negotiation, + which due to my recent changes in bug 2049262, would land on the highest + supported nfs version, likely 4.2. - The issue appears when using '-t ntfs4' and setting the version using -o - vers=. + Users who specify what version they want should get the version they ask + for, and thus, this is a regression introduced in 1:1.3.4-2.5ubuntu3.6. - When using 1:1.3.4-2.5ubuntu3.5 I am able to use '-o vers' to set the version when using -t ntfs4 eg - mount -t nfs4 -o vers=4.0 -vvv SERVER.local:/srv/data /mnt/test - mount.nfs4: trying text-based options 'vers=4.0,addr=xx.xx.xx.xx,clientaddr=xx.xx.xx.xx' + A workaround is to drop '-t nfs4' and to use mount.nfs directly instead, + i.e.: - mount -t nfs4 -o vers=4.1 -vvv SERVER.local:/srv/data /mnt/test - mount.nfs4: trying text-based options 'vers=4.1,addr=xx.xx.xx.xx,clientaddr=xx.xx.xx.xx' + $ sudo mount.nfs -o vers=4.1 -vvv jammy-nfs-server:/ /mnt - However after upgrading to 1:1.3.4-2.5ubuntu3.6 it always mounts as nfs4.2 - mount -t nfs4 -o vers=4.0 -vvv SERVER.local:/srv/data /mnt/test - mount.nfs4: trying text-based options 'vers=4.2,addr=xx.xx.xx.xx,clientaddr=xx.xx.xx.xx' + [Testcase] - mount -t nfs4 -o vers=4.1 -vvv SERVER.local:/srv/data /mnt/test - mount.nfs4: trying text-based options 'vers=4.2,addr=xx.xx.xx.xx,clientaddr=xx.xx.xx.xx' + Create two VMs, one jammy and one focal. - I would have expected the specified version in -o vers to be used when - using '-t nfs4' + The jammy VM will be the server. - When using '-t nfs' I am able to mount volumes as nfs 4.0. I understand - that 1:1.3.4-2.5ubuntu3.6 fixes version negotiation so maybe this isn't - a bug and the intent with '-t nfs4' is to always use the highest - version. If so please feel free to close the report + Server VM: + $ sudo hostnamectl set-hostname jammy-nfs-server + $ sudo apt update && sudo apt upgrade -y + $ sudo apt install nfs-kernel-server + $ sudo mkdir /export + $ sudo mkdir /export/users + $ sudo mkdir /home/users + $ sudo vi /etc/fstab # add the following line: + /home/users /export/users none bind 0 0 + $ sudo mount -a + $ sudo vi /etc/exports # add the following lines: + /export 192.168.122.0/24(rw,fsid=0,no_subtree_check,sync) + /export/users 192.168.122.0/24(rw,nohide,insecure,no_subtree_check,sync) + $ sudo systemctl restart nfs-server.service + + Focal VM: + $ sudo hostnamectl set-hostname focal-nfs-client + $ sudo apt update && sudo apt upgrade -y + $ sudo apt install nfs-common + + And then try mounting with both '-t nfs4' and '-o vers=4.1': + + $ sudo mount -t nfs4 -o vers=4.1 -vvv jammy-nfs-server:/ /mnt + mount.nfs4: timeout set for Wed Apr 3 00:51:23 2024 + mount.nfs4: trying text-based options 'vers=4.2,addr=192.168.122.217,clientaddr=192.168.122.9' + + and then try with both '-t nfs4' and '-o vers=4,minorversion=1': + + $ sudo mount -t nfs4 -o vers=4,minorversion=1 -vvv jammy-nfs-server:/ /mnt + mount.nfs4: timeout set for Wed Apr 3 02:19:03 2024 + mount.nfs4: trying text-based options 'minorversion=1,vers=4.2,addr=192.168.122.217,clientaddr=192.168.122.9' + + In each of those mounts, it incorrectly uses protocol version 4.2, + instead of requested 4.1. + + If you install the test packages in the following ppa: + + https://launchpad.net/~mruffell/+archive/ubuntu/lp2059197-test + + then vers should always be 4.1, instead of 4.2. + + [Where problems can occur] + + It is quite clear now that changing version negotiation and parsing is + quite problematic, after the number of regressions the previous + 1:1.3.4-2.5ubuntu3.6 caused the community, and the sheer number of + commits upstream took to resolve lingering issues. + + We need to be careful, to make sure we don't introduce any further + regressions. + + This time, we are only changing how mount.nfs parses and processes + command line arguments for version specification, and not changing + version negotiation itself. This could impact NFS clients, when they go + to mount NFS filesystems. + + If a regression were to occur, then users
[Bug 2059197] Re: Issue with nfs4.0 mounts after upgrade to 3.6
Hi Jeff, I believe this is a valid bug. I can reproduce it: On Focal: $ sudo mount -t nfs4 -o vers=4.1 -vvv jammy-nfs-server:/ /mnt mount.nfs4: timeout set for Wed Apr 3 00:51:23 2024 mount.nfs4: trying text-based options 'vers=4.2,addr=192.168.122.217,clientaddr=192.168.122.9' On Jammy: $ sudo mount -t nfs4 -o vers=4.1 -vvv jammy-nfs-server:/ /mnt mount.nfs4: timeout set for Wed Apr 3 00:57:08 2024 mount.nfs4: trying text-based options 'vers=4.1,addr=192.168.122.217,clientaddr=192.168.122.213' I apologise for introducing this particular regression when I changed the version negotiation. Let me try and find a fix and build a test package. In the meantime, you can use a workaround of dropping "-t nfs4" and changing "mount" to "mount.nfs", i.e.: $ sudo mount.nfs -o vers=4.1 -vvv jammy-nfs-server:/ /mnt mount.nfs: timeout set for Wed Apr 3 00:51:59 2024 mount.nfs: trying text-based options 'vers=4.1,addr=192.168.122.217,clientaddr=192.168.122.9' I will write back shortly. Thanks, Matthew ** Also affects: nfs-utils (Ubuntu Focal) Importance: Undecided Status: New ** Changed in: nfs-utils (Ubuntu) Status: New => Fix Released ** Changed in: nfs-utils (Ubuntu Focal) Status: New => In Progress ** Changed in: nfs-utils (Ubuntu Focal) Importance: Undecided => Medium ** Changed in: nfs-utils (Ubuntu Focal) Assignee: (unassigned) => Matthew Ruffell (mruffell) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2059197 Title: Issue with nfs4.0 mounts after upgrade to 3.6 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/2059197/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1949723] Re: systemd-resolved segfault in hashmap_iterate_entry
** Changed in: systemd (Ubuntu Focal) Status: New => In Progress ** Changed in: systemd (Ubuntu Focal) Importance: Low => Medium ** Changed in: systemd (Ubuntu Focal) Assignee: (unassigned) => Matthew Ruffell (mruffell) ** Tags added: sts -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1949723 Title: systemd-resolved segfault in hashmap_iterate_entry To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1949723/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Touch-packages] [Bug 1949723] Re: systemd-resolved segfault in hashmap_iterate_entry
** Changed in: systemd (Ubuntu Focal) Status: New => In Progress ** Changed in: systemd (Ubuntu Focal) Importance: Low => Medium ** Changed in: systemd (Ubuntu Focal) Assignee: (unassigned) => Matthew Ruffell (mruffell) ** Tags added: sts -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1949723 Title: systemd-resolved segfault in hashmap_iterate_entry Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Focal: In Progress Bug description: installed libnss-resolve that put "resolve" in nsswitch.conf. $ lsb_release -rd Description: Ubuntu 20.04.3 LTS Release: 20.04 $ dpkg -l systemd | grep systemd ii systemd245.4-4ubuntu3.13 amd64system and service manager $ grep ^hosts /etc/nsswitch.conf hosts: files libvirt mdns4_minimal resolve [NOTFOUND=return] dns mymachines systemd-resolved crashed once with segmentation fault. (gdb) bt #0 0x7f119c67693a in hashmap_iterate_entry (h=h@entry=0x706f746b73656465, i=i@entry=0x7ffc4ef515d0) at ../src/basic/hashmap.c:705 #1 0x7f119c6789d6 in internal_hashmap_iterate (h=0x706f746b73656465, i=i@entry=0x7ffc4ef515d0, value=value@entry=0x7ffc4ef515c8, key=key@entry=0x0) at ../src/basic/hashmap.c:714 #2 0x7f119c678a8b in set_iterate (s=, i=i@entry=0x7ffc4ef515d0, value=value@entry=0x7ffc4ef515c8) at ../src/basic/hashmap.c:735 #3 0x55ba5e0ea917 in dns_query_candidate_go (c=c@entry=0x55ba5f353180) at ../src/resolve/resolved-dns-query.c:152 #4 0x55ba5e0e9f0c in dns_query_candidate_notify (c=c@entry=0x55ba5f353180) at ../src/resolve/resolved-dns-query.c:312 #5 0x55ba5e0ea178 in dns_transaction_complete (t=0x55ba5f37a9d0, state=) at ../src/resolve/resolved-dns-transaction.c:351 #6 0x55ba5e0e27cd in dns_transaction_process_dnssec (t=t@entry=0x55ba5f37a9d0) at ../src/resolve/resolved-dns-transaction.c:838 #7 0x55ba5e0e3649 in dns_transaction_process_reply (t=t@entry=0x55ba5f37a9d0, p=p@entry=0x55ba5f39dce0) at ../src/resolve/resolved-dns-transaction.c:1210 #8 0x55ba5e0e40ab in on_dns_packet (s=, fd=, revents=, userdata=0x55ba5f37a9d0) at ../src/resolve/resolved-dns-transaction.c:1264 #9 0x7f119c5e6c77 in source_dispatch (s=s@entry=0x55ba5f346780) at ../src/libsystemd/sd-event/sd-event.c:3193 #10 0x7f119c5e6f11 in sd_event_dispatch (e=e@entry=0x55ba5f320430) at ../src/libsystemd/sd-event/sd-event.c:3634 #11 0x7f119c5e8948 in sd_event_run (e=e@entry=0x55ba5f320430, timeout=timeout@entry=18446744073709551615) at ../src/libsystemd/sd-event/sd-event.c:3692 #12 0x7f119c5e8b6f in sd_event_loop (e=0x55ba5f320430) at ../src/libsystemd/sd-event/sd-event.c:3714 #13 0x55ba5e0c326a in run (argv=, argc=) at ../src/resolve/resolved.c:84 #14 main (argc=, argv=) at ../src/resolve/resolved.c:91 This seems to have been reported upstream https://github.com/systemd/systemd/issues/16168 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1949723/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2033892] Re: ls -l triggers mount of autofs shares when --ghost option is present or browse_mode is enabled
Thank you for the help sorting autopkgtests Mauricio. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to coreutils in Ubuntu. https://bugs.launchpad.net/bugs/2033892 Title: ls -l triggers mount of autofs shares when --ghost option is present or browse_mode is enabled Status in coreutils package in Ubuntu: Fix Released Status in coreutils source package in Jammy: Fix Committed Status in coreutils package in Fedora: Fix Released Bug description: [Impact] Issuing a 'ls -l' or a 'stat' on an autofs share when you have set --ghost in the auto.master file, or browse_mode=yes in autofs.conf will lead to the shares being mounted, when they didn't previously. Disks / shares may not be present and the mounts may fail, leading to errors in your output. This is a behaviour change in autofs 8.32, which occurred in the transition to using statx() instead of stat()/lstat() in previous releases. There doesn't seem to be any workarounds, apart from not running a 'ls -l' in your autofs share directory. [Testcase] Start two Jammy VMs. One will be a NFS server, the other, the client. NFS server: Server VM: $ sudo hostnamectl set-hostname jammy-nfs-server $ sudo apt update && sudo apt upgrade -y $ sudo apt install nfs-kernel-server $ sudo mkdir /export $ sudo mkdir /export/users $ sudo vi /etc/exports # add the following lines: /export 192.168.122.0/24(rw,fsid=0,no_subtree_check,sync) /export/users 192.168.122.0/24(rw,nohide,insecure,no_subtree_check,sync) $ sudo systemctl restart nfs-server.service AutoFS Client: $ sudo apt update $ sudo apt install autofs $ sudo vim /etc/autofs.conf browse_mode = yes $ sudo mkdir /mnt2 $ sudo vim /etc/auto.master /mnt2 /etc/auto.indirect $ sudo vim /etc/auto.indirect export 192.168.122.18:/export export-missing 192.168.122.18:/export-missing $ sudo reboot $ cd /mnt2 $ ls -l ls: cannot access 'export-missing': No such file or directory total 4 drwxr-xr-x 3 root root 4096 Feb 12 21:48 export d? ? ?? ?? export-missing $ mount -l | grep /mnt2 /etc/auto.indirect on /mnt2 type autofs (rw,relatime,fd=6,pgrp=634,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=21561) 192.168.122.18:/export on /mnt2/export type nfs (rw,relatime,vers=3,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.122.18,mountvers=3,mountport=35786,mountproto=udp,local_lock=none,addr=192.168.122.18) We see the mount for export occurred, and export-missing was attempted, but it was either bogus or the disk was not present, leading to a "No such file or directory" error. There are test packages available in the following ppa: https://launchpad.net/~mruffell/+archive/ubuntu/sf378489-test If you install them, this is what should occur: $ ls -l total 0 drwxr-xr-x 2 root root 0 Feb 12 22:01 export drwxr-xr-x 2 root root 0 Feb 12 22:01 export-missing $ mount -l | grep /mnt2 /etc/auto.indirect on /mnt2 type autofs (rw,relatime,fd=6,pgrp=636,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=18346) No mounts happen, and no errors either. [Where problems could occur] We are changing the behaviour of core utilities, ls and stat, such that they no longer attempt to mount autofs shares when --ghost option is present or browse_mode is enabled. This is the intended behaviour in the first place, and has been this way for at least a decade prior, and was changed to return to this behaviour shortly after the release of coreutils that introduced statx() that caused automounts to occur. It is unlikely any system administrators are relying on the behaviour found in jammy in any scripts or day to day operations that would be adversely affected by the change. The worst case scenario is that a user doing an 'ls -l' on an unmounted disk finds the mount doesn't automatically occur, and they have to attach the disk and issue the mount themselves. If a regression were to occur, it would be limited to the ls and stat commands, specifically when listing directories linked to autofs mountpoints. [Other info] The automount behaviour change was introduced upstream in version 8.32, with the introduction of the statx() call. This means only Jammy is affected. It was quickly reverted back to how it was originally in version 9.1, which is already available in Mantic and onward. The commits that solve the issue are: commit 85c975df2c25bd799370b04bb294e568e001102f From: Rohan Sable Date: Mon, 7 Mar 2022 14:14:13 + Subject: ls: avoid triggering automounts Link: https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v9.0-177-g85c975df2c2 commit 92cb8427c537f37edd43c5cef1909585201372ab From: Pádraig Brady Date: Mon, 7 Mar 2022 23:29:20 + Subject: stat: only automount with
[Bug 2033892] Re: ls -l triggers mount of autofs shares when --ghost option is present or browse_mode is enabled
Thank you for the help sorting autopkgtests Mauricio. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2033892 Title: ls -l triggers mount of autofs shares when --ghost option is present or browse_mode is enabled To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/2033892/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Touch-packages] [Bug 2033892] Re: ls -l triggers mount of autofs shares when --ghost option is present or browse_mode is enabled
Performing verification for Jammy I set up two Jammy VMs, one a nfs-server and the other an autofs/nfs- client. The client is using coreutils 8.32-4.1ubuntu1.1 from -updates. $ apt-cache policy coreutils | grep Installed Installed: 8.32-4.1ubuntu1.1 I set up the nfs server and autofs mounts as the Testcase indicates. $ ls -l ls: cannot access 'export-missing': No such file or directory total 4 drwxr-xr-x 3 root root 4096 Mar 20 22:16 export d? ? ?? ?? export-missing $ mount -l | grep mnt2 /etc/auto.indirect on /mnt2 type autofs (rw,relatime,fd=6,pgrp=692,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=21588) 192.168.122.65:/export on /mnt2/export type nfs (rw,relatime,vers=3,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.122.65,mountvers=3,mountport=47718,mountproto=udp,local_lock=none,addr=192.168.122.65) The mounts were previously unmounted, but when I issue 'ls -l', the mounts occur, which is not wanted, and we error out on the non-existant export-missing mount. I then enabled -proposed, and installed coreutils 8.32-4.1ubuntu1.2. $ apt-cache policy coreutils | grep Installed Installed: 8.32-4.1ubuntu1.2 From there, lets try the 'ls -l': $ ls -l total 0 drwxr-xr-x 2 root root 0 Mar 20 22:25 export drwxr-xr-x 2 root root 0 Mar 20 22:25 export-missing $ mount -l | grep mnt2 /etc/auto.indirect on /mnt2 type autofs (rw,relatime,fd=6,pgrp=648,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=16856) This time the mounts do not occur, we just get a listing of the possible autofs mounts. We can confirm with 'mount -l' that nothing was actually actioned. The package in -proposed fixes the issues. Happy to mark verified for Jammy. ** Tags removed: verification-needed verification-needed-jammy ** Tags added: verification-done-jammy -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to coreutils in Ubuntu. https://bugs.launchpad.net/bugs/2033892 Title: ls -l triggers mount of autofs shares when --ghost option is present or browse_mode is enabled Status in coreutils package in Ubuntu: Fix Released Status in coreutils source package in Jammy: Fix Committed Status in coreutils package in Fedora: Fix Released Bug description: [Impact] Issuing a 'ls -l' or a 'stat' on an autofs share when you have set --ghost in the auto.master file, or browse_mode=yes in autofs.conf will lead to the shares being mounted, when they didn't previously. Disks / shares may not be present and the mounts may fail, leading to errors in your output. This is a behaviour change in autofs 8.32, which occurred in the transition to using statx() instead of stat()/lstat() in previous releases. There doesn't seem to be any workarounds, apart from not running a 'ls -l' in your autofs share directory. [Testcase] Start two Jammy VMs. One will be a NFS server, the other, the client. NFS server: Server VM: $ sudo hostnamectl set-hostname jammy-nfs-server $ sudo apt update && sudo apt upgrade -y $ sudo apt install nfs-kernel-server $ sudo mkdir /export $ sudo mkdir /export/users $ sudo vi /etc/exports # add the following lines: /export 192.168.122.0/24(rw,fsid=0,no_subtree_check,sync) /export/users 192.168.122.0/24(rw,nohide,insecure,no_subtree_check,sync) $ sudo systemctl restart nfs-server.service AutoFS Client: $ sudo apt update $ sudo apt install autofs $ sudo vim /etc/autofs.conf browse_mode = yes $ sudo mkdir /mnt2 $ sudo vim /etc/auto.master /mnt2 /etc/auto.indirect $ sudo vim /etc/auto.indirect export 192.168.122.18:/export export-missing 192.168.122.18:/export-missing $ sudo reboot $ cd /mnt2 $ ls -l ls: cannot access 'export-missing': No such file or directory total 4 drwxr-xr-x 3 root root 4096 Feb 12 21:48 export d? ? ?? ?? export-missing $ mount -l | grep /mnt2 /etc/auto.indirect on /mnt2 type autofs (rw,relatime,fd=6,pgrp=634,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=21561) 192.168.122.18:/export on /mnt2/export type nfs (rw,relatime,vers=3,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.122.18,mountvers=3,mountport=35786,mountproto=udp,local_lock=none,addr=192.168.122.18) We see the mount for export occurred, and export-missing was attempted, but it was either bogus or the disk was not present, leading to a "No such file or directory" error. There are test packages available in the following ppa: https://launchpad.net/~mruffell/+archive/ubuntu/sf378489-test If you install them, this is what should occur: $ ls -l total 0 drwxr-xr-x 2 root root 0 Feb 12 22:01 export drwxr-xr-x 2 root root 0 Feb 12 22:01 export-missing $ mount -l | grep /mnt2 /etc/auto.indirect on /mnt2 type autofs
[Bug 2033892] Re: ls -l triggers mount of autofs shares when --ghost option is present or browse_mode is enabled
Performing verification for Jammy I set up two Jammy VMs, one a nfs-server and the other an autofs/nfs- client. The client is using coreutils 8.32-4.1ubuntu1.1 from -updates. $ apt-cache policy coreutils | grep Installed Installed: 8.32-4.1ubuntu1.1 I set up the nfs server and autofs mounts as the Testcase indicates. $ ls -l ls: cannot access 'export-missing': No such file or directory total 4 drwxr-xr-x 3 root root 4096 Mar 20 22:16 export d? ? ?? ?? export-missing $ mount -l | grep mnt2 /etc/auto.indirect on /mnt2 type autofs (rw,relatime,fd=6,pgrp=692,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=21588) 192.168.122.65:/export on /mnt2/export type nfs (rw,relatime,vers=3,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.122.65,mountvers=3,mountport=47718,mountproto=udp,local_lock=none,addr=192.168.122.65) The mounts were previously unmounted, but when I issue 'ls -l', the mounts occur, which is not wanted, and we error out on the non-existant export-missing mount. I then enabled -proposed, and installed coreutils 8.32-4.1ubuntu1.2. $ apt-cache policy coreutils | grep Installed Installed: 8.32-4.1ubuntu1.2 From there, lets try the 'ls -l': $ ls -l total 0 drwxr-xr-x 2 root root 0 Mar 20 22:25 export drwxr-xr-x 2 root root 0 Mar 20 22:25 export-missing $ mount -l | grep mnt2 /etc/auto.indirect on /mnt2 type autofs (rw,relatime,fd=6,pgrp=648,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=16856) This time the mounts do not occur, we just get a listing of the possible autofs mounts. We can confirm with 'mount -l' that nothing was actually actioned. The package in -proposed fixes the issues. Happy to mark verified for Jammy. ** Tags removed: verification-needed verification-needed-jammy ** Tags added: verification-done-jammy -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2033892 Title: ls -l triggers mount of autofs shares when --ghost option is present or browse_mode is enabled To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/2033892/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Kernel-packages] [Bug 2054218] Re: kvm: Running perf against qemu processes results in page fault inside guest
Performing verification for mantic.
I deployed mantic onto a bare metal server, with kernel 6.5.0-26-generic from
-updates.
I installed a KVM stack, synced a cloud image, and tested VM creation.
$ uvt-kvm create --cpu 4 --memory 4096 --disk 10 jammy-a release=jammy
arch=amd64
$ uvt-kvm ssh jammy-a
Welcome to Ubuntu 22.04.4 LTS (GNU/Linux 5.15.0-101-generic x86_64)
From there, I found the PID of the VM:
$ ps aux | grep qemu
libvirt+1799 107 1.5 9642380 1044752 ? Sl 03:21 0:38
/usr/bin/qemu-system-x86_64 -name guest=jammy-a,debug-threads=on -S -object
{"qom-ty
We run perf:
$ sudo perf top -p 1799
$ virsh console jammy-a
Connected to domain 'jammy-a'
Escape character is ^] (Ctrl + ])
[ 161.413890] BUG: unable to handle page fault for address: fe18cdb1c028
[ 161.419474] #PF: supervisor read access in kernel mode
[ 161.423707] #PF: error_code(0x) - not-present page
[ 161.427949] PGD 17ffca0[ 161.429508] BUG: unable to handle page fault for
address: fe18cdb1c028
[ 161.429513] #PF: supervisor read access in kernel mode
[ 161.429516] #PF: error_code(0x) - n
The VM suffers a page fault and crashes, and is not accessible over ssh.
$ uvt-kvm ssh jammy-a
(no response).
I then enabled -proposed, and installed 6.5.0-27-generic:
$ uname -rv
6.5.0-27-generic #28-Ubuntu SMP PREEMPT_DYNAMIC Thu Mar 7 18:21:00 UTC 2024
$ uvt-kvm create --cpu 4 --memory 4096 --disk 10 jammy-a release=jammy
arch=amd64
$ uvt-kvm ssh jammy-a
Welcome to Ubuntu 22.04.4 LTS (GNU/Linux 5.15.0-101-generic x86_64)
We get the pid of the VM:
$ ps aux | grep qemu
libvirt+1786 42.5 1.5 7960876 1022308 ? Sl 03:37 0:40
/usr/bin/qemu-system-x86_64 -name guest=jammy-a,debug-threads=on -S -object
{"qom-ty
We run perf:
$ sudo perf top -p 1786
This time, the VM does not crash, and stays running:
$ virsh console jammy-a
Connected to domain 'jammy-a'
Escape character is ^] (Ctrl + ])
jammy-a login:
jammy-a login:
We can also ssh to the VM just fine:
$ uvt-kvm ssh jammy-a
Welcome to Ubuntu 22.04.4 LTS (GNU/Linux 5.15.0-101-generic x86_64)
This is much better. The kernel in -proposed fixes the issue, happy to
mark verified for mantic.
** Tags removed: verification-needed-mantic-linux
** Tags added: verification-done-mantic-linux
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/2054218
Title:
kvm: Running perf against qemu processes results in page fault inside
guest
Status in linux package in Ubuntu:
Fix Released
Status in linux source package in Mantic:
Fix Committed
Bug description:
BugLink: https://bugs.launchpad.net/bugs/2054218
[Impact]
Running perf against a QEMU/kvm process results in the guest suffering
a page fault in trying to store Precise Event Based Sampling (PEBS)
records for the host. This affects both using perf against a single
process, in which it crashes the targeted guest, or using perf system
wide, in which it crashes all running guests on the system.
The issue was introduced in 6.0 by:
commit c59a1f106f5cd4843c097069ff1bb2ad72103a67
Author: Like Xu
Date: Mon Apr 11 18:19:36 2022 +0800
Subject: KVM: x86/pmu: Add IA32_PEBS_ENABLE MSR emulation for extended PEBS
Link:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c59a1f106f5cd4843c097069ff1bb2ad72103a67
This affects all 6.2 and 6.5 kernels. There is no known workaround,
apart from not using perf on affected systems.
[Fix]
The issue was fixed in 6.7 by:
commit 971079464001c6856186ca137778e534d983174a
Author: Paolo Bonzini
Date: Thu Jan 4 16:15:17 2024 +0100
Subject: KVM: x86/pmu: fix masking logic for MSR_CORE_PERF_GLOBAL_CTRL
Link:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=971079464001c6856186ca137778e534d983174a
This reinstates the logic for setting MSR_CORE_PERF_GLOBAL_CTRL to
what it was before "KVM: x86/pmu: Add IA32_PEBS_ENABLE MSR emulation
for extended PEBS".
- .guest = intel_ctrl & (~cpuc->intel_ctrl_host_mask |
~pebs_mask),
+ .guest = intel_ctrl & ~cpuc->intel_ctrl_host_mask &
~pebs_mask,
The faulty logic includes any bit that isn't both marked as
exclude_guest and using PEBS, while it should really be excluding PEBS
from the host.
[Testcase]
Start a bare metal server. Enable KVM, start a few VMs. The VMs can be
idle, they don't require any workload.
$ sudo apt-get install qemu-kvm libvirt-daemon-system libvirt-clients
bridge-utils uvtool
$ sudo reboot
$ ssh-keygen
$ uvt-simplestreams-libvirt sync --source
http://cloud-images.ubuntu.com/daily release=jammy arch=amd64
$ uvt-kvm create --cpu 4 --memory 4096 --disk 10 jammy-a release=jammy
arch=amd64
$ uvt-kvm create --cpu 4 --memory 4096 --disk 10 jammy-b release=jammy
arch=amd64
$ uvt-kvm create --cpu 4 --memory 4096 --disk 10 jammy-c
[Bug 2054218] Re: kvm: Running perf against qemu processes results in page fault inside guest
Performing verification for mantic.
I deployed mantic onto a bare metal server, with kernel 6.5.0-26-generic from
-updates.
I installed a KVM stack, synced a cloud image, and tested VM creation.
$ uvt-kvm create --cpu 4 --memory 4096 --disk 10 jammy-a release=jammy
arch=amd64
$ uvt-kvm ssh jammy-a
Welcome to Ubuntu 22.04.4 LTS (GNU/Linux 5.15.0-101-generic x86_64)
From there, I found the PID of the VM:
$ ps aux | grep qemu
libvirt+1799 107 1.5 9642380 1044752 ? Sl 03:21 0:38
/usr/bin/qemu-system-x86_64 -name guest=jammy-a,debug-threads=on -S -object
{"qom-ty
We run perf:
$ sudo perf top -p 1799
$ virsh console jammy-a
Connected to domain 'jammy-a'
Escape character is ^] (Ctrl + ])
[ 161.413890] BUG: unable to handle page fault for address: fe18cdb1c028
[ 161.419474] #PF: supervisor read access in kernel mode
[ 161.423707] #PF: error_code(0x) - not-present page
[ 161.427949] PGD 17ffca0[ 161.429508] BUG: unable to handle page fault for
address: fe18cdb1c028
[ 161.429513] #PF: supervisor read access in kernel mode
[ 161.429516] #PF: error_code(0x) - n
The VM suffers a page fault and crashes, and is not accessible over ssh.
$ uvt-kvm ssh jammy-a
(no response).
I then enabled -proposed, and installed 6.5.0-27-generic:
$ uname -rv
6.5.0-27-generic #28-Ubuntu SMP PREEMPT_DYNAMIC Thu Mar 7 18:21:00 UTC 2024
$ uvt-kvm create --cpu 4 --memory 4096 --disk 10 jammy-a release=jammy
arch=amd64
$ uvt-kvm ssh jammy-a
Welcome to Ubuntu 22.04.4 LTS (GNU/Linux 5.15.0-101-generic x86_64)
We get the pid of the VM:
$ ps aux | grep qemu
libvirt+1786 42.5 1.5 7960876 1022308 ? Sl 03:37 0:40
/usr/bin/qemu-system-x86_64 -name guest=jammy-a,debug-threads=on -S -object
{"qom-ty
We run perf:
$ sudo perf top -p 1786
This time, the VM does not crash, and stays running:
$ virsh console jammy-a
Connected to domain 'jammy-a'
Escape character is ^] (Ctrl + ])
jammy-a login:
jammy-a login:
We can also ssh to the VM just fine:
$ uvt-kvm ssh jammy-a
Welcome to Ubuntu 22.04.4 LTS (GNU/Linux 5.15.0-101-generic x86_64)
This is much better. The kernel in -proposed fixes the issue, happy to
mark verified for mantic.
** Tags removed: verification-needed-mantic-linux
** Tags added: verification-done-mantic-linux
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2054218
Title:
kvm: Running perf against qemu processes results in page fault inside
guest
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2054218/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Desktop-packages] [Bug 2044420] Re: gtkpod segfaults when attempting to display songs
Attached is a debdiff for mantic which fixes this issue. ** Patch added: "Debdiff for gtkpod on mantic" https://bugs.launchpad.net/ubuntu/+source/gtkpod/+bug/2044420/+attachment/5757356/+files/lp2044420_mantic.debdiff ** Changed in: glib2.0 (Ubuntu Noble) Status: Triaged => Fix Released ** No longer affects: gtkpod (Ubuntu Noble) -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to glib2.0 in Ubuntu. https://bugs.launchpad.net/bugs/2044420 Title: gtkpod segfaults when attempting to display songs Status in GLib: Fix Released Status in glib2.0 package in Ubuntu: Fix Released Status in gtkpod package in Ubuntu: New Status in glib2.0 source package in Mantic: Triaged Status in gtkpod source package in Mantic: New Status in glib2.0 source package in Noble: Fix Released Bug description: Open gtkpod, and select your ipod from the list. If it has more than one screenfull of songs to display in the list, gtkpod will immediately segfault. I haven't found a workaround yet. Broken on Mantic, works on Lunar. Thread 1 "gtkpod" received signal SIGSEGV, Segmentation fault. __GI___wcsxfrm_l (dest=0x0, src=0x0, n=0, l=0x76fff5a0 <_nl_global_locale>) at ../string/strxfrm_l.c:685 685 ../string/strxfrm_l.c: No such file or directory. (gdb) bt #0 __GI___wcsxfrm_l (dest=0x0, src=0x0, n=0, l=0x76fff5a0 <_nl_global_locale>) at ../string/strxfrm_l.c:685 #1 0x770c5a5e in g_utf8_collate_key () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x77f852ec in fuzzy_skip_prefix () at /lib/x86_64-linux-gnu/libgtkpod.so.1 #3 0x7fffa80980ca in ??? () at /usr/lib/x86_64-linux-gnu/gtkpod/libsorttab_display.so #4 0x7fffa80997fd in normal_sort_tab_page_add_track () at /usr/lib/x86_64-linux-gnu/gtkpod/libsorttab_display.so #5 0x7fffa8099526 in normal_sort_tab_page_add_track () at /usr/lib/x86_64-linux-gnu/gtkpod/libsorttab_display.so #6 0x7fffa809f196 in sorttab_display_select_playlist_cb () at /usr/lib/x86_64-linux-gnu/gtkpod/libsorttab_display.so #7 0x7718d130 in g_closure_invoke () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #8 0x771ba4ac in ??? () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #9 0x771ab9b1 in ??? () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #10 0x771abbd6 in g_signal_emit_valist () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #11 0x771abc93 in g_signal_emit () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #12 0x77f67e4b in gtkpod_set_current_playlist () at /lib/x86_64-linux-gnu/libgtkpod.so.1 #13 0x7fffa807cce0 in ??? () at /usr/lib/x86_64-linux-gnu/gtkpod/libplaylist_display.so #14 0x7708ba11 in ??? () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #15 0x770e746f in ??? () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #16 0x7708c46f in g_main_loop_run () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #17 0x777f61ed in gtk_main () at /lib/x86_64-linux-gnu/libgtk-3.so.0 #18 0xea1f in main () To manage notifications about this bug go to: https://bugs.launchpad.net/glib/+bug/2044420/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2044420] Re: gtkpod segfaults when attempting to display songs
Attached is a debdiff for mantic which fixes this issue. ** Patch added: "Debdiff for gtkpod on mantic" https://bugs.launchpad.net/ubuntu/+source/gtkpod/+bug/2044420/+attachment/5757356/+files/lp2044420_mantic.debdiff ** Changed in: glib2.0 (Ubuntu Noble) Status: Triaged => Fix Released ** No longer affects: gtkpod (Ubuntu Noble) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to glib2.0 in Ubuntu. https://bugs.launchpad.net/bugs/2044420 Title: gtkpod segfaults when attempting to display songs Status in GLib: Fix Released Status in glib2.0 package in Ubuntu: Fix Released Status in gtkpod package in Ubuntu: New Status in glib2.0 source package in Mantic: Triaged Status in gtkpod source package in Mantic: New Status in glib2.0 source package in Noble: Fix Released Bug description: Open gtkpod, and select your ipod from the list. If it has more than one screenfull of songs to display in the list, gtkpod will immediately segfault. I haven't found a workaround yet. Broken on Mantic, works on Lunar. Thread 1 "gtkpod" received signal SIGSEGV, Segmentation fault. __GI___wcsxfrm_l (dest=0x0, src=0x0, n=0, l=0x76fff5a0 <_nl_global_locale>) at ../string/strxfrm_l.c:685 685 ../string/strxfrm_l.c: No such file or directory. (gdb) bt #0 __GI___wcsxfrm_l (dest=0x0, src=0x0, n=0, l=0x76fff5a0 <_nl_global_locale>) at ../string/strxfrm_l.c:685 #1 0x770c5a5e in g_utf8_collate_key () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x77f852ec in fuzzy_skip_prefix () at /lib/x86_64-linux-gnu/libgtkpod.so.1 #3 0x7fffa80980ca in ??? () at /usr/lib/x86_64-linux-gnu/gtkpod/libsorttab_display.so #4 0x7fffa80997fd in normal_sort_tab_page_add_track () at /usr/lib/x86_64-linux-gnu/gtkpod/libsorttab_display.so #5 0x7fffa8099526 in normal_sort_tab_page_add_track () at /usr/lib/x86_64-linux-gnu/gtkpod/libsorttab_display.so #6 0x7fffa809f196 in sorttab_display_select_playlist_cb () at /usr/lib/x86_64-linux-gnu/gtkpod/libsorttab_display.so #7 0x7718d130 in g_closure_invoke () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #8 0x771ba4ac in ??? () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #9 0x771ab9b1 in ??? () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #10 0x771abbd6 in g_signal_emit_valist () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #11 0x771abc93 in g_signal_emit () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #12 0x77f67e4b in gtkpod_set_current_playlist () at /lib/x86_64-linux-gnu/libgtkpod.so.1 #13 0x7fffa807cce0 in ??? () at /usr/lib/x86_64-linux-gnu/gtkpod/libplaylist_display.so #14 0x7708ba11 in ??? () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #15 0x770e746f in ??? () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #16 0x7708c46f in g_main_loop_run () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #17 0x777f61ed in gtk_main () at /lib/x86_64-linux-gnu/libgtk-3.so.0 #18 0xea1f in main () To manage notifications about this bug go to: https://bugs.launchpad.net/glib/+bug/2044420/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 2044420] Re: gtkpod segfaults when attempting to display songs
gtkpod has been removed from debian, and thus removed from noble, so no need to fix there. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to glib2.0 in Ubuntu. https://bugs.launchpad.net/bugs/2044420 Title: gtkpod segfaults when attempting to display songs Status in GLib: Fix Released Status in glib2.0 package in Ubuntu: Fix Released Status in gtkpod package in Ubuntu: New Status in glib2.0 source package in Mantic: Triaged Status in gtkpod source package in Mantic: New Status in glib2.0 source package in Noble: Fix Released Bug description: Open gtkpod, and select your ipod from the list. If it has more than one screenfull of songs to display in the list, gtkpod will immediately segfault. I haven't found a workaround yet. Broken on Mantic, works on Lunar. Thread 1 "gtkpod" received signal SIGSEGV, Segmentation fault. __GI___wcsxfrm_l (dest=0x0, src=0x0, n=0, l=0x76fff5a0 <_nl_global_locale>) at ../string/strxfrm_l.c:685 685 ../string/strxfrm_l.c: No such file or directory. (gdb) bt #0 __GI___wcsxfrm_l (dest=0x0, src=0x0, n=0, l=0x76fff5a0 <_nl_global_locale>) at ../string/strxfrm_l.c:685 #1 0x770c5a5e in g_utf8_collate_key () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x77f852ec in fuzzy_skip_prefix () at /lib/x86_64-linux-gnu/libgtkpod.so.1 #3 0x7fffa80980ca in ??? () at /usr/lib/x86_64-linux-gnu/gtkpod/libsorttab_display.so #4 0x7fffa80997fd in normal_sort_tab_page_add_track () at /usr/lib/x86_64-linux-gnu/gtkpod/libsorttab_display.so #5 0x7fffa8099526 in normal_sort_tab_page_add_track () at /usr/lib/x86_64-linux-gnu/gtkpod/libsorttab_display.so #6 0x7fffa809f196 in sorttab_display_select_playlist_cb () at /usr/lib/x86_64-linux-gnu/gtkpod/libsorttab_display.so #7 0x7718d130 in g_closure_invoke () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #8 0x771ba4ac in ??? () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #9 0x771ab9b1 in ??? () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #10 0x771abbd6 in g_signal_emit_valist () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #11 0x771abc93 in g_signal_emit () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #12 0x77f67e4b in gtkpod_set_current_playlist () at /lib/x86_64-linux-gnu/libgtkpod.so.1 #13 0x7fffa807cce0 in ??? () at /usr/lib/x86_64-linux-gnu/gtkpod/libplaylist_display.so #14 0x7708ba11 in ??? () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #15 0x770e746f in ??? () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #16 0x7708c46f in g_main_loop_run () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #17 0x777f61ed in gtk_main () at /lib/x86_64-linux-gnu/libgtk-3.so.0 #18 0xea1f in main () To manage notifications about this bug go to: https://bugs.launchpad.net/glib/+bug/2044420/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2044420] Re: gtkpod segfaults when attempting to display songs
gtkpod has been removed from debian, and thus removed from noble, so no need to fix there. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to glib2.0 in Ubuntu. https://bugs.launchpad.net/bugs/2044420 Title: gtkpod segfaults when attempting to display songs Status in GLib: Fix Released Status in glib2.0 package in Ubuntu: Fix Released Status in gtkpod package in Ubuntu: New Status in glib2.0 source package in Mantic: Triaged Status in gtkpod source package in Mantic: New Status in glib2.0 source package in Noble: Fix Released Bug description: Open gtkpod, and select your ipod from the list. If it has more than one screenfull of songs to display in the list, gtkpod will immediately segfault. I haven't found a workaround yet. Broken on Mantic, works on Lunar. Thread 1 "gtkpod" received signal SIGSEGV, Segmentation fault. __GI___wcsxfrm_l (dest=0x0, src=0x0, n=0, l=0x76fff5a0 <_nl_global_locale>) at ../string/strxfrm_l.c:685 685 ../string/strxfrm_l.c: No such file or directory. (gdb) bt #0 __GI___wcsxfrm_l (dest=0x0, src=0x0, n=0, l=0x76fff5a0 <_nl_global_locale>) at ../string/strxfrm_l.c:685 #1 0x770c5a5e in g_utf8_collate_key () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x77f852ec in fuzzy_skip_prefix () at /lib/x86_64-linux-gnu/libgtkpod.so.1 #3 0x7fffa80980ca in ??? () at /usr/lib/x86_64-linux-gnu/gtkpod/libsorttab_display.so #4 0x7fffa80997fd in normal_sort_tab_page_add_track () at /usr/lib/x86_64-linux-gnu/gtkpod/libsorttab_display.so #5 0x7fffa8099526 in normal_sort_tab_page_add_track () at /usr/lib/x86_64-linux-gnu/gtkpod/libsorttab_display.so #6 0x7fffa809f196 in sorttab_display_select_playlist_cb () at /usr/lib/x86_64-linux-gnu/gtkpod/libsorttab_display.so #7 0x7718d130 in g_closure_invoke () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #8 0x771ba4ac in ??? () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #9 0x771ab9b1 in ??? () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #10 0x771abbd6 in g_signal_emit_valist () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #11 0x771abc93 in g_signal_emit () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #12 0x77f67e4b in gtkpod_set_current_playlist () at /lib/x86_64-linux-gnu/libgtkpod.so.1 #13 0x7fffa807cce0 in ??? () at /usr/lib/x86_64-linux-gnu/gtkpod/libplaylist_display.so #14 0x7708ba11 in ??? () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #15 0x770e746f in ??? () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #16 0x7708c46f in g_main_loop_run () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #17 0x777f61ed in gtk_main () at /lib/x86_64-linux-gnu/libgtk-3.so.0 #18 0xea1f in main () To manage notifications about this bug go to: https://bugs.launchpad.net/glib/+bug/2044420/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Bug 2044420] Re: gtkpod segfaults when attempting to display songs
gtkpod has been removed from debian, and thus removed from noble, so no need to fix there. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2044420 Title: gtkpod segfaults when attempting to display songs To manage notifications about this bug go to: https://bugs.launchpad.net/glib/+bug/2044420/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2044420] Re: gtkpod segfaults when attempting to display songs
Attached is a debdiff for mantic which fixes this issue. ** Patch added: "Debdiff for gtkpod on mantic" https://bugs.launchpad.net/ubuntu/+source/gtkpod/+bug/2044420/+attachment/5757356/+files/lp2044420_mantic.debdiff ** Changed in: glib2.0 (Ubuntu Noble) Status: Triaged => Fix Released ** No longer affects: gtkpod (Ubuntu Noble) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2044420 Title: gtkpod segfaults when attempting to display songs To manage notifications about this bug go to: https://bugs.launchpad.net/glib/+bug/2044420/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2044420] Re: gtkpod segfaults when attempting to display songs
gtkpod has been removed from debian, and thus removed from noble, so no need to fix there. -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to glib2.0 in Ubuntu. https://bugs.launchpad.net/bugs/2044420 Title: gtkpod segfaults when attempting to display songs To manage notifications about this bug go to: https://bugs.launchpad.net/glib/+bug/2044420/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 2044420] Re: gtkpod segfaults when attempting to display songs
Attached is a debdiff for mantic which fixes this issue. ** Patch added: "Debdiff for gtkpod on mantic" https://bugs.launchpad.net/ubuntu/+source/gtkpod/+bug/2044420/+attachment/5757356/+files/lp2044420_mantic.debdiff ** Changed in: glib2.0 (Ubuntu Noble) Status: Triaged => Fix Released ** No longer affects: gtkpod (Ubuntu Noble) -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to glib2.0 in Ubuntu. https://bugs.launchpad.net/bugs/2044420 Title: gtkpod segfaults when attempting to display songs To manage notifications about this bug go to: https://bugs.launchpad.net/glib/+bug/2044420/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Kernel-packages] [Bug 2056143] Re: block/loop: No longer allows to create partitions
Performing verification for Jammy. I started a fresh VM, with 5.15.0-101-generic from updates. I ran the following reproducer: $ fallocate -l 1G /tmp/blob $ LOOPDEV=$(sudo losetup --find --show /tmp/blob) $ sudo /usr/sbin/parted -s -m -a optimal $LOOPDEV -- unit KiB mklabel gpt mkpart primary 0% 100% Error: Partition(s) 1 on /dev/loop4 have been written, but we have been unable to inform the kernel of the change, probably because it/they are in use. As a result, the old partition(s) will remain in use. You should reboot now before making further changes. I then enabled -proposed, and installed 5.15.0-102-generic: $ uname -rv 5.15.0-102-generic #112-Ubuntu SMP Tue Mar 5 16:50:32 UTC 2024 Running the reproducer: $ fallocate -l 1G /tmp/blob $ LOOPDEV=$(sudo losetup --find --show /tmp/blob) $ sudo /usr/sbin/parted -s -m -a optimal $LOOPDEV -- unit KiB mklabel gpt mkpart primary 0% 100% $ losetup -a /dev/loop4: []: (/tmp/blob) $ ll /dev ... brw-rw 1 root disk 7, 4 Mar 19 03:45 loop4 brw-rw 1 root disk259, 0 Mar 19 03:45 loop4p1 ... Things are now working as intended. The kernel in -proposed solves the issue. Happy to mark verified for Jammy. ** Tags removed: verification-needed-jammy-linux ** Tags added: sts verification-done-jammy-linux -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2056143 Title: block/loop: No longer allows to create partitions Status in linux package in Ubuntu: Invalid Status in linux source package in Jammy: Fix Committed Bug description: == SRU Justification == -- Impact -- In 22.04/Jammy with the GA 5.15 kernel there was an upstream change preventing partition table operations when GENHD_FL_NO_PART is set. 1a721de8489f "block: don't add or resize partition on the disk with GENHD_FL_NO_PART" Beside of changing return codes and breaking some user-space that way this also causes loop block devices to no longer be able to have partitions manually created. This is because the loop block driver uses GENHD_FL_NO_PART to prevent active partition scans. -- Fix -- This was changed in 5.19 (and thus Mantic is not affected) by introducing a separate flag to prevent those scans: b9684a71fca7 "block, loop: support partitions without scanning" The fix depends on a larger rewrite so it cannot be simply picked. The biggest change from the original is moving the check for the new flag into a helper function in genhd.h which checks whether a disk should be scanned for partitions. That function was dropped with the upstream rewrite and checking moved into the loop driver directly. But it felt like adjusting the helper was the better approach. Note: The upstream patch has a follow-up change submitted: 748008e1da92 "block: don't add partitions if GD_SUPPRESS_PART_SCAN is set" We do _NOT_ need that in Jammy/5.15 because block/partitions/core.c: blk_add_partitions() checks disk_part_scan_enabled() which was where we added the check for the backport instead of modifying disk_scan_partitions() directly. -- Testcase -- $ fallocate -l 1G /tmp/blob $ LOOPDEV=$(sudo losetup --find --show /tmp/blob) $ sudo /usr/sbin/parted -s -m -a optimal $LOOPDEV -- unit KiB mklabel gpt mkpart primary 0% 100% -- Regression Potential -- If things go wrong it might be other devices which no longer get scanned automatically or other issues with the loop block driver. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2056143/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Bug 2056143] Re: block/loop: No longer allows to create partitions
Performing verification for Jammy. I started a fresh VM, with 5.15.0-101-generic from updates. I ran the following reproducer: $ fallocate -l 1G /tmp/blob $ LOOPDEV=$(sudo losetup --find --show /tmp/blob) $ sudo /usr/sbin/parted -s -m -a optimal $LOOPDEV -- unit KiB mklabel gpt mkpart primary 0% 100% Error: Partition(s) 1 on /dev/loop4 have been written, but we have been unable to inform the kernel of the change, probably because it/they are in use. As a result, the old partition(s) will remain in use. You should reboot now before making further changes. I then enabled -proposed, and installed 5.15.0-102-generic: $ uname -rv 5.15.0-102-generic #112-Ubuntu SMP Tue Mar 5 16:50:32 UTC 2024 Running the reproducer: $ fallocate -l 1G /tmp/blob $ LOOPDEV=$(sudo losetup --find --show /tmp/blob) $ sudo /usr/sbin/parted -s -m -a optimal $LOOPDEV -- unit KiB mklabel gpt mkpart primary 0% 100% $ losetup -a /dev/loop4: []: (/tmp/blob) $ ll /dev ... brw-rw 1 root disk 7, 4 Mar 19 03:45 loop4 brw-rw 1 root disk259, 0 Mar 19 03:45 loop4p1 ... Things are now working as intended. The kernel in -proposed solves the issue. Happy to mark verified for Jammy. ** Tags removed: verification-needed-jammy-linux ** Tags added: sts verification-done-jammy-linux -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2056143 Title: block/loop: No longer allows to create partitions To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2056143/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Kernel-packages] [Bug 2049634] Re: smb: wsize blocks of bytes followed with binary zeros on copy, destroying data
Performing verification for mantic. I started two VMs. A jammy VM for the cifs server, and a mantic VM, for the client. I set the jammy VM up as per the testcase. I set the mantic VM up as per the testcase. The mantic VM uses kernel 6.5.0-25-generic from -updates. $ uname -rv 6.5.0-25-generic #25-Ubuntu SMP PREEMPT_DYNAMIC Wed Feb 7 14:58:39 UTC 2024 I created the testdata, took the SHA256 hash, and copied it over: $ ( set -o pipefail && head --bytes=$(( 55 * 1000 )) /dev/zero | openssl enc -aes-128-ctr -nosalt -pass "pass:my-seed" -iter 1 | hexdump --no-squeezing --format '40/1 "%02x"' --format '"\n"' >"testdata.txt" ) $ sha256sum testdata.txt 9ec09af020dce3270ea76531141940106f173c7243b7193a553480fb8500b3f2 testdata.txt $ cp testdata.txt share/ On the jammy VM, I confirmed the hash has changed: $ sha256sum sambashare/testdata.txt 9e573a0aa795f9cd4de4ac684a1c056dbc7d2ba5494d02e71b6225ff5f0fd866 sambashare/testdata.txt $ less sambashare/testdata.txt Looking at the file with less, I see the large blocks of zeros. I then enabled -proposed, and installed 6.5.0-27-generic: $ uname -rv 6.5.0-27-generic #28-Ubuntu SMP PREEMPT_DYNAMIC Thu Mar 7 18:21:00 UTC 2024 I mounted the share: $ sudo mount -t cifs -o username=ubuntu,vers=1.0,wsize=16850 //192.168.122.65/sambashare ~/share Password for ubuntu@//192.168.122.65/sambashare: Looking in dmesg, I see: [ 57.280020] Key type cifs.spnego registered [ 57.280035] Key type cifs.idmap registered [ 57.280345] Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers [ 57.280861] CIFS: VFS: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers [ 57.281307] CIFS: VFS: wsize rounded down to 16384 to multiple of PAGE_SIZE 4096 [ 57.281599] CIFS: Attempting to mount //192.168.122.65/sambashare the line of interest is "CIFS: VFS: wsize rounded down to 16384 to multiple of PAGE_SIZE 4096" showing we now have a wsize of 16384, and we can see this with mount -l: $ mount -l //192.168.122.65/sambashare on /home/ubuntu/share type cifs (rw,relatime,vers=1.0,cache=strict,username=ubuntu,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.122.65,soft,unix,posixpaths,serverino,mapposix,acl,rsize=1048576,wsize=16384,bsize=1048576,echo_interval=60,actimeo=1,closetimeo=1) I then copied the file over: $ cp testdata.txt share/ Looking at the SHA256 sum on the Jammy server: $ sha256sum sambashare/testdata.txt 9ec09af020dce3270ea76531141940106f173c7243b7193a553480fb8500b3f2 sambashare/testdata.txt When looking at the file with less, there are no more binary zeros. The kernel in -proposed fixes the issue, happy to mark verified for mantic. ** Tags removed: verification-needed-mantic-linux ** Tags added: verification-done-mantic-linux -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2049634 Title: smb: wsize blocks of bytes followed with binary zeros on copy, destroying data Status in linux package in Ubuntu: Fix Committed Status in linux source package in Mantic: Fix Committed Status in linux source package in Noble: Fix Committed Bug description: BugLink: https://bugs.launchpad.net/bugs/2049634 [Impact] Upon installing the 6.5 HWE kernel on Jammy, users with a custom wsize set will see data destruction when copying files from their systems onto a cifs smb mount. wsize defaults to 65535 bytes, but when set to smaller values, like 16850, users will see blocks of 16850 bytes copied over, followed by 3900 binary zeros, followed by the next block of data followed by more binary zeros. This destroys what you are copying, and the data corruption is completely silent. A workaround is to set wsize to a multiple of PAGE_SIZE. [Fix] This was fixed upstream in 6.8-rc5 by the following: commit 4860abb91f3d7fbaf8147d54782149bb1fc45892 Author: Steve French Date: Tue Feb 6 16:34:22 2024 -0600 Subject: smb: Fix regression in writes when non-standard maximum write size negotiated Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4860abb91f3d7fbaf8147d54782149bb1fc45892 This patch has been selected for upstream stable. The patch looks at wsize negotiation from the server, and also what is set on the mount command line, and if not a multiple of PAGE_SIZE, rounds it down, taking care to not be 0. The real corruption bug still exists in netfs/folios subsystems and we are looking for it still, but this solves the immediate data corruption issues on smb. [Testcase] Start two VMs, one for the server, and the other, the client. Server -- $ sudo apt update $ sudo apt upgrade $ sudo apt install samba $ sudo vim /etc/samba/smb.conf server min protocol = NT1 [sambashare] comment = Samba on Ubuntu path = /home/ubuntu/sambashare
[Kernel-packages] [Bug 2049634] Re: smb: wsize blocks of bytes followed with binary zeros on copy, destroying data
The fix for noble should be present in 6.8.0-16-generic and later. Marking as Fix committed for Noble. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2049634 Title: smb: wsize blocks of bytes followed with binary zeros on copy, destroying data Status in linux package in Ubuntu: Fix Committed Status in linux source package in Mantic: Fix Committed Status in linux source package in Noble: Fix Committed Bug description: BugLink: https://bugs.launchpad.net/bugs/2049634 [Impact] Upon installing the 6.5 HWE kernel on Jammy, users with a custom wsize set will see data destruction when copying files from their systems onto a cifs smb mount. wsize defaults to 65535 bytes, but when set to smaller values, like 16850, users will see blocks of 16850 bytes copied over, followed by 3900 binary zeros, followed by the next block of data followed by more binary zeros. This destroys what you are copying, and the data corruption is completely silent. A workaround is to set wsize to a multiple of PAGE_SIZE. [Fix] This was fixed upstream in 6.8-rc5 by the following: commit 4860abb91f3d7fbaf8147d54782149bb1fc45892 Author: Steve French Date: Tue Feb 6 16:34:22 2024 -0600 Subject: smb: Fix regression in writes when non-standard maximum write size negotiated Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4860abb91f3d7fbaf8147d54782149bb1fc45892 This patch has been selected for upstream stable. The patch looks at wsize negotiation from the server, and also what is set on the mount command line, and if not a multiple of PAGE_SIZE, rounds it down, taking care to not be 0. The real corruption bug still exists in netfs/folios subsystems and we are looking for it still, but this solves the immediate data corruption issues on smb. [Testcase] Start two VMs, one for the server, and the other, the client. Server -- $ sudo apt update $ sudo apt upgrade $ sudo apt install samba $ sudo vim /etc/samba/smb.conf server min protocol = NT1 [sambashare] comment = Samba on Ubuntu path = /home/ubuntu/sambashare read only = no browsable = yes $ mkdir ~/sambashare $ sudo smbpasswd -a ubuntu Client -- $ sudo apt update $ sudo apt install cifs-utils $ mkdir ~/share $ sudo mount -t cifs -o username=ubuntu,vers=1.0,wsize=16850 //192.168.122.172/sambashare ~/share $ ( set -o pipefail && head --bytes=$(( 55 * 1000 )) /dev/zero | openssl enc -aes-128-ctr -nosalt -pass "pass:my-seed" -iter 1 | hexdump --no-squeezing --format '40/1 "%02x"' --format '"\n"' >"testdata.txt" ) $ sha256sum testdata.txt 9ec09af020dce3270ea76531141940106f173c7243b7193a553480fb8500b3f2 testdata.txt Now copy the file to the share. Client -- $ cp testdata.txt share/ Server -- $ sha256sum sambashare/testdata.txt 9e573a0aa795f9cd4de4ac684a1c056dbc7d2ba5494d02e71b6225ff5f0fd866 sambashare/testdata.txt The SHA256 hash is different. If you view the file with less, you will find a block of wsize=16850 bytes, then 3900 bytes of binary zeros, followed by another wsize=16850 bytes, then 3900 bytes of binary zeros, etc. An example of a broken file is: https://launchpadlibrarian.net/712573213/testdata-back-from-server.txt [Where problems could occur] We are changing the wsize that the SMB server negotiates or the user explicitly sets on the mount command line to a safe value, if the asked for value was not a multiple of PAGE_SIZE. It is unlikely that any users will notice any difference. If the wsize happens to be rounded down to a significantly smaller number, there may be a small performance impact, e.g. you set wsize=8094 for some reason, it would round down to wsize=4096, and lead to double the writes. At least you have data integrity though. Most users default to wsize=65535, and will have no impact at all. Only those with very old smb 1.0 servers that negotiate down to 16850 will see any difference. If a regression were to occur, it could result in user's wsize being incorrectly set, leading to the underlying netfs/folios data corruption being triggered and causing data corruption. [Other info] The issue was introduced in 6.3-rc1 by: commit d08089f649a0cfb2099c8551ac47eef0cc23fdf2 Author: David Howells Date: Mon Jan 24 21:13:24 2022 + Subject: cifs: Change the I/O paths to use an iterator rather than a page list Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d08089f649a0cfb2099c8551ac47eef0cc23fdf2 Upstream mailing list discussion: https://lore.kernel.org/linux- cifs/6a65b2d1-7596-438a-8ade-2f7526b15...@rd10.de/T/#m22cd9b7289f87cd945978bd7995bcaf1beebfe67 To manage notifications about this bug go to:
[Bug 2049634] Re: smb: wsize blocks of bytes followed with binary zeros on copy, destroying data
The fix for noble should be present in 6.8.0-16-generic and later. Marking as Fix committed for Noble. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2049634 Title: smb: wsize blocks of bytes followed with binary zeros on copy, destroying data To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2049634/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2049634] Re: smb: wsize blocks of bytes followed with binary zeros on copy, destroying data
Performing verification for mantic. I started two VMs. A jammy VM for the cifs server, and a mantic VM, for the client. I set the jammy VM up as per the testcase. I set the mantic VM up as per the testcase. The mantic VM uses kernel 6.5.0-25-generic from -updates. $ uname -rv 6.5.0-25-generic #25-Ubuntu SMP PREEMPT_DYNAMIC Wed Feb 7 14:58:39 UTC 2024 I created the testdata, took the SHA256 hash, and copied it over: $ ( set -o pipefail && head --bytes=$(( 55 * 1000 )) /dev/zero | openssl enc -aes-128-ctr -nosalt -pass "pass:my-seed" -iter 1 | hexdump --no-squeezing --format '40/1 "%02x"' --format '"\n"' >"testdata.txt" ) $ sha256sum testdata.txt 9ec09af020dce3270ea76531141940106f173c7243b7193a553480fb8500b3f2 testdata.txt $ cp testdata.txt share/ On the jammy VM, I confirmed the hash has changed: $ sha256sum sambashare/testdata.txt 9e573a0aa795f9cd4de4ac684a1c056dbc7d2ba5494d02e71b6225ff5f0fd866 sambashare/testdata.txt $ less sambashare/testdata.txt Looking at the file with less, I see the large blocks of zeros. I then enabled -proposed, and installed 6.5.0-27-generic: $ uname -rv 6.5.0-27-generic #28-Ubuntu SMP PREEMPT_DYNAMIC Thu Mar 7 18:21:00 UTC 2024 I mounted the share: $ sudo mount -t cifs -o username=ubuntu,vers=1.0,wsize=16850 //192.168.122.65/sambashare ~/share Password for ubuntu@//192.168.122.65/sambashare: Looking in dmesg, I see: [ 57.280020] Key type cifs.spnego registered [ 57.280035] Key type cifs.idmap registered [ 57.280345] Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers [ 57.280861] CIFS: VFS: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers [ 57.281307] CIFS: VFS: wsize rounded down to 16384 to multiple of PAGE_SIZE 4096 [ 57.281599] CIFS: Attempting to mount //192.168.122.65/sambashare the line of interest is "CIFS: VFS: wsize rounded down to 16384 to multiple of PAGE_SIZE 4096" showing we now have a wsize of 16384, and we can see this with mount -l: $ mount -l //192.168.122.65/sambashare on /home/ubuntu/share type cifs (rw,relatime,vers=1.0,cache=strict,username=ubuntu,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.122.65,soft,unix,posixpaths,serverino,mapposix,acl,rsize=1048576,wsize=16384,bsize=1048576,echo_interval=60,actimeo=1,closetimeo=1) I then copied the file over: $ cp testdata.txt share/ Looking at the SHA256 sum on the Jammy server: $ sha256sum sambashare/testdata.txt 9ec09af020dce3270ea76531141940106f173c7243b7193a553480fb8500b3f2 sambashare/testdata.txt When looking at the file with less, there are no more binary zeros. The kernel in -proposed fixes the issue, happy to mark verified for mantic. ** Tags removed: verification-needed-mantic-linux ** Tags added: verification-done-mantic-linux -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2049634 Title: smb: wsize blocks of bytes followed with binary zeros on copy, destroying data To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2049634/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2049634] Re: smb: wsize blocks of bytes followed with binary zeros on copy, destroying data
** Changed in: linux (Ubuntu Noble) Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2049634 Title: smb: wsize blocks of bytes followed with binary zeros on copy, destroying data To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2049634/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Kernel-packages] [Bug 2049634] Re: smb: wsize blocks of bytes followed with binary zeros on copy, destroying data
** Changed in: linux (Ubuntu Noble) Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2049634 Title: smb: wsize blocks of bytes followed with binary zeros on copy, destroying data Status in linux package in Ubuntu: Fix Committed Status in linux source package in Mantic: Fix Committed Status in linux source package in Noble: Fix Committed Bug description: BugLink: https://bugs.launchpad.net/bugs/2049634 [Impact] Upon installing the 6.5 HWE kernel on Jammy, users with a custom wsize set will see data destruction when copying files from their systems onto a cifs smb mount. wsize defaults to 65535 bytes, but when set to smaller values, like 16850, users will see blocks of 16850 bytes copied over, followed by 3900 binary zeros, followed by the next block of data followed by more binary zeros. This destroys what you are copying, and the data corruption is completely silent. A workaround is to set wsize to a multiple of PAGE_SIZE. [Fix] This was fixed upstream in 6.8-rc5 by the following: commit 4860abb91f3d7fbaf8147d54782149bb1fc45892 Author: Steve French Date: Tue Feb 6 16:34:22 2024 -0600 Subject: smb: Fix regression in writes when non-standard maximum write size negotiated Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4860abb91f3d7fbaf8147d54782149bb1fc45892 This patch has been selected for upstream stable. The patch looks at wsize negotiation from the server, and also what is set on the mount command line, and if not a multiple of PAGE_SIZE, rounds it down, taking care to not be 0. The real corruption bug still exists in netfs/folios subsystems and we are looking for it still, but this solves the immediate data corruption issues on smb. [Testcase] Start two VMs, one for the server, and the other, the client. Server -- $ sudo apt update $ sudo apt upgrade $ sudo apt install samba $ sudo vim /etc/samba/smb.conf server min protocol = NT1 [sambashare] comment = Samba on Ubuntu path = /home/ubuntu/sambashare read only = no browsable = yes $ mkdir ~/sambashare $ sudo smbpasswd -a ubuntu Client -- $ sudo apt update $ sudo apt install cifs-utils $ mkdir ~/share $ sudo mount -t cifs -o username=ubuntu,vers=1.0,wsize=16850 //192.168.122.172/sambashare ~/share $ ( set -o pipefail && head --bytes=$(( 55 * 1000 )) /dev/zero | openssl enc -aes-128-ctr -nosalt -pass "pass:my-seed" -iter 1 | hexdump --no-squeezing --format '40/1 "%02x"' --format '"\n"' >"testdata.txt" ) $ sha256sum testdata.txt 9ec09af020dce3270ea76531141940106f173c7243b7193a553480fb8500b3f2 testdata.txt Now copy the file to the share. Client -- $ cp testdata.txt share/ Server -- $ sha256sum sambashare/testdata.txt 9e573a0aa795f9cd4de4ac684a1c056dbc7d2ba5494d02e71b6225ff5f0fd866 sambashare/testdata.txt The SHA256 hash is different. If you view the file with less, you will find a block of wsize=16850 bytes, then 3900 bytes of binary zeros, followed by another wsize=16850 bytes, then 3900 bytes of binary zeros, etc. An example of a broken file is: https://launchpadlibrarian.net/712573213/testdata-back-from-server.txt [Where problems could occur] We are changing the wsize that the SMB server negotiates or the user explicitly sets on the mount command line to a safe value, if the asked for value was not a multiple of PAGE_SIZE. It is unlikely that any users will notice any difference. If the wsize happens to be rounded down to a significantly smaller number, there may be a small performance impact, e.g. you set wsize=8094 for some reason, it would round down to wsize=4096, and lead to double the writes. At least you have data integrity though. Most users default to wsize=65535, and will have no impact at all. Only those with very old smb 1.0 servers that negotiate down to 16850 will see any difference. If a regression were to occur, it could result in user's wsize being incorrectly set, leading to the underlying netfs/folios data corruption being triggered and causing data corruption. [Other info] The issue was introduced in 6.3-rc1 by: commit d08089f649a0cfb2099c8551ac47eef0cc23fdf2 Author: David Howells Date: Mon Jan 24 21:13:24 2022 + Subject: cifs: Change the I/O paths to use an iterator rather than a page list Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d08089f649a0cfb2099c8551ac47eef0cc23fdf2 Upstream mailing list discussion: https://lore.kernel.org/linux- cifs/6a65b2d1-7596-438a-8ade-2f7526b15...@rd10.de/T/#m22cd9b7289f87cd945978bd7995bcaf1beebfe67 To manage notifications about this bug go to:
[Bug 2056549] Re: Problems with nfs-common after upgrade to 3.6
Hi Rainer. I think we will leave it as is. Keep using v4.0 for now, and you should be fine. I'll close the bug. Andreas, I will remove regression-update if that is okay with you. Thanks, Matthew ** Changed in: nfs-utils (Ubuntu Focal) Status: New => Invalid ** Changed in: nfs-utils (Ubuntu) Status: New => Invalid ** Tags removed: regression-update -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2056549 Title: Problems with nfs-common after upgrade to 3.6 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/2056549/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2056549] Re: Problems with nfs-common after upgrade to 3.6
Hi Rainer, Thanks for trying that out, and it is great to hear that v4.0 works for you, and you added it to your /etc/fstab as a good workaround for the meantime. Are you interested in debugging why your system hangs when trying v4.2 and v4.1? or do you want to leave it there? 4.0 will keep working for you with 1:1.3.4-2.5ubuntu3.6. Thanks, Matthew -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2056549 Title: Problems with nfs-common after upgrade to 3.6 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/2056549/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Kernel-packages] [Bug 2056743] Re: Keyboard stops working after suspend on Dell XPS 13
I think the fix was included in 5.15.149 upstream; https://lwn.net/Articles/963359/ Input: atkbd - skip ATKBD_CMD_SETLEDS when skipping ATKBD_CMD_GETID The kernel team have just pulled in 5.15.148, and haven't started on 149. They will likely get to it in the next week or so. Thanks, Matthew -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2056743 Title: Keyboard stops working after suspend on Dell XPS 13 Status in linux package in Ubuntu: New Bug description: The problem occurs with the 5.15.0-102 kernel but not with 5.15.0-100. The issue seems to be identical to the problem reported for 6.7.0 here: https://bbs.archlinux.org/viewtopic.php?id=292203 On the page linked above is says a patch was submitted 2024-01-26 and the problem solved 2024-03-04 in linux 6.7.5 or linux-lts 6.6.17. I'm concerned that this still needs fixing in the 5.xxx kernel branch. Touchpad does not freeze and mouse-control of windows still works, so it's different from a bug reported elsewhere. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: linux-image-5.15.0-102-generic 5.15.0-102.112 ProcVersionSignature: Ubuntu 5.15.0-100.110-generic 5.15.143 Uname: Linux 5.15.0-100-generic x86_64 ApportVersion: 2.20.11-0ubuntu82.5 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: axel 2494 F pulseaudio CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME Date: Mon Mar 11 09:54:23 2024 DistributionChannelDescriptor: # This is a distribution channel descriptor # For more information see http://wiki.ubuntu.com/DistributionChannelDescriptor canonical-oem-somerville-xenial-amd64-20160624-2 HibernationDevice: RESUME=UUID=461ac6d0-c7ab-4f93-b97d-4d7b3f14f378 InstallationDate: Installed on 2018-08-31 (2018 days ago) InstallationMedia: Ubuntu 16.04 "Xenial" - Build amd64 LIVE Binary 20160624-10:47 Lsusb: Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 003: ID 0489:e0a2 Foxconn / Hon Hai Bus 001 Device 002: ID 0bda:58f4 Realtek Semiconductor Corp. Integrated_Webcam_HD Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: Dell Inc. XPS 13 9370 ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-100-generic root=UUID=fb8af021-9abd-4e95-9458-7a78ac12bb46 ro quiet splash mem_sleep_default=deep vt.handoff=7 RelatedPackageVersions: linux-restricted-modules-5.15.0-100-generic N/A linux-backports-modules-5.15.0-100-generic N/A linux-firmware 20220329.git681281e4-0ubuntu3.29 SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 07/06/2022 dmi.bios.release: 1.21 dmi.bios.vendor: Dell Inc. dmi.bios.version: 1.21.0 dmi.board.name: 0W970W dmi.board.vendor: Dell Inc. dmi.board.version: A03 dmi.chassis.type: 10 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvr1.21.0:bd07/06/2022:br1.21:svnDellInc.:pnXPS139370:pvr:rvnDellInc.:rn0W970W:rvrA03:cvnDellInc.:ct10:cvr:sku07E6: dmi.product.family: XPS dmi.product.name: XPS 13 9370 dmi.product.sku: 07E6 dmi.sys.vendor: Dell Inc. modified.conffile..etc.default.apport: # set this to 0 to disable apport, or to 1 to enable it # you can temporarily override this with # sudo service apport start force_start=1 enabled=0 mtime.conffile..etc.default.apport: 2018-09-08T10:23:15.468001 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2056743/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Bug 2056743] Re: Keyboard stops working after suspend on Dell XPS 13
I think the fix was included in 5.15.149 upstream; https://lwn.net/Articles/963359/ Input: atkbd - skip ATKBD_CMD_SETLEDS when skipping ATKBD_CMD_GETID The kernel team have just pulled in 5.15.148, and haven't started on 149. They will likely get to it in the next week or so. Thanks, Matthew -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2056743 Title: Keyboard stops working after suspend on Dell XPS 13 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2056743/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2056549] Re: Problems with nfs-common after upgrade to 3.6
Hi Rainer, Thanks for the screenshots. The updated package changes how the '-o vers=4' parameter works. The old / wrong behaviour would always use nfs v4.0 no matter what. All other nfs-common versions apart from the version in focal would try v4.2, then if that didn't work, then v4.1, and then v4.0, and then eventually v3.0, in a laddering fashion. You can see in your second screenshot that: $ mount -vvv -o vers=4 /srv/www/nextcloud/data ...,vers=4.2,... See, it now tries v4.2 by default? I guess your QNAP appliance is not replying to v4.2 version negotiation correctly. It is suppose to ladder down to 4.1 and then 4.0, but maybe the QNAP server doesn't reply correctly and nfs-common just waits. Can you try each specific version and report back? $ mount -vvv -o vers=4.2 /srv/www/nextcloud/data // this should hang? $ mount -vvv -o vers=4.1 /srv/www/nextcloud/data // unknown. $ mount -vvv -o vers=4.0 /srv/www/nextcloud/data // this should work As a workaround in the meantime, you can edit your /etc/fstab to set nfsvers=4.0, and you should be restored to what it was before. Just add a ".0" to the end of "nfsvers=4". Do you happen to have access to the QNAP appliance to configure NFS versions? Thanks, Matthew -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2056549 Title: Problems with nfs-common after upgrade to 3.6 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/2056549/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2056549] Re: Problems with nfs-common after upgrade to 3.6
Hi Rainer, I developed the nfs-utils update of 1:1.3.4-2.5ubuntu3.6, and I am very interested to hear more about the possible regression. The intention was to fix version negotiation when using the '-t nfs4' or '-o vers=4' parameters in your mount command. You can find more about it here: https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/2049262 Since you are affected, you must be using '-t nfs4' or '-o vers=4'. Can you please let us know the /etc/fstab entry for this mount point? Could you also do a mount manually with -vvv appended to the mount command line? $ mount -vvv /my_nfs_path/ e.g. $ sudo mount -o vers=4 -vvv nfs-server:/ /mnt I would really like to see the verbose output. Please include it in your comment. What version NFS are you using? It must be 4.x, since the changes only affect 4.x negotiation. Let me know these details and I will investigate asap. Thanks, Matthew ** Also affects: nfs-utils (Ubuntu Focal) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2056549 Title: Problems with nfs-common after upgrade to 3.6 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/2056549/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2053041] Re: Issue when shutting down computer: internal hard drive is not shut down properly
Yes, 6.5.0-25-generic is available for both jammy and mantic systems. It was released earlier this week. Is anyone able to try it out and let me know if it fixes the issue? Thanks. ** Changed in: linux (Ubuntu Mantic) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2053041 Title: Issue when shutting down computer: internal hard drive is not shut down properly To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2053041/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Kernel-packages] [Bug 2053041] Re: Issue when shutting down computer: internal hard drive is not shut down properly
Yes, 6.5.0-25-generic is available for both jammy and mantic systems. It was released earlier this week. Is anyone able to try it out and let me know if it fixes the issue? Thanks. ** Changed in: linux (Ubuntu Mantic) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2053041 Title: Issue when shutting down computer: internal hard drive is not shut down properly Status in linux package in Ubuntu: Fix Released Status in linux source package in Mantic: Fix Released Bug description: After the last kernel upgrade, I noticed that, in the S.M.A.R.T. monitor, parameter ID 192 "Power Off Retract Count" increased every time I turned off the system. I also noticed the "click" of the head parking when shutting down the computer. By restarting the computer with previous kernel version (6.5.0-15.15~22.04.1) the issue didn't happen, so I assume it's a kernel bug, that causes it to shut down the computer before hard drive is deactivated ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: linux-image-6.5.0-17-generic 6.5.0-17.17~22.04.1 ProcVersionSignature: Ubuntu 6.5.0-17.17~22.04.1-generic 6.5.8 Uname: Linux 6.5.0-17-generic x86_64 ApportVersion: 2.20.11-0ubuntu82.5 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: XFCE Date: Tue Feb 13 16:35:55 2024 InstallationDate: Installed on 2020-10-02 (1228 days ago) InstallationMedia: Ubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731) SourcePackage: linux-signed-hwe-6.5 UpgradeStatus: Upgraded to jammy on 2022-08-11 (550 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2053041/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 2056297] Re: Non-flatpak Firefox-based browsers crash with kernel 6.8.0-11-generic in 24.04
*** This bug is a duplicate of bug 2046844 *** https://bugs.launchpad.net/bugs/2046844 Hi cipricus, This is a security feature working as intended. Ubuntu recently decided to disable unprivileged access to user namespaces. You can find more information it about it here: https://ubuntu.com/blog/ubuntu-23-10-restricted-unprivileged-user-namespaces https://discourse.ubuntu.com/t/spec-unprivileged-user-namespace-restrictions-via-apparmor-in-ubuntu-23-10/37626 https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2046844 It was included (but turned off in 23.10). In 24.04, it has been turned on. We have been adding apparmor profiles for most packaged applications. Saying that, firefox downloaded from tarballs or other places don't come with an apparmor profile, so the mitigation isn't relaxed for them. You can enable user namespaces by either making a apparmor profile for your firefox installs, making sure the directory where firefox is installed is correct in the profile, or by just enabling user namespaces for your system. There is instructions to do this in the first blog link. Thanks, Matthew ** This bug has been marked a duplicate of bug 2046844 AppArmor user namespace creation restrictions cause many applications to crash with SIGTRAP -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2056297 Title: Non-flatpak Firefox-based browsers crash with kernel 6.8.0-11-generic in 24.04 Status in linux package in Ubuntu: New Bug description: All details are to be found in my previous bug report (https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/2056190). Given that simply reverting to kernel 6.5.0-17-generic fixes the problem, the bug seems to be with the 6.8.0 kernel. Therefore I'm posting this. ProblemType: Bug DistroRelease: Ubuntu 24.04 Package: linux-image-6.8.0-11-generic 6.8.0-11.11 ProcVersionSignature: Ubuntu 6.8.0-11.11-generic 6.8.0-rc4 Uname: Linux 6.8.0-11-generic x86_64 ApportVersion: 2.28.0-0ubuntu1 Architecture: amd64 CRDA: N/A CasperMD5CheckResult: pass CurrentDesktop: KDE Date: Wed Mar 6 09:49:36 2024 InstallationDate: Installed on 2023-10-04 (154 days ago) InstallationMedia: Kubuntu 22.04 LTS "Jammy Jellyfish" - Release amd64 (20220419) MachineType: Sony Corporation VPCSB2P9E ProcFB: 0 i915drmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-6.8.0-11-generic root=UUID=0dbb7177-a759-43f8-86d2-53e3253805d5 ro quiet splash vt.handoff=7 PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon. RelatedPackageVersions: linux-restricted-modules-6.8.0-11-generic N/A linux-backports-modules-6.8.0-11-generic N/A linux-firmware20240202.git36777504-0ubuntu1 SourcePackage: linux UpgradeStatus: Upgraded to noble on 2024-03-04 (2 days ago) dmi.bios.date: 11/16/2011 dmi.bios.release: 20.85 dmi.bios.vendor: INSYDE dmi.bios.version: R2085H4 dmi.board.asset.tag: N/A dmi.board.name: VAIO dmi.board.vendor: Sony Corporation dmi.board.version: N/A dmi.chassis.asset.tag: N/A dmi.chassis.type: 10 dmi.chassis.vendor: Sony Corporation dmi.chassis.version: N/A dmi.ec.firmware.release: 20.85 dmi.modalias: dmi:bvnINSYDE:bvrR2085H4:bd11/16/2011:br20.85:efr20.85:svnSonyCorporation:pnVPCSB2P9E:pvrC609DJQ5:rvnSonyCorporation:rnVAIO:rvrN/A:cvnSonyCorporation:ct10:cvrN/A:skuN/A: dmi.product.family: VAIO dmi.product.name: VPCSB2P9E dmi.product.sku: N/A dmi.product.version: C609DJQ5 dmi.sys.vendor: Sony Corporation To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2056297/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Bug 2056297] Re: Non-flatpak Firefox-based browsers crash with kernel 6.8.0-11-generic in 24.04
*** This bug is a duplicate of bug 2046844 *** https://bugs.launchpad.net/bugs/2046844 Hi cipricus, This is a security feature working as intended. Ubuntu recently decided to disable unprivileged access to user namespaces. You can find more information it about it here: https://ubuntu.com/blog/ubuntu-23-10-restricted-unprivileged-user-namespaces https://discourse.ubuntu.com/t/spec-unprivileged-user-namespace-restrictions-via-apparmor-in-ubuntu-23-10/37626 https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2046844 It was included (but turned off in 23.10). In 24.04, it has been turned on. We have been adding apparmor profiles for most packaged applications. Saying that, firefox downloaded from tarballs or other places don't come with an apparmor profile, so the mitigation isn't relaxed for them. You can enable user namespaces by either making a apparmor profile for your firefox installs, making sure the directory where firefox is installed is correct in the profile, or by just enabling user namespaces for your system. There is instructions to do this in the first blog link. Thanks, Matthew ** This bug has been marked a duplicate of bug 2046844 AppArmor user namespace creation restrictions cause many applications to crash with SIGTRAP -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2056297 Title: Non-flatpak Firefox-based browsers crash with kernel 6.8.0-11-generic in 24.04 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2056297/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Kernel-packages] [Bug 2055147] Re: Kernel upgrade to 6.5.0-21-generic fails to boot
Hi Sly, We do actually test as many dkms builds as we can. Well, mainly all the kernel modules present in the Ubuntu archive, like evdi-dkms. The trouble starts when you get dkms sources from other places that we don't know about, like the DisplayLink installer that I linked above. You, me, and other users just install it, and forget all about it, until something breaks. The real solution is to get rid of as many out of tree kernel modules as we can. In the case of evdi, a few people have tried, and failed, to get it into the mainline kernel. Upstream aren't interested in tidying it up for inclusion, so it just rots out of tree. Anyway, I am glad that it works for you now. Thanks, Matthew -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2055147 Title: Kernel upgrade to 6.5.0-21-generic fails to boot Status in linux package in Ubuntu: Invalid Bug description: After automatic update to kernel 6.5.0-21-generic my laptop fails to complete booting with a kernel panic. Safe mode did not work. Booting to previous kernel 6.5.0-17-generic is fine. Errors during failed boot include: ``` VFS Cannot open root device /dev/mapper/vgubuntu-root or unknown-block(0.0) error -6 Please append a correct root= boot option Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0.0) ``` Trying clean up, I see the following error with the kernel installation: ``` sly@sigil:~$ sudo apt-get autoremove Reading package lists... Done Building dependency tree... Done Reading state information... Done 0 to upgrade, 0 to newly install, 0 to remove and 6 not to upgrade. 3 not fully installed or removed. After this operation, 0 B of additional disk space will be used. Setting up linux-headers-6.5.0-21-generic (6.5.0-21.21) ... /etc/kernel/header_postinst.d/dkms: * dkms: running auto installation service for kernel 6.5.0-21-generic Sign command: /usr/bin/kmodsign Signing key: /var/lib/shim-signed/mok/MOK.priv Public certificate (MOK): /var/lib/shim-signed/mok/MOK.der Building module: Cleaning build area... make -j16 KERNELRELEASE=6.5.0-21-generic all INCLUDEDIR=/lib/modules/6.5.0-21-generic/build/include KVERSION=6.5.0-21-generic DKMS_BUILD=1...(bad exit status: 2) ERROR (dkms apport): binary package for evdi: 1.11.0 not found Error! Bad return status for module build on kernel: 6.5.0-21-generic (x86_64) Consult /var/lib/dkms/evdi/1.11.0/build/make.log for more information. dkms autoinstall on 6.5.0-21-generic/x86_64 succeeded for nvidia dkms autoinstall on 6.5.0-21-generic/x86_64 failed for evdi(10) Error! One or more modules failed to install during autoinstall. Refer to previous errors for more information. * dkms: autoinstall for kernel 6.5.0-21-generic ...fail! run-parts: /etc/kernel/header_postinst.d/dkms exited with return code 11 dpkg: error processing package linux-headers-6.5.0-21-generic (--configure): installed linux-headers-6.5.0-21-generic package post-installation script subprocess returned error exit status 1 dpkg: dependency problems prevent configuration of linux-headers-generic: linux-headers-generic depends on linux-headers-6.5.0-21-generic; however: Package linux-headers-6.5.0-21-generic is not configured yet. dpkg: error processing package linux-headers-generic (--configure): dependency problems - leaving unconfigured No apport report written because the error message indicates its a followup error from a previous failure. No apport report written because the error message indicates its a followup error from a previous failure. dpkg: dependency problems prevent configuration of linux-generic: linux-generic depends on linux-headers-generic (= 6.5.0.21.20); however: Package linux-headers-generic is not configured yet. dpkg: error processing package linux-generic (--configure): dependency problems - leaving unconfigured Processing triggers for linux-image-6.5.0-21-generic (6.5.0-21.21) ... /etc/kernel/postinst.d/dkms: * dkms: running auto installation service for kernel 6.5.0-21-generic Sign command: /usr/bin/kmodsign Signing key: /var/lib/shim-signed/mok/MOK.priv Public certificate (MOK): /var/lib/shim-signed/mok/MOK.der Building module: Cleaning build area... make -j16 KERNELRELEASE=6.5.0-21-generic all INCLUDEDIR=/lib/modules/6.5.0-21-generic/build/include KVERSION=6.5.0-21-generic DKMS_BUILD=1...(bad exit status: 2) ERROR (dkms apport): binary package for evdi: 1.11.0 not found Error! Bad return status for module build on kernel: 6.5.0-21-generic (x86_64) Consult /var/lib/dkms/evdi/1.11.0/build/make.log for more information. dkms autoinstall on 6.5.0-21-generic/x86_64
[Bug 2055147] Re: Kernel upgrade to 6.5.0-21-generic fails to boot
Hi Sly, We do actually test as many dkms builds as we can. Well, mainly all the kernel modules present in the Ubuntu archive, like evdi-dkms. The trouble starts when you get dkms sources from other places that we don't know about, like the DisplayLink installer that I linked above. You, me, and other users just install it, and forget all about it, until something breaks. The real solution is to get rid of as many out of tree kernel modules as we can. In the case of evdi, a few people have tried, and failed, to get it into the mainline kernel. Upstream aren't interested in tidying it up for inclusion, so it just rots out of tree. Anyway, I am glad that it works for you now. Thanks, Matthew -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2055147 Title: Kernel upgrade to 6.5.0-21-generic fails to boot To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2055147/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2055147] Re: Kernel upgrade to 6.5.0-21-generic fails to boot
Hi Sly, Your evdi kernel module for DisplayLink docks failed to compile. It likely couldn't generate your initramfs, leaving your 6.5.0-21-generic not able to boot. Your logs say its trying to build version 1.11.0: ERROR (dkms apport): binary package for evdi: 1.11.0 not found Error! Bad return status for module build on kernel: 6.5.0-21-generic (x86_64) Consult /var/lib/dkms/evdi/1.11.0/build/make.log for more information. This is a bit old and outdated. You can re-install the DisplayLink drivers from the upstream source, that has a newer version of evdi: https://www.synaptics.com/products/displaylink-graphics/downloads/ubuntu That will probably remove the old evdi and install a newer one. Alternatively, you can remove the old evdi dkms entry and install evdi- dkms from the Ubuntu repositories which has a evdi compatible with 6.5.0-21-generic. DisplayLink support is kinda bad on Ubuntu, but its what we must do to have working displays with our docks. Thanks, Matthew ** Changed in: linux (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2055147 Title: Kernel upgrade to 6.5.0-21-generic fails to boot To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2055147/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Kernel-packages] [Bug 2055147] Re: Kernel upgrade to 6.5.0-21-generic fails to boot
Hi Sly, Your evdi kernel module for DisplayLink docks failed to compile. It likely couldn't generate your initramfs, leaving your 6.5.0-21-generic not able to boot. Your logs say its trying to build version 1.11.0: ERROR (dkms apport): binary package for evdi: 1.11.0 not found Error! Bad return status for module build on kernel: 6.5.0-21-generic (x86_64) Consult /var/lib/dkms/evdi/1.11.0/build/make.log for more information. This is a bit old and outdated. You can re-install the DisplayLink drivers from the upstream source, that has a newer version of evdi: https://www.synaptics.com/products/displaylink-graphics/downloads/ubuntu That will probably remove the old evdi and install a newer one. Alternatively, you can remove the old evdi dkms entry and install evdi- dkms from the Ubuntu repositories which has a evdi compatible with 6.5.0-21-generic. DisplayLink support is kinda bad on Ubuntu, but its what we must do to have working displays with our docks. Thanks, Matthew ** Changed in: linux (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2055147 Title: Kernel upgrade to 6.5.0-21-generic fails to boot Status in linux package in Ubuntu: Invalid Bug description: After automatic update to kernel 6.5.0-21-generic my laptop fails to complete booting with a kernel panic. Safe mode did not work. Booting to previous kernel 6.5.0-17-generic is fine. Errors during failed boot include: ``` VFS Cannot open root device /dev/mapper/vgubuntu-root or unknown-block(0.0) error -6 Please append a correct root= boot option Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0.0) ``` Trying clean up, I see the following error with the kernel installation: ``` sly@sigil:~$ sudo apt-get autoremove Reading package lists... Done Building dependency tree... Done Reading state information... Done 0 to upgrade, 0 to newly install, 0 to remove and 6 not to upgrade. 3 not fully installed or removed. After this operation, 0 B of additional disk space will be used. Setting up linux-headers-6.5.0-21-generic (6.5.0-21.21) ... /etc/kernel/header_postinst.d/dkms: * dkms: running auto installation service for kernel 6.5.0-21-generic Sign command: /usr/bin/kmodsign Signing key: /var/lib/shim-signed/mok/MOK.priv Public certificate (MOK): /var/lib/shim-signed/mok/MOK.der Building module: Cleaning build area... make -j16 KERNELRELEASE=6.5.0-21-generic all INCLUDEDIR=/lib/modules/6.5.0-21-generic/build/include KVERSION=6.5.0-21-generic DKMS_BUILD=1...(bad exit status: 2) ERROR (dkms apport): binary package for evdi: 1.11.0 not found Error! Bad return status for module build on kernel: 6.5.0-21-generic (x86_64) Consult /var/lib/dkms/evdi/1.11.0/build/make.log for more information. dkms autoinstall on 6.5.0-21-generic/x86_64 succeeded for nvidia dkms autoinstall on 6.5.0-21-generic/x86_64 failed for evdi(10) Error! One or more modules failed to install during autoinstall. Refer to previous errors for more information. * dkms: autoinstall for kernel 6.5.0-21-generic ...fail! run-parts: /etc/kernel/header_postinst.d/dkms exited with return code 11 dpkg: error processing package linux-headers-6.5.0-21-generic (--configure): installed linux-headers-6.5.0-21-generic package post-installation script subprocess returned error exit status 1 dpkg: dependency problems prevent configuration of linux-headers-generic: linux-headers-generic depends on linux-headers-6.5.0-21-generic; however: Package linux-headers-6.5.0-21-generic is not configured yet. dpkg: error processing package linux-headers-generic (--configure): dependency problems - leaving unconfigured No apport report written because the error message indicates its a followup error from a previous failure. No apport report written because the error message indicates its a followup error from a previous failure. dpkg: dependency problems prevent configuration of linux-generic: linux-generic depends on linux-headers-generic (= 6.5.0.21.20); however: Package linux-headers-generic is not configured yet. dpkg: error processing package linux-generic (--configure): dependency problems - leaving unconfigured Processing triggers for linux-image-6.5.0-21-generic (6.5.0-21.21) ... /etc/kernel/postinst.d/dkms: * dkms: running auto installation service for kernel 6.5.0-21-generic Sign command: /usr/bin/kmodsign Signing key: /var/lib/shim-signed/mok/MOK.priv Public certificate (MOK): /var/lib/shim-signed/mok/MOK.der Building module: Cleaning build area... make -j16 KERNELRELEASE=6.5.0-21-generic all
[Bug 2053041] Re: Issue when shutting down computer: internal hard drive is not shut down properly
Hi everyone, @angros47, yes, this issue looks to be what you are experiencing here. https://bugs.archlinux.org/task/80064 mentions that the issue was introduced in: commit aa3998dbeb3abce63653b7f6d4542e7dcd022590 Author: Damien Le Moal Date: Sat Aug 26 09:43:39 2023 +0900 Subject: ata: libata-scsi: Disable scsi device manage_system_start_stop Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=aa3998dbeb3abce63653b7f6d4542e7dcd022590 This was first included in... 6.5.0-17-generic. The bug mentions the fix is: commit 24eca2dce0f8d19db808c972b0281298d0bafe99 Author: Damien Le Moal Date: Wed Oct 25 15:46:12 2023 +0900 Subject: scsi: sd: Introduce manage_shutdown device flag Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=24eca2dce0f8d19db808c972b0281298d0bafe99 This is currently queued up for 6.5.0-25-generic, which is currently in -proposed for mantic, and is currently being built for jammy. If you are on mantic / 23.10, please try the -proposed kernel: Instructions to Install (On a mantic system): 1) cat << EOF | sudo tee /etc/apt/sources.list.d/ubuntu-$(lsb_release -cs)-proposed.list # Enable Ubuntu proposed archive deb http://archive.ubuntu.com/ubuntu/ $(lsb_release -cs)-proposed main universe EOF 2) sudo apt update 3) sudo apt install linux-image-6.5.0-25-generic linux-modules-6.5.0-25-generic linux-modules-extra-6.5.0-25-generic linux-headers-6.5.0-25-generic 4) sudo rm /etc/apt/sources.list.d/ubuntu-$(lsb_release -cs)-proposed.list 5) sudo apt update 6) sudo reboot 7) uname -rv 6.5.0-25-generic #25-Ubuntu SMP PREEMPT_DYNAMIC Wed Feb 7 14:58:39 UTC 2024 For jammy / 22.04 users, I have built 6.5.0-21-generic with the fix ontop of it, for anyone who wants to try it and report back that it actually fixes the issue. Please note this package is NOT SUPPORTED by Canonical, and is for TESTING PURPOSES ONLY. ONLY Install in a dedicated test environment. Instructions to Install (On a jammy system): 1) sudo add-apt-repository ppa:mruffell/lp2053041-test 2) sudo apt update 3) sudo apt install linux-image-unsigned-6.5.0-21-generic linux-modules-6.5.0-21-generic linux-modules-extra-6.5.0-21-generic linux-headers-6.5.0-21-generic 4) sudo reboot 5) uname -rv 6.5.0-21-generic #21~22.04.1+TEST2053041v20240226b1-Ubuntu SMP PREEMPT_DYNAMIC Mo If asked to abort removing the running kernel, say no. You can also wait, and I'll write back when 6.5.0-25-generic enters -proposed for Jammy, will be a day or two. If the patch works, then the kernel SRU cycle will complete in the first week of March, as per https://kernel.ubuntu.com/, so you don't have too much longer to wait until 6.5.0-25-generic becomes available. Thanks, Matthew ** Changed in: linux (Ubuntu) Status: Confirmed => Fix Released ** Changed in: linux (Ubuntu Mantic) Status: Confirmed => Fix Committed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2053041 Title: Issue when shutting down computer: internal hard drive is not shut down properly To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2053041/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2049634] Re: smb: wsize blocks of bytes followed with binary zeros on copy, destroying data
Reviews from Senior Kernel Team Members: ACK 1 https://lists.ubuntu.com/archives/kernel-team/2024-February/149051.html ACK 2 https://lists.ubuntu.com/archives/kernel-team/2024-February/149061.html Applied https://lists.ubuntu.com/archives/kernel-team/2024-February/149119.html Will let you know when this gets tagged to a kernel release. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2049634 Title: smb: wsize blocks of bytes followed with binary zeros on copy, destroying data To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2049634/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2049262] Re: mount.nfs: fix version negotiation laddering with parameters '-t nfs4' or '-o vers=4'
Performing verification for Focal. I set up a Jammy VM to be the nfs server, using the instructions in the SRU template. $ sudo cat /proc/fs/nfsd/versions -2 -3 +4 -4.0 +4.1 +4.2 4.0 is not allowed, but 4.1 and 4.2 are. I then started a fresh Focal VM, and installed nfs-common 1.3.4-2.5ubuntu3.5 from -updates. I then tried to mount the NFS share: $ sudo mount -o vers=4 -vvv jammy-nfs-server:/ /mnt mount.nfs: timeout set for Mon Feb 26 01:21:35 2024 mount.nfs: trying text-based options 'vers=4,addr=192.168.122.17,clientaddr=192.168.122.19' mount.nfs: mount(2): Protocol not supported mount.nfs: Protocol not supported as the bug report describes, when we specify -o vers=4 on the mount command line, it only tries 4.0 and no other version. I then enabled -proposed and installed nfs-common 1.3.4-2.5ubuntu3.6. Trying the mount again: $ sudo mount -o vers=4 -vvv jammy-nfs-server:/ /mnt mount.nfs: timeout set for Mon Feb 26 01:27:47 2024 mount.nfs: trying text-based options 'vers=4.2,addr=192.168.122.17,clientaddr=192.168.122.19' $ ll /mnt total 12 drwxr-xr-x 3 root root 4096 Feb 26 01:10 ./ drwxr-xr-x 19 root root 4096 Feb 26 01:13 ../ drwxr-xr-x 2 root root 4096 Feb 26 01:10 users/ This time it correctly tries version 4.2, and since 4.2 is allowed, the mount succeeds. To test the laddering, I went to the nfs-server and then edited /etc/nfs.conf and changed: vers4.2=n and restarted nfs-server.service. Back on the Focal VM, we now see: $ sudo mount -o vers=4 -vvv jammy-nfs-server:/ /mnt mount.nfs: timeout set for Mon Feb 26 01:30:40 2024 mount.nfs: trying text-based options 'vers=4.2,addr=192.168.122.17,clientaddr=192.168.122.19' mount.nfs: mount(2): Protocol not supported mount.nfs: trying text-based options 'vers=4.1,addr=192.168.122.17,clientaddr=192.168.122.19' $ ll /mnt total 12 drwxr-xr-x 3 root root 4096 Feb 26 01:10 ./ drwxr-xr-x 19 root root 4096 Feb 26 01:13 ../ drwxr-xr-x 2 root root 4096 Feb 26 01:10 users/ The laddering works, and we try version 4.2, then 4.1 which succeeds. Lets also turn off 4.1 on the server, and enable 4.0: vers4.0=y vers4.1=n now on the client, we see: $ sudo mount -o vers=4 -vvv jammy-nfs-server:/ /mnt mount.nfs: timeout set for Mon Feb 26 01:32:53 2024 mount.nfs: trying text-based options 'vers=4.2,addr=192.168.122.17,clientaddr=192.168.122.19' mount.nfs: mount(2): Protocol not supported mount.nfs: trying text-based options 'vers=4.1,addr=192.168.122.17,clientaddr=192.168.122.19' mount.nfs: mount(2): Protocol not supported mount.nfs: trying text-based options 'vers=4.0,addr=192.168.122.17,clientaddr=192.168.122.19' $ ll /mnt total 12 drwxr-xr-x 3 root root 4096 Feb 26 01:10 ./ drwxr-xr-x 19 root root 4096 Feb 26 01:13 ../ drwxr-xr-x 2 root root 4096 Feb 26 01:10 users/ We laddered all the way down to 4.0 and connected, since we just allowed it. This works great. The package in -proposed fixes the issue. Happy to mark verified for Focal. ** Tags removed: verification-needed verification-needed-focal ** Tags added: verification-done-focal -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2049262 Title: mount.nfs: fix version negotiation laddering with parameters '-t nfs4' or '-o vers=4' To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/2049262/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
