Bug 26284 - Installer sometimes tries to reinstall firmware files that have been installed earlier - this is now a fatal error
Summary: Installer sometimes tries to reinstall firmware files that have been installe...
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: Installer (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: release_blocker major
Target Milestone: ---
Assignee: Thierry Vignaud
QA Contact:
URL:
Whiteboard:
Keywords: PATCH
Depends on:
Blocks:
 
Reported: 2020-03-02 20:47 CET by Martin Whitaker
Modified: 2020-03-15 23:00 CET (History)
0 users

See Also:
Source RPM: drakx-installer-stage2-18.23-2.mga8.src.rpm
CVE:
Status comment:


Attachments
Installer log showing failure (121.96 KB, application/x-xz)
2020-03-02 20:47 CET, Martin Whitaker
Details
install.log from same install (29.99 KB, application/x-xz)
2020-03-02 23:41 CET, Martin Whitaker
Details
Proposed fix (1.67 KB, text/plain)
2020-03-14 18:32 CET, Martin Whitaker
Details

Description Martin Whitaker 2020-03-02 20:47:31 CET
Created attachment 11531 [details]
Installer log showing failure

This bug first showed up in Mageia 7 and was quite noticeable in the Live ISO builds. Sometimes, during install_hardware_packages() in afterInstallPackages(), the installer fails to detect that one or more of the firmware packages has already been installed and attempts to reinstall it. For Mageia 7 this wasn't a problem, as the reinstall succeeded, but in cauldron it fails (probably related to bug #25439) and the installer aborts.

This bug comes and goes. For a given install configuration it seems to be consistent, but change some settings (or add some print statements to try to debug the problem) and it will flip.

I've attached the installer log from a failed Live ISO build.

Setting to release blocker, as this blocks ISO building.

Setting component to installer, but from what debug I've managed to do, I suspect the real culprit is perl-URPM, so assigning to Thierry.
Comment 1 Thierry Vignaud 2020-03-02 23:31:00 CET
I don't see the link with the other bug report which looks unrelated.
I don't have your /mnt/root/drakx/install.log to confirm it but the culprit seems to be that because it's already installed, it's part of 2 transactions:

* selecting radeon-firmware-20200204-2.mga8.nonfree.noarch
* set_rejected: radeon-firmware-20200204-2.mga8.nonfree.noarch
* selecting hso-rezero-0.1-20.mga8.x86_64
* transaction valid: remove=radeon-firmware-20200204-2.mga8.nonfree.noarch update=radeon-firmware,hso-rezero
* scheduled sets of transactions:
remove=1=radeon-firmware-20200204-2.mga8.nonfree.noarch update=2=radeon-firmware,hso-rezero
* opening rpmdb (root=/mnt, write=1)
* trans: scheduling removal of radeon-firmware-20200204-2.mga8.nonfree.noarch
* trans: scheduling update of hso-rezero-0.1-20.mga8.x86_64 (id=10190, file=/tmp/image/media/core/release/hso-rezero-0.1-20.mga8.x86_64.rpm)
* trans: scheduling update of radeon-firmware-20200204-2.mga8.nonfree.noarch (id=29285, file=/tmp/image/media/nonfree/release/radeon-firmware-20200204-2.mga8.nonfree.noarch.rpm)

Could you provide install.log for such a case?
I can only imagine scenarios:
install::pkgs::_install_raw() failing to register it actually got installed:
   if ($check_installed) {
       _unselect_package($packages, $pkg);

But somehow it does know it's installed since it tries to remove it which must have failed b/c it's needed by some pkgs, but again we need install.log

What I know is that it happens when drakx-net code tries to install some pkgs later...

Keywords: (none) => NEEDINFO

Comment 2 Martin Whitaker 2020-03-02 23:41:04 CET
Created attachment 11532 [details]
install.log from same install

radeon-firmware was selected in the last batch of the main package install, but isn't listed as an installed package - although clearly it was installed.

The link to the other bug is that the reinstall used to work in mga7, but doesn't in cauldron, which has changed this bug from a minor annoyance to a release blocker :-(
Comment 3 Martin Whitaker 2020-03-14 15:32:48 CET
The bug is in the close_helper() subroutine defined in install::pkgs::_install_raw():

    # ignore first close after end of verify:
    if ($is_installing && $verify_just_closed) {
        undef $verify_just_closed;
        return;
    }

This causes the first package in each transaction to go unrecorded.

git blame gives me

commit 73aa98991a97501bc1e251689865d71ec20298a9
Author: Thierry Vignaud <thierry.vignaud@gmail.com>
Date:   Wed Nov 21 03:53:02 2018 +0100

    remove debug statement
    
    wrongly added with commit 6375ef3a8cd8b1b1e057334ab680c5c701123395
    (spot by Martin Whitaker)

but it looks like you also reverted a possible fix for this bug.

Keywords: NEEDINFO => (none)
Source RPM: (none) => drakx-installer-stage2-18.23-2.mga8.src.rpm

Comment 4 Martin Whitaker 2020-03-14 18:32:11 CET
Created attachment 11549 [details]
Proposed fix

Testing what was reverted, it didn't work. This does.
Martin Whitaker 2020-03-14 18:32:27 CET

Keywords: (none) => PATCH

Comment 5 Thierry Vignaud 2020-03-15 08:49:58 CET
Looks good (& tested by you)
Commit it…
Comment 6 Martin Whitaker 2020-03-15 23:00:17 CET
Fixed in drakx-installer-stage2-18.24

Resolution: (none) => FIXED
Status: NEW => RESOLVED


Note You need to log in before you can comment on or make changes to this bug.