Date: Mon, 16 Mar 2020 21:08:49 +0100 From: Polytropon <freebsd@edvax.de> To: freebsd@dreamchaser.org Cc: FreeBSD Mailing List <freebsd-questions@freebsd.org> Subject: Re: SD card formatting Message-ID: <20200316210849.7de243db.freebsd@edvax.de> In-Reply-To: <3b552229-fe07-941b-2000-56036f15c0a8@dreamchaser.org> References: <b7070f0e-a387-9c7e-945f-ab708f9f5a76@dreamchaser.org> <20200316000029.a6ba47c9.freebsd@edvax.de> <90f83226-b557-98c4-749b-81d9dbd795c3@dreamchaser.org> <20200316090538.27b1ecb1.freebsd@edvax.de> <3b552229-fe07-941b-2000-56036f15c0a8@dreamchaser.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 16 Mar 2020 12:36:25 -0600, Gary Aitken wrote: > On 3/16/20 2:05 AM, Polytropon wrote: > > On Sun, 15 Mar 2020 19:06:22 -0600, Gary Aitken wrote: > >> On 3/15/20 5:00 PM, Polytropon wrote: > >>> On Sun, 15 Mar 2020 15:39:33 -0600, Gary Aitken wrote: > >>>> 11.3-RELEASE-p6 GENERIC amd64 > >>>> > >>>> I'm having trouble reading SD cards formatted in my camera (Olympus > >>>> EM1-MkII) or on a Win 7 system. > >>> > >>> What filesystem is in use? For cards, it's typically FAT. > >>> > >>> > >>> > >>>> When attempting to mount, I get the following: > >>>> > >>>> $ mount -t msdosfs /dev/da0s1 /mnt/memstick mount_msdosfs: > >>>> /dev/da0s1: Invalid argument $ mount -t ntfs /dev/da0s1 > >>>> /mnt/memstick mount: /dev/da0s1: Operation not supported by device > >>>> > >>>> Cards used without formatting *usually* seem to work. > >>> > >>> So those are preformatted (sometimes sold this way, sometimes > >>> initialized when first used in a camera). > >>> > >>> > >>> > >>>> If I look at the cards which don't mount using gpart, I see: > >>>> > >>>> Card formatted in camera: > >>>> $ gpart show -p /dev/da0 > >>>> => 63 120944577 da0 MBR (58G) > >>>> 63 32705 - free - (16M) > >>>> 32768 120911872 da0s1 ntfs [active] (58G) > >>> ^^^^ > >>> > >>> It seems that the card has been accidentally formatted with NTFS. In > >>> most cases, cameras cannot use that. If you want to mount it on > >>> FreeBSD, use ntfs-3g. > >> > >> As stated above, this is a card formatted _in the camera_. So the > >> camera can read it fine. The problem is fbsd can't mount it. > > > >>From the program output presented, it seems that you're > > trying to mount a NTFS partition using the FAT mount option, > > which will not work. Try ntfs-3g (needs to be installed; > > mount_ntfs is no longer part of the OS). > > Ah, that's a help, thanks. > Ugh: > > # ntfs-3g /dev/da0s1 /mnt/memstick > NTFS signature is missing. > # ntfs-3g.probe --readonly /dev/da0s1 > NTFS signature is missing. > # file -r - </dev/da0 > /dev/stdin: DOS/MBR boot sector; partition 1 : ID=0x7, active, > start-CHS (0x2,10,9), end-CHS (0x3ff,254,63), startsector 32768, > 124702720 sectors > # file -r - < /dev/da0s1 > /dev/stdin: DOS/MBR boot sector You can install ""libfsntfs" and use its identification tool to see what you really have here. If the NTFS signature is missing, the filesystem either is heavily damaged (and in that case, it's strange to see the "Windows" PC and camera being able to use it), ot, it's _not_ a NTFS filesystem, and some partitioning data is terribly misleading. > >>> Personally, I tend to leave the formatting to the camera which I want > >>> to use the card in; the camera "knows best" what it can uderstand. > >>> :-) > >> > >> In this case, the camera is not the problem; cards formatted in the camera > >> are usable by the camera. But they aren't mountable on fbsd. So I can't > >> transfer the files to fbsd, either from the camera or by inserting the > >> card in an fbsd usb adapter. > > > > Depending on the camera, a USB connection can show up as > > a mass storage device (leads to /dev/da<something>) or a > > MTP interface (leads to /dev/ugen<something>). In many cases, > > the "personality" can be seleted by the menu in the camera. > > It shows up as mass storage, /dev/da0 in this case So you can access the SD card "through" the camera, but you'll probably experience the same problem, right? > >> For a card never reformatted (i.e. formatted by the manufacturer, and > >> used in the camera); this card is usable by the camera and mountable > >> by fbsd: > >> > >> # file -r - < /dev/da0 > >> /dev/stdin: DOS/MBR boot sector; partition 1 : ID=0xc, active, > >> start-CHS (0x0,130,3), end-CHS (0x3ff,254,63), startsector 8192, > >> 31496192 sectors > >> # file -r - < /dev/da0s1 > >> /dev/stdin: , code offset 0x0+3, OEM-ID " ", sectors/cluster 64, > >> reserved sectors 504, Media descriptor 0xf8, sectors/track 63, > >> heads 255, hidden sectors 8192, sectors 31496192 (volumes > 32 MB), > >> FAT (32 bit), sectors/FAT 3844, serial number 0x0, unlabeled > >> # mount_msdosfs /dev/da0s1 /mnt/memstick > >> # ls /mnt/memstick > >> DCIM System Volume Information > > > > This doesn't actually look like a "mint condition" card. A > > directory named "DCIM" is typically created by a camera. > > However, _this_ card is FAT-formatted, and therefore can be > > mounted with msdosfs as correctly shown above. The directory > > name "System Volume Information" suggests it has been in a > > "Windows" PC before. COnclusion: Card works both in camera > > an in "Windows" PC. > > Correct, it's not an unused card. It's been put in the camera, > recorded on, and then put in a windows system to transfer images. Okay, so that's the configuration to replicate. > > So the camera seems (!) to initialize cards as NTFS (strange, > > but surely possible), but also understands FAT. > > That seems to be the case. > Since ntfs-3g doesn't seem to like the camera-generated NTFS > filesystem, it seems my best option is to try to format with > the FAT it understands. Fully agree. NTFS seems to be the wrong thing (but gpart reports it). Just a stupid question: Have you tried "newfs_msdosfs -A -F 32 /dev/da0"? I mean, without the gpart part? Could that work? > > All you need to do now is to replicate _that_ formatting. > > The output shows "FAT (32 bit)", and the partitioning also > > looks reasonable. You should be able to create this either > > with gpart + newfs_msdosfs (should be quite standard today), > > or the traditional way with fdisk + newfs_msdosfs (archaic, > > but should also still work). > > Tried the following: > > # gpart create -s MBR /dev/da0 > da0 created > # gpart show -l da0 > => 63 120944577 da0 MBR (58G) > 63 120944577 - free - (58G) > # gpart add -t fat32 -a 4K /dev/da0 > da0s1 added > # gpart show -l /dev/da0 > => 63 120944577 da0 MBR (58G) > 63 1 - free - (512B) > 64 120944576 1 (null) (58G) > # newfs_msdos -F 32 -A /dev/da0s1 > /dev/da0s1: 120885440 sectors in 1888835 FAT32 clusters (32768 bytes/cluster) > BytesPerSec=512 SecPerClust=64 ResSectors=46 FATs=2 Media=0xf0 > SecPerTrack=63 Heads=255 HiddenSecs=0 HugeSectors=120944576 > FATsecs=14761 RootCluster=2 FSInfo=1 Backup=2 > # mount -t msdosfs /dev/da0s1 /mnt/memstick > mount_msdosfs: /dev/da0s1: Invalid argument > > Obviously I'm missing something? You could see if -F 12 or -F 16 changes something. Another option is to use traditional fdisk instead of gpart... -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200316210849.7de243db.freebsd>