Two flakes on ubuntu-2004, unrelated. Good enough, these are hard to get to green with 3x runs, and no need to block this.

Thanks @KKoukiou ! Indeed https://www.patternfly.org/v4/components/number-input looks correct on Chromium, so that off-by-one baseline seems to be a problem in cockpit only.

Cockpit version: cockpit-238.2-1.el8.x86_64 OS: RHEL 8.4 Page: login

After logging in the page is blank and then it errors out. I've tried uninstalling with sudo dnf remove cockpit and reinstalling but nothing changed. I've also tried restarting the cockpit socket via sudo systemctl restart --now cockpit.socket but nothing changed. I've tried rebooting multiple times and changing things but nothing changed. This issue started appearing randomly and nothing particular was changed in the system before it started happening. Journalctl yields no logs to this issue. I'm connecting directly to the webserver itself and there is no firewall enabled between the hosts.

I've tried connecting from a virtual machine and it works fine. I'm using firefox 89.0.1 on the host that has the issue and 89.0.2 on the virtual machine. I've tried clearing data or using a private session but the issue seems to persist.

Below are screenshots/logs:

sudo journalctl -u cockput
-- Logs begin at Wed 2021-06-23 16:43:04 CEST, end at Wed 2021-06-23 16:57:25 CEST. --
-- No entries --

Steps to reproduce

1. Login to the webpage

It seems there is no actual error on the target machine (192.168.1.105), but that the browser fails to talk to the websocket. Do you perhaps have some extensions which may block this? Could you try this with a fresh profile? The least intrusive way is to close firefox, and run HOME=/tmp/f firefox.

That test did indeed work, thanks. Today it started working again in my main firefox profile (nothing was changed) but I have no clue on how it fixed itself.

FTR, I re-tested that with Chromium, and it's differently broken:

https://github.com/patternfly/patternfly/issues/4189

FTR, I re-tested that with Chromium, and it's differently broken:

Given how absurdly fast and easy testing this is now (with dist cache and such), I went through all the pages.

There was just one thing that caught my eye, the misaligned font size buttons:

but I confirm that this is already broken on master (possibly with the most recent firefox?), so this PR is fine.

Good catch - it's broken on PF docs as well - I will report it.

Given how absurdly fast and easy testing this is now (with dist cache and such), I went through all the pages.

There was just one thing that caught my eye, the misaligned font size buttons:

but I confirm that this is already broken on master (possibly with the most recent firefox?), so this PR is fine.

/packit test

Logs page on master:

Logs page on this PR looks exactly the same to me:

Thanks!

Lots of networking related test flakes, as this triggers the "affected must succeed 3 times" logic. One round of retries.

Totally "throw it over the fence" drive-by.

I think we can (and should) do better.

Installing the test suite's cockpit.pam.insecure is really bad advice -- it disrespects the distribution's standard policy, and is not even going to work on systems without pam_selinux.

Fixes #15981

Cockpit version: compiled from the main branch pulled on June 14, 2021. OS: Mariner Page: Login page

I try to login as any user, including root, but cockpit complains "Authentication failed: internal-error: Module is unknown"

Steps to reproduce:

1. I compiled from the main branch, following the instructions in HACKING.md
2. make install
3. sudo cp src/bridge/cockpit.pam.insecure /etc/pam.d/cockpit
4. systemctl start cockpit
5. On my other device, visit https://<ip-address>:9090, log in
6. See the error

In the logs I only see the following messages. This is after I followed the instructions in HACKING.md to enable more debug log output from cockpit-bridge, cockpit-protocol, and cockpit-ws.

Jun 22 15:10:29 scz3 cockpit-session[2666]: pam_unix(cockpit:session): session opened for user root by (uid=0)
Jun 22 15:10:29 scz3 cockpit-ws[2653]: cockpit-session: couldn't open session: root: Module is unknown

Could anyone direct me to how further debug this? My next step is to look into the code from cockpit-session to see what's going on, but any extra help would be appreciated :)

@allisonkarlitskaya : No-change force push to not unnecessarily litter our test statistics with this new selinux thing.

Very considerate.

I'm experiencing the same issue on Fedora 33 (Server Edition) and Safari, Firefox, Chrome on macOS 11.X and 12db1 as well as Safari on iPad (iOS 14.X and 15db1)

https://logs.cockpit-project.org/logs/pull-15993-20210624-133356-77d55ed7-fedora-34/log.html#75 shows what we'd expect to see:

DevTools listening on ws://127.0.0.1:10181/devtools/browser/7106732b-27e2-4c91-a6a5-e42a332fb064
[0624/140610.482222:ERROR:gpu_init.cc(426)] Passthrough is not supported, GL is egl
CDP: {"source":"security","level":"error","text":"Refused to apply inline style because it violates the following Content Security Policy directive: \"default-src 'self' http://127.0.0.2:9191\". Either the 'unsafe-inline' keyword, a hash ('sha256-BMIkowAqVEI88ibUJ1NtYB8ByZOuS4MTi73eGoFo2+Q='), or a nonce ('nonce-...') is required to enable inline execution. Note also that 'style-src' was not explicitly set, so 'default-src' is used as a fallback.\n","timestamp":1624543572443.991,"url":"http://127.0.0.2:9191/cockpit/@localhost/shell/index.js","lineNumber":30,"stackTrace":{"callFrames":[{"functionName":"ke","scriptId":"21","url":"http://127.0.0.2:9191/cockpit/@localhost/shell/index.js","lineNumber":30,"columnNumber":35691},{"functionName":"Ze","scriptId":"21","url":"http://127.0.0.2:9191/cockpit/@localhost/shell/index.js","lineNumber":30,"columnNumber":44728},{"functionName":"append","scriptId":"21","url":"http://127.0.0.2:9191/cockpit/@localhost/shell/index.js","lineNumber":30,"columnNumber":46409},{"functionName":"D","scriptId":"21","url":"http://127.0.0.2:9191/cockpit/@localhost/shell/index.js","lineNumber":63,"columnNumber":24932},{"functionName":"","scriptId":"21","url":"http://127.0.0.2:9191/cockpit/@localhost/shell/index.js","lineNumber":63,"columnNumber":34130},{"functionName":"","scriptId":"21","url":"http://127.0.0.2:9191/cockpit/@localhost/shell/index.js","lineNumber":68,"columnNumber":160544},{"functionName":"","scriptId":"21","url":"http://127.0.0.2:9191/cockpit/@localhost/shell/index.js","lineNumber":68,"columnNumber":160548}]}}
> error: Modal: Specify at least one of: title, aria-label, aria-labelledby.
> warning: grep: /sys/class/dmi/id/power/autosuspend_delay_ms: Input/output error

> warning: loading available updates failed: {"detail":"cannot update repo 'fedora': Cannot prepare internal mirrorlist: Curl error (6): Couldn't resolve host name for https://mirrors.fedoraproject.org/metalink?repo=fedora-34&arch=x86_64 [Could not resolve host: mirrors.fedoraproject.org]; Last error: Curl error (6): Couldn't resolve host name for https://mirrors.fedoraproject.org/metalink?repo=fedora-34&arch=x86_64 [Could not resolve host: mirrors.fedoraproject.org]","code":64}
Submodule 'test/reference' (https://github.com/cockpit-project/pixel-test-reference) registered for path 'test/reference'
Cloning into '/work/bots/make-checkout-workdir/test/reference'...
Submodule path 'test/reference': checked out '3384f225f880fc19594bdb17ba09bfb345e72ec0'
> warning: transport closed: disconnected
Failed to get session path: No session '143' known
# Result testAddServices (__main__.TestFirewall) succeeded
# 1 TEST PASSED [43s on 3-ci-srv-05]

@allisonkarlitskaya : No-change force push to not unnecessarily litter our test statistics with this new selinux thing.

@KKoukiou : I just saw that in another PR, and reported that https://bugzilla.redhat.com/show_bug.cgi?id=1975811 , and sent https://github.com/cockpit-project/bots/pull/2142 to naughty it. @allisonkarlitskaya : So apparently it's not so rare after all :grin:

"oops! it happened again!"

https://logs.cockpit-project.org/logs/pull-15987-20210624-125257-823fc21a-fedora-34/log.html#101

I sent https://github.com/cockpit-project/bots/pull/2142 for the unrelated new selinux violation

Makes sense to me.

I like this.