Aurora Spring 2026 Update

[inffy]

Fresh out of the oven, we have a new big update based on Fedora 44.

https://docs.getaurora.dev/blog/aurora-spring26-update

Update: 12.05.2026: stable images available

[manfredlotz]

The asusctl rpm package contains

/usr/lib/systemd/system/asus-shutdown.service
/usr/lib/systemd/system/asusd.service
/usr/lib/udev/rules.d/99-asusd.rules

Does asusctl via homebrew also include systemd service and udev rules?

[inffy]

https://github.com/ublue-os/homebrew-tap/blob/main/Casks/asusctl-linux.rb

[Danathar]

I noticed that the akmods repo is still on 43 and it looks like you are using that in latest? Seems to work, is there plans to move that to 44 to match latest? (does it matter?)

I noticed when I moved my test repo that builds zfs on top of it (the one cloned from @renner0e), moved the akmod to 44 in the containerfile and it failed (thats when I looked to see what Aurora latest was using).

[inffy]

akmods has 44 builds too and we use those in latest stream but its built from the beta branch

[renner0e]

I noticed that the akmods repo is still on 43 and it looks like you are using that in latest? Seems to work, is there plans to move that to 44 to match latest? (does it matter?)

I noticed when I moved my test repo that builds zfs on top of it (the one cloned from @renner0e), moved the akmod to 44 in the containerfile and it failed (thats when I looked to see what Aurora latest was using).

I don't follow, what thing has a mismatch, can you show me why you think that?

[Danathar]

I compared my Containerfile to yours, and I think I understand the mismatch now.

My current working file has FEDORA_VERSION=43 for the akmods and akmods-zfs stages, but it still uses ghcr.io/ublue-os/aurora:latest as the base. Since aurora:latest currently resolves to Fedora 44, that means my working build is mixing F43 coreos-stable akmods/ZFS with an F44 Aurora base.

Your current template doesn't do that, it uses aurora:${FEDORA_VERSION}, so with FEDORA_VERSION=44, the Aurora base is also F44.

The part I am stuck on is that when I changed my repo to FEDORA_VERSION=44, the build failed immediately because these tags do not seem to exist:

ghcr.io/ublue-os/akmods:coreos-stable-44
ghcr.io/ublue-os/akmods-zfs:coreos-stable-44

So should F44 ZFS builds wait for the coreos-stable-44 akmods/ZFS tags, or should they use a different available tag, such as main-44 or a versioned kernel tag?

This discussion should probably move over to your template repo..apologies!

[inffy]

you can't really mix stable and latest. Stable (coreOS) is not yet on 44

[Danathar]

I ended up mixing streams because when I tried moving my fork to 44, the build failed right away since I could not find matching coreos-stable-44 akmods / akmods-zfs images. My workaround was to leave Aurora on latest and keep the akmods/ZFS stages on 43, but I understand now that this is just a mismatch that happened to work, not a correct setup.

I’ll wait for the proper upstream inputs instead of mixing latest and coreos-stable (even though...it seems to work anyway)

[manfredlotz]

I thought I participate in testing. Using Virt Machine Manager I cannot start a virtual machine.

Details say: " File "/usr/share/virt-manager/virtManager/object/domain.py", line 1446, in startup
self._backend.create()
~~~~~~~~~~~~~~~~~~~~^^
File "/usr/lib64/python3.14/site-packages/libvirt.py", line 1395, in create
raise libvirtError('virDomainCreate() failed')
libvirt.libvirtError: operation failed: swtpm died and reported: libvirt: error : cannot execute binary /usr/bin/swtpm: Permission denied"

SELinux gives

Apr 29 12:40:00 hogwart setroubleshoot[14909]: SELinux is preventing rpc-virtqemud from entrypoint access on the file /usr/bin/swtpm. For complete SELinux messages run: seal>
Apr 29 12:40:00 hogwart setroubleshoot[14909]: SELinux is preventing rpc-virtqemud from entrypoint access on the file /usr/bin/swtpm.
                                               
                                               *****  Plugin restorecon (99.5 confidence) suggests   ************************
                                               
                                               If you want to fix the label. 
                                               /usr/bin/swtpm default label should be swtpm_exec_t.
                                               Then you can run restorecon. The access attempt may have been stopped due to insufficient permissions to access a parent direc>
                                               Do
                                               # /sbin/restorecon -v /usr/bin/swtpm
                                               
                                               *****  Plugin catchall (1.49 confidence) suggests   **************************
                                               
                                               If you believe that rpc-virtqemud should be allowed entrypoint access on the swtpm file by default.
                                               Then you should report this as a bug.
                                               You can generate a local policy module to allow this access.
                                               Do
                                               allow this access for now by executing:
                                               # ausearch -c 'rpc-virtqemud' --raw | audit2allow -M my-rpcvirtqemud
                                               # semodule -X 300 -i my-rpcvirtqemud.pp

[renner0e]

Restart works as well for me. Does it mean I have to restart it every time after boot? Will check after the next reboot.

In theory the workaround service is supposed to run at every boot, but nobody so far has more deeply looked into why this happened all of a sudden.

[manfredlotz]

Ok, I did a reboot and see

● swtpm-workaround.service - Workaround swtpm not having the correct label
     Loaded: loaded (/usr/lib/systemd/system/swtpm-workaround.service; enabled; preset: disabled)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: active (exited) since Fri 2026-05-01 11:48:08 CEST; 58s ago
 Invocation: 2eb1b46d29904a31a548fdafacc7de6b
    Process: 2319 ExecStartPre=/usr/bin/bash -c [ -x /usr/local/bin/overrides/swtpm ] || /usr/bin/cp /usr/bin/swtpm /usr/local/bin/overrides/swtpm (code=exited, status=0/SUC>
    Process: 2384 ExecStartPre=/usr/bin/mount --bind /usr/local/bin/overrides/swtpm /usr/bin/swtpm (code=exited, status=0/SUCCESS)
    Process: 2406 ExecStart=/usr/sbin/restorecon /usr/bin/swtpm (code=exited, status=0/SUCCESS)
   Main PID: 2406 (code=exited, status=0/SUCCESS)
   Mem peak: 2M
        CPU: 16ms

May 01 11:48:08 hogwart systemd[1]: Starting swtpm-workaround.service - Workaround swtpm not having the correct label...
May 01 11:48:08 hogwart systemd[1]: Finished swtpm-workaround.service - Workaround swtpm not having the correct label.

Still starting a virt machine not possible.

Restarted the swtpm-workaround.service. status looks the same as above.

Now, starting virt machine is working fine.

[Danathar]

if you have the problem, can you selinux disable and see if that fixes it and then turn it back on? I hate SELinux labeling issues...

[inffy]

Ok, I did a reboot and see

● swtpm-workaround.service - Workaround swtpm not having the correct label
     Loaded: loaded (/usr/lib/systemd/system/swtpm-workaround.service; enabled; preset: disabled)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: active (exited) since Fri 2026-05-01 11:48:08 CEST; 58s ago
 Invocation: 2eb1b46d29904a31a548fdafacc7de6b
    Process: 2319 ExecStartPre=/usr/bin/bash -c [ -x /usr/local/bin/overrides/swtpm ] || /usr/bin/cp /usr/bin/swtpm /usr/local/bin/overrides/swtpm (code=exited, status=0/SUC>
    Process: 2384 ExecStartPre=/usr/bin/mount --bind /usr/local/bin/overrides/swtpm /usr/bin/swtpm (code=exited, status=0/SUCCESS)
    Process: 2406 ExecStart=/usr/sbin/restorecon /usr/bin/swtpm (code=exited, status=0/SUCCESS)
   Main PID: 2406 (code=exited, status=0/SUCCESS)
   Mem peak: 2M
        CPU: 16ms

May 01 11:48:08 hogwart systemd[1]: Starting swtpm-workaround.service - Workaround swtpm not having the correct label...
May 01 11:48:08 hogwart systemd[1]: Finished swtpm-workaround.service - Workaround swtpm not having the correct label.

Still starting a virt machine not possible.

Restarted the swtpm-workaround.service. status looks the same as above.

Now, starting virt machine is working fine.

Ok, I did a reboot and see

● swtpm-workaround.service - Workaround swtpm not having the correct label
     Loaded: loaded (/usr/lib/systemd/system/swtpm-workaround.service; enabled; preset: disabled)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: active (exited) since Fri 2026-05-01 11:48:08 CEST; 58s ago
 Invocation: 2eb1b46d29904a31a548fdafacc7de6b
    Process: 2319 ExecStartPre=/usr/bin/bash -c [ -x /usr/local/bin/overrides/swtpm ] || /usr/bin/cp /usr/bin/swtpm /usr/local/bin/overrides/swtpm (code=exited, status=0/SUC>
    Process: 2384 ExecStartPre=/usr/bin/mount --bind /usr/local/bin/overrides/swtpm /usr/bin/swtpm (code=exited, status=0/SUCCESS)
    Process: 2406 ExecStart=/usr/sbin/restorecon /usr/bin/swtpm (code=exited, status=0/SUCCESS)
   Main PID: 2406 (code=exited, status=0/SUCCESS)
   Mem peak: 2M
        CPU: 16ms

May 01 11:48:08 hogwart systemd[1]: Starting swtpm-workaround.service - Workaround swtpm not having the correct label...
May 01 11:48:08 hogwart systemd[1]: Finished swtpm-workaround.service - Workaround swtpm not having the correct label.

Still starting a virt machine not possible.

Restarted the swtpm-workaround.service. status looks the same as above.

Now, starting virt machine is working fine.

If you look at ls -laZ /usr/bin/swtpm before running the systemctl restart and after you see that the service changes the labels.

I tried to look why this service isn't doing its thing during boot, even if the systemctl status says its enabled, but i couldn't really find any logs to show that it hasn't run or didn't do its thing....

[UMineiro]

I thought I participate in testing. Using Virt Machine Manager I cannot start a virtual machine.

Details say: " File "/usr/share/virt-manager/virtManager/object/domain.py", line 1446, in startup self._backend.create() ~~~~~~~~~~~~~~~~~~~~^^ File "/usr/lib64/python3.14/site-packages/libvirt.py", line 1395, in create raise libvirtError('virDomainCreate() failed') libvirt.libvirtError: operation failed: swtpm died and reported: libvirt: error : cannot execute binary /usr/bin/swtpm: Permission denied"

SELinux gives

Apr 29 12:40:00 hogwart setroubleshoot[14909]: SELinux is preventing rpc-virtqemud from entrypoint access on the file /usr/bin/swtpm. For complete SELinux messages run: seal>
Apr 29 12:40:00 hogwart setroubleshoot[14909]: SELinux is preventing rpc-virtqemud from entrypoint access on the file /usr/bin/swtpm.
                                               
                                               *****  Plugin restorecon (99.5 confidence) suggests   ************************
                                               
                                               If you want to fix the label. 
                                               /usr/bin/swtpm default label should be swtpm_exec_t.
                                               Then you can run restorecon. The access attempt may have been stopped due to insufficient permissions to access a parent direc>
                                               Do
                                               # /sbin/restorecon -v /usr/bin/swtpm
                                               
                                               *****  Plugin catchall (1.49 confidence) suggests   **************************
                                               
                                               If you believe that rpc-virtqemud should be allowed entrypoint access on the swtpm file by default.
                                               Then you should report this as a bug.
                                               You can generate a local policy module to allow this access.
                                               Do
                                               allow this access for now by executing:
                                               # ausearch -c 'rpc-virtqemud' --raw | audit2allow -M my-rpcvirtqemud
                                               # semodule -X 300 -i my-rpcvirtqemud.pp

Same for me. I am issuing this daily since the update so that my VM's can be started:
$ sudo restorecon -rv /var/log/libvirt/
$ systemctl restart swtpm-workaround.service

Before the update the VM's started automatically on boot without issue every day.

Standard image with DX before the update. Since according to the release notes there was some change to make DX part of the base image I suspect the issue is somewhere on the change.

[inffy]

Stable images are building right now and will be available very soon

[b9AcE]

At https://dl.getaurora.dev/ the files are still dated 2026-05-01 and when I downloaded "aurora-nvidia-open-stable-webui-x86_64.iso", extracted the "squashfs.img" from inside that ISO-file, extracted the content of that "squashfs.img" and checked its internal /etc/os-release-file, it still says

NAME="Aurora"
VERSION="43.20260428 (Kinoite)"
RELEASE_TYPE=stable
ID=aurora
ID_LIKE="fedora"
VERSION_ID=43
VERSION_CODENAME="Stargazer"
PRETTY_NAME="Aurora (Version: 43.20260428)"
ANSI_COLOR="0;38;2;60;110;180"
LOGO=fedora-logo-icon
CPE_NAME="cpe:/o:universal-blue:aurora:43"
DEFAULT_HOSTNAME="aurora"
HOME_URL="https://getaurora.dev/"
DOCUMENTATION_URL="https://docs.getaurora.dev"
SUPPORT_URL="https://github.com/ublue-os/aurora/issues/"
BUG_REPORT_URL="https://github.com/ublue-os/aurora/issues/"
SUPPORT_END=2026-12-02
VARIANT="Kinoite"
VARIANT_ID=aurora-nvidia-open
OSTREE_VERSION='43.20260428'
BUILD_ID="440b050"
IMAGE_ID="aurora-nvidia-open"
IMAGE_VERSION="43.20260428"

Should those ISO-files not have been updated by now so that a fresh install results in the version F44.20260511, considering https://github.com/inffy/aurora/releases/tag/stable-20260511 was about 19 hours ago?
I am primarily asking for in case something has gotten stuck, a bug, and needs a nudge to progress as intended.

[inffy]

At dl.getaurora.dev the files are still dated 2026-05-01 and when I downloaded "aurora-nvidia-open-stable-webui-x86_64.iso", extracted the "squashfs.img" from inside that ISO-file, extracted the content of that "squashfs.img" and checked its internal /etc/os-release-file, it still says

NAME="Aurora"
VERSION="43.20260428 (Kinoite)"
RELEASE_TYPE=stable
ID=aurora
ID_LIKE="fedora"
VERSION_ID=43
VERSION_CODENAME="Stargazer"
PRETTY_NAME="Aurora (Version: 43.20260428)"
ANSI_COLOR="0;38;2;60;110;180"
LOGO=fedora-logo-icon
CPE_NAME="cpe:/o:universal-blue:aurora:43"
DEFAULT_HOSTNAME="aurora"
HOME_URL="https://getaurora.dev/"
DOCUMENTATION_URL="https://docs.getaurora.dev"
SUPPORT_URL="https://github.com/ublue-os/aurora/issues/"
BUG_REPORT_URL="https://github.com/ublue-os/aurora/issues/"
SUPPORT_END=2026-12-02
VARIANT="Kinoite"
VARIANT_ID=aurora-nvidia-open
OSTREE_VERSION='43.20260428'
BUILD_ID="440b050"
IMAGE_ID="aurora-nvidia-open"
IMAGE_VERSION="43.20260428"

Should those ISO-files not have been updated by now so that a fresh install results in the version F44.20260511, considering inffy/aurora@stable-20260511 (release) was about 19 hours ago? I am primarily asking for in case something has gotten stuck, a bug, and needs a nudge to progress as intended.

No, they should have not.

#2198 - these will be the ISOs that will get promoted to the main site, propably in few days.

[b9AcE]

Aha. Good to know.
Thank you, @inffy!

It may be good to clarify this on the main page (https://getaurora.dev/en/) because the "Download Aurora"-section is directly preceded by the "News"-section where it is declared that "Aurora:stable now based on Fedora 44" while there is no versioning of the ISO-files visible outside those files' internal content, so it seems plausible to me that more people than just me would see the announcement and assume that to include the ISO-files for fresh installs being version 44 too, since there is no indication to the contrary.

If it is possible, maybe it would be good to include the OSTREE_VERSION in the filenames of the ISO-files (i.e. e.g. "aurora-nvidia-open-stable-webui-x86_64_-_43.20260428.iso"), so that people can clearly see if there has been an update, not just in this case but in general, without having to download the pretty large files just to check the version. Or if that is impractical maybe have some auto-populated field in the download-section of the website write out what the current version of the selected ISO-file is.
This is an issue I have had with the Aurora downloads previously, that the ISO-file versions are unknown until downloaded.

Thanks again!

[inffy]

In the end the ISO doesn't really matter, its just a installation media. Doesn't really matter which version it is as the update will take it to the most recent version anyway.

Adding version numbers is just too volatile and would make the ISO filename just a mess to deal with on the download picker.

[b9AcE]

It does matter when a change is the installation process itself, such as for example now using the Plasma Setup.

[inffy]

I have to disagree. The end result is the same, it is just the installation process is little bit different.

Yes the plasma-setup might be little nicer but in the end, doesn't matter for the end result.

[renner0e]

@manfredlotz https://github.com/ublue-os/aurora/actions/runs/25964708955?pr=2223

I have a fix for this, please rebase to one of those artifacts to confirm nothing else breaks, it's old tech debt that seems to have caught up to us. On a freshly installed system the right labels were applied without any workarounds.

Please feel free to poke me when you don't understand how to rebase to those artifacts or anything else.

[manfredlotz]

Hm, I am running a custom image and thus I am not sure how to do testing here... The custom image is based on ghcr.io/ublue-os/aurora-dx-nvidia-open:latest.

[renner0e]

Hm, I am running a custom image and thus I am not sure how to do testing here... The custom image is based on `ghcr.io/ublue-os/aurora-dx-nvidia-open:latest

The next time you rebuild and update you will have the changes

[Danathar]

Thanks @renner0e I had the same problem this morning and had to hand relabel selinux as well.

[manfredlotz]

@renner0e Thanks. Then I will report tomorrow afternoon, CEST timezone.

[manfredlotz]

Just booted with ghcr.io/ublue-os/aurora-dx-nvidia-open:latest from May 17th.

Things are fine again:

❯ ls -lZ /usr/bin/swtpm
-rwxr-xr-x. 1 root root system_u:object_r:swtpm_exec_t:s0 42200 Jan  1  1970 /usr/bin/swtpm*

[msrn]

The update to Fedora 44 removed my layered Firefox, I had to rollback to previous but in that image the desktop icons are mysteriously missing

Edit: Just ran kbuildsycoca6 --noincremental to fix them desktop entries.

➜  rpm-ostree status
State: busy
AutomaticUpdates: stage; rpm-ostreed-automatic.timer: inactive
Transaction: upgrade 
  Initiator: client(id:cli dbus:1.206 unit:uupd.service uid:0)
Deployments:
● ostree-image-signed:docker://ghcr.io/ublue-os/aurora-dx:stable
                   Digest: sha256:2c8f055121a0465a6eca24d842dae26965a34d6ae66787e74672f8b5c0edfe59
                  Version: 43.20260421 (2026-04-21T01:56:05Z)
          LayeredPackages: firefox keepassxc yt-dlp

  ostree-image-signed:docker://ghcr.io/ublue-os/aurora-dx:stable
                   Digest: sha256:f4c4ed17eefc82ef4922385570ff6049d1343ab97e8500722f78ba434528217e
                  Version: 44.20260511.1 (2026-05-11T21:15:04Z)
          LayeredPackages: code keepassxc yt-dlp
``

[inffy]

#2209 (comment)

[msrn]

Thank you for the response. I would gladly use Flatpak firefox, but the keepassxc integration is the only thing holding me back, and I don't want to have weird hacks to use Keepassxc with flatpak browser. Is there ETA for the update?