Un*x to the rescue

My boss was trying to do a thing using Windows 10. It wouldn't work. They asked me if I could do it under Xubuntu. Problem solved in short order.

Using Synchrotech's X4SD USB 2.0 SD Card Reader Four (4) Slot for SD Card duplication

Synchrotech's X4SD USB 2.0 SD Card Reader allows simultaneous access to four SD Card style media. In Automating X4SD USB 2.0 SD Card Reader Four (4) Slot Operations Synchrotech outlines several techniques for automating the copying of files to the device's multiple slots. Here we explore making exact binary copies of media using the device. A common use of this process is duplication.

There's various ways to do do device duplication or byte-for-byte copies of media. Whether we're duplicating CD-ROMs, hard drive disks, SRAM PC Cards, or other removable media, the Unix dd is frequently preferred for these types of operations. While we can execute card to card duplications from one X4SD slot to another, the most common use for the reader is to write an existing SD Card image to all four slots simultaneously. To that end we'll create a binary image of a master SD Card and then use that master to write to blank cards.

Creating an image of the SD Card

dd works with block devices, so we need to unmount the SD Card. To make this simple, we'll be using just one of the X4SD slots at this stage. We'll be using Mac OS X for our example and detail the difference for OpenBSD and Xubuntu. First, we need to identify the mount point of the inserted card. Calling mount in the terminal shows us the information we need (we're leaving out the rest of the output here).

/dev/disk1s1 on /Volumes/NO NAME (local, nodev, nosuid)

We use that information to unmount the mounted device.

[kyoto:~/Desktop] rds% sudo diskutil unmount /Volumes/NO\ NAME
Volume /Volumes/NO NAME unmounted

OpenBSD and Xubuntu would use umount /[devicepath]. Using the block device reference to the X4SD slot, we can copy the card to a binary file using dd.

[kyoto:~/Desktop] rds% sudo dd if=/dev/disk1s1 of=sdcard.bin
1951677+0 records in
1951677+0 records out
999258624 bytes transferred in 1203.276878 secs (830448 bytes/sec)

Writing the image to SD Cards

Inserting a new card into the X4SD, then unmounting it, we can create a duplicate of the original. We then test it using cmp to see if it is identical to the binary file.

[kyoto:~/Desktop] rds% sudo dd if=sdcard.bin of=/dev/disk1s1
1951677+0 records in
1951677+0 records out
999258624 bytes transferred in 1203.276878 secs (830448 bytes/sec)
[kyoto:~/Desktop] rds% cmp /dev/disk1s1 ~/Desktop/sdcard.bin
[kyoto:~/Desktop] rds% 

Here we write to all four slots simultaneously on a Xubuntu machine. It's feasible that using hubs and multiple X4SD, we could write to more than four cards at once on a machine with enough CPUs/CPU cores. However, there's a practical limit to the amount of I/O operations one would want to run at the same time. Perhaps writing to each bank of cards sequentially would be the best practice? Since I was only provided a single test unit, that remains an academic question.

rds@okinawa-lin2:~$ sudo dd if=sdcard.bin of=/dev/sdc1 & \
&& dd if=sdcard.bin of=/dev/sdd1 & \
&& dd if=sdcard.bin of=/dev/sde1 & \
&& dd if=sdcard.bin of=/dev/sdf1 &

1951677+0 records in
1951677+0 records out
999258624 bytes (999 MB) copied, 270.799 s, 3.7 MB/s
1951677+0 records in
1951677+0 records out
999258624 bytes (999 MB) copied, 423.987 s, 2.4 MB/s
1951677+0 records in
1951677+0 records out
999258624 bytes (999 MB) copied, 775.1 s, 1.3 MB/s
1951677+0 records in
1951677+0 records out
999258624 bytes (999 MB) copied, 860.479 s, 1.2 MB/s

---

Appendices

Determining Media Paths

Here's the abridged results of running mount on our various test systems with the X4SD plugged in and all four of its slot occupied. This output will look different based on what's connected to an individual system.

OpenBSD
sd0i on /mnt/s1 type msdos (local)
sd1i on /mnt/s2 type msdos (local)
sd2i on /mnt/s3 type msdos (local)
sd3i on /mnt/s4 type msdos (local)

Xubuntu Linux
/dev/sdd1 on /media/BF2C-1214 type vfat (rw,nosuid,nodev,uid=1000,gid=1000,shortname=mixed,dmask=0077,utf8=1,showexec,flush,uhelper=udisks)
/dev/sdf1 on /media/02A3-1214 type vfat (rw,nosuid,nodev,uid=1000,gid=1000,shortname=mixed,dmask=0077,utf8=1,showexec,flush,uhelper=udisks)
/dev/sde1 on /media/3A3A-1214 type vfat (rw,nosuid,nodev,uid=1000,gid=1000,shortname=mixed,dmask=0077,utf8=1,showexec,flush,uhelper=udisks)
/dev/sdc1 on /media/5AED-1214 type vfat (rw,nosuid,nodev,uid=1000,gid=1000,shortname=mixed,dmask=0077,utf8=1,showexec,flush,uhelper=udisks)

Mac OS X
/dev/disk2s1 on /Volumes/NO NAME 3 (local, nodev, nosuid)
/dev/disk4s1 on /Volumes/NO NAME 2 (local, nodev, nosuid)
/dev/disk3s1 on /Volumes/NO NAME (local, nodev, nosuid)
/dev/disk1s1 on /Volumes/NO NAME 1 (local, nodev, nosuid)

My Test Systems

Here's the results of running uname -a on our various test systems.

OpenBSD okinawa-bsd2.my.domain 5.1 GENERIC.MP#207 amd64
Linux okinawa-lin2 3.2.0-39-generic #62-Ubuntu SMP Wed Feb 27 22:05:17 UTC 2013 i686 i686 i386 GNU/Linux
Darwin kyoto 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh powerpc

Code example disclaimer

Technology Musings grants you a nonexclusive copyright license to use all programming code examples from which you can generate similar function tailored to your own specific needs.

All sample code is provided by Technology Musings for illustrative purposes only. These examples have not been thoroughly tested under all conditions. Technology Musings, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs.

All programs contained herein are provided to you "AS IS" without any warranties of any kind. The implied warranties of non-infringement, merchantability and fitness for a particular purpose are expressly disclaimed.

Samba changes in OpenBSD

The other day when I was trying to mount an ISO image for remote burning of SmartCard reader driver discs on our work network, I was getting error messages when trying to log on via samba. Since I usually use NFS instead of samba, I hadn't noticed that OpenBSD had changed the password back-end for samba. This was with 4.8-current, although they might have changed things earlier without me noticing. In fact, it may well have been a samba change rather than an OpenBSD specific one.

Regardless, the new configuration isn't any harder than the previous incarnation, just different. Took all of one minute to get things working again.

See

/usr/local/share/doc/samba/README.OpenBSD

for full details

U111-M Q&A, Compatibility with Mac OS X? on EverythingHerePlus.com Store blog - Plus U111-M on OpenBSD and Linux updates!

The store blog from EverythingHerePlus.com answers questions regarding U111M compatibility with Mac OS X in Store EverythingHerePlus.com: U111-M Q&A, Compatibility with Mac OS X?. Of interest is the OpenBSD work around testing we did. U111M units with the most current firmware (1.05 above) work just fine with OpenBSD, with the exception of PCMCIA PC Card hot-swapping. As long as the card is inserted in the U111-M prior to connecting, the OpenBSD kernel recognizes it. In fact, there's no need to reboot between PCMCIA PC Card exchanges. Unplugging and plugging in the U111M on the USB bus is all that's necessary to recognize a new card.

Using OpenBSD, we were able to read, write, format, create binary images from, and write binary images to PCMCIA PC Card SRAM and ATA Flash. These capabilities, using just standard command line Unix utilities, are features once exclusively part of expensive, proprietary, Windows software packages. Now, using the U111-M with OpenBSD or Linux provides important low level features often needed with equipment from Honeywell, Canon, Epson, and others.

EverythingHerePlus.com will soon have detailed instructions for these operations.

U111-M USB to PC Card Read-Writer 1 Slot PCMCIA PC Card ATA Flash and SRAM Memory Cards

The U111-M is an external read-writer for PCMCIA PC Card SRAM, and ATA Flash memory cards. The U111-M works without additional software or drivers on supported operating systems, treating both SRAM and ATA Flash as standard removable USB mass storage devices. Used in concert with a Type II PC Card adapter, the U111M USB to PCMCIA Memory PC Card drive will work with a variety of consumer memory cards including CompactFlash and SD Cards. Used with desktop or notebooks computers, the U111-M USB to PC Card Read-Writer 1 Slot PCMCIA PC Card ATA Flash and SRAM makes copying files to and from PCMCIA PC Card SRAM and PCMCIA PC Card ATA Flash devices simple and straight forward without confusing software interfaces.

The U111-M comes with a USB 'Y' for use on rare systems with underpowered ports. Simply plug in the additional power only connection in order to provide necessary current. The U111M provides an inexpensive, hassle free solution to deploying legacy PCMCIA PC Card memory SRAM and ATA Flash cards on modern Linux and Windows computers with USB 1.1 or USB 2.0 ports.

Using Text Configuration Files with NetInfo Manager

Using Text Configuration Files with NetInfo Manager

NetInfo Manager, like most NeXT style applications utilizing the columnar data presentation, is clumsy at best for entering information. Only the most stalwart advocate would be caught trying to use it to enter any lengthy lists of data. Fortunately Apple provides an alternative to those used to the elegant simplicity of text configuration files. Here we will populate NetInfo with a hosts listing from a standard BSD hosts file. This is a simple and very practical example.

To see the very specific format NetInfo prefers the hosts file, and to prevent missing any important information, let's export the existing data from Netinfo first. Make sure the resulting file is in /etc/hosts (permissions apply).

nidump hosts local@localhost

Once we've added all the additional entries, we can now reimport the data into NetInfo Manager.

sudo niload -v hosts . < /etc/hosts

For a full overview of command line utility access to NetInfo, execute apropos netinfo and read the corresponding man pages. We are also assuming that the reader is familiar with maintaining standard Unix host files.

Getting Gambit to respect prefix settings at configure

After posting a concern about Gambit inserting an additional "version" directory into the installation path, the following was suggested on the Gambit mailing list and works perfectly. When executing make install set the PACKAGE_SUBDIR="" to remove the version number from the installation path.

For me the configure, make, install routine works as follows:

$ ./configure --enable-single-host --enable-gcc-opts --prefix=/Users/Shared
$ make install prefix=/usr/local PACKAGE_SUBDIR=""

This places the Gambit files in the directories I expect them to be in.