Environment
Ubuntu-20.04 LTS
Bash shell
Question
How to define specific SD card to specific mount point when multiple SD card is inserted as same time and no UUID?
Background
I am working on a bash script which used to copy daily generated image from 2 cameras (front/rear-view) stored in coresponding SD card. The workflow would be somethings like this:
Manually extract the SD cards from cameras (SD cards are labelled and assume they are inserted in correct order, e.g. front-camera always comes with the "A" SD card.)
Insert to the SD card readers that already plugged into the host pc, ( /dev/sda and /dev/sdb )
Automount to desired path , e.g. /media/user/front-sd-card and /media/user/rear-sd-card
Run the script (which the source path is pre-defined as above) and start copying from source to dest
Challenge
I found that at this moment if I insert the rear-sd-card first, it will mount to /dev/sda/disk, and if I insert the front-sd-card first, it will mount to /dev/sda/disk. The next one would be /dev/sdb/disk1. So, which one is inserted first, which will be disk and the second one is disk1, this make human error possible...
Assume the operator insert to the correct card reader ( "A" sd card alwasys insert to sda card reader, and so to "B", this also generate human error if they dont follow).
I have run blkid and no UUID for both SD card, so I could not use UUID and set /etc/fstab to automount to correct mount directory.
Expectation
The "A" SD card and "B" SD card alwasys go to the desired mount point so that the script can pre-define the source path for copying to desired destination directory.
The copy task script is alredy ready and in use, but I want to minimise the human error due to the source pathing issue. So far is check manully before running the script.
I also think of adding a function to open a preview image of both Sd cards, and promot the user to answer yes/no, if the sequence is wrong, answer no and exit the script.
Any other suggestion of workflow also welcome.
How to define specific SD card to specific mount point when multiple SD card is inserted as same time and no UUID?
Detect with udev to which card reader the card was inserted and add a udev rule to mount it.
This consist of watching udevadm monitor, inserting the card, then the second, watching the stream what values you can use for the rule. Then write a rule, which will look somewhere like https://github.com/crittermike/dotfiles/blob/master/udev/11-sd-cards-auto-mount.rules or and you can find many examples of udev rules online.
See also See https://wiki.archlinux.org/title/persistent_block_device_naming .
-l /dev/disk/by-path show something might be useful. pci-0000:00:14.0-usb-0:2.3:1.0-scsi-0:0:0:0-part1 for /sda1 and pci-0000:00:14.0-usb-0:2.4:1.0-scsi-0:0:0:0-part1 for /sdb1
Great, so just mount /dev/disk/pci-0000:00:14.0-usb-0:2.3:1.0-scsi-0:0:0:0-part1 /where/you/want/to/mount/one/card and similar for the other one..
If you are using those SD cards on an ongoing basis, you may as well bite the bullet and assign either a UUID or LABEL or both. Those operations are non-destructive to the content of the partition (they warn you that you should always do a backup before performing these operations), but the UUID/LABEL values are permanently changed and can be restored manually IF you kept track of what those values were before the operations.
After you plugged in your SD card (I would do this one card at a time so you know which card is which),
enter mount -l to obtain the current details for mounted devices (specifically options for the SD card which may be required to create an fstab entry).
open gparted,
select the device from the drop-down menu at the upper-left,
then right-click on the line for the partition in question (there should be a "key" icon next to the /dev/${partition}, meaning locked on mounting),
then choose the unmount option.
Now GParted will allow you to make changes to the SD card ... so click and choose carefully! The little key icon should be gone.
If you right-click on the partition again, you will now have options, including
Label File-system
New UUID
Option 1: UUID
If you choose UUID, that will actually update the SD card with a new UUID (replace the previous UUID, or, add one where there was none before).
Option 2: LABEL
Your other option is to create a LABEL on your partition. If you choose that option, not only will it create a label, that operation also replaces any previously existing UUID with a new UUID to signify that the partition has been physically modified, namely a LABEL has now been assigned.
So, basically, Option 2 is the better choice, unless you absolutely must keep the LABEL for code that uses that value.
After that, setting up an fstab entry to perform mount based on UUID={...} or LABEL={...} is up to your preferences. Using UUID has become the standard approach for the most part but you might choose the LABEL approach for FRONT or BACK as labels.
There are many examples available for details on how to do those various steps.
I'd like to make one file representing (linking) bunch of files - something as on Linux named pipe do. The motivation is not to concatenate files (not to create the new one when I have originals and I want to keep them) so do not duplicate data. For example I want to use this to load videos from camera which are divided by approx. 2 GB.
hard drive is dying, trying to save all my pictures and having to manually copy one by one in dos. The names are just numbered jpgs. Ie: 001 010 305 ect. Is there a way to make it copy them in order? I would just copy the whole folder but when it hits a corrupted file the drive dies and I have to re plug in. So if I could choose the starting point and increment up that would be perfect. Thanks!
I've got an image that I write onto a bootable USB that I need to tweak. I've managed to mount the stick as /dev/loopX including allowing for the partition start offset, and I can read files from it. However writing back 'seems to work' (no errors reported) but after writing the resulting tweaked image to a USB drive, I can no longer read the tweaked files correctly.
The file that fails is large and also a compressed tarfile.
Is writing back in this manner simply a 'no-no' or is there some way to make this work?
If possible, I don't want to reformat the partition and rewrite from scratch because that will (I assume) change the UUID and then I need to go worry about the boot partition etc.
I believe I have the answer. When using losetup to create a writeable virtual device from the partition on your USB drive, you must specify the --sizelimit parameter as well as the offset parameter. If you don't then the resulting writes can go past the last defined sector on the partition (presumably requires your USB drive to have extra space). Linux reports no errors until later when you try to read. The key hints/evidence for this are that when reads (or (re)written data) fail, dmesg shows read errors attempting to read past the end of the drive. fsck tools such as dosfsck also indicate that the drive claims to be larger than it is.
Is it possible to programmatically push files to a wireless SD card - like a www.eye.fi card?
I use a Mac and thought I could do this using some AppleScript - but have not found a way...
Derek
The eye-fi card relies on image files being written to a specific directory in the card before they'll transfer them. Beyond that it works exactly like a memory card.
Write a file to it as if you're writing a regular memory card, and as long as it's a jpg image file of reasonable size, and in an appropriate directory (something under \DCIM\ probably) and they should transfer.
If you're having trouble, double check that it works with your camera, and find out where your camera puts the images on the card, and duplicate that. You might even try naming them similar names to the types of images your camera produces.
-Adam
It looks like you can treat it just like an external hard drive (plug the memory card in and figure out where the mount point is).
I think he wants to send files to it while its in another device, not plug it in and use it to transmit files like an antena directly connected to the machine.