Improve improper cockpit-ostree install on systems without rpm-ostree #295
Comments
|
In addition to the standard page UI, we also need to make sure that the update check on the overview page is doing the right thing based on whether the system is PackageKit-based or ostree-based. |
|
After reporting on this issue during an upgrade (in cockpit-project/cockpit#17858), it looks like it's staged to do the same thing again. I'm on cockpit v278 now, and according to the update's component listings, ostree will again be installed with an update to v280 (screen attached). I'm making the assumption that removing ostree will again correct the problem if in fact it does get installed, but it seems obvious that there's something wrong in the update checks for either cockpit itself, or with Fedora's own check - IF - that's the check routine that cockpit relies upon instead of its own internal one. I'll complete the software update - recheck the system for further updates - and recheck cockpit components to see what transpired after all updates are complete. This machine is still on Fedora Workstation 36
|
|
After the update and rechecks... ostree was indeed reinstalled. The same on-screen error showed - "Unable to communicate..." - and after another removal of cockpit-ostree, everything returned to normal in cockpit ('about console' screenshot attached).
I'm also about to update Fedora to 37, so I'll watch for the next round of cockpit updates and see if there's any change in update behaviour with the next round of releases past 280. |
|
@humantex : Do you have the |
|
@martinpitt : No, it isn't installed, and as far as I know, it isn't now or has it ever been a dependency from anything installed on this machine. Essentially, this machine runs as a DNS trap on my local network, and not as a server or desktop environment, so basically I access it remotely via a browser for its primary purpose. |
|
@humantex: Ah, so you do have the rpm-ostree package installed. Your machine is not using it. To fix this for your system now, please |
|
I had earlier tried to use both --v and --V to see if it was installed, and if so, what version... and got errors, so I assumed it wasn't installed. Then seeing a mention of trying the 'status' option, and seeing the red 'error' line in terminal when running it, I again assumed it wasn't installed. As you rightly corrected my wrong assumption, I found that it required a different command to have it spit out what I'd missed... Given that it really is installed, I'm wondering why, and if my DNS trap (Technitium DNS Server) might be using it as a required dependency for some odd reason. I'd like to spend some time looking into that before summarily removing it and causing issues somewhere else. This is the lone Fedora box I have on the network, and it started its life with a fresh install of Fedora 34, so I suppose it's possible that it's been a holdover from a previous OS version and never got pruned -but- if it's still needed, I might have an easier time removing cockpit-ostree after upcoming Cockpit updates than trying to find a workaround for other scenarios where rpm-ostree is needed. |
|
My apologies for the late reply... I just had a chance to get back to finally doing the Fedora 37 upgrade, and as part of that process, cockpit-ostree was somehow reinstalled. Cockpit was running fine - cockpit-ostree had previously been removed after another minor update had reinstalled it again - and the software updates pane was showing as-expected, and was functional for the latest and successful system update from earlier today. The Fedora 37' update required removal of some Xorg support files as it fully moved to Wayland, but I saw no other notifications about Cockpit specific updates or modifications that would be performed. I didn't expect to see them... I just wanted to state that they weren't displayed, nor were any other specifics for other packages noted during the upgrade. Cockpit components showing after all of today's updates/upgrades - and once again, removing cockpit-ostree...
|
|
@humantex: Apologies that it's still happening for you (somehow — it really shouldn't). Thanks for sharing that it does. Would you mind sharing a list of packages you have installed manually on your system? This command is supposed to show you everything you manually installed (however, it mistakenly also shows some installed packages you haven't specifically asked for): dnf repoquery --userinstalledIf you install comm -12 <(dnf leaves | cut -f2 -d" " | sort) <(sudo dnf history userinstalled | sort)Either way, using the simple or the convoluted command above, a list of packages you have installed on your system would help! Thanks! Your comment shows that we really need to have the fallback implemented for the really odd times where A fallback, of course, is also still important for when people like Cockpit and want everything it has to offer and install |
|
Thanks for the reply @garrett... I have no doubt that running the command isn't representative of what I've specifically chosen and installed myself. The list (below) also seems to include lots of packages that were part of various system updates and upgrades - either those run via cockpit's routine, or the desktop software app. The actual list is short. Other than Cockpit and several of its addins (which really aren't in use yet, i.e., Navigator and Podman containers, etc.), I installed WireShark, the FileZilla client, and Technitium DNS (https://technitium.com) over the top of a basic Fedora Workstation LiveCD install. Anything else would have been some minor system utilities and a few Gnome extensions to help setup the machine. If it matters, this is running on an HP EliteDesk 705 G3 Desktop Mini, and I think I started with Fedora WS 34. There were no ostree issues until somewhere late into Fedora 36, but I don't have a specific update point in time where it happened... other than the report date for #17858, above. From dnf leaves... |
|
I think I've found the initiator that is reinstalling cockpit-ostree, and it isn't Cockpit core... at least in how it's installed for my instance. From the expanded tree on the software installer screen inside Cockpit: The issue seems to stem from the cockpit-podman app getting updated and I'm assuming it's is also been the triggering package responsible for any/every previous occurrence where cockpit-ostree got reinstalled in error. From their project page (https://github.com/cockpit-project/cockpit-podman) it notes that it was based on Cockpit's Starter Kit, but I'm unsure whether that might mean the kit needs to include some new code or other guidance for 3rd party devs. I've posted a new issue in their queue (cockpit-project/cockpit-podman#1191), and referenced it to this issue. |
|
dnf wanted to install Short version: We have some plans how to fix this issue properly. @martinpitt is looking into it. |
These pave the way for bundling packages together with the webserver, and only showing them if the target system actually supports the corresponding functionality. For example, CoreOS does not have libvirt, so we can bundle but hide the "Machines" page on such systems. This also allows us to better handle ostree vs. packagekit -- even if a user installs cockpit-ostree on a standard RPM system, they should still see the packagekit version of "Software Updates" [1]. This is a more flexible approach than the old static `priority` field. Take inspiration from systemd unit files, which support e.g. `ConditionPathExists=`. The conditions should be declarative and cheap to evaluate. Support file exists/not exists tests for now, which should suffice for most use cases. The format and implementation is easy to extend in the future. Do not document this yet -- this is still considered experimental, and it also is not implemented in the C bridge yet. [1] cockpit-project/cockpit-ostree#295
We only want to show this page if Packagekit is installed, and the system is not an OSTree. First half of cockpit-project/cockpit-ostree#295
|
I started working on this in cockpit-project/cockpit#18291 . |
These pave the way for bundling packages together with the webserver, and only showing them if the target system actually supports the corresponding functionality. For example, CoreOS does not have libvirt, so we can bundle but hide the "Machines" page on such systems. This also allows us to better handle ostree vs. packagekit -- even if a user installs cockpit-ostree on a standard RPM system, they should still see the packagekit version of "Software Updates" [1]. This is a more flexible approach than the old static `priority` field. Take inspiration from systemd unit files, which support e.g. `ConditionPathExists=`. The conditions should be declarative and cheap to evaluate. Support file exists/not exists tests for now, which should suffice for most use cases. The format and implementation is easy to extend in the future. Comment out the documentation for now. This is still considered experimental, and it also is not implemented in the C bridge yet. Once we switch over, we can enable this. [1] cockpit-project/cockpit-ostree#295
We only want to show this page if Packagekit is installed, and the system is not an OSTree. The integration test will fail as soon as we make the Python bridge the default and drop the C bridge -- this will remind us of updating the test and docs, instead of letting it silently break (with a simple skip). First half of cockpit-project/cockpit-ostree#295
We only want to show this page if Packagekit is installed, and the system is not an OSTree. The integration test will fail as soon as we make the Python bridge the default and drop the C bridge -- this will remind us of updating the test and docs, instead of letting it silently break (with a simple skip). First half of cockpit-project/cockpit-ostree#295
These pave the way for bundling packages together with the webserver, and only showing them if the target system actually supports the corresponding functionality. For example, CoreOS does not have libvirt, so we can bundle but hide the "Machines" page on such systems. This also allows us to better handle ostree vs. packagekit -- even if a user installs cockpit-ostree on a standard RPM system, they should still see the packagekit version of "Software Updates" [1]. This is a more flexible approach than the old static `priority` field. Take inspiration from systemd unit files, which support e.g. `ConditionPathExists=`. The conditions should be declarative and cheap to evaluate. Support file exists/not exists tests for now, which should suffice for most use cases. The format and implementation is easy to extend in the future. Comment out the documentation for now. This is still considered experimental, and it also is not implemented in the C bridge yet. Once we switch over, we can enable this. [1] cockpit-project/cockpit-ostree#295
We only want to show this page if Packagekit is installed, and the system is not an OSTree. The integration test will fail as soon as we make the Python bridge the default and drop the C bridge -- this will remind us of updating the test and docs, instead of letting it silently break (with a simple skip). First half of cockpit-project/cockpit-ostree#295
These pave the way for bundling packages together with the webserver, and only showing them if the target system actually supports the corresponding functionality. For example, CoreOS does not have libvirt, so we can bundle but hide the "Machines" page on such systems. This also allows us to better handle ostree vs. packagekit -- even if a user installs cockpit-ostree on a standard RPM system, they should still see the packagekit version of "Software Updates" [1]. This is a more flexible approach than the old static `priority` field. Take inspiration from systemd unit files, which support e.g. `ConditionPathExists=`. The conditions should be declarative and cheap to evaluate. Support file exists/not exists tests for now, which should suffice for most use cases. The format and implementation is easy to extend in the future. Comment out the documentation for now. This is still considered experimental, and it also is not implemented in the C bridge yet. Once we switch over, we can enable this. [1] cockpit-project/cockpit-ostree#295
We only want to show this page if Packagekit is installed, and the system is not an OSTree. Update `TestUpdates.testNoPackageKit` to test the new behaviour: Previously, the page would just show "PackageKit is not installed", now it does not get shown at all. Test the old and new behaviour based on `$TEST_SCENARIO`, so that the test will fail as soon as we make the Python bridge the default and drop the C bridge. This will remind us of updating the test and docs, instead of letting it silently break (with a simple skip). First half of cockpit-project/cockpit-ostree#295
We only want to show this page if Packagekit is installed, and the system is not an OSTree. Update `TestUpdates.testNoPackageKit` to test the new behaviour: Previously, the page would just show "PackageKit is not installed", now it does not get shown at all. Test the old and new behaviour based on `$TEST_SCENARIO`, so that the test will fail as soon as we make the Python bridge the default and drop the C bridge. This will remind us of updating the test and docs, instead of letting it silently break (with a simple skip). First half of cockpit-project/cockpit-ostree#295
These pave the way for bundling packages together with the webserver, and only showing them if the target system actually supports the corresponding functionality. For example, CoreOS does not have libvirt, so we can bundle but hide the "Machines" page on such systems. This also allows us to better handle ostree vs. packagekit -- even if a user installs cockpit-ostree on a standard RPM system, they should still see the packagekit version of "Software Updates" [1]. This is a more flexible approach than the old static `priority` field. Take inspiration from systemd unit files, which support e.g. `ConditionPathExists=`. The conditions should be declarative and cheap to evaluate. Support file exists/not exists tests for now, which should suffice for most use cases. The format and implementation is easy to extend in the future. Comment out the documentation for now. This is still considered experimental, and it also is not implemented in the C bridge yet. Once we switch over, we can enable this. [1] cockpit-project/cockpit-ostree#295
We only want to show this page if Packagekit is installed, and the system is not an OSTree. Update `TestUpdates.testNoPackageKit` to test the new behaviour: Previously, the page would just show "PackageKit is not installed", now it does not get shown at all. Test the old and new behaviour based on `$TEST_SCENARIO`, so that the test will fail as soon as we make the Python bridge the default and drop the C bridge. This will remind us of updating the test and docs, instead of letting it silently break (with a simple skip). First half of cockpit-project/cockpit-ostree#295
Only show ostree if the system is actually *using* OSTree, by checking for /sysroot/ostree. It sometimes happens that users install cockpit-ostree on classic RPM systems, which "breaks" the "Software Updates" page. This is a better solution than the current static priorities of packagekit vs. ostree. However, this only works with the Python bridge [1]. Fixes cockpit-project#295 [1] cockpit-project/cockpit#18291
Only show ostree if the system is actually *using* OSTree, by checking for /sysroot/ostree. It sometimes happens that users install cockpit-ostree on classic RPM systems, which "breaks" the "Software Updates" page. This is a better solution than the current static priorities of packagekit vs. ostree. However, this only works with the Python bridge [1]. Fixes #295 [1] cockpit-project/cockpit#18291
We've been getting a lot of issues lately about people who have cockpit-ostree installed on a system that isn't based on rpm-ostree.
Whether someone installed
cockpit-*or a weird dependency chain might've pulled inostree(and thencockpit-ostree) on their system, we can improve the experience.This can range anywhere from:
rpm-ostreewith a message (perhaps even automatically with a small banner at the top with an info message, so there's some UI with the issue)We might even want to do this in steps, like immediately improve the error messaging and then work on a follow-up to handle it more gracefully.
A few recent issues within the past few days, as an example:
The text was updated successfully, but these errors were encountered: