On 2025-05-09, I posted here to ask a question about Kinoite, and I was told that Kinoite is maintained by Fedora and that I was in the wrong forum. However, when I asked at the Fedora Atomic Desktop forums (where I was allowed to post my rpm-ostree status output), someone pointed out that I am running ublue-os kinoite-nvidia (Kinoite with the proprietary Nvidia driver included) rather than fedora x86_64 kinotite. This makes sense as I need supergfxctl so that I can switch mode to Vfio and supergfxctl is not included with Fedora Kinoite.
Anyway, if this is still not the correct place to ask this question, I ask for both your understanding and guidance as to where the proper place to ask might be.
My new question is - Why have updates stopped? I currently find myself running on a Fedora 41 system. Running
$ rpm-ostree upgrade
results in no errors and the final message
No upgrade available.
It appears I am using the ālatestā tag on the docker link. Again, Iād love to post the rpm-ostree status output so that you might see the docker URLs for yourself, but this forum wonāt currently let me (I guess because I am a new user).
I checked github and ālatestā tag for kinoite-nvidia at this writing points at tag 42-20250513.2. My current system is 41.20250403.0, per rpm-ostree status.
Iāve run into update problems on my personal Bazzite systems before where I had too many systems pinned for the size of the /boot partition, but this does not appear to be the case here. Running a df -h shows that I have 452 MB available on /boot. Only my current system is pinned.
You can see that yesterday I tried rebasing to Fedora Kinoite. It seemed to go fine, but I was unable to fully test it due to the lack of supergfxctl. I actually built supergfxctl in a Toolbox container but I couldnāt figure out how to get the service to run on the host system.
Iām fine with staying on the ublue-os version provided I can get updates working again.
I could ditch docker but to my knowledge, layering is the only viable way to install qemu and libvirt. I should point out that this is a working system that has been receiving updates normally since January/February (under kinoite-nvidia) and since November 2024 (before I rebased from Bazzite to kinoite-nvidia) without no apparent issues.
Below is the output from the last time I ran rpm-ostree upgrade earlier today.
Haha true enough. Iām just trying to avoid that if possible. It was a chunk of work and I feel lucky I got a working system out of it. Well, working until I developed this update problem.
Potentially significant info I just noticed: On the github page (assuming Iām looking in the right place), thereās a banner at the top that says āThis repository was archived by the owner on Apr 27, 2025. It is now read-only.ā Relevant?
Sorry, Iām not sure I understand. Are you suggesting that I need to rebase to change my remote ref? The link you posted is the same one that I posted in my previous comment.
Yeah sorry, githubās rewriting of the url is annoying, but thatās the package you should be on. After a reset run an upgrade, and you should be on that image.
Found another potentially relevant item. The URL line under [remote ādefaultā] in my /sysroot/ostree/repo/config references ābazzite-nvidia-open-stableā. As stated previously in this thread, this was a initially a Bazzite system before rebasing to kinoite-nvidia. As for the path, I donāt have an install under /run or /var/run so Iām guessing this line is not about my system but the remote system.
I really do appreciate your suggestion and interacting with me, but having to reinstall qemu and libvirt for every upgrade might make atomic desktop non-viable for my use case.
Perhaps could you suggest a way that I might prove that the layered packages are interfering in the upgrade? Iām a little shocked that there wouldnāt be additional errors in the update output or failing that, the journal if this was indeed the case.
No clue how to diagnose this, youāre running an unsupported configuration, youād have to dig into the service logs and find out what the root cause is.
Youāre using a base image that we use for generating our end user images, something like Aurora DX is probably a better fit.
