You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When the storage pool is overfilled by image auto-update operation, the inconsistent image ends up being used.
In my case it resulted in containers failing to start, but the bug can be less visible.
incusd.log:
time="2024-01-13T10:27:37Z" level=warning msg="Unpack failed" allowedCmds="[xz]" err="Failed to run: tar --wildcards --exclude=dev/* --exclude=./dev/* --exclude=rootfs/dev/* --exclude=rootfs/./dev/* --restrict --force-local -C /var/lib/incus/storage-pools/default/images/54df95801a0bdbdd981401884bbdec09f6b959170877df2e71f0677d3f220319 --numeric-owner --xattrs-include=* -Jxf -: exit status 2 (tar: metadata.yaml: Cannot write: No space left on device\ntar: templates/hostname.tpl: Cannot write: No space left on device\ntar: templates/hosts.tpl: Cannot write: No space left on device\ntar: Exiting with failure status due to previous errors)" extension=.tar.xz file=/var/lib/incus/images/54df95801a0bdbdd981401884bbdec09f6b959170877df2e71f0677d3f220319 path=/var/lib/incus/storage-pools/default/images/54df95801a0bdbdd981401884bbdec09f6b959170877df2e71f0677d3f220319
container-name/console.log:
/sbin/init: error while loading shared libraries: /lib/x86_64-linux-gnu/libseccomp.so.2: file too short
journalctl -u incus:
level=error msg="Failed to retrieve PID of executing child process" instance=huge-cluster-server-1 instanceType=container project=default
Steps to reproduce
Pull some image from public repo, make sure it it configured to be auto-updated
Make storage pool to be almost full
Make image auto-update happen (e.g. wait; I don't know how to trigger it)
Try to incus launch a container from previously downloaded image having auto-update on
Observe it failing to start
Workaround
Manually delete all images from storage pool: incus image list, incus image delete ...
Information to attach
Any relevant kernel output (dmesg)
Container log (incus info NAME --show-log)
Container configuration (incus config show NAME --expanded)
Main daemon log (at /var/log/incus/incusd.log)
Output of the client with --debug
Output of the daemon with --debug (alternatively output of incus monitor --pretty while reproducing the issue)
The text was updated successfully, but these errors were encountered:
andrey-utkin
changed the title
Auto-updated image is corrupted and can fail due to no space, but leave corrupetd image
If image auto-update fails due to no space, it stays and corrupts new containers
Jan 19, 2024
Required information
incus info
Issue description
When the storage pool is overfilled by image auto-update operation, the inconsistent image ends up being used.
In my case it resulted in containers failing to start, but the bug can be less visible.
incusd.log:
container-name/console.log:
journalctl -u incus
:Steps to reproduce
incus launch
a container from previously downloaded image having auto-update onWorkaround
Manually delete all images from storage pool:
incus image list
,incus image delete ...
Information to attach
dmesg
)incus info NAME --show-log
)incus config show NAME --expanded
)incus monitor --pretty
while reproducing the issue)The text was updated successfully, but these errors were encountered: