Verdin write to USB from container

This should be simple and I’m most likely doing something stupid.

docker run --rm -it --name=BoardVerification --device=/dev/verdin-uart2 --device=/dev/snd -v /media:/media/torizon:rw -v /tmp:/tmp -v /var/run/dbus:/var/run/dbus -v /dev/galcore:/dev/galcore --device-cgroup-rule='c 199:* rmw' myUserName/board_verification_container /bin/bash

I want to have all of the thumb drives appear under /media/torizon in my container and be writeable.

When I add
-v/media:/media/torizon:rw
I can see them and do a directory listing, but I cannot touch a shiny new text file.

My container is built on your Buster container.

Judging from the questions about this, USB seems to give many difficulties.

Any help will be appreciated.

With which user is the USB mounted on the Yocto (base) OS? You might need to add a rule to change the owner at mount time.

Thanks for responding!

base-image-after-container-running

Within container

Inside container we are running as torizon user.

Thanks to your response though, I tweaked my search parameters in here searching for USB rule and located this message thread that didn’t turn up with previous USB searches.

I need to hack an fstab file and copy it in via Dockerfile.

Thanks again. After some sleep I just needed a nudge in the proper direction to find the answer.
Roland

1 Like

Mm, I think that goes into the board’s fstab.

Well,

When I cold boot the board with thumb drive installed, it wasn’t showing anything in /media. After the container got started, I could see entries in /media at the board level (via different SSH into board.)

I want to research more this automount.rules concept because I think that would be the better solution. The fstab entry appears to have a “known” device name/label, but I haven’t dug deep. Too many things competing for my attention this morning.

I do thank you for your assistance!

You are correct sir!

Just to round out this discussion, what is presented in the previous link is a partial solution. If you have only one thumb drive, it will work. They need to be in place at power up though . . . I haven’t tested dynamically adding thumb drive.

usb-drive-1

You are limited to 2.

If you have a keyboard connected that has a pair of USB ports so your mouse doesn’t have to take the other one on the carrier board, you can get two.

The default device tree allows for /sda1 and /sdb1. Yes, someone who is familiar with low level Linux device trees can probably tweak that to allow as many as they want.

On the board itself, after you log in as torizon

sudo nano /etc/fstab

/dev/sda1            /media/usbhd         auto       relatime,nofail,utf8,uid=torizon,gid=torizon,umask=002 0 0
/dev/sdb1            /media/usbhd2        auto       relatime,nofail,utf8,uid=torizon,gid=torizon,umask=002 0 0

Exit and save. Exit out of your SSH session. Touch the reset button.

usb-drive-2

Now load your container where you add the following:
-v /media:/media/torizon

The default mount on the board itself isn’t consistent with Linux. It mounds them directly under /media. If you want to develop and test your Linux code in a VM, your USB media will be mounted under /media/your-username/. The above keeps that mounting consistent.

usb-drive-3

There is joy in Mudville today!

Hello, I see you’ve already found the fstab solution I suggested on a previous post.

One thing I wanted to add that I didn’t see mentioned already is, will the USB device here be dynamically removed and reinserted, while the container is running?

If yes you might want to consider the bind-propagation property of Docker, instead of a normal bind mount. Otherwise if you remove the USB or it gets unmounted, these changes will not be reflected properly inside the container with a normal bind-mount.

Just something to consider.

Best Regards,
Jeremias

Thank you for the feedback.

I tried “shared” I tried “rprivate” and I tried some others. It simply doesn’t work.

--mount type=bind,source=/media,target=/media/torizon,bind-propagation=shared

No matter which one I tried, when you pull the thumb drive out it’s still there in the container because it appears in fstab.

The only way to solve that problem is to dig into “rules” creating automount and autounmount rules. The fstab entries simply stay. They automount, but they don’t auto dismount, propagation or not.

First I add the following line to /etc/fstab:
/dev/sda1 /media/usbhd auto relatime,nofail,utf8,uid=torizon,gid=torizon,umask=002 0 0

Next I start a container with the following command:
docker run -it --mount type=bind,source=/media,target=/media,bind-propagation=shared debian bash

Here I plug in a USB drive and the contents appear within the container:

root@1717e5998cc3:/# ls -l /media/usbhd/
total 80
drwxrwxr-x 2 1000 1000 16384 Jun  1  2021 'System Volume Information'
drwxrwxr-x 9 1000 1000 16384 Dec  3 14:06  temp
drwxrwxr-x 2 1000 1000 16384 Dec  6 20:59  test
drwxrwxr-x 2 1000 1000 16384 Dec 17 01:51  torizon-core-docker-apalis-imx8-Tezi_5.5.0-devel-20211217003446+build.0
drwxrwxr-x 4 1000 1000 16384 Dec  9 02:44  update

Then I remove the USB drive while the container is still running:

root@1717e5998cc3:/# ls -l /media/usbhd/
total 0

Then if I plug the drive back in the container can see the contents again. The state of the mounted directory correctly updates within the container.

Best Regards,
Jeremias

Yes, but it doesn’t go away like it should.

When you pull the thumb drive out of a box running Ubuntu native, the entry goes away in /media. This stops applications that search /media for export media from attempting to use it. What you have shown requires an application put in extra effort to figure out if media is really there.

That was my point.

/media/usbhd is there forever once entry is in fstab but that doesn’t mean it is a valid mount point.

Ok so your issue then is not that the device isn’t dismounted, but rather that the directory used as the mount-point isn’t cleaned up automatically?

In which case, then yes you’ll need to handle this depending on your use-case.

Best Regards,
Jeremias