Bug 1552910

Summary: Upgrading F27 > F28 is not possible because of shim
Product: [Fedora] Fedora Reporter: František Zatloukal <fzatlouk>
Component: shimAssignee: Matthew Garrett <mjg59>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 27CC: awilliam, fzatlouk, gmarr, klember, mjg59, pjones, rfarmer84, rharwood, robatino
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-03-16 22:53:59 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1469204    
Attachments:
Description Flags
dnf debugsolver none

Description František Zatloukal 2018-03-07 22:24:01 UTC
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.

Comment 1 Fedora Blocker Bugs Application 2018-03-08 10:01:07 UTC
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

Comment 2 František Zatloukal 2018-03-09 09:33:07 UTC
This issue is fixed in updates-testing. Package shim-x64.x86_64 is not available in F28 without updates-testing.

Comment 3 Adam Williamson 2018-03-10 01:24:38 UTC
+1 blocker. See also https://bugzilla.redhat.com/show_bug.cgi?id=1553807 , may have the same cause.

Comment 4 Fedora Update System 2018-03-10 01:30:05 UTC
shim-signed-13-4 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-9877df9844

Comment 5 Ryan Farmer 2018-03-12 00:27:33 UTC
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.

Comment 6 Peter Jones 2018-03-12 17:33:48 UTC
(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.

Comment 7 Geoffrey Marr 2018-03-12 20:07:53 UTC
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

Comment 8 Adam Williamson 2018-03-12 22:23:12 UTC
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?

Comment 9 Adam Williamson 2018-03-16 22:53:59 UTC
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.