Created attachment 1405624 [details] dnf debugsolver Description of problem: Upgrading Fedora 27 to Fedora 28 is currently not possible because of broken shim dependencies. Version-Release number of selected component (if applicable): dnf-2.7.5-2.fc27.noarch python3-dnf-plugin-system-upgrade-2.0.5-1.fc27.noarch PackageKit-1.1.9-0.fc27.kalev_copr0.x86_64 Actual results: Last metadata expiration check: 0:00:00 ago on Wed 07 Mar 2018 11:04:20 PM CET. --> Starting dependency resolution --> Finished dependency resolution Error: Problem: package fwupdate-libs-10-6.fc28.x86_64 requires shim, but none of the providers can be installed - problem with installed package fwupdate-libs-10-1.fc27.x86_64 - shim-x64-13-0.7.x86_64 does not belong to a distupgrade repository - fwupdate-libs-10-1.fc27.x86_64 does not belong to a distupgrade repository Expected results: Upgradepath should work. Additional info: dnf debugsolver attached. The system was updated to the latest updates-testing.
Proposed as a Blocker for 28-beta by Fedora user frantisekz using the blocker tracking app because: "The upgraded system must include all packages that would be present on the system after a default installation from install media, plus any packages the user previously had (minus any obsolete content)."[1] After upgrading with current dependency resolution outcome, gnome-software and fwupd will be missing. [1] https://fedoraproject.org/wiki/Fedora_28_Beta_Release_Criteria#Upgrade_requirements
This issue is fixed in updates-testing. Package shim-x64.x86_64 is not available in F28 without updates-testing.
+1 blocker. See also https://bugzilla.redhat.com/show_bug.cgi?id=1553807 , may have the same cause.
shim-signed-13-4 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-9877df9844
Possibly the cause of the failure to boot from the 3-10 nightly image? With Secure Boot turned on, my machine stops and says it is unable to load the operating system due to security policy in effect on this system.
(In reply to Ryan Farmer from comment #5) > Possibly the cause of the failure to boot from the 3-10 nightly image? > > With Secure Boot turned on, my machine stops and says it is unable to load > the operating system due to security policy in effect on this system. That's caused by the 13-1 package.
Discussed during the 2018-03-12 blocker review meeting: [1] The decision was made to delay the classification of this as a bug as it seems this has been fixed; we will follow up with pjones to see if there are any other problems and make a decision on this next week. [1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2018-03-12/f28-blocker-review.2018-03-12-16.01.txt
So, here's the basic state of this. Fedora-28-20180302.n.0 had these shim packages: shim-ia32-13-0.3.x86_64.rpm shim-unsigned-0.8-1.fc22.x86_64.rpm shim-unsigned-ia32-13-0.2.fc28.x86_64.rpm shim-unsigned-x64-13-0.2.fc28.x86_64.rpm shim-x64-13-0.3.x86_64.rpm Notably, none of those packages provides 'shim'. Fedora-28-20180309.n.0 had these shim packages: shim-ia32-13-1.x86_64.rpm shim-unsigned-0.8-1.fc22.x86_64.rpm shim-unsigned-ia32-13-0.2.fc28.x86_64.rpm shim-unsigned-x64-13-0.2.fc28.x86_64.rpm shim-x64-13-1.x86_64.rpm So, the same shim-unsigned packages, but different shim-{ia32,x64} packages. shim-x86-13-1.x86_64 *does* provide shim: [adamw@adam tmp]$ rpm -qp --provides shim-x64-13-1.x86_64.rpm bundled(openssl) = 1.0.2j shim = 13-1 shim-signed = 13-1 shim-signed-x64 = 13-1 shim-x64 = 13-1 shim-x64(x86-64) = 13-1 It seems https://koji.fedoraproject.org/koji/buildinfo?buildID=1051707 (shim-signed-13-1) was not tagged f28 on 2018-03-02, but *was* tagged f28 by 2018-03-09. That has mostly resolved the issues here. GNOME Software is present on Workstation images in the 20180309.n.0 compose (and subsequent composes), so it looks like the dependency issue is indeed resolved. So far as we know, that resolves the blocker issues. However, I would like to ask pjones for the record: * Is there any important reason we should have shim-signed-13-4 in Beta rather than shim-signed-13-1? * Should the source package 'shim' be retired and blocked, which would result in the ancient shim-unsigned-0.8-1.fc22.x86_64.rpm package no longer appearing in the compose? Or is it still required for some reason?
So this specific issue is resolved by 13-1 being tagged, but it turns out there *is* a reason why 13-1 is bad: https://bugzilla.redhat.com/show_bug.cgi?id=1555391 it doesn't have the right signatures or something - it doesn't actually work for Secure Boot. pjones says 13-0.7 or 13-4 should work. I'm suggesting we should go with 13-4 to avoid the possibility of 13-1 stomping on 13-0.7. Anyway, follow-up in that other bug. Let's close this specific one.