I encountered a problem during build of Vivado 2018.1 with rootless podman on a standard Linux machine. The problem was related to this line:
|
tar -xvzf /tmp/$VIVADO_INSTALLATION_FILE -C /tmp/installer --strip-components=1 |
tar -xvzf /tmp/$VIVADO_INSTALLATION_FILE -C /tmp/installer --strip-components=1
This command emits lots of warning about changing ownership to uid 65673, gid 10115.
As default, /etc/subuid and /etc/subgid maps a 65536 range. The UID 65673 is out of that range and this causes some ID mapping issues with rootless podman.
The easiest solution is adding --no-same-owner to tar not to force chowning the origin IDs.
tar -xvzf /tmp/$VIVADO_INSTALLATION_FILE -C /tmp/installer --strip-components=1 --no-same-owner
That was worked for Vivado 2018.1 but don't think that the problem and solution is specific to that version.
I haven't tested for others yet but since I mainly use Docker to build images, my current aim is to add a comment to Dockerfiles and not to change commands, just to be stay at the safe side.
I encountered a problem during build of Vivado 2018.1 with rootless podman on a standard Linux machine. The problem was related to this line:
EBox/xilinx/vivado-vitis-sdk/2018.1/Dockerfile
Line 59 in f47d611
tar -xvzf /tmp/$VIVADO_INSTALLATION_FILE -C /tmp/installer --strip-components=1This command emits lots of warning about changing ownership to uid 65673, gid 10115.
As default,
/etc/subuidand/etc/subgidmaps a 65536 range. The UID 65673 is out of that range and this causes some ID mapping issues with rootless podman.The easiest solution is adding
--no-same-ownertotarnot to force chowning the origin IDs.tar -xvzf /tmp/$VIVADO_INSTALLATION_FILE -C /tmp/installer --strip-components=1 --no-same-ownerThat was worked for Vivado 2018.1 but don't think that the problem and solution is specific to that version.
I haven't tested for others yet but since I mainly use Docker to build images, my current aim is to add a comment to Dockerfiles and not to change commands, just to be stay at the safe side.