rpi-clone mounts fail under PiAware 3.0.4

rpi-clone is a useful utility for cloning SD card to SD card. I’ve used it for a while and it works like a charm on my other Jessie systems (not Piaware). But while setting up PiAware 3.0.4 from the card image, I tried to use rpi-clone and it fails with messages about the target SD card already mounted. Sure enough it is! But I didn’t mount it.

It is being automatically mounted at /media/usb/sdc1 and sdc2. Unfortunately, this is not where rpi-clone wants them. There are two services running called media-usb-sdc1.mount and media-usb-sdc2.mount. I tried stopping these, unmounting the SD card partitions, and running rpi-clone, but these services start again and mount the partitions back where they were before, and rpi-clone fails.

The usbmount package does not appear to be installed. (I tried to remove it, but it wasn’t there). So that’s not it.

Any one have any idea who/what is automounting the SD card?

Thanks,
…John

They are mounted by udev rules that are part of the piaware-support package. Those rules are necessary for configuring a piaware (or flightfeeder) via a USB drive.

You should be able to unmount them by masking the services that get generated, I guess.

Thanks for the quick reply. I masked media-usb-sdc1.mount, and sdc2. Unplugged/replugged the SD card reader, and it remounted the card as sdd1/sdd2. So I masked those, and it remounted as sde1/sde2. I masked those too, and then it mounted as sdf1/sdf2. I got as far as sdh1/sdh2 and figured this wasn’t working as planned. I’m open to another idea? :slight_smile:

For those who are also using rpi-clone, “mask” is a way to turn off linux services using the systemctl command. Basically it puts a link to /dev/null for that service in /etc/systemd/system. The command is sudo systemctl mask name-of-service. For example sudo systemctl mask media-usb-sdc1.mount. I can see the links to /dev/null, and indeed that service doesn’t start. But a different one is being generated by incrementing the device name.

Thanks,
…John

Is ‘dd’ on its own too low tech?

Certainly taking a different approach to cloning the SD card is “in the cards” if I can’t over come this problem. :slight_smile:

Rpi-clone uses rsync, which I have found faster than “dd” if the changes are few. YMMV of course. I suppose I could write my own rsync script assuming /media/usb/sdc1 and 2 mount points. I just thought it might be easier to resolve this little problem and continue using an existing tool. Perhaps not!

Cheers,
…John

I think you can symlink /etc/udev/rules.d/60-piaware-support.rules to /dev/null and this will disable the automounting.

The underlying udev rules file is installed at /lib/udev/rules.d/60-piaware-support.rules; creating the symlink in /etc should override that.
(Better to do it in /etc if you can, rather than meddling in /lib, as then your changes will survive a package upgrade)

Bingo! that fixed it. Thank you very much Oliver. Much appreciated.

For others who may hit this, creating the symlink in /etc/udev/rules.d/ will prevent automatically mounting a USB drive when you insert one. Here is the command:


sudo ln -s   /dev/null   /etc/udev/rules.d/60-piaware-support.rules

If you don’t remove this link after cloning the card, you probably can’t use a USB drive to update the piaware configuration. I didn’t test that because it is easier for me to put the config file in the /boot folder on the SD card.

Thanks again for your responsiveness to my question.