we are trying to install a custom TEZI image from USB with Toradex Easy Installer.
We adjusted image.json in order to autoinstall the image.
In gerneral Easy Installer works as expected: USB stick is deteced, the image is automatically installed and the system rebooted afterwards.
Unfortunatelly the image installed is missing all Linux capabilities set. The capabilities are present in the rootfs tar.gz.
It seems that Easy Installer is not restoring capabilities while untaring (maybe missing parameters: --xattrs --xattrs-include=‘*’). Can you confirm that or am I missing something?
Unfortunatelly the image installed is missing all Linux capabilities set. The capabilities are present in the rootfs tar.gz.
What do mean exactly with that? What exactly is missing?
It seems that Easy Installer is not restoring capabilities while untaring (maybe missing parameters: --xattrs --xattrs-include=‘*’). Can you confirm that or am I missing something?
How did you add the capabilities to the rootfs.tar.gz?
Did you use a unmodified regular image or did you modify it?
We create a custom image based on core-image-minimal.
Yocto is correctly handling the capabilties. We have verfied this by untaring the tar.gz generated by Yocto and the one included in TEZI. If you use the mentioned tar parameters, the files are restored correctly (with all capabilites set). If you untar with default parameters capabilites are not restored (same behaviour as Easy Installer).
If we use our firmware updater (uses ubifs image generated by Yocto) all capabilties are correctly set. Just initial installation via Easy Installer is not working.
The --xattr option is being used to untar the tarballs for linux-compatible filesystems (obviously). We do not pass the --xattr-include=* parameter. Have you tested whether it actually works without it?
here a simple test for this (tested with GNU tar 1.29):
mkdir test
touch script.sh
setcap CAP_SYS_NICE,CAP_NET_ADMIN=+ep test/script.sh
getcap test/script.sh => capabilities set
tar --xattrs -cvzf test.tar.gz ./test/
tar --xattrs -xvf test.tar.gz
getcap test/script.sh => no capabilities set
tar --xattrs --xattrs-include="*" -xvf test.tar.gz
getcap test/script.sh => capabilities set
Hmm… I can reproduce that even with 1.32 yes… It clearly goes against the documentation as you say. For the time being we can’t do much about it until next release I’m afraid… You could maybe use the wrapup.sh script to add these capabilities manually…
we just tested 2.0b2. According to release notes the issue should be fixed. Unfortunatelly it is not.
I tried to figure out what’s still wrong and I think that you missed activating CONFIG_EXT4_FS_SECURITY in kernel config. Without this flag ext4 driver seems not to be able to handle capabilities.
I remember we tested the feature using some random extended attributes, but maybe it does not work with security labels? I was under the impression that xattrs are xattrs, no matter what their exact semantics are… But maybe there is special handling in tar (or the file system) which needs FS support to extract security labels xattrs?
What module are you actually using? Just wondering because in the original request it says “Colibri iMX7 Dual 512MB | V1.1D”, which would be a raw NAND module where UBIFS is used.
i have to apologize. We are so busy right now that I mixed up modules.
You are right, it is working now for the Colibri iMX7.
I’m currently testing Colibri iMX8X for another application. For that module the parameter is not set. Also I cannot connect to that module using Windows RDP-Client (Linux xfreerdp is ok).
BTW, why did you drop VNC support?
No Problem. That’s great if this is working on Colibri iMX7. Thanks for your Input regarding Colibri iMX8X, we did not test this feature yet, since it is an early Access Product.
Oh I see, yes it seems that CONFIG_EXT4_FS_SECURITY is missing for the iMX 8/8X based modules. I will create a ticket for this. Just to be clear on the priority, so it is fine for Colibri iMX7 and hence not as high then, right? Colibri iMX8X is not yet in volume production…
Windows RDP should actually work, I remember we tested it. What is the error you get?
The reason why VNC is not supported right now is because we switched to Qt5 and use the Weston backend. Qt5 does not allow to share the screen with VNC and show it on the local device… So we use Weston’s screen sharing capability which currently only supports RDP.
Out of interested, do you have any preference one over the other, and if so, why?
If I connect from Windows 10-1809 to iMX8X, I get an certificate errror (rdp-1.png). After clicking yes I get an internal error (rdp-2.png). After that server crashes and does not recover.
Actually there is no real preference. VNC is plain simple and well documented (we’ve implemented a client on our own in couple of hours). RDP is more a Windows thing and quite complex. But if you get it working with Windows client it’s ok, too.
