composefs-backend: Check for /var symlink before creating to fix issue with bootc switch on other distros.

[KyleGospo]

Fixes issue with bootc switch on Debian, Arch, and other distros.
Previous behavior would error out with: error: Composefs Switching: Writing composefs state: Failed to create symlink /var: File exists (os error 17)

Here's proof of functionality:

Coauthored-by: Tulip Blossom [email protected] @tulilirockz

[gemini-code-assist]

Code Review

This pull request aims to fix an issue where creating a symlink for /var fails if it already exists. The proposed change checks for the existence of the path before creating the symlink. However, the use of Path::exists() is problematic as it follows symlinks and returns false for broken symlinks, which would cause the code to attempt to create the symlink again and fail. I've suggested a more robust way to handle this by attempting the operation and ignoring the AlreadyExists error, which also avoids a potential race condition.

[Johan-Liebert1]

The issue here seems to be that switch is somehow outputting the same verity for two images? Or was the switch cancelled after the /var symlink was created? In the latter case I think we'd need to remove the state dir and recreate it. The former case feels unlikely.

A reproducible example would be great

[KyleGospo]

The issue here seems to be that switch is somehow outputting the same verity for two images? Or was the switch cancelled after the /var symlink was created? In the latter case I think we'd need to remove the state dir and recreate it. The former case feels unlikely.

A reproducible example would be great

Any image at https://github.com/bootcrew/ will reproduce this (I recommend https://github.com/bootcrew/debian-bootc), the issue is that the /var link already exists when this is fired off from what I can tell.

To reproduce it, boot one of their images and then attempt to bootc switch to the actual ghcr.io link. It will silently fail, and then on reboot you'll be brought to the original image.

[Johan-Liebert1]

To reproduce it, boot one of their images and then attempt to bootc switch to the actual ghcr.io link. It will silently fail, and then on reboot you'll be brought to the original image.

So we build the image locally and then switch to the remote image? If there are no differences between the images, then they will both output the same verity, for which we already have the state dir. But, in your screenshot I can see the images have different verity...

Anyway, this is an issue, and simply checking for /var symlink existing is not good as we might overwrite everything else in the state dir

[Johan-Liebert1]

One solution I had in mind for this is to just update the .origin file if the switched image has the same verity as any one of the image present. As that's basically what were doing, updating the target imgref, but nothing in the image has actually changed

[KyleGospo]

To reproduce it, boot one of their images and then attempt to bootc switch to the actual ghcr.io link. It will silently fail, and then on reboot you'll be brought to the original image.

So we build the image locally and then switch to the remote image? If there are no differences between the images, then they will both output the same verity, for which we already have the state dir. But, in your screenshot I can see the images have different verity...

Anyway, this is an issue, and simply checking for /var symlink existing is not good as we might overwrite everything else in the state dir

If you've got a concept for how to fix this the proper way I am happy to test it against this as much as you need.

Images could differ from local build and the ghcr remote just based on timing and what changes upstream, so this isn't just a need to change origin.