From owner-freebsd-questions@FreeBSD.ORG Sun Oct 26 12:55:35 2014 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D8ABA597 for ; Sun, 26 Oct 2014 12:55:35 +0000 (UTC) Received: from mx02.qsc.de (mx02.qsc.de [213.148.130.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7548E60B for ; Sun, 26 Oct 2014 12:55:35 +0000 (UTC) Received: from r56.edvax.de (port-92-195-215-178.dynamic.qsc.de [92.195.215.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx02.qsc.de (Postfix) with ESMTPS id 8A58D24BD5; Sun, 26 Oct 2014 13:48:09 +0100 (CET) Received: from r56.edvax.de (localhost [127.0.0.1]) by r56.edvax.de (8.14.5/8.14.5) with SMTP id s9QCm96q004422; Sun, 26 Oct 2014 13:48:09 +0100 (CET) (envelope-from freebsd@edvax.de) Date: Sun, 26 Oct 2014 13:48:09 +0100 From: Polytropon To: "William A. Mahaffey III" Subject: Re: problems trying to mount SDHC card .... Message-Id: <20141026134809.18222082.freebsd@edvax.de> In-Reply-To: <544CEB1A.6020200@hiwaay.net> References: <544C34A2.1070806@hiwaay.net> <20141026052929.ef41a037.freebsd@edvax.de> <544CEB1A.6020200@hiwaay.net> 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 Cc: FreeBSD Questions !!!! X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2014 12:55:35 -0000 On Sun, 26 Oct 2014 07:37:46 -0500, William A. Mahaffey III wrote: > On 10/25/14 23:29, Polytropon wrote: > > On Sat, 25 Oct 2014 18:39:14 -0500, William A. Mahaffey III wrote: > >> > >> .... I am trying to mount some SDHC cards through a USB reader > >> (Transcend USB 2.0) with an eye towards using them to create bootable > >> drives for a Raspberry Pi B+. > > In that case, you probably won't have anything to do > > with mounting the SD card (especially not as a MS-DOS > > file system). The thing you're going to do here probably > > isn't much more than "dd if=pi.img of=/dev/da0", and > > Xfce is not able to help here. When the image has been > > written, there's probably a file system different from > > FAT on the card. > > > Aaaaaaahhhhh .... That clarifies much .... I work w/ the device > directly, not MSDOS .... Beauty, ace ;-) .... The Xfce desktop doesn't have much tools for this specific kind of use, so you are probably safe to ignore error messages because they just state the already obvious. :-) > >> When I try to view the drive through > >> XFCE's 'flash File Manager' (from top toolbar) it pops up an error > >> dialog saying: > >> > >> mount_msdosfs: can't find or load "msdos_iconv" kernel module > >> mount_msdosfs: msdos_iconv: operation not permitted. > > Is the card currently formatted? What does > > > > # fdisk da0 > > > > say (if /dev/da0 is the SD card reader)? Or with today's > > tools, > > > > # gpart show da0 > > > [root@kabini1, /etc, 7:30:02am] 495 % gpart show da0 > => 63 31127489 da0 MBR (14G) > 63 8129 - free - (4M) > 8192 31119360 1 !12 (14G) > > [root@kabini1, /etc, 7:30:06am] 496 % Okay, so no "DOS primary partition" there, no msdosfs-related file system. > > Also check the dmesg entries in relation to the card reader. > > Anything suspicious? > > nothing at all, it's dated 3:03 A.M. this morning .... Good, so the reader picks up the card properly. > > In case the card is formatted with FAT, can you _manually_ > > mount it? > > From my messages file this A.M.: > > Oct 26 07:29:49 kabini1 kernel: ugen3.2: at usbus3 > Oct 26 07:29:49 kabini1 kernel: umass0: class 0/0, rev 2.00/9.03, addr 2> on usbus3 > Oct 26 07:29:49 kabini1 kernel: umass0: SCSI over Bulk-Only; quirks = > 0x4100 > Oct 26 07:29:49 kabini1 kernel: umass0:4:0:-1: Attached to scbus4 > Oct 26 07:29:49 kabini1 kernel: (probe0:umass-sim0:0:0:0): REPORT LUNS. > CDB: a0 00 00 00 00 00 00 00 00 10 00 00 > Oct 26 07:29:49 kabini1 kernel: (probe0:umass-sim0:0:0:0): CAM status: > SCSI Status Error > Oct 26 07:29:49 kabini1 kernel: (probe0:umass-sim0:0:0:0): SCSI status: > Check Condition > Oct 26 07:29:49 kabini1 kernel: (probe0:umass-sim0:0:0:0): SCSI sense: > ILLEGAL REQUEST asc:20,0 (Invalid command operation code) > Oct 26 07:29:49 kabini1 kernel: (probe0:umass-sim0:0:0:0): Error 22, > Unretryable error > Oct 26 07:29:49 kabini1 kernel: da0 at umass-sim0 bus 0 scbus4 target 0 > lun 0 > Oct 26 07:29:49 kabini1 kernel: da0: > Removable Direct Access SCSI-6 device > Oct 26 07:29:49 kabini1 kernel: da0: Serial Number 000000000903 > Oct 26 07:29:49 kabini1 kernel: da0: 40.000MB/s transfers > Oct 26 07:29:49 kabini1 kernel: da0: 15199MB (31127552 512 byte sectors: > 255H 63S/T 1937C) > Oct 26 07:29:49 kabini1 kernel: da0: quirks=0x3 > > > All I see is the device name (da0), no further partitions referenced .... This is okay. The card reader, when attached, doesn't determine the card's size (no card in it), and da0 then is created correctly. I think this looks correct. Keep in mind that /dev/da0 is equivalent to /dev/da0c, where 'c' means "the whole device" or "the whole partition covering the whole device" in MBR-speak. So _if_ there is only one partition on it, /dev/da0 will correspond to that partition ("dedicated"). If a MBR partition table has been added, the "s1" part appears. And if that slice carries more than one partition, the other letters ('a' for a boot partition, 'b' for swap, 'd' up to 'h' for other partitions) may appear. In regards of SD cards, it's sometimes helpful to issue the command # true > /dev/da0 to have the system "re-taste" the card to make it aware of what slices and/or partitions may reside on it. I have to do this regularly with my build-in card reader, or I won't be able to mount the SD card. Example: crw-r----- 1 root operator 0, 129 2014-10-26 06:11:23 /dev/da1 crw-r----- 1 root operator 0, 162 2014-10-26 12:48:41 /dev/da1s1 The 2nd file (used for the mount command, representing a MS-DOS file system on that card) does not appear when the card is inserted, even though the reader is recognized: da1: Removable Direct Access SCSI-0 device da1: 40.000MB/s transfers da1: Attempt to query device size failed: NOT READY, Medium not present It's required to issue the command mentioned above to make it appear. Afterwards, mounting works as expected. % df -h /media/sd Filesystem Size Used Avail Capacity Mounted on /dev/da1s1 1.9G 208M 1.7G 11% /media/sd The act of mounting of course happens manually here. > >> I am doing this as an ordinary user, something in fstab or amd.conf ? > > I'm surprised you get any reaction at all. I never got > > automounting to work with Xfce... > > It's not exactly working for me either, only if I separately prompt an > automount from CLI in another window :-/ .... I got it working exactly once, after several hours, with Gnome, HAL, automounter, a "rewrite" of /sbin/umount, and other embarrassing things I'd like to forget (or which I already forgot because they were so terrible). :-) > > If you have the automounting stuff via HAL and DBUS, > > your /etc/fstab won't probably have an entry for the > > SD card reader, and /etc/amd.conf is probably totally > > out of scope here. Maybe this is an expression of the > > growing incompatibilities between Linux (where Xfce > > has been created for) and FreeBSD? > > > > I'm a bit surprised about the "msdos_iconv" kernel > > module, which should be present. Can you manually > > load it, maybe via /boot/loader.conf? > > > Could I load it w/ kldload (if it's there to load) ? Yes, that should be possible. You can verify if it's working with a card that _definitely_ has a MS-DOS file system on it, for example a SD card from a digital camera. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...