Bug#1108462: ReRe: Bug#1108462: linux-image-6.12.33+deb13-amd64: Fails to write mounted NTFS drive, I/O error
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 > ([email protected]) > (...) > > (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 > ([email protected]) > (...) > 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 > ([email protected]) > (...) > (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 t
Bug#1108462: ReRe: Bug#1108462: linux-image-6.12.33+deb13-amd64: Fails to write mounted NTFS drive, I/O error
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 ([email protected]) (...) (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 ([email protected]) (...) 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 ([email protected]) (...) (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 sugges
