I have IncusOS installed on a single machine running version 202607270148:
[2026/07/30 16:15:58 BST] incus-osd: 2026-07-30 15:15:58 INFO System is starting up machine-id=24c26aa735874e6fbf53c2ba0274ebc6 mode=production version=202607270148
However, when incus-osd attempts to update the Incus application, I see in the logs:
[2026/07/30 16:16:20 BST] incus-osd: 2026-07-30 15:16:20 INFO Downloading application update application=incus channel=stable version=202607270148
[2026/07/30 16:16:20 BST] incus-osd: 2026-07-30 15:16:20 ERROR Failed to check for application updates err=Failed to run: systemd-dissect --validate /var/lib/incus-os-extensions/202607270148/incus.raw: exit status 1 (/var/lib/incus-os-extensions/202607270148/incus.raw: Couldn't identify a suitable partition table or file system.) provider=images
I have seen (but unfortunately lost) logs which indicate that the area Incus updates are being downloaded to has run out of space. Given the immutable nature of IncusOS, it seems I have no ability to go free space myself.
Everything else is working as expected, I am able to create new VMs, connect via incus webui and restart the machine with no issues. However, the version of Incus being run seems several months out of date.
So, there’s a few interesting problems occurring in this situation…
At startup, IncusOS checks available disk space, and will print a warning if it’s less than 5 GiB. At 1 GiB or less, it tries to free up some space by wiping /var/cache/ and vacuuming the systemd journal files. But this check is only run on startup, and the system root partition could fill up without IncusOS noticing.
Currently, the incus application takes ~850MiB of disk space uncompressed. Because multiple versions of an application are kept, downloading an application update requires enough disk space for the new version; eventually the Nth oldest version of the application is deleted, reclaiming that extra used space. The OS-level updates, however, are handled differently because they are written directly to one of the A/B sets of partitions on disk. All that is needed is sufficient temporary space to download the update, before it is written to the appropriate partitions. Because of how IncusOS behaves, the OS-level update temporary files aren’t removed until the next update is downloaded. Since the OS-level updates are all roughly the same size (+/- a few MiB), if your disk isn’t 100% full the OS-level update will likely succeed because it can clear out the prior temporary files and now there would be sufficient space to download the new OS-level update. This means that a system with a very full disk may fail to apply an application update, but still be able to apply a new OS update, and I’ve been able to successfully replicate this in my test environment.
But that still leaves us with a partially-downloaded application update, which won’t properly validate. The current download logic attempts to skip needlessly downloading updates if they already exist on disk, but it doesn’t check that the existing file is actually valid. That’s a bad assumption that will need to be fixed.
@jamesreprise based on the logs you’ve provided, I suspect your IncusOS system managed to fill its disk space with journalctl logs, and you then had a update failure when it tried to download version 202607270148. On the next reboot it cleared out the journal files, which freed up at least 5 GiB of space (since there isn’t a warning about low disk space when incus-osd starts). But you’re stuck with a bad incus sysext image. A new stable release of IncusOS (202607310233) has been published since your initial post – I’d be interested to see if your system was able to successfully update to that version or not.
I’ll be working on a few bug fixes related to this, which should at least make it impossible to have an invalid application sysext image left on disk so we don’t encounter this weird update check error again in the future.
The challenge is that we don’t know what the decompressed update size is before attempting to extract it. It might be worthwhile, though, to add a generic warning if less than 1 GiB of disk space is available prior to attempting an update.
Yeah, we don’t know exactly how much space we’ll need, but we can still run the same logic you’d hit on boot so we can clean any huge systemd journal output or something.
I restarted the machine yesterday unplugging it so I think I’ve missed some logs about the update, but here’s what incus-osd said most recently:
> incus admin os debug log -u incus-osd -b0
[2026/08/03 20:22:03 BST] systemd: Started incus-osd.service - IncusOS - management daemon.
[2026/08/03 20:22:03 BST] incus-osd: 2026-08-03 19:22:03 INFO System is starting up machine-id=24c26aa735874e6fbf53c2ba0274ebc6 mode=production version=202607310233
[2026/08/03 20:22:03 BST] incus-osd: 2026-08-03 19:22:03 INFO Bringing up the network
[2026/08/03 20:22:14 BST] incus-osd: 2026-08-03 19:22:14 INFO Bringing up the local storage
[2026/08/03 20:22:15 BST] incus-osd: 2026-08-03 19:22:15 INFO Starting application name=incus version=7.3 [202607310233]
[2026/08/03 20:22:19 BST] incus-osd: 2026-08-03 19:22:19 INFO Application TLS certificate fingerprint fingerprint=f7d8d1c81a465670b570f9c0d55c04a0473192da840cec6722cd26e22fc4e133 name=incus
[2026/08/03 20:22:19 BST] incus-osd: 2026-08-03 19:22:19 INFO System is ready version=202607310233
So it seems IncusOS was able to update successfully (this was already the case before), and the Incus application has also updated successfully, which is new. From my reading of your post it doesn’t seem as though you were expecting that.
If there’s some way for me to retrieve logs from previous boots, please let me know as I appreciate there is a complete lack of any detail as to how everything started working again.
As for an ironclad fix, it would feel good to know that the space the application updates download to is completely separate from space used for logs etc.
You can obtain the previous boot logs by adjusting the parameter -b. E.g., -b -1 gives you the previous boot log, -b -2 gives you the boot log before that, etc:
> incus admin os debug log -u incus-osd -b -1 --debug --verbose
WARNING: The IncusOS API and configuration is subject to change
[2026/07/30 16:15:58 BST] systemd: Started incus-osd.service - IncusOS - management daemon.
[2026/07/30 16:15:58 BST] incus-osd: 2026-07-30 15:15:58 INFO System is starting up machine-id=24c26aa735874e6fbf53c2ba0274ebc6 mode=production version=202607270148
[2026/07/30 16:15:58 BST] incus-osd: 2026-07-30 15:15:58 INFO Bringing up the network
[2026/07/30 16:16:06 BST] incus-osd: 2026-07-30 15:16:06 INFO Bringing up the local storage
[2026/07/30 16:16:07 BST] incus-osd: 2026-07-30 15:16:07 INFO Downloading application update application=incus channel=stable version=202607270148
[2026/07/30 16:16:07 BST] incus-osd: 2026-07-30 15:16:07 ERROR Failed to check for application updates err=Failed to run: systemd-dissect --validate /var/lib/incus-os-extensions/202607270148/incus.raw: exit status 1 (/var/lib/incus-os-extensions/202607270148/incus.raw: Couldn't identify a suitable partition table or file system.) provider=images
[2026/07/30 16:16:07 BST] incus-osd: 2026-07-30 15:16:07 INFO Starting application name=incus version=6.23 [202604150351]
[2026/07/30 16:16:10 BST] incus-osd: 2026-07-30 15:16:10 INFO Application TLS certificate fingerprint fingerprint=f7d8d1c81a465670b570f9c0d55c04a0473192da840cec6722cd26e22fc4e133 name=incus
[2026/07/30 16:16:10 BST] incus-osd: 2026-07-30 15:16:10 INFO System is ready version=202607270148
[2026/07/30 16:16:20 BST] incus-osd: 2026-07-30 15:16:20 INFO Downloading application update application=incus channel=stable version=202607270148
[2026/07/30 16:16:20 BST] incus-osd: 2026-07-30 15:16:20 ERROR Failed to check for application updates err=Failed to run: systemd-dissect --validate /var/lib/incus-os-extensions/202607270148/incus.raw: exit status 1 (/var/lib/incus-os-extensions/202607270148/incus.raw: Couldn't identify a suitable partition table or file system.) provider=images
[2026/07/30 22:17:07 BST] incus-osd: 2026-07-30 21:17:07 INFO Downloading application update application=incus channel=stable version=202607270148
[2026/07/30 22:17:07 BST] incus-osd: 2026-07-30 21:17:07 ERROR Failed to check for application updates err=Failed to run: systemd-dissect --validate /var/lib/incus-os-extensions/202607270148/incus.raw: exit status 1 (/var/lib/incus-os-extensions/202607270148/incus.raw: Couldn't identify a suitable partition table or file system.) provider=images
[2026/07/31 04:18:07 BST] incus-osd: 2026-07-31 03:18:07 INFO Downloading application update application=incus channel=stable version=202607270148
[2026/07/31 04:18:07 BST] incus-osd: 2026-07-31 03:18:07 ERROR Failed to check for application updates err=Failed to run: systemd-dissect --validate /var/lib/incus-os-extensions/202607270148/incus.raw: exit status 1 (/var/lib/incus-os-extensions/202607270148/incus.raw: Couldn't identify a suitable partition table or file system.) provider=images
[2026/07/31 10:19:07 BST] incus-osd: 2026-07-31 09:19:07 INFO Downloading application update application=incus channel=stable version=202607270148
[2026/07/31 10:19:07 BST] incus-osd: 2026-07-31 09:19:07 ERROR Failed to check for application updates err=Failed to run: systemd-dissect --validate /var/lib/incus-os-extensions/202607270148/incus.raw: exit status 1 (/var/lib/incus-os-extensions/202607270148/incus.raw: Couldn't identify a suitable partition table or file system.) provider=images
[2026/07/31 16:20:07 BST] incus-osd: 2026-07-31 15:20:07 INFO Downloading application update application=incus channel=stable version=202607270148
[2026/07/31 16:20:07 BST] incus-osd: 2026-07-31 15:20:07 ERROR Failed to check for application updates err=Failed to run: systemd-dissect --validate /var/lib/incus-os-extensions/202607270148/incus.raw: exit status 1 (/var/lib/incus-os-extensions/202607270148/incus.raw: Couldn't identify a suitable partition table or file system.) provider=images
[2026/07/31 22:21:07 BST] incus-osd: 2026-07-31 21:21:07 INFO Downloading application update application=incus channel=stable version=202607270148
[2026/07/31 22:21:07 BST] incus-osd: 2026-07-31 21:21:07 ERROR Failed to check for application updates err=Failed to run: systemd-dissect --validate /var/lib/incus-os-extensions/202607270148/incus.raw: exit status 1 (/var/lib/incus-os-extensions/202607270148/incus.raw: Couldn't identify a suitable partition table or file system.) provider=images
[2026/08/01 04:22:07 BST] incus-osd: 2026-08-01 03:22:07 INFO Downloading application update application=incus channel=stable version=202607270148
[2026/08/01 04:22:07 BST] incus-osd: 2026-08-01 03:22:07 ERROR Failed to check for application updates err=Failed to run: systemd-dissect --validate /var/lib/incus-os-extensions/202607270148/incus.raw: exit status 1 (/var/lib/incus-os-extensions/202607270148/incus.raw: Couldn't identify a suitable partition table or file system.) provider=images
[2026/08/01 10:23:07 BST] incus-osd: 2026-08-01 09:23:07 INFO Downloading SecureBoot update channel=stable version=202607310233
[2026/08/01 10:23:07 BST] incus-osd: 2026-08-01 09:23:07 INFO Applying Secure Boot certificate update version=202607310233
[2026/08/01 10:23:07 BST] incus-osd: 2026-08-01 09:23:07 INFO Downloading application update application=incus channel=stable version=202607310233
[2026/08/01 10:23:44 BST] incus-osd: 2026-08-01 09:23:44 INFO Downloading OS update channel=stable version=202607310233
[2026/08/01 10:24:53 BST] incus-osd: 2026-08-01 09:24:53 INFO Applying OS update version=202607310233
[2026/08/01 10:24:54 BST] incus-osd: 2026-08-01 09:24:54 INFO Reloading application name=incus version=202607310233
[2026/08/02 05:00:00 BST] incus-osd: 2026-08-02 04:00:00 INFO Executing periodic job job=pool_scrub
[2026/08/02 05:00:00 BST] incus-osd: 2026-08-02 04:00:00 INFO Scrubbing pool pool=local
It seems once the incus application it was trying to download switched from 202607270148 to 202607310233, it worked.
I tried adding --debug and --verbose but no luck in getting anything more detailed.
My issue is solved now, and it seemed to happen with little intervention. I’ll mark your response as the solution @gibmat. Thank you for the help, all!
Actually, no, that was exactly what I was hoping would happen. IncusOS had managed to free up sufficient free disk space, so when the next update was published it was able to download and apply both the application and OS-level update. Your system still has a corrupted Incus sysext image for version 202604150351, but that shouldn’t be an issue unless you try to rollback to that specific version.
The tricky part is that depending on what applications(s) are installed, different amounts of total disk space will be required, so we can’t just set a static quota that would work for all systems. Maybe we should investigate ways to give better insight into the disk usage of the root partition.
IncusOS had managed to free up sufficient free disk space, so when the next update was published it was able to download and apply both the application and OS-level update. Your system still has a corrupted Incus sysext image for version 202604150351, but that shouldn’t be an issue unless you try to rollback to that specific version.