I’m not familiar with this package and don’t know what it’s supposed to be used for, but you could try installing it in a Toolbx container and see if it works as expected.
This looks too experimental and at first glance I can’t even see how it would relate to my problem.
The twingate package appears to make some post installation changes that are incompatible with rpm-ostree systems. I am looking for a way to address that and successfully layer the package.
I m not sure the problem is with package. Though it is the first one to give me this problem. But it doesn’t install with the above error messages!
I m just looking for a way to address this. I ‘ve tried many things I m not mentioning here to keep context relevant but they were either totally wrong things to try or didn’t work.
Any package from the official Fedora repositories can be installed on Silverblue. We have an example of how to install a third-party package. You can try it if you haven’t already, but I don’t know if it will make any difference in this particular case.
On Atomic Desktops it is generally better to prefer using Toolbx/Podman containers over layering software. As I mentioned, I am not familiar with this software and I don’t know what it is supposed to be used for, nor if this container image is the same application you want to layer, but you can try twingate/connector - Docker Image.
It looks like the twingate RPM is using mkdir commands to create the directories it needs during the postinstall phase:
$ rpm -qp --scripts twingate-x86_64.rpm
postinstall scriptlet (using /bin/sh):
#!/bin/sh
if [ $1 -eq 1 ] ; then
# Initial installation
systemctl --no-reload preset twingate.service &>/dev/null || :
elif [ $1 -eq 2 ] ; then
echo "Upgrading Twingate package..."
# Check if service is running before migration
SERVICE_WAS_RUNNING=0
if systemctl is-active --quiet twingate.service; then
SERVICE_WAS_RUNNING=1
twingate service-stop
fi
twingate account migrate || echo "Warning: Migration failed, but continuing installation"
# Restart service if it was running before migration
if [ "$SERVICE_WAS_RUNNING" -eq 1 ]; then
twingate service-start
fi
fi
# Create Twingate directories with proper permissions
mkdir -p /var/lib/twingate
chmod 0711 /var/lib/twingate
mkdir -p /var/lib/twingate/profiles
chmod 01777 /var/lib/twingate/profiles
chown -R root:root /var/lib/twingate
...
I believe I have seen issues with using mkdir in this phase of RPM installs on Atomic Desktops, but I can’t find any exact examples of this problem…
Regardless, you can try to pre-create this directories before you run rpm-ostree install to see if that would alleviate the problem. Ideally, the packaging of the RPM would be updated to use systemd tmpfiles.d snippets, but given the package appears to be closed-source, I’m not sure how receptive they would be to that kind of request.
I would second the suggestion from @hricky to experiment with the sysext approach. It can be use successfully to address problems with RPMs that do not install cleanly on Atomic Desktops. YMMV.
Indeed it is those commands that create the problem.
What I ended up doing was to use rpmrebuild and remove (comment out) those instructions. Then the package installed and after next boot I manually run the commands to create said folders.
ChatGPT said that /var/lib is read only in the compose sandbox, though I haven’t heard that term before to know if it’s real or hallucination.
I will keep in mind the sys-extensions thing but to be honest I m hesitant because it look like it is something that it’s in its early stages (ie more bleeding edge than leading edge) which mean higher maintenance burden. Will read up on it though to at least better understand what it is and what it provides.