Sysbox Data Root Configuration Issues

The following Sysbox Data Root issues were observed with Sysbox-CE 0.4.0.

• specifying a Data Root of /data/sysbox creates the standard 5x directories under both /var/lib/sysbox and /data/sysbox
• it is expected that neither /var/lib/sysbox nor its subdirectories would be created in this scenario
• this becomes confusing when confirming which directories Sysbox is using
• it also makes it more difficult to tell whether Sysbox is successfully cleaning up the Data Root directory

• using systemctl start sysbox ignores config changes in /lib/systemd/system/sysbox.service
• whereas systemctl restart sysbox does pick up config changes
• both after firstly performing systemctl daemon-reload

• specifying a Data Root which is a symlink produces the following error when a System container is launched

docker: Error response from daemon: OCI runtime create failed: container_linux.go:393: starting container process caused: process_linux.go:607: container init caused: standard_init_linux.go:82: validating cwd caused: rootfs_linux.go:1142: cwd /data/sysbox/shiftfs/b158cc46-6d84-4c73-94df-36f5b8517ac6 is not container's rootfs /var/lib/sysbox/shiftfs/b158cc46-6d84-4c73-94df-36f5b8517ac6 caused:: unknown.
ERRO[0006] error waiting for container: context canceled

• seems restarting Sysbox again allowed the System container to launch successfully in one test which is now not able to be reproduced
• the symlink was from /var/lib/sysbox to /data/sysbox
• the config is kept in original condition (ie. specifies --version only and no --data-root specified on the startup line)
• using a symlink works successfully in Sysbox-CE 0.3.0 (ie. the above issues are not observed)
• the workaround in Sysbox-CE 0.4.0 is to configure --data-root to directly point to the target directory, rather than the source directory of the symlink