Comments

1355 Comments
karma
var/log/dnf.log: Problem: cannot install the best update candidate for package firefox-87.0-2.fc32.x86_64
var/log/dnf.log:  - nothing provides nss >= 3.63 needed by firefox-88.0-1.fc32.x86_64

There is no nss 3.63 update for F32 AFAICT. If it's really needed, it needs to be built for F32 and added to this update, ALONG WITH any required changes to other packages (e.g. nspr).

BZ#1950997 Firefox 88.0 available

Can confirm the Dell developer edition issue is fixed, this version boots fine.

BZ#1938630 include new bootloaders on Fedora 34 install media so UEFI Secure Boot enabled systems can boot from them

We explicitly allow and support upgrades across two release versions, for people who don't want to upgrade every six months. So F33 direct to F35 upgrade is a supported/release blocking operation. There will be people out there who expect to be able to upgrade from F33 to F35.

One thing I note about the scriptlet, BTW, is it doesn't check whether the symlink target actually exists. If I make /etc/pam.d/fingerprint-auth a dangling symlink, I do get an error during update:

    Running scriptlet: pam-1.5.1-5.fc34.x86_64
/usr/bin/grep: /etc/pam.d/fingerprint-auth: No such file or directory

I don't think it's a big issue, though.

BTW, can we have this change on Rawhide too?

karma

openQA tests look good.

@clnetbox the hang you hit may have been this one, if you have ibus packages installed: https://bugzilla.redhat.com/show_bug.cgi?id=1948197

karma

Fix confirmed here also.

BZ#1929643 logout after switch returns the user to console instead of sddm

Since the update clearly doesn't really fully fix the bug, unmarked it.

@wtaymans please note above feedback. I believe we know of similar issues upgrading from previous releases.

Can we please avoid this kind of thing in future? It's really really bad if a core thing like pipewire flat out dies trying to read its own config file from a previous version. This just should not be necessary with proper planning and design.

openQA results look good.

karma

openQA results look good.

BZ#1948034 Server deployment fails on current F34 and Rawhide ("All nameservers failed to answer the query...")

This looks right AFAICS. updates-testing is disabled, and the versions are correct.

BZ#1947704 Do final F34 fedora-release and fedora-repos builds

@decathorpe note that, AIUI, the fact we're hitting this means SB was effectively not fully functional before - this seems to be how developer edition XPS systems ship (I didn't know about it either). SB is enabled in the firmware, but validation is disabled at the mok level, or something. We have to run a magic command to actually have SB working.

It is a bug that boot breaks in this config, though, and the fix is coming.

This update has been unpushed.

I filed https://github.com/rhboot/shim/pull/362 in case I'm right about the problem and the fix.

So poking through the code a bit I suspect https://github.com/rhboot/shim/commit/65be3503 , a bit, because it's a commit between 15 and 15.4 that touches user_insecure_mode. Just on the face of it - I may be misunderstanding - it looks like it adds a function (import_one_mok_state) that's intended to be called one-by-one on a bunch of variables and import them one at a time, but it unconditionally does user_insecure_mode = 0; at the start, whether it's reading the variable that might set it to 1 or not. So even if it's momentarily set to 1 when the relevant variable (MokSBState) is read, won't it then get set straight back to 0 by reading the next variable? Note user_insecure_mode is declared extern in shim.h, which AIUI makes it something like a global variable, right?

Again, I may be missing something, but if so, the same may apply to ignore_db (set by MokDBState). It also is declared as extern and set unconditionally at the start of import_one_mok_state.

I'm going to test reverting that commit if possible...

openQA failure seems to be a real one: it's the test that deploys a server and client as F33 and upgrades them to F34 to check that works OK. The server is showing up with ipa.service failed after the upgrade runs. Journal shows ipa-server-upgrade failed, with a ton of errors to do with things not existing, basically. The earliest message I see that's obviously an error is:

Apr 08 13:05:31 ipa001.test.openqa.fedoraproject.org ns-slapd[924]: [08/Apr/2021:16:05:31.102189684 -0400] - ERR - slapi_entry_schema_check_ext - Entry "cn=ng,cn=alt,dc=test,dc=openqa,dc=fedoraproject,dc=org" required attribute "objectclass" missing

and the last few are:

Apr 08 13:05:37 ipa001.test.openqa.fedoraproject.org ipactl[678]: Parent DN of cn=ca,cn=topology,cn=ipa,cn=etc,dc=test,dc=openqa,dc=fedoraproject,dc=org may not exist, cannot create the entry
Apr 08 13:05:37 ipa001.test.openqa.fedoraproject.org ipactl[678]: default_range: No local ID range and no admins group found. Cannot create default ID range
Apr 08 13:05:37 ipa001.test.openqa.fedoraproject.org ipactl[678]: update_idrange_type: cannot retrieve list of ranges with no type set: no such entry
Apr 08 13:05:37 ipa001.test.openqa.fedoraproject.org ipactl[678]: Error retrieving: cn=ipaConfig,cn=etc,dc=test,dc=openqa,dc=fedoraproject,dc=org
Apr 08 13:05:37 ipa001.test.openqa.fedoraproject.org ipactl[678]: Upgrade failed with no such entry
Apr 08 13:05:37 ipa001.test.openqa.fedoraproject.org ipactl[678]: IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run command ipa-server-upgrade manually.
Apr 08 13:05:37 ipa001.test.openqa.fedoraproject.org ipactl[678]: ('IPA upgrade failed.', 1)
Apr 08 13:05:37 ipa001.test.openqa.fedoraproject.org ipactl[678]: The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for more information
Apr 08 13:05:37 ipa001.test.openqa.fedoraproject.org ipactl[678]: See the upgrade log for more details and/or run /usr/sbin/ipa-server-upgrade again

Between that are a ton of others. Grab https://openqa.fedoraproject.org/tests/849781/file/role_deploy_domain_controller_check-var_log.tar.gz to see for yourself.

Confirmed that after downgrading to shim-x86-15-8 I can boot with SB enabled.

I noticed that when doing so, something (shim?) briefly shows "Booting in insecure mode", though after boot, mokutil --sb-state shows SecureBoot enabled. Searching around for references on that, I found https://bugzilla.redhat.com/show_bug.cgi?id=1531961 , which claims that running mokutil --enable-validation would 'fix' it, though I can't find any explanation as to why. I ran that anyway, it asked for a password, I gave it one, it apparently completed OK.

System still does not boot with SB enabled and this shim, though. I don't know if it made the "Booting in insecure mode" message when booting with older shim go away yet (haven't checked, it's a lot of rebooting).

After updating my XPS 13 (9360) to current F34, with this shim, I cannot boot with Secure Boot enabled. The screen briefly shows

Bootloader has not verified loaded image.
System is compromised.  halting.

and then shuts down. This happens with any kernel I try to boot. Boot with SB disabled works fine. Boot with SB enabled was working fine until I updated. fwupdmgr update does not show any available firmware updates.