Open nicrame opened 2 years ago
@nicrame Hi. This cannot be actually fixed on our side now. The error you see is caused by an rpm that is going to be installed on the system during the upgrade - to be clear, the package is signed by depracated algorithms (SHA1). We cannot check the signature of the package before it is downloaded. The download of packages is happening AFTER reporting phase, which means after the preupgrade
ends, as the download of packages could be considerably time-consuming for people. We are thinking about a way to cover these later phases in future as well by preupgrade
sub-command (possibly with some special option?). But it will not happen in a close future.
To better understand the problem, see:
Oh, thank You for explanation. Maybe when there is such problem, it would be nice to make information below STDERR to be more simple and understandable for human forms, or give some clue what is happening, because to say the truth, it was completely no information for me at all what is wrong, why, and how to resolve this.
You are right. We plan to cover it in future by a better error msg. Regarding the missing time we considered this as minor issue in the past as system is not harmed and we expected that when people deliver some rpms with RSA/SHA1 signature to be installed during the upgrade, such a packages will be already present on the system, which we covered by inhibitor with proper instructions. Hopefully we will cover better err msg for the next release.
@nicrame just for the curiosity. Have you had some packages with RSA/SHA1 signatures installed on the system before already or packages with the problematic signatures have been discovered just in custom repos related to RHEL 9?
@nicrame just for the curiosity. Have you had some packages with RSA/SHA1 signatures installed on the system before already or packages with the problematic signatures have been discovered just in custom repos related to RHEL 9?
They were already there. Some (few) packages were installed from additional repo that i used when i played with "ovirt" install. I have removed ovirt and just used kvm, but some repo was still there, and it was interesting because few libs and python3-something packages were in newer versions from that ovirt repo that i had. My solution was to downgrade those packages.
I just do the trick with:
rpm -q --nosignature --querybynumber XXX
dnf --showduplicates list python3-cairo
dnf downgrade python3-cairo-1.16.3-6.el8
After few times i just "dnf list installed | grep @ovirt-4.4" and downgrade every packages, then removed this repo, and then update did go fine, and i've got updated OS!
@nicrame Just checked the logs seeing that you already have present problematic packages on the system as mentioned in the report file
Risk Factor: high
Title: Detected RPMs with RSA/SHA1 signature
Summary: Digital signatures using SHA-1 hash algorithm are no longer considered secure and are not allowed to be used on RHEL 9 systems by default. This causes issues when using DNF/RPM to handle packages with RSA/SHA1 signatures as the signature cannot be checked with the default cryptographic policy. Any such packages cannot be installed, removed, or replaced unless the signature check is disabled in dnf/rpm or SHA-1 is enabled using non-default crypto-policies. For more information see the following documents:
....
But what is important, this report is not inhibitor. So I assume you have set already the LEGACY
system wide crypto policies, correct? (I would check that but in the attached files I can access only text files; binary files return 502 gateway err). If so, the error is weird as you should be able to upgrade then. We have been using it as a workaround in the past for couple of months and it worked pretty well, so I am confused why it's not working in your case now. But I've seen similar problem on a cloud machine yesterday. I already planed to investigate that later this / the other week. So if we discover what's wrong, we will let you know here. From our POV, when you set the LEGACY crypto policies (reboot expected after that) you should be able to upgrade even with such a packages.
it was interesting because few libs and python3-something packages were in newer versions from that ovirt repo that i had
If the external repo is hosted in Fedora Copr, this SHA mixup is expected. We used the default (SHA1) algorithm for signing packages in Copr and switched to SHA256 recently.
Actual behavior I'm trying to upgrade RHEL 8.6 to 9. While preupgrade goes fine, the real upgrade fail with error below.
To Reproduce Run leapp upgrade --debug --target 9.0 Result:
Expected behavior Edited(@pirat89): ~Upgrade OS.~ Update the error msg to make clear what's exactly the problem and what people could do.
System information (please complete the following information): Red Hat Enterprise Linux 8.6 (Ootpa)
# uname -a
# rpm -qa "*leapp*"
(or shorthashes of commits in case of manual installation):Attach (or provide link to) log files if applicable (optional - may contain confidential information): https://love.itos.pl/s/y8TSYnY8jiggz8X
Additional context I already tried rebuilding rpm db with "rpm --rebuilddb" and "dcrpm" but it looks fine.