Description of problem: After a fresh install of Mageia 9 on a clean disk update fails with bad sha256 payload Version-Release number of selected component (if applicable): How reproducible: Starting January 1, 2016 it is always reproducible after a clean install of Mageia 9. Steps to Reproduce: 1. Install Mageia 9 on a clean drive. 2. At the stage it asks to run update select update and next. Wait and the following is returned. "1 installation transactions failed There was a problem during the installation: package glibc-6:2.36-57.mga9.x86_64 does not verify: Payload SHA256 ALT digest: BAD (Expected 16625f6c4d8e48946c4dd4623a1a97b787f489e152d343790e0631630271cd5e != d02ab2b19f15183b923784e5ffd7903d77829cef0bcf0971a74a42aa181fe068) No xml info for medium "Core Updates", unable to return any result for package meta-task-9-4.mga9.noarch "
Repeat the clean install and at the step were it asks to run updates select no. Reboot. After you login start Konsole or similar. At the command line run sudo urpmi --update-all The following is returned: " To satisfy dependencies, the following packages are going to be installed: Package Version Release Arch (medium "Core Updates") glibc 2.36 57.mga9 x86_64 lib64rpm9 4.18.2 1.mga9 x86_64 meta-task 9 4.mga9 noarch perl 5.36.0 1.2.mga9 x86_64 perl-base 5.36.0 1.2.mga9 x86_64 perl-doc 5.36.0 1.2.mga9 noarch python3-rpm 4.18.2 1.mga9 x86_64 rpm 4.18.2 1.mga9 x86_64 rpm-plugin-syslog 4.18.2 1.mga9 x86_64 rpm-plugin-systemd-inhibit 4.18.2 1.mga9 x86_64 8.4KB of additional disk space will be used. 23MB of packages will be retrieved. Proceed with the installation of the 10 packages? (Y/n) y installing rpm-4.18.2-1.mga9.x86_64.rpm meta-task-9-4.mga9.noarch.rpm perl-doc-5.36.0-1.2.mga9.noarch.rpm lib64rpm9-4.18.2-1.mga9.x86_64.rpm perl-5.36.0-1.2.mga9.x86_64.rpm perl-base-5.36.0-1.2.mga9.x86_64.rpm rpm-plugin-syslog-4.18.2-1.mga9.x86_64.rpm glibc-2.36-57.mga9.x86_64.rpm rpm-plugin-systemd-inhibit-4.18.2-1.mga9.x86_64.rpm python3-rpm-4.18.2-1.mga9.x86_64.rpm from /var/cache/urpmi/rpms Preparing... ########################################################################### Installation failed: package glibc-6:2.36-57.mga9.x86_64 does not verify: Payload SHA256 ALT digest: BAD (Expected 16625f6c4d8e48946c4dd4623a1a97b787f489e152d343790e0631630271cd5e != d02ab2b19f15183b923784e5ffd7903d77829cef0bcf0971a74a42aa181fe068) "
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=34920
After the installation on Mageia 9 the update process attempts to first update glibc. Note that if I now run "urpmi mageia-release" then run "urpmi --update-all" the update succeeds. I suggest that the glibc spec file for mageia 9 have the following command added to it: Requires(pre): mageia-release It is important to fix this because potential new users to Mageia prior to the release of Mageia 10 will run into this problem and it is cleaner to have the encryption key updated automatically than expect a novice to update it.
Priority: Normal => HighAssignee: bugsquad => pkg-bugs
I doubt we can fix this one so the recommendation will be Install without add repositories After finish boot in the system Open terminal and run su - urpmi.removemedia -a wget https://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/9/x86_64/media/core/release/media_info/pubkey rpm -e --nodeps gpg-pubkey-80420f66-4d4fe123 then add repositories with urpmi or in mcc And update
Keywords: (none) => FOR_ERRATA9
Keywords: (none) => FOR_RELEASENOTES9
After posting Comment 2 I realized adding "Require(pre): mageia-release" to the glibc spec would not help as it would be encapsulated in an rpm signed with the new key. I found that you can just choose towards the end of the install to answer no to update when prompted to update or not. Then reboot. After login open a terminal and then run su - root urpmi mageia-release <<<<---this updates the GPG-pubkey then you can run urpmi --update-all (Note 1 that the various repositories were setup with the correct keys during the install so need to remove the media) (Note 2 that by default the ordinary user does not get su privilege or any elevated privileges during install unless at the user page step they click on the advanced button and select there the su privilege, etc.).
(In reply to katnatek from comment #3) > I doubt we can fix this one so the recommendation will be > See my Comment 4
CC: (none) => brunoKeywords: FOR_RELEASENOTES9 => FOR_RELEASENOTES10
As this may happen again in the future, I think a more global solution should be found. Maybe our installer should prioritize the mageia-release-common package first so that we are sure that what ever additional key needed after are installed first before any other package (which of course has a catch22 issue, that this same package should be signed with the previous keys to be installed). Probably other devs should have a look as more used to this context.
I can't reproduce the issue. Error in comment 0 sounds more like a broken download or mirror as it mentions payload. Mageia 9 netinstall isn't affected as urpmi mirrors has updated signing key. A fresh install from Mageia-9-x86_64.iso with additional/supplementary Core Release and Updates online (Princeton) media works OK. Updated packages were installed from Princeton mirror during the install. Second fresh install from Mageia-9-x86_64.iso without additional/supplementary media works also OK with pkg updates from Princeton mirror during the install. Third fresh install from Mageia-9-x86_64.iso without additional/supplementary media and without updates during install works OK. Updating pkgs from online media (accum.se) works OK after reboot.
CC: (none) => jani.valimaa
CC: (none) => stephengermany
Keywords: FOR_RELEASENOTES10 => (none)Flags: (none) => in_release_notes10?
Can't reproduce with Classic Installer, latter I test with Live
For the moment, I add a note in Release Notes about use good shape mirrors
Keywords: FOR_ERRATA9 => IN_RELEASENOTES9
Can't reproduce in Live installer I guess you got bad luck in the installation and get a bad mirror, the weird is after boot in installed system you get a good mirror if mageia-release is the updated version
Would be nice to know which mirror was used to upgrade so we could try to reproduce.
Isn't this the well and prominently docummented issue from the Errata, which can simply be solved with a urpmi --clean? https://wiki.mageia.org/en/Mageia_9_Errata#Downloading_software
CC: (none) => fri
(In reply to Jani Välimaa from comment #11) > Would be nice to know which mirror was used to upgrade so we could try to > reproduce. We can try with the ones still in 2025 https://mirrors.mageia.org/status http://ftp.twaren.net/Linux/Mageia/ http://mirror2.tuxinator.org/mageia/ http://mirror.rise.ph/mageia/ The marked with X https://mageia.zero.com.ar/ https://mirror.serverion.com/mageia/ http://geex.freeboxos.fr/
When I originally came across this problem I repeated all the steps several times in the course of several hours and retained each of the VMs I used. They all had the same negative results. A day or two later I repeated the experiment with anther fresh VM and this time the clean install succeeded and the update step worked installing glibc and the other initial updates. There is no obvious way to know form the installer UI which mirror was used. I did see that in all the installs there is a file /etc/urpmi/mediacfg.d/Official-9-x86_64/url . Does this contain the URL of the mirror used during the install? If so in all of my test VMs including the successful one url it contains is https://us.mirrors.cicku.me/mageia/distrib/9/x86_/64 (As an aside the root above mageia in this url is dubious and perhaps mageia council may want to discuss this). I suspect when I ran my original set of tests that there was some sort of corruption in the distribution on the mirror. There is no obvious way in the installer UI to know which mirror is being used. It may be useful enhancement to have the url of the mirror be shown in the UI during the update stage. Another useful feature would be if there is a problem reported by the updater that it retries with a different mirror.
I read urpmi manual and I see --force-key Force update of GPG key when updating media. I think we need to force the use of the switch in the related software programs.
For me it just works... Today i made a fresh mga9 Live Plasma With persistence added, i did a full update, rebooted, and experimented successfully with backport kernel. Never any complaint at all about key or any other donwloading problem. I from start set it to use a specified mirror, http://mirror.accum.se/
(In reply to Morgan Leijström from comment #16) > For me it just works... > Today i made a fresh mga9 Live Plasma > With persistence added, i did a full update, rebooted, and experimented > successfully with backport kernel. > Never any complaint at all about key or any other donwloading problem. > I from start set it to use a specified mirror, http://mirror.accum.se/ A novice user will be clueless about mirrors and just use the default setting which automatically chooses a mirror. If there is a problem there is no readily available information about which mirror is involved so it would be more difficult for a novice user to ask for help. You may find it useful to read some of the forums were users of MS Windows discuss efforts to migrate to Linux. Installer usability is an issue. Make installation easier with appropriate retries behind the scenes when mirror problems occur and better logging would be a winner. The rule of thumb is one disgruntled user/consumer will communicate their opinion to at least 100 other people.
True. What I was testing is that there is no problem as long as the used mirror(s) are working, even when there have been no update to the system between when mga9 released and now.
Concerning mirrors management, I have created that BR as indeed there is work to do: https://bugs.mageia.org/show_bug.cgi?id=34965