Move guest rootfs selection earlier to the shim

[sidneychang]

Background

Currently, urunc chooses the guest rootfs in the runtime path, inside chooseRootfs(), shortly before Exec() prepares the monitor environment.

For upcoming shim-side storage work, such as view snapshots or copy-boot-files mode, the shim needs to know this decision earlier.

Proposal

Pre-compute the guest rootfs choice in the shim when possible, then pass the selected types.RootfsParams to the runtime through internal annotations.

The runtime should still keep the existing chooseRootfs() logic as a fallback, so podman/direct urunc usage continues to work.

Main concerns

We cannot simply move the current chooseRootfs() implementation into the shim.

There are several issues:

1. Rootfs mount timing

   Runtime-side block-rootfs detection currently uses getMountInfo(bundle/rootfs). However, the shim wrapper runs before the wrapped runc task service mounts r.Rootfs into bundle/rootfs, so bundle/rootfs may not be mounted yet.

   Shim-side logic may need to use CreateTaskRequest.Rootfs or containerd snapshot metadata instead.

2. Different available state

   Runtime-side chooseRootfs() uses decoded annotations, urunc host config, guest capabilities, monitor capabilities, and rootfs mount information. In the shim, some of these inputs may not exist yet or may need to be reconstructed from config.json, image metadata, urunc.json, and /etc/urunc/config.toml.

3. State handoff

   The shim cannot pass the result through memory. If it writes the selected types.RootfsParams into config.json, urunc create must also copy that information into state.json, because Exec() later reads from state.json.

4. Compatibility

   urunc can also be used without this shim, for example through podman or direct urunc commands. Therefore, runtime-side chooseRootfs() must remain as a fallback when no shim-provided rootfs choice exists.

5. Side effects

   The current rootfs selection path may also create or prepare paths such as bundle/monRootfs. If selection is pre-computed in the shim, we should avoid filesystem side effects during the selection phase and keep actual rootfs preparation in the runtime path.

[cmainas]

Hello @sidneychang ,

I will answer some of your concerns. Please let me know if you need more information.

1. This is true and we have two options here. The first is to call chooseRootfs after the mount has been done. The other option is to obtain the information of the rootfs from the shim before the mount takes place and use this information instead of getMountInfo. Fell free to choose whichever option you prefer. In the future, we will totally remove the mounting of a block based rootfs if we have the view snapshots, since it is useless for urunc.
2. Feel free to obtain the annotations however you want and we can later adapt your changes with the work that sets the annotations in the shim.
3. That is correct. The arguments can be passed either as cli args or through the config.json as annotations. urunc Create already reads and writes the annotations form config.json in the state so maybe that's the most straightforward approach.
4. That is correct. We can use the annotations to determine if urunc has all the information it needs for the rootfs or not.
5. Yes, that is also ok to be done in the shim. As said in 1, at the end of the whole refactor, the shim will be responsible to handle and prepare the rootfs for the monitor process.