How to pass environment variables to torizon

Hi

On Verdin Plus and Torizon Core, how to set environment variables for Wayland terminal?
I just run Weston with the following command

$ docker run -e ACCEPT_FSL_EULA=1 -e HOGE=hoge -d --rm --name=weston --net=host --cap-add CAP_SYS_TTY_CONFIG -v /dev:/dev -v /tmp:/tmp -v /run/udev/:/run/udev/ -v /home/torizon/weston.ini:/etc/xdg/weston-dev/weston.ini --device-cgroup-rule=‘c 4:* rmw’ --device-cgroup-rule=‘c 13:* rmw’ --device-cgroup-rule=‘c 199:* rmw’ --device-cgroup-rule=‘c 226:* rmw’ torizon/weston-vivante:2 --developer weston-launch --tty=/dev/tty7 --user=torizon

and then open Wayland terminal by pushing the top left small icon, I can see environment variables with “printenv” command at Wayland terminal.
However, HOGE=hoge is not passed to Wayland terminal, though it is passed to Weston. It can be confirmed by the following command.

$ docker run -e ACCEPT_FSL_EULA=1 -e HOGE=hoge torizon/weston-vivante:2 env | grep HOGE
HOGE=hoge

Could you kindly let me know the following question?

  1. Is it possible to pass environment variables to Wayland terminal with docker run command?
  2. How to make an initial of ~/.bashrc? (I just want to set TZ=JSP-9.)
  3. In Wayland terminal, “sudo” command is not accepted. as I just input torizon core OS password which should be set at the installing(Initially user=torizon password=torizon which I have changed). What is the password? Or anything required to set password?
    I guess TorizonCore builder is required to solve the 3 aboves… Is there any other easier and convenient way, or could you kindly help and advice?

Thanks and regards
ujsugi

Hi @ujsugi ,

Before answering your questions, let me see if I understand what you want to do:

You want to access the Weston container, and you’re trying to do it via the Weston terminal directly in the graphical interface i.e. by clicking on the top left icon. Is this correct?

If this is the case, you can easily access the running container through docker exec instead. Just enter this command after docker run:

docker exec -it --user=torizon weston /bin/bash

Once you run the command above, you will be inside the Weston container, and any environment variables you specified on docker run, such as HOGE, will be present.

About .bashrc, if you want to pass it to container you can do so by bind mounting the desired file to the container, in the same way you did with weston.ini.

If you really need root access inside the container you can do so by repeating the docker exec command above, but replacing --user=torizon by --user 0. The default torizon user in the container doesn’t have a password, hence, you can’t access root privileges using sudo.

Let me know if this helps you.

Best regards,
Lucas Akira

Lucas Akira

Thanks a lot for quick prompt.

Yes, you are correct. I want to access Weston via Weston terminal directly in the graphical interface.

Reagrding your advice of “docker exec -it --user=torizon weston /bin/bash”, it is accessing from Torizon OS terminal or terminal connected to Torizon OS via SSH, instead of Wayland terminal.
Originally I wanted to change TimeZone to JSP-9 and tried to pass environment variable but I found that it was not passed to Wayland terminal then I posted the questions. But now that .bashrc can be bind-mounted, the problem was solved.
However, another question has come! On Walyland terminal, SDcard or USB memory are mounted to /media when inserting them, but both file mode are drwx------ which means any access is not permitted, because of no root privilege. Any idea to access(read and write) to such devices via Wayland terminal?
I suppose that some data stored by a container application is copied to USB memory or SDcard without terminal or PC connected via SSH.

Thanks and regards
ujsugi

Hi @ujsugi ,

Reagrding your advice of “docker exec -it --user=torizon weston /bin/bash”, it is accessing from Torizon OS terminal or terminal connected to Torizon OS via SSH, instead of Wayland terminal.

Right, I mentioned the docker exec approach as that probably is the more common method used to gain access to a running container. If you really need access to it through the graphical interface that could be more complicated.

Glad that bind mounting ~/.bashrc solved your initial problem. I assume that the new variables are only visible on the graphical Weston terminal if you’re using bash, not sh, right? I did some tests and that looks to be the case.

However, another question has come! On Walyland terminal, SDcard or USB memory are mounted to /media when inserting them, but both file mode are drwx------ which means any access is not permitted,

This one is curious though, as I was able to access a mounted USB drive on the graphical terminal once I bind mounted it (i.e. with -v /media:/media); my ls -l output is similar to this:

/media$ ls -l
total 8
drwxrwxrwx 3 root root 4096 Jan 20 14:20 <series of numbers, probably the device UUID>
drwxrwxrwx 3 root root 4096 Jan 20 14:20 sda1

Inside sda1 are the USB contents, in which I was able to read and write files successfully.

Check if the permissions you got inside the container are the same outside of it (i.e. check them directly on TorizonCore). If they are, you could change them directly on TorizonCore though the chmod command, given that you have sudo access there. I’d just advice caution when doing so, as it is related to general device security.

See if this helps.

Best regards,
Lucas Akira

Lucas Akira

Thanks for reply.
The permission is 766 on TorizonCode while it is 700 on Container as below.
Only case inserting USB memory before booting(power on, reboot), it is 766 on Container.
Once it is removed and inserted, it will be 700.
I did with FAT32 format as well as ext4 format, but the result is same…
I guess I do something wrong, because the below has some differences from you in output. Ex. you are 777(drwxrwxrwx) and output is different…
Anything you notice?

— Torizon Core —
torizon@verdin-imx8mp-07321134:~$ ls -alH /media
total 12
drwxr-xr-x 3 root root 4096 Jan 23 15:55 .
drwxr-xr-x 7 root root 4096 Jan 10 14:28 …
drwxr-xr-x 3 root root 4096 Jan 1 1970 UJDISK

— Container —
root@verdin-imx8mp-07321134:/home/torizon# ls -al /media
total 12
drwxr-xr-x 3 root root 4096 Jan 23 06:55 .
drwxr-xr-x 1 root root 4096 Jan 23 06:42 …
drwx------ 2 root root 4096 Jan 23 06:55 UJDISK

— Container just after reboot inserting USB memory —
root@verdin-imx8mp-07321134:/home/torizon# ls -al /media
total 12
drwxr-xr-x 3 root root 4096 Jan 23 07:02 .
drwxr-xr-x 1 root root 4096 Jan 23 07:04 …
drwxr-xr-x 3 root root 4096 Jan 1 1970 UJDISK
root@verdin-imx8mp-07321134:/home/torizon#

Thanks and regarts
ujsugi

Hi @ujsugi ,

Thank you for the additional information. With this I was able to reproduce the permission being 700 inside the container if I plug the USB drive after starting the container. This can be solved by adding an option when bind mounting the USB, see step 7 below for more details.

As for the permissions outside of the container, it looks like non-root users don’t have write permission for some reason. This can be changed with the chmod command (step 3).

To reproduce my results:

  1. Stop the Weston container if it is running: docker stop weston

  2. Plug the USB drive, then in TorizonCore (i.e. outside of the container) go to /media

  3. Change the USB drive permissions so non-root users have read/write permissions:
    sudo chmod 777 UJDISK

  4. Unmount the USB drive: sudo umount /media/UJDISK

  5. Power off the USB device with this command: sudo udisksctl power-off -b /dev/sdX, where X is a letter corresponding to your USB device; check it with lsblk, NAME field

  6. Unplug your USB drive

  7. Start the Weston container with a new bind mount for /media: -v /media:/media:rslave
    (more information here: ubuntu - Use auto mounted USB drives in Docker container - Server Fault)

  8. Plug your USB drive

  9. Inside the container (e.g. in the Weston terminal), /media/UJDISK should have read/write permissions for all users (777)

  10. Read and write operations inside the container work as expected with user torizon

I did the steps above with an ext4 formatted USB drive, 4 GiB.

Let me know if this helps you.

EDIT: replaced the eject command with udisksctl power-off

Best regards,
Lucas Akira

Lucas Akira

Thanks for kind support.

Step7(-v /media:/media:rslave) seems to work. If bind-mounting with rslave, permissions is hold at unplugging and plugging USB. However, I am struggling to change permission mode to 777. It never change to 777 even after executing “sudo chmod 777 UJDISK”. It is always 755 (owner is root). I tried something like editing /etc/fstab to add /dev/sda1 but it was in vain.
But it is sure that the permissions on you PC is 777. I like to know what is the difference b/w you and I.
There should be something trick or magic hidden?

PS: Actually FAT32 has permission, doesn’t it? Is this a thing hidden…?

Thanks and regards

ujsugi

Hi @ujsugi ,

Step7(-v /media:/media:rslave) seems to work. If bind-mounting with rslave, permissions is hold at unplugging and plugging USB.

Great, it’s good to know that this part is working as it should.

It never change to 777 even after executing “sudo chmod 777 UJDISK”. It is always 755 (owner is root). I tried something like editing /etc/fstab to add /dev/sda1 but it was in vain.
But it is sure that the permissions on you PC is 777. I like to know what is the difference b/w you and I.
There should be something trick or magic hidden?
PS: Actually FAT32 has permission, doesn’t it? Is this a thing hidden…?

From what I found apparently FAT32 doesn’t support Linux-like permissions, they’re determined by how the drive is mounted: This should explain why you couldn’t change permissions with chmod. See these links for more info:

With a FAT32 USB drive I was able to reproduce your results: When mounted, the USB drive had permissions set to 755, with root being the owner. All my previous tests were done with an ext4 formatted USB stick.

I eventually managed to mount the FAT32 USB drive with 755 permission but with user torizon as the owner of the mount point, allowing read and write access. To do this I added the following line in /etc/fstab:

UUID=<usb-uuid> /var/rootdirs/media/UJDISK vfat users,noauto,uid=1000,gid=1000,umask=0022 0 0

Replace <usb-uuid> with the UUID of your USB drive. You can find it by plugging it and then running sudo blkid. After that reboot your device; you should be able to access the contents of the USB stick with read and write permissions, inside and outside of a container:

torizon@colibri-imx8x:/media$ ls -l
total 8
drwxr-xr-x 2 torizon torizon 4096 Jan  1  1970 FAT32_USB

Hope this works for you.

Best regards,
Lucas Akira

Lucas Akira

Thanks for tireless support.
I gave it a try and got 777.
It’s FAT32 foundamental issue, so I cannot help doing the workaroud you kindly specified. No choice!
Anyway, thanks for yor good support.

ujsugi

Hi @ujsugi ,

Just to confirm, is your issue solved?

If you have any other questions, please don’t hesitate to ask here or create another topic if needed.

Best regards,
Lucas Akira

Lucas Akira

I will say it is solved at this time.
However, there are amount of applicances and electric products which use emb linux but I have not seen any one which could not save to USB/SDcard without doing something.
This is fundamental and chemistry issue on linux and FAT, but I hope I could find out better solution some day.
If you find decent one, please let me know.

Thanks for warm support
ujsugi

1 Like