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).
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.
@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.
@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.
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
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
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: [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: 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: 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: 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: 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: Upgrade failed with no such entry Apr 08 13:05:37 ipa001.test.openqa.fedoraproject.org ipactl: 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: ('IPA upgrade failed.', 1) Apr 08 13:05:37 ipa001.test.openqa.fedoraproject.org ipactl: 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: 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.