Hi,
This is to track that when using current ubuntu-image (3.0+snap3 r495) with an image definition yaml that includes a manual customization snippet such as:
- manual:
copy-file:
- source: fixups.sh
destination: /usr/local/sbin/fixups.sh
execute:
- path: /usr/local/sbin/fixups.sh
fixups.sh will always be searched in the current directory, even if ubuntu-image is pointed at an image definition yaml in a different directory. For instance:
sudo /snap/bin/ubuntu-image classic image-definitions/ubuntu-server.yaml
will try to open ./fixups.sh instead of image-definitions/fixups.sh.
This code path is exactly what happens with livecd-rootfs, so that means as such we can't use image customizations in livecd-rootfs (that's frowned upon though, since we typically want official images not to have any, but it might be needed during development of an image or to workaround bugs).
Thanks,
Here are the places where a user could define a path:
- --output-dir to declare where to put the generated image
- --disk-info` path of the file to be used as `.disk/info`
- --workdir path of the workdir.
- --apparmor-
- --cloud-init cloud-config data to be copied to the image
- model_assertion the path to the model assertion file
- image_definition the path to the image definition file
- paths in various objects in model assertion and image definition. Except the Source of CopyFile, these paths are interpreted in the context of a chroot (in a rootfs of an image).
- CopyFile
- Execute
- TouchFile
- etc.
We have two conflicting situations:
- when executing ubuntu-image and giving it command-line arguments, it seems natural to interpret paths relative to the current directory
- when reading a model assertion or image definition, it seems natural to interpret paths defined in these files relative to the model assertion / image definition file path.
AFAICS no command line argument overrides a value set in model_assertion or image_definition, so we could handle both cases differently.
Plan to improve the situation:
- keep paths given as command line arguments relative to current directory
- do not change the "destination" path interpretation in manual customization (Execute, ToucheFile, etc.).
- store the image_definition / model_assertion dir path at the start and use it to as the root for relative paths of every path/file present in the image_definitio