Erf, this package clearly needs to be in critpath since it can break login and su :( Not being in critpath is why openQA didn't test it; it would have caught the bug immediately.

I'll add it to critpath in comps and whitelist it for openQA testing, since critpath generation from comps is still broken AFAIK :/

Those logs were captured right after the clients tried and failed to enrol, BTW.

Logs from the server end of a failed test can be found here now - there's a tarball of /var/log and also, which turned out to be useful in previous debugging so I still have the tests set to upload it.

Yell if there's anything else needed from the server end to figure this out, and I can probably make it happen.

@abbra of course it's possible - in fact I'd say likely - that the actual bug is on the server end. The client may be (probably is) doing the right thing and sending the DNS query to the FreeIPA server, but not getting the expected response. It's harder for me in openQA to get logs out of the server when it's the client that fails, though, because of how openQA behaves (when the client test fails it just kills the server test, without sending it through the post-fail hook stage where we usually upload logs and stuff). I'll try and hack it up, though.

@thaller here's all the output from those commands (smooshed into one text file but you should be able to tell what's from what):

       LLMNR setting: resolve             
MulticastDNS setting: no                  
  DNSOverTLS setting: no                  
      DNSSEC setting: no                  
    DNSSEC supported: no                  
Fallback DNS Servers:             

Link 2 (ens4)
      Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
DefaultRoute setting: yes                      
       LLMNR setting: yes                      
MulticastDNS setting: no                       
  DNSOverTLS setting: no                       
      DNSSEC setting: no                       
    DNSSEC supported: no                       
  Current DNS Server:             
         DNS Servers:             
ens4    ethernet  connected  Wired connection 1 
lo      loopback  unmanaged  --                 
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: ens4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 52:54:00:12:00:ff brd ff:ff:ff:ff:ff:ff
    altname enp0s4
    inet brd scope global noprefixroute ens4
       valid_lft forever preferred_lft forever
    inet6 fe80::3545:4731:61f3:61e9/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
default via dev ens4 proto static metric 100 dev ens4 proto kernel scope link src metric 100

Oh, for Rawhide, I can't tell if it has this problem because Rawhide is running into a bug in FreeIPA server deployment, which means we never reach client enrolment.

@thaller will do that. sorry i'm a bit slow, i'm technically off work till January. :)

So briefly the situation in openQA testing is: we have a test that deploys as a FreeIPA server. It sets itself up for static networking with IP and hostname ipa001.domain.local using the commands you can see here. It then sets up some repo stuff for testing the update, reboots, and runs the commands from this test code to do the actual deployment. It's all basically just running commands at a console, anywhere it says assert_script_run, it's running a command and expecting it to succeed. All those commands apparently succeed and we reach the comment # we're ready for children to enrol, now, where we wait on several client tests to enrol against us. All of those fail. The one I previously linked is the simplest one. It sets its DNS server to be - the FreeeIPA server's IP, remember - then runs realm join --user=admin ipa001.domain.local, as you can see here, and that fails with "realm: No such realm found".

In tests of other F33 updates this same test is passing.

In openQA testing, this seems to break FreeIPA client enrolment. I'm technically off for the month but still checking update test results, so I haven't looked into this in detail, will give it a quick look if time allows. Tagging some FreeIPA folks: @abbra , @cipherboy , @rcritten

Leaving negative feedback for now, if this turns out to be an artifact of how we run the tests or something, will change.

@ctubbsii apparently you need permissions on all packages in an update to do stuff to it, so when I edited it to add the dependency, you could no longer manage it. I think we really need a rethink of the Bodhi permissions model, but it's hard to think about what the edges should be. Anyway, I'll push it for now.

I was hoping to hear back from @rdieter , but if we don't soon, we can do that, yeah.

Can folks who seem to be affected by issues with update notification try downgrading fwupd to 1.4.6? See .

@rdieter the "immediate movement" has been happening in . We did some more digging and it seems much less clear that issues with update notification have anything to do with this update, see the tests I ran tonight. Can you check that things reliably work for you with 1.2.2-1 and reliably don't work with 1.2.2-2? I can't say that's the case for me, it seems to be less obvious than that.

Is not installable without a bump to secretstorage. See .

BZ#1873845 python-keyring-21.5.0 is available

Is not installable without a bump to secretstorage. See .

BZ#1873845 python-keyring-21.5.0 is available
BZ#1873845 python-keyring-21.5.0 is available

This update has been unpushed.

openQA tests on Rawhide suggest this may have broken update check on first login, so I don't think we should push it stable till that is investigated.

It works fine on my test instance, and on lab. It's already been running on lab for several days.

The "unable to serialize" error looks like it comes from this change, but that doesn't seem like it's intended to make anything fatal that wasn't previously fatal. The later errors that seem to be about missing configuration seem more like the problem, but not entirely sure what's going on there.


Per @kalev and @mclasen , depending on mozilla-openh264 is wrong. Recommending it would be OK, but not requiring it.