+++ This bug was initially created as a clone of Bug #1911766 +++ Description of problem: Cockpit web interface is broken after upgrade to Fedora 33. For example, - on "Overview" page, "Health" widget shows "Loading available updates failed" messages. - on "Dashboard", seemingly randomly, some servers have OS name displayed, some do not (blank OS name) See the attached files for the browser messages and Systemd journal. It seems that the first error is The resource from “https://west.roof.aimk.com:9094/cockpit/$81f8626bf888771cfee7262a61bde7c4ea29d62402a338aaf0c40bcc5a908f48/shell/nav.css” was blocked due to MIME type (“text/html”) mismatch (X-Content-Type-Options: nosniff). west.roof.aimk.com:9094 Version-Release number of selected component (if applicable): Fedora 33 cockpit-session-recording-6-1.fc33.noarch cockpit-dashboard-233.1-1.fc33.noarch cockpit-bridge-234-1.fc33.x86_64 cockpit-system-234-1.fc33.noarch cockpit-networkmanager-234-1.fc33.noarch cockpit-selinux-234-1.fc33.noarch cockpit-storaged-234-1.fc33.noarch cockpit-packagekit-234-1.fc33.noarch cockpit-pcp-234-1.fc33.x86_64 cockpit-ws-234-1.fc33.x86_64 cockpit-234-1.fc33.x86_64 cockpit-composer-27-1.fc33.noarch cockpit-kdump-234-1.fc33.noarch cockpit-machines-234-1.fc33.noarch cockpit-podman-26-1.fc33.noarch cockpit-sosreport-234-1.fc33.noarch cockpit-doc-234-1.fc33.noarch firefox-84.0.1-2.fc33.x86_64 chromium-87.0.4280.88-1.fc33.x86_64 How reproducible: Steps to Reproduce: 1. Create new Firefox profile 2. Goto Cockpit URL and login Actual results: Ooops! message at the top. "Loading available updates failed" message in "Health" widget. Expected results: No Ooops! message. Appropriate "Health" content. Additional info: Cockpit worked in Fedora 32 and stopped to work after the machine was upgraded to Fedora 33. In Chromium browser the error message is Refused to apply style from 'https://west.roof.aimk.com:9094/cockpit/$81f8626bf888771cfee7262a61bde7c4ea29d62402a338aaf0c40bcc5a908f48/shell/nav.css' because its MIME type ('text/html') is not a supported stylesheet MIME type, and strict MIME checking is enabled. Systemd journal has multiple messages like below Dec 30 21:42:44 west.roof.aimk.com cockpit-tls[73439]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received. Dec 30 21:43:15 west.roof.aimk.com cockpit-ws[73464]: request timed out, closing --- Additional comment from Alexander Murashkin on 2020-12-31 03:51:10 UTC --- --- Additional comment from Alexander Murashkin on 2020-12-31 03:51:33 UTC --- --- Additional comment from Martin Pitt on 2020-12-31 15:27:59 UTC --- There are several unrelated issues here. The "nav.css MIME type" happens for me as well. We should fix that indeed, but it's mostly cosmetical, and definitively not the reason for the "oops". That "Oops" is certainly the most severe problem here. Unfortunately the logs are not helpful here. An "Oops" message should usually be accompanied by an error/traceback in the browser console, but there is none. The *.map files messages should only be debug-level (I don't even seem them in Fedora 33 with Firefox), the only weird thing is the "WebExtension context not found! ExtensionParent.jsm:1075" -- I don't get that, and I have no idea what it could mean. Could you perhaps try this with a temporary user or with `HOME=/tmp/f firefox` and see if you get the same in a Firefox without 3rd party extensions? > "Loading available updates failed" message in "Health" widget. The journal unfortunately only shows the bits from cockpit.service, but this usually means that PackageKit is not working for some reason. Can you please attach the full journal from the login page up to when the cockpit session is loaded? Does `pkcon get-updates` work for you? > on "Dashboard", seemingly randomly, some servers have OS name displayed, some do not (blank OS name) > cockpit-dashboard-233.1-1.fc33.noarch Not quite "random", it depends on which servers it can connect to with SSH, and which need further authentication. But anyway, cockpit-dashboard got dropped in favor of the shell's host switcher. The cockpit-bridge package has "Obsoletes: cockpit-dashboard", but apparently dnf did not clean it up on upgrades.. I'll clone this bug for that issue. Let's devote this bug for the "Oops". Thanks!
Matej, is that something you can look into, please? Apparently "Obsoletes" is not strong enough, maybe it needs "Conflicts:" or whatnot?
The new package needs to also provide the name of the old for a clean upgrade path. See also: https://docs.fedoraproject.org/en-US/packaging-guidelines/#renaming-or-replacing-existing-packages That conflict is present as well at my machine.
"If a package supersedes/replaces an existing package without being a sufficiently compatible replacement as defined above, use only the Obsoletes: line from the above example." We want to go this way. The current spec is broken though, see https://github.com/cockpit-project/cockpit/pull/15244 > That conflict is present as well at my machine. What conflict is that?
(In reply to Matej Marušák from comment #3) > "If a package supersedes/replaces an existing package without being a > sufficiently compatible replacement as defined above, use only the > Obsoletes: line from the above example." > We want to go this way. The current spec is broken though, see > https://github.com/cockpit-project/cockpit/pull/15244 > > > That conflict is present as well at my machine. > > What conflict is that? When doing a dnf update: Problem 1: package cockpit-bridge-235-1.fc32.x86_64 conflicts with cockpit-dashboard < 233 provided by cockpit-dashboard-232-1.fc32.noarch - cannot install the best update candidate for package cockpit-bridge-232-1.fc32.x86_64 - problem with installed package cockpit-dashboard-232-1.fc32.noarch Problem 2: package cockpit-system-235-1.fc32.noarch requires cockpit-bridge >= 235-1.fc32, but none of the providers can be installed - package cockpit-bridge-235-1.fc32.x86_64 conflicts with cockpit-dashboard < 233 provided by cockpit-dashboard-232-1.fc32.noarch - cannot install the best update candidate for package cockpit-system-232-1.fc32.noarch - cannot install the best update candidate for package cockpit-dashboard-232-1.fc32.noarch This is a packaging issue. I've worked around it by removing cockpit-dashboard and then doing a dnf update. If I try again to install cockpit-dashboard (which should give me basically cockpit-bridge since the functionality was moved there), I get: Installing: cockpit-dashboard noarch 216-1.fc32 fedora 200 k Downgrading: cockpit-bridge x86_64 216-1.fc32 fedora 602 k cockpit-system noarch 216-1.fc32 fedora 1.8 M
(In reply to Charalampos Stratakis from comment #2) > The new package needs to also provide the name of the old for a clean > upgrade path. See also: > https://docs.fedoraproject.org/en-US/packaging-guidelines/#renaming-or- > replacing-existing-packages > > That conflict is present as well at my machine. Although indeed that could be the missing obsoletes as indicated by the upstream PR.
> Apparently "Obsoletes" is not strong enough Obsoletes is very strong. This indicates a problem with it. What obsoletes what?
Apparently, nothing: $ repoquery --repo={fedora,updates{,-testing}} --releasever 33 --latest=1 --whatobsoletes cockpit-dashboard (empty result)
> Apparently, nothing: Yeah, being fixed in https://github.com/cockpit-project/cockpit/pull/15244 . We had it in a "if rhel" branch.
FEDORA-2021-0ad93a9b1e has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-0ad93a9b1e
FEDORA-2021-0ad93a9b1e has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-0ad93a9b1e` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-0ad93a9b1e See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-0ad93a9b1e has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.