Adding groups on Torizon image

I’m trying to add some usergroups to our TorizonCore image in order to assign permissions to specific devices. I have the udev rule(s) working properly, however I am having issues trying to get the new group changes to persist on a clean flash of the image via TEZI - the groups are not present in /etc/group.

However, the groups are present in the “custom filesystem” folder specified in the tcbuild.yaml file - for example, I added a group called lp5521 and pulled the changes from the SoM with torizoncore-builder. My [custom FS overlay dir]/usr/etc/group contains lp5521:x:1001: and gshadow has a corresponding entry too.

However, neither of these changes appear on first boot if I build this image and deploy it “fresh” by loading TEZI in recovery mode and then inserting the USB drive with the newly built image.

Am I doing something wrong or is adding groups in this way simply not possible?

Thanks!

Hi @bw908 ,

I’ve tried to reproduce your issue by adding lp5521:x:1001: to /etc/group on an Apalis iMX6, isolating it via torizoncore-builder isolate, then building a custom image with the changes using torizoncore-builder build.

On my side the new image does have the altered /etc/group with lp5521:x:1001:, as expected.

How are you creating the image with the changes? Is your tcbuild.yaml similar to the customization shown here: TorizonCore Builder Tool “build” command | Toradex Developer Center

Best regards,
Lucas Akira

Thanks for confirming this should be possible.

The other changes present in the custom FS overlay folder (such as the udev rules I created) are appearing correctly after the rebuild and deploy of the built image - just not the groups so I believe the overall build process for the image is correct.

Did I miss some of the files required? I do not want the entire contents of the isolate command to be overlaid on the image as it contains other changes I do not wish to persist, so my usual process here is to do the isolate command into a separate temporary directory, and manually bring the desired set of changes over to the “golden” custom directory.

These are the items that I placed in my “real” custom directory when I attempted to do this:

custom/usr/etc/udev/rules.d/lp5521.rules
custom/usr/etc/group
custom/usr/etc/gshadow
custom/usr/etc/.tcattr (with the appropriate permissions for `groups` and `gshadow`)

Does this concur with the contents of the directory you isolated when you had it work correctly?

Hi @bw908 ,

It’s strange that on your side only some of the changes were applied.

Did I miss some of the files required?

It doesn’t seem to be the case, as I did some more tests, including one with the same configuration as yours:

[tcbworkdir]$ tree -a isolate_changes
isolate_changes
└── usr
    └── etc
        ├── group
        ├── gshadow
        ├── .tcattr
        └── udev
            └── rules.d
                └── lp5521.rules

And all changes were present when first booting the new image, so I don’t think the issue is in the changes directory.

Some suggestions:

  • Check if you have the latest TorizonCore Builder version by running source tcb-env-setup.sh;

  • Check if your custom directory is inside the TBC working directory i.e. where tcb-env-setup.sh is, usually ~/tcbworkdir/;

  • This is the tcbuild.yaml I’ve used to create the custom image with the filesystem changes above:

input:
  easy-installer:
    local: input_images/torizon-core-docker-apalis-imx6-Tezi_5.7.0+build.17.tar

customization:
  filesystem:
     - isolate_changes/

output:
  easy-installer:
    local: output_directory

Compare with the one you use and see if there are any differences.

  • Try to isolate the cause of the problem e.g. create an image with only a single change in /etc/group and see if it works.

Hope that helps you.

Best regards,
Lucas Akira

The plot thickens - I had an idea which I think elminiates the need to try some of the steps you suggest.

Namely, I unpacked the output tar.zst in my output directory, and if I browse down to ostree/deploy/torizon/deploy/[commit hash]/etc/ and open the group file, I can see the groups are present.

So it is getting applied to the actual image - which confirms the build environment is set up correctly and the change should be present. yet I’ve done numerous images unpack output and deploy calls and they have not materialized - the files stubbornly stay empty of my new entries.

Hi @bw908 ,

Namely, I unpacked the output tar.zst in my output directory, and if I browse down to ostree/deploy/torizon/deploy/[commit hash]/etc/ and open the group file, I can see the groups are present.

Great, it is a good way to verify your custom image. With this I don’t think the issue is related to your image.

So it is getting applied to the actual image - which confirms the build environment is set up correctly and the change should be present. yet I’ve done numerous images unpack output and deploy calls and they have not materialized - the files stubbornly stay empty of my new entries.

I was able to reproduce your issue when deploying the image through SSH via torizoncore-builder deploy and at least in this situation I have a possible explanation for it.

The reason is due to how OSTree, the program responsible for versioning/deploying the images, works: If a tracked file in /etc is modified in relation to its counterpart in /usr/etc, OSTree will not change it, even if the update has a newer version of it, as said here: Atomic Upgrades | ostreedev/ostree

/usr/etc is the “default configuration” of the image, and OSTree uses it as a point of reference to track any changes made in /etc.

In particular /etc/group and /etc/gshadow are modified when first logging in on a new TorizonCore install, so unless you undo the modifications these two files won’t be affected by any updates made using torizoncore-builder deploy.

This shouldn’t happen when installing the image through TEZI though, as OSTree versioning is reset.

I suggest you try the following:

  • Install a vanilla TorizonCore image via TEZI on your module, version should be the same you used for the custom image;

  • Login as user torizon, then check the differences between /etc and /usr/etc with:

sudo ostree admin config-diff

group and gshadow should be marked with ‘M’, meaning they are modified in relation to /usr/etc.

sudo rsync -avh /usr/etc/ /etc/ --delete

This command will also reset the torizon user password to torizon.

  • Check again with sudo ostree admin config-diff. There should be no output, or at the very least group and gshadow should not be present.

  • On your host machine deploy your custom image that has the modified /etc/group and /etc/gshadow:

torizoncore-builder images unpack <your custom image directory>
torizoncore-builder union <branch name, can be anything>
torizoncore-builder deploy <branch name> --remote-host <SoM IP> --reboot
  • After the module finishes rebooting, login again (remember that the password has been reset to torizon)

  • All changes should be present on the image.

See if this helps you.

Best regards,
Lucas Akira

Thanks for the explanation - I’ll give that a try in a few days when I am looking at this next (the remainder of this week is a holiday here in the US). Hopefully that does indeed resolve my issue :+1:

I can confirm this was the issue. I did a fresh and clean deploy with TEZI and this did indeed create the desired groups in /etc/groups. I swear I did a fresh deploy via TEZI at some point in the past but I guess not… Thanks for the assistance!

Glad I was able to help!

Best regards,
Lucas Akira