crash due to umount a fat32 hd...

hern42

hern42

hi, my system just crashed when i was trying to unmount an external hard-drive.
where shall i look to see what was going on? i perused /var/log/ but didn't find anything useful... sorry if it's a dumb question. it's why i didn't paste any log :/
 
Did it happen under command prompt or X11 session? Some window managers have disk stuff running in background that can need additional troubleshooting.
 
If you read this message, it means that the kernel was trying to write on the disk. It was trying to write 32KB, which makes sense. What doesn't make sense is that it is trying to write at a place that doesn't exist, namely a huge negative offset, about minus 1TB. The disk obviously can't do that (offsets go from 0 to the size), so it responds with error 5, which is an IO error.

In and of itself, that should not cause a system crash, but the error should be reported and the operation (probably your unmount) aborted. So superficially there are two problems: A write to a disk at a crazy offset, and a system crash. But most likely those are not separate problems, but caused by the same root cause. Which is hard to diagnose, in particular from a distance.
 
ralphbsz said:
If you read this message, it means that the kernel was trying to write on the disk. It was trying to write 32KB, which makes sense. What doesn't make sense is that it is trying to write at a place that doesn't exist, namely a huge negative offset, about minus 1TB. The disk obviously can't do that (offsets go from 0 to the size), so it responds with error 5, which is an IO error.

In and of itself, that should not cause a system crash, but the error should be reported and the operation (probably your unmount) aborted. So superficially there are two problems: A write to a disk at a crazy offset, and a system crash. But most likely those are not separate problems, but caused by the same root cause. Which is hard to diagnose, in particular from a distance.
Click to expand...
thanks...
i'll try and mount it again when i have the time and look if i can do it. i hope it did not damage it or the fs.
 
2TB is the max allowable FAT32. I have a hunch that is the issue. I would try with a 1.9TB partition.

A

Solved Thread 'Cluster size limit in newfs_msdos(8)'

FAT32:
Maximum cluster size for FAT32 is 256K.

Windows:
Microsoft documentation and related blogs are all over the places. They generally state that max is 64K -- they rarely mentioned 256K.
I've read somewhere clusters larger than 64K in Windows may cause problem for calculating space (in some programs).
But you can have 256K cluster: FORMAT /A:256K. That's OK.

BSDs:
newfs_msdos(8) in all three BSDSs i.e. FreeBSD, OpenBSD and NetBSD has a limit of 32768 (32K) for -S sector-size option.

Question:...
  • a6h
  • cluster fat fat32 newfs
  • Replies: 3
  • Forum: Storage
Also checkout your sectors.
 
so i can mount it, and copy from it. i cannot copy to it.
and when i unmounted it, it froze x11 and crashed the same way, with the same message, trying to write at a crazy offset.
i tried and look in /var/crash but i do not have debug installed so the info is empty. the core is 1.4G so i guess i'm not uploading it.

so i ran fsck_msdosfs on it and it seems to have worked. at least i'm able to write stuff onto it.
i'll now try to unmount and cross fingers.
[posting this before i do it, in case it crashes again, noting it won't solve the issue, just maybe have fixed my fs]
 
hern42 said:
so i can mount it, and copy from it. i cannot copy to it.
and when i unmounted it, it froze x11 and crashed the same way, with the same message, trying to write at a crazy offset.
i tried and look in /var/crash but i do not have debug installed so the info is empty. the core is 1.4G so i guess i'm not uploading it.

so i ran fsck_msdosfs on it and it seems to have worked. at least i'm able to write stuff onto it.
i'll now try to unmount and cross fingers.
[posting this before i do it, in case it crashes again, noting it won't solve the issue, just maybe have fixed my fs]
Click to expand...
ok so the umount didn't crash the system :)
maybe partitioning the whole hd as 2 times 1TB could be a good idea but i'd need to backup the whole thing before, wouldn't i?
 
Phishfry said:
2TB is the max allowable FAT32. I have a hunch that is the issue. I would try with a 1.9TB partition.

A

Solved Thread 'Cluster size limit in newfs_msdos(8)'

FAT32:
Maximum cluster size for FAT32 is 256K.

Windows:
Microsoft documentation and related blogs are all over the places. They generally state that max is 64K -- they rarely mentioned 256K.
I've read somewhere clusters larger than 64K in Windows may cause problem for calculating space (in some programs).
But you can have 256K cluster: FORMAT /A:256K. That's OK.

BSDs:
newfs_msdos(8) in all three BSDSs i.e. FreeBSD, OpenBSD and NetBSD has a limit of 32768 (32K) for -S sector-size option.

Question:...
  • a6h
  • cluster fat fat32 newfs
  • Replies: 3
  • Forum: Storage
Also checkout your sectors.
Click to expand...
Bash: 
[root@punkspresso /home/hern42/Downloads]# df -h /media/USB
Filesystem              Size    Used   Avail Capacity  Mounted on
/dev/msdosfs/Alaotra    1.8T    1.7T    113G    94%    /media/USB

so i'm under the 2TB, possibly for that very reason.
 
hern42 said:
ok so the umount didn't crash the system :)
maybe partitioning the whole hd as 2 times 1TB could be a good idea but i'd need to backup the whole thing before, wouldn't i?
Click to expand...
Yes, repartitioning would likely destroy any data on it.

Yes, it is possible to shrink file systems in place. So if the thing is half full, you could shrink the existing partition to 1TB (first telling the file system to move all the data to the first half), then use the free space to create a new partition. Shrinking file systems is playing with fire; shrinking a non-native file system is playing with high explosives. Not recommended. On FAT file systems, the technology for shrinking is well understood, and even 30 years ago, you could buy shrink-wrap software that did it well and reliably on MS-DOS (I think it was called "partition magic"). But backing up the data is a much more sane idea.

If the problem is really caused by a partition size, that would be a bug in the FreeBSD file system implementation for FAT, which you should report into a PR. Turning disk offsets that are too large into negative numbers is just unacceptable behavior for quality software. But I'm not sure this is really the problem.
 
ah. actually i spoke to fast.
i crashed it again and again... apparently the funky offset is still here. the same line appears again and again with negative offset.
this starts to get annoying.
i tried without x, directly in tty. here is a screenshot (an actual one! with a phone camera, shooting the screen) of the message right before the crash (one of them ahah).
 

Attachments

  • signal-2025-07-12-194819.jpeg
    signal-2025-07-12-194819.jpeg
    382.9 KB · Views: 142
Another idea is to download the latest snapshot of 15.0-CURRENT, boot the installer, enter a shell and try to reproduce. Because 15.0-CURRENT has many debugging options activated, the problem might be detected at an earlier point in time (closer to its origin) and a better error message produced, which will speed up the debugging.
 
JordanG said:
The photo displaying the panic and the related kernel messages is sufficient to file a problem report. Start here: https://www.freebsd.org/support/
Include in your report the output of file -s /dev/msdosfs/Alaotra because it includes the basic parameters of the FAT filesystem.
Click to expand...
ok i'll do that when i get the chance.
thanks for the help. it's gonna be my first report i hope i'll do it properly.
 
You must log in or register to reply here.
Back
Top