[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1108462: marked as done (linux-image-6.12.33+deb13-amd64: Fails to write mounted NTFS drive, I/O error)

Your message dated Tue, 1 Jul 2025 08:25:05 +0200
with message-id <[🔎] aGN_QaJk-8m9r5Jq@eldamar.lan>
and subject line Re: ReRe: Bug#1108462: linux-image-6.12.33+deb13-amd64: Fails to write mounted NTFS drive, I/O error
has caused the Debian Bug report #1108462,
regarding linux-image-6.12.33+deb13-amd64: Fails to write mounted NTFS drive, I/O error
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
1108462: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1108462
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: src:linux
Version: 6.12.33-1
Severity: important
X-Debbugs-Cc: debian-amd64@lists.debian.org, dhao2001@outlook.com
User: debian-amd64@lists.debian.org
Usertags: amd64

Dear Maintainer,

After upgrading the kernel version from `6.12.32` to `6.12.33+deb13`, I was unable to perform file write operations on my NTFS volumes, although file reads are still possible.

The volume's mount entry is as follows (mounted with GNOME Files):

```
/dev/nvme1n1p1 on /media/myname/Data type ntfs3 (rw,nosuid,nodev,relatime,uid=1000,gid=1000,iocharset=utf8,uhelper=udisks2)
```

An IO error occurs when writing files, either in GNOME Files or via the terminal, or in other applications, e.g.,

```
myname@MyPC:~$ echo "xxx" > /media/myname/Data/test.txt
bash: /media/myname/Data/test.txt: Input/output error
```

After making sure to completely reboot Windows many times, I believe that this issue is not due to Windows Fast Boot.

Also, when I boot with the previous version `6.12.32` kernel, this issue no longer occurs.

Unfortunately, I didn't notice anything helpful in `dmesg`.

I'm not sure if this issue is directly related to the kernel image. However, since ntfs3 is used to mount the NTFS volume, I decided to report it here. Please let me know if this is the wrong place and I would like to apologize for the potential mistakes.

In the meantime, please let me know if there is any information I can submit to further clarify this issue.

Thanks a lot!


-- Package-specific info:
** Version:
Linux version 6.12.33+deb13-amd64 (debian-kernel@lists.debian.org) (x86_64-linux-gnu-gcc-14 (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44) #1 SMP PREEMPT_DYNAMIC Debian 6.12.33-1 (2025-06-19)

** Command line:
BOOT_IMAGE=/@rootfs/boot/vmlinuz-6.12.33+deb13-amd64 root=UUID=12345678-1234-5678-9012-abcd12345678 ro rootflags=subvol=@rootfs nvidia-drm.modeset=1 quiet

** Tainted: PWOE (12801)
 * proprietary module was loaded
 * kernel issued warning
 * externally-built ("out-of-tree") module was loaded
 * unsigned module was loaded

** Loaded modules:
...
ntfs3
ext4
vfat
fat
btrfs
...


-- System Information:
Debian Release: 13.0
  APT prefers testing-security
  APT policy: (990, 'testing-security'), (990, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.12.33+deb13-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_HK.UTF-8, LC_CTYPE=en_HK.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages linux-image-6.12.33+deb13-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.148.2
ii  kmod                                    34.2-2
ii  linux-base                              4.12

Versions of packages linux-image-6.12.33+deb13-amd64 recommends:
ii  apparmor  4.1.0-1

Versions of packages linux-image-6.12.33+deb13-amd64 suggests:
pn  debian-kernel-handbook  <none>
ii  firmware-linux-free     20241210-2
ii  grub-efi-amd64          2.12-8
pn  linux-doc-6.12          <none>

Versions of packages linux-image-6.12.33+deb13-amd64 is related to:
ii  firmware-amd-graphics      20250410-2
pn  firmware-atheros           <none>
pn  firmware-bnx2              <none>
pn  firmware-bnx2x             <none>
pn  firmware-brcm80211         <none>
pn  firmware-cavium            <none>
pn  firmware-cirrus            <none>
ii  firmware-intel-graphics    20250410-2
ii  firmware-intel-misc        20250410-2
pn  firmware-intel-sound       <none>
pn  firmware-ipw2x00           <none>
pn  firmware-ivtv              <none>
ii  firmware-iwlwifi           20250410-2
pn  firmware-libertas          <none>
pn  firmware-marvell-prestera  <none>
ii  firmware-mediatek          20250410-2
ii  firmware-misc-nonfree      20250410-2
pn  firmware-myricom           <none>
pn  firmware-netronome         <none>
pn  firmware-netxen            <none>
ii  firmware-nvidia-graphics   20250410-2
pn  firmware-qcom-soc          <none>
pn  firmware-qlogic            <none>
ii  firmware-realtek           20250410-2
pn  firmware-samsung           <none>
pn  firmware-siano             <none>
pn  firmware-ti-connectivity   <none>
pn  xen-hypervisor             <none>

-- no debconf information

--- End Message ---
--- Begin Message --- 
Control: tags -1 - moreinfo

Hi,

On Mon, Jun 30, 2025 at 12:55:56AM +0800, Huxley Deng wrote:
> 
> On 2025/6/29/Sun 20:25, Salvatore Bonaccorso wrote:
> > Control: tags -1 + moreinfo
> > 
> > Hi,
> > 
> > This is very odd, as there seem to be not ntfs3 related changes in the
> > changes between v6.12.32 and v6.12.33 (which was as well a very small
> > release).
> > 
> > A couple of things:
> > 
> > 1. Can you please try as well 6.15.4-1~exp1 in experimental to verify if
> >     you can trigger the issue there as well?
> > 
> > 2. Can you please still do the following, but each kernel respective,
> >     mount the NTFS volume and try to write to it. Then paste the full
> >     dmesg you get for both 6.12.32-1 booted system and 6.12.33-1
> >     bootest system.
> > 
> > 3. If you feel confident, can you bisect the changes between 6.12.32 and
> >     6.12.33 to pinpoint the commit which "breaks" so we might hopefully
> >     be able to narrow down more closely the problem?
> > 
> > Regards,
> > Salvatore
> > 
> Hi!
> 
> Thank you for your interest and response to this question.
> 
> I did some test and I want to apologize because from the results, I'm not
> even quite sure if this is an issue that could be called a bug.
> 
> Overall, the problem, while it did occur after I upgraded my kernel to
> 6.12.33, *the direct link between the new version of the kernel and the
> problem is not clear*.
> 
> Here is a brief dmesg message timeline related to ntfs3 from `journalctl -k
> -b`. A bunch of messy nvidia-drm-related warning is omitted. I would also
> like to apologize for failing to consult the logs from the previous session
> when I filed this bug earlier.
> 
> ```
> |(Kernel upgraded from v6.12.32 to v6.12.33)
> (v6.12.33 booted)
> Jun 29 16:08:33 MyPC kernel: Linux version 6.12.33+deb13-amd64
> (debian-kernel@lists.debian.org)
> (...)
> 
> (First observed error related to NTFS3 in dmesg)
> (Before this, I had already experienced the IO write error issue and was
> testing it.)
> Jun 29 16:09:53 MyPC kernel: ntfs3(nvme1n1p1): MFT: r=142228, expect seq=5
> instead of 9!
> Jun 29 16:09:54 MyPC kernel: ntfs3(nvme1n1p1): MFT: r=142228, expect seq=5
> instead of 9!
> Jun 29 16:09:54 MyPC kernel: ntfs3(nvme1n1p1): MFT: r=142228, expect seq=5
> instead of 9!
> Jun 29 16:09:54 MyPC kernel: ntfs3(nvme1n1p1): MFT: r=142228, expect seq=5
> instead of 9!
> Jun 29 16:09:54 MyPC kernel: ntfs3(nvme1n1p1): MFT: r=142228, expect seq=5
> instead of 9!
> Jun 29 16:09:55 MyPC kernel: ntfs3(nvme1n1p1): MFT: r=142228, expect seq=5
> instead of 9!
> Jun 29 16:09:55 MyPC kernel: ntfs3(nvme1n1p1): MFT: r=142228, expect seq=5
> instead of 9!
> Jun 29 16:09:55 MyPC kernel: ntfs3(nvme1n1p1): MFT: r=142228, expect seq=5
> instead of 9!
> Jun 29 16:09:57 MyPC kernel: ntfs3(nvme1n1p1): MFT: r=142228, expect seq=5
> instead of 9!
> Jun 29 16:09:57 MyPC kernel: ntfs3(nvme1n1p1): MFT: r=142228, expect seq=5
> instead of 9!
> Jun 29 16:10:01 MyPC kernel: ntfs3: 16 callbacks suppressed
> Jun 29 16:10:01 MyPC kernel: ntfs3(nvme1n1p1): MFT: r=142228, expect seq=5
> instead of 9!
> Jun 29 16:10:01 MyPC kernel: ntfs3(nvme1n1p1): MFT: r=142228, expect seq=5
> instead of 9!
> Jun 29 16:10:06 MyPC kernel: ntfs3(nvme1n1p1): MFT: r=142228, expect seq=5
> instead of 9!
> Jun 29 16:10:11 MyPC kernel: ntfs3(nvme1n1p1): MFT: r=142228, expect seq=5
> instead of 9!
> Jun 29 16:10:15 MyPC kernel: ntfs3(nvme1n1p1): MFT: r=142228, expect seq=5
> instead of 9!
> (...)
> 
> (Some writing tests and fails, some reboots to Windows and previous v6.12.32
> kernel, but no related error recorded.)
> (Thus it seems that not every occurred I/O write error or volume mounting
> corresponds to a log error entry.)
> (...)
> 
> (This bug was filed to Debian BTS.)
> (...)
> 
> Jun 29 16:55:16 MyPC kernel: Linux version 6.12.33+deb13-amd64
> (debian-kernel@lists.debian.org)
> (...)
> Jun 29 16:56:53 MyPC kernel: ntfs3(nvme0n1p1): Mark volume as dirty due to
> NTFS errors
> Jun 29 16:57:13 MyPC kernel: ntfs3(nvme0n1p1): MFT: r=142228, expect seq=5
> instead of a!
> (...)
> 
> Jun 29 21:01:19 MyPC kernel: Linux version 6.12.33+deb13-amd64
> (debian-kernel@lists.debian.org)
> (...)
> (First time I noticed this error in dmesg)
> Jun 29 21:05:26 MyPC kernel: ntfs3(nvme0n1p1): Mark volume as dirty due to
> NTFS errors
> Jun 29 21:06:47 MyPC kernel: ntfs3(nvme0n1p1): MFT: r=142228, expect seq=5
> instead of 9!
> (...)|
> ```
> 
> After the timeline above, I tried booting Windows and run the Disk Check in
> Windows Explorer, and not surprisingly the tool thought there was an error
> in this NTFS filesystem and fixed it.
> 
> After completing the fix, I've lived in harmony with this NTFS volume in
> Debian so far without further problems, except that Windows Disk Check
> removed some files I had written earlier to found.000.
> 
> I had been spending my time on Debian for about half a month before I
> encountered this problem, so I can't for the moment think of an opportunity
> to mess up the filesystem possibly due to Windows.
> 
> However, the precarious reproducibility of this problem now makes locating
> it even more difficult. I think it's hard to say whether the problem is due
> to a bug in kernel/ntfs3 or something else.
> 
> If possible, I will further test the experimental version of the kernel at
> my convenience as you suggested, and report back further if I encounter this
> issue again.
> 
> Thanks again for your help with this issue.

Thanks for coming back with taht detailed timeline. My gut feeling is
that then there is no bug on our end we should/can close this bug.

*But* if you can re-trigger it, *do* reopen it and it appears again on
our radars.

Regards,
Salvatore

--- End Message ---
Reply to: