Re: Problem mounting new Sandisk 1TB USB drive

From: Gary Aitken <freebsd_at_dreamchaser.org>
Date: Thu, 11 Jan 2024 03:34:04 UTC
On 1/10/24 17:42, Polytropon wrote:
> On Wed, 10 Jan 2024 16:42:22 -0700, Gary Aitken wrote:

>> /boot/loader.conf.local:
>> # added and commented out amdtemp; no longer needed?
>> #amdtemp="YES"
>> verbose_loading="YES"
>> # Enable FUSE functionality for exfat filesystem mounting
>> fuse_enable="YES"
>> fuse_load="YES"
> 
> THe _enable settings belong to /etc/rc.conf; /boot/loader.conf
> uses the _load settings.
> 

Thanks, should have noticed that, it was also in rc.conf.

>>> 2. Mount device manually, read-only, perform checks, then
>>>      unmount again:
>>>
>>> 	# mount.exfat -o ro /dev/da0s1 /mnt/memstick
>>> 	# df -f /mnt/memstick
>>> 	# ls -R /mnt/memstick
>>> 	# umount /mnt/memstick
>>
>> What was the intent of the df -f (-f => invalid option)?
> 
> Should have been "df -h". :-)
> 
> Intention: Compare "dmesg" entry (device reporting size)
> with filesystem size, and then compare to what's written
> on the device itself.

Ok, df -h makes sense, but I don't understand the ls -R now.
I don't see anything comparable to df -h output.

>> A series of mount.exfat / umount / mount.exfat on fbsd seemed to
>> clear it up.
> 
> There are also fsck tools for most filesystems, and there
> probably is one for exFAT, just in case.

I thought probably so.
Looks like its exfatfsck, in sysutils/exfat-utils:
$ cat /usr/ports/sysutils/exfat-utils/pkg-descr
Utilities to manage extended file allocation table filesystem. This
package provides tools to create, check and label the filesystem.
It contains dumpexfat to dump properties of the filesystem, exfatfsck
to report errors found on a exFAT filesystem, exfatlabel to label a
exFAT filesystem and mkexfatfs to create a exFAT filesystem.

> Okay, thanks for that pointer. It's not obvious that you
> need the manpage of "mount.exfat-fuse" when you want to
> know the options of "mount.exfat" though...

No kidding.  I've stumbled on that multiple times.  A symlink
seems like a no-brainer, but for once apropos was useful.
I did add a symlink just now to save trouble.  Don't know if that
would be preserved across upgrades though.
  
>> I want to be able to read it from an android phone, and I was/am
>> concerned reformatting may make it unreadable by the phone.
> 
> In worst case, let the target deivce format the stick.
> I've once been bitten by that because I "knew better"
> and preformatted a SD card with FAT, just to discover
> that my digital camera doesn't like it - it wanted the
> old 8.3 type format instead of the -F 32 one.

I've run into something like that before also, also with a camera.

> In your specific case, exFAT (or FAT with the -F 32
> format - see "man newfs_msdos") is probably the safest
> way for data exchange here.

Thanks

>> So all is well, thanks, but one question not addressed:
>> Given that FUSE_ENABLE="YES" is present in rc.conf,
>> why is kldlist="fusefs" still needed?
> 
> Personally, I am explicit instead of relying on "chains"
> here: I put fuse_enable="YES" in /boot/loader.conf and
> have the correct module loaded. Simple things need to
> be simple and kept boring. :-)

uh-oh, I'm confused; that seems to contradict your comment above.

fuse_enable="YES" makes sense in both /etc/rc.conf and
/boot/loader.conf?
I thought only kld_lists="fusefs" went in /boot/loader.conf

Thanks again,

Gary