From owner-freebsd-questions@freebsd.org Mon Mar 16 20:09:03 2020 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0C3F126E4E0 for ; Mon, 16 Mar 2020 20:09:03 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mout.kundenserver.de (mout.kundenserver.de [217.72.192.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.kundenserver.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48h6nn4QRjz4Hg1 for ; Mon, 16 Mar 2020 20:09:01 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from r56.edvax.de ([94.222.11.49]) by mrelayeu.kundenserver.de (mreue107 [212.227.15.183]) with ESMTPA (Nemesis) id 1MRnXY-1ikkJv3LPW-00TGRP; Mon, 16 Mar 2020 21:08:50 +0100 Date: Mon, 16 Mar 2020 21:08:49 +0100 From: Polytropon To: freebsd@dreamchaser.org Cc: FreeBSD Mailing List Subject: Re: SD card formatting Message-Id: <20200316210849.7de243db.freebsd@edvax.de> In-Reply-To: <3b552229-fe07-941b-2000-56036f15c0a8@dreamchaser.org> References: <20200316000029.a6ba47c9.freebsd@edvax.de> <90f83226-b557-98c4-749b-81d9dbd795c3@dreamchaser.org> <20200316090538.27b1ecb1.freebsd@edvax.de> <3b552229-fe07-941b-2000-56036f15c0a8@dreamchaser.org> Reply-To: Polytropon Organization: EDVAX X-Mailer: Sylpheed 3.1.1 (GTK+ 2.24.5; i386-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:Qt6Tl8bx3GPL4iE2PkUtmvcqheoO7S/1t46SWVYSyqg3W7ls9pj dMPXrpdvGFWpjthNr6EfremtfcB+0x01MiibLrW1qe+JRDwyognAcoNi9BnqEhXm00KKM6O XzI9Gw6N2EPxix05UQkSNy7cwI+Jx+tYa0b550qARWvjgNtC4BqkXkwImRylIO2kN5MflS5 pLKbYGXOFttM5tNq0JVuQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:6E+8vNBAR5w=:oQy/64d7F1X14f/6/9BkKW 0Lwme8dnm0rSyI5Rn95hUBgtHwA6k0f9YYKq6TQLx/KxS9/3fwlFuK4Bi/rRtm1Ecex8Gb8a4 Jv26sQ0wmrGpUu93gBXN6Pte/FV/KAJ6sFJa2VIKlSPczaNUgH6mjPm6TZrepj1sRzKxDEaQf 5sDL9dxm51BbMRVAqeK6Kst12+r2HqLZJCGVz2pThdvycAg7f5azEO/YBZZMivKmyhqHdfft8 OgXTwRDLMa88bgz83WqwGU1XWXZ0CcQ3vyi0QdkkQCqboeBvXtTS8UamE/YbrDYw77qS5enoT FOZgZF1yUTdPDOz9dYaDQiWSwPONRIld9ZLSn2KHQrwiwqfgZuIDFJ+SZVGHRwl5cuKExzN4E P4ukpVvPutyuP1vK+13TRtY97OIQ8FO6E4EUH0JOwEZAgTKr/bKGUvL3IT/iP5IYudDa7W2ij xKL2WlkIW6QYJuJARHvAJp52Qyab2dJDe/345wfV/wwf6oygOpZHnpwqCuZAimbd5CloEtYSQ kOM1aO+uisIY1f/4HFRG8yHclIjUYmWErT5E2IiVP+41kNtC+h7eU1/mw8LX2kteHpMi4nctL nGyZDWEA9McK5H9E0rUquEbQer740IQfrBJUH68NdX2snJgyEW2sG0SSMXYhJiIih15aJZek5 i3oZk3Pzo0gKs8VZTzpkEBuWtXF3Eue63IgcMg/CRwLAbInInjs9biJYDshtUoYw6UJ2iX6IA TmcwrQtV/iCsXswMUdbNEVHn/TIEN/lnkAiyVRSp2P4zfCiO1Ec8fPz5uNWLTMYSeVV54P6D5 KdYKuW35Ov4Qewh8Wa5Cc+t5JntOAw1r2ZJy5jiJclqUtH9PHYSG423VEp8dwkpGP6nMWlR X-Rspamd-Queue-Id: 48h6nn4QRjz4Hg1 X-Spamd-Bar: ++++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd@edvax.de has no SPF policy when checking 217.72.192.73) smtp.mailfrom=freebsd@edvax.de X-Spamd-Result: default: False [4.94 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[freebsd@edvax.de]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; HAS_ORG_HEADER(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:8560, ipnet:217.72.192.0/20, country:DE]; MIME_TRACE(0.00)[0:+]; RECEIVED_SPAMHAUS_PBL(0.00)[49.11.222.94.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; ARC_NA(0.00)[]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[edvax.de]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(1.00)[1.000,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(1.00)[1.000,0]; MID_CONTAINS_FROM(1.00)[]; RCVD_IN_DNSWL_NONE(0.00)[73.192.72.217.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; IP_SCORE(0.54)[ip: (0.17), ipnet: 217.72.192.0/20(0.37), asn: 8560(2.18), country: DE(-0.02)] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2020 20:09:03 -0000 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/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) or a > > MTP interface (leads to /dev/ugen). 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, ...