202605270119 Update

Okay, so I have two problems with this update. They may stem from the same problem, which seems to be that this latest update now has two different main applications that can be used, incus 202605272150 and incus-lts-7.0 202605272150. My system does not choose one.

On my two-server cluster (waiting for Unique Situation I can’t seem to find anywhere involving adding a server to my cluster to get fixed so I can add another node), I get this error at startup:

lsstat /var/lib/extensions/Incus-lts-7.0.raw: no such file or directory.

It also shows incus() and incus-lts-7.0() are installed applications.

On my third node that I am waiting to cluster, which does not have a default configuration installed but modified networking, it does seem to boot and I can reach it remotely, but it also has both applications installed. This is what I see in the logs:

May 28, 05:06:27 AM 4c4c4544-0038-5310-8048-c2c04f395a32 incus-osd[806]: 2026-05-28 05:06:27 ERROR more than one primary application present in installation list: incus, incus-lts-7.0 err=more than one primary application present in installation list: incus, incus-lts-7.0 provider=images
May 28, 06:22:41 AM 4c4c4544-0038-5310-8048-c2c04f395a32 incus-osd[806]: 2026-05-28 06:22:41 ERROR more than one primary application present in installation list: incus, incus-lts-7.0 err=more than one primary application present in installation list: incus, incus-lts-7.0 provider=images

What do you recommend I do to fix this?

Yes, we unfortunately had a bug in the application download logic that wasn’t exposed until we introduced a second Incus LTS application with IncusOS 202605270119. Essentially there are now two “flavors” of the Incus application, and the code had been assuming there would ever only be one. This has been fixed by incus-osd/providers: Fix selection of proper application for download by gibmat · Pull Request #1120 · lxc/incus-os · GitHub , but existing systems will download both versions until they get an update with that fix.

IncusOS 202605270119 was briefly in the stable channel, and if your system updated to it you’ll see that error about more than one primary application being present. However, the system will still be accessible via API and should work as expected; the Incus versions are currently identical, so there’s no change in observed behavior. We’ve since demoted that IncusOS version back to testing so it’s not available for normal updates.

We fixed the duplicate application download issue and attempted to cleanup the accidental LTS application in IncusOS 202605272150 (currently only in the testing channel), but I had a major facepalm because it removed the Incus LTS application from 202605270119, but not the freshly updated 202605272150. :flushed_face: This exposed another bug that’s expressing itself as the lstat error upon reboot.

Last night I made the accidental Incus LTS application cleanup more robust ( incus-osd: Make the cleanup logic for accidental incus LTS more robust by gibmat · Pull Request #1125 · lxc/incus-os · GitHub ) and am working on a fix for the secondary bug causing the lstat error. Hopefully there will be another IncusOS release to the testing channel fairly soon that should cleanly update and get things back into a good state.

Getting IncusOS back to a good state

If you’re currently on the stable update channel and had updated to 202605270119, ignore the error about more than one primary application being installed. IncusOS will still operate correctly, and the next stable update will properly clean things up.

For IncusOS systems on the testing channel that boot with the lstat error, some manual recovery work will be needed. You’ll need to follow the steps at Emergency Procedure for a Lost Client Certificate - IncusOS documentation to use an encryption recovery key to manually mount the IncusOS system drive. Once mounted, remove any incus-lts-7.0.raw image(s) that exist under /var/lib/incus-os-extensions/ (find /var/lib/ -xdev | grep lts), then reboot and IncusOS should come up cleanly. Because this error occurs very early in the startup process, I don’t think we’ll be able to push an automatic fix for this problem.

Edit: A few people have also reported that booting back into the prior stable release, 202605181246, allows IncusOS to startup and resume operations. When a new stable release is published, those systems should automatically apply it upon next reboot.

Thanks for the detailed reply. As you said, I am not too worried about the node on 202605270119. It still works.

I have reverted my other two nodes to 202605181246 for the time being. Will I still need to run the Emergency procedure you mention above? I should note that these are all on the stable channel.
Thanks for the help!

If the other two nodes boot properly when reverted to 202605181246, then you shouldn’t have to do anything extra. The next stable release of IncusOS should then apply cleanly and you’ll be in a good state on those machines.

1 Like

My operations center shows me that the next stable update is available: 202605270119 -> 202605281810. Does it suppose to fix the issue? When I try to run the update, IncusOS shows me the same error that more than one primary application is present and the update is not installing.

I just updated to 202605281810 after rolling back to the previous version, and that fixed the issue for me!

Has a new stable been released so far? I’m on 202605272150 now, but it appears that I’m not able to get past it, whereas https://images.linuxcontainers.org/os/index.json suggests there are newer stable releases. Can you explain?

@ykazakov If your IncusOS system updated to 202605270119, as long as the prior isn’t older than 202604070253, if you reboot into that older version it should fetch the latest update, apply it, and then reboot. That should get you back into a good state.

@Unroasted It appears your IncusOS system is on the testing channel. If the prior installed version of IncusOS isn’t 202605270119, you will likely be able to reboot into that older version, which will then fetch the latest update, apply it, and then reboot. Please review the relevant section this post: Details on this week's IncusOS updates and steps for updating to the current stable release.

As far as I understand, I am on stable though :thinking:

config:
  auto_reboot: false
  channel: stable
  check_frequency: 6h
state:
  last_check: "2026-06-02T07:53:20.03102314+02:00"
  needs_reboot: false
  status: 'more than one primary application present in installation list: incus,
    incus-lts-7.0'

Was this a brand new IncusOS install? Version 202605272150 was only ever available in the testing channel, so the only other way you could have gotten it is if you had manually installed the update by hand.

This install is from around February 2026. I didn’t touch this setting in the past, but :person_shrugging:

I think there’s nothing else I can do then to manually remove it I believe?

I have the same situation. Installed IncusOS 3 weeks ago on stable channel. Now i am stuck on 202605272150. I know of another instance installed 5 month ago with the same situation.

Is there any solution besides reinstallation?

config:
  auto_reboot: false
  channel: stable
  check_frequency: 6h
state:
  last_check: "2026-06-06T15:33:06.117399874Z"
  needs_reboot: false
  status: 'more than one primary application present in installation list: incus,
    incus-lts-7.0'

If 202605272150 was only released in testing there might be another bug?

Can i help with more information? I could give you access to one of the servers for investigation if that would help.

That image was in stable, just not for very long as we retracted it as soon as we noticed things going bad…

Can you show incus admin os show?

environment:
  hostname: xxx
  os_name: IncusOS
  os_version: "202605272150"
  os_version_next: "202605272150"
  system_is_ready: true
  uptime: 62479