Bug 28349

Summary: Plymouth from Mga7 is still shown after an upgrade to Mga8
Product: Mageia Reporter: Sébastien Morin <sebsweb>
Component: Release (media or process)Assignee: Donald <watersnowrock>
Status: RESOLVED FIXED QA Contact:
Severity: major    
Priority: High CC: mageia, ouaurelien, sysadmin-bugs
Version: 8Keywords: USABILITY
Target Milestone: ---Flags: ouaurelien: in_errata7-
Hardware: All   
OS: Linux   
Whiteboard: 8rc1
Source RPM: mageia-theme-8.0-2.mga8.src.rpm CVE:
Status comment: Mageia 7 theme for Plymouth is carried over an upgrade, and user still see it after upgrade to M8.
Attachments: Log file from the upgrade
Log of the new successfull test on Feb. 15th

Description Sébastien Morin 2021-02-11 17:59:40 CET
Description of problem:

Inside a VM, I tested an online upgrade from Mageia 7 to Mageia 8.
I followed the instructions from the release notes:
1. urpmi.removemedia -a
2. urpmi.addmedia --distrib --mirrorlist 'http://mirrors.mageia.org/api/mageia.8.$ARCH.list'
3. urpmi --auto-update (I didn't use --auto --force to be able to check each of the steps)

The upgrade was a success, BUT after reboot, I noticed that right after grub screen, the plymouth splash screen was still the Mageia7 themed plymouth.

$ uname -romi
5.10.14-desktop-1.mga8 x86_64 x86_64 GNU/Linux


Aurélien advised me to run (as root)
# dracut -f

After that command was run successfully, I rebooted the VM and the Mageia8 themed plymouth screen magically appeared ;)
Comment 1 Sébastien Morin 2021-02-11 18:36:03 CET
Created attachment 12332 [details]
Log file from the upgrade

This file is the result of the following command:

# journalctl --since "2021-02-11 19:30:00" | grep RPM > /home/sebastien/rpm-log.txt

The date/time correspond to the time of the upgrade.
Comment 2 Lewis Smith 2021-02-11 20:24:42 CET
Good astuce, Aurélien!

I wondered whether this was the right pkg (from the journal):
20:05:25 localhost [RPM][12937]:
 erase plymouth-system-theme-0.9.4-1.mga7.x86_64: success
20:05:29 localhost [RPM][12937]:
 install plymouth-system-theme-0.9.5-5.mga8.x86_64: success
20:05:29 localhost [RPM][12937]:
 erase plymouth-system-theme-0.9.4-1.mga7.x86_64: success
20:05:39 localhost [RPM][12937]:
 install plymouth-system-theme-0.9.5-5.mga8.x86_64: success

@Aurélien: what do you think was the problem?

CC: (none) => lewyssmith

Comment 3 Aurelien Oudelet 2021-02-11 21:18:21 CET
In facts, we should see mageia-theme package. When is it installed/updated? Before or after plymouth package? Before or after Kernel-desktop package which will trigger an initrd rebuild for current hardware...

I will see this later this night...

CC: (none) => ouaurelien

Comment 4 Aurelien Oudelet 2021-02-12 15:21:45 CET
Yeah, that's I was suspected mageia-theme is pulled with this RPM transaction:
févr. 11 20:06:10 localhost [RPM][12937]: Transaction ID 602555f2 started

but it is AFTER the RPM transaction with kernel-desktop which triggers the initrd rebuild (See timestamps !)
févr. 11 20:05:24 localhost [RPM][12937]: Transaction ID 602555c3 started

See below: grepped output from attachment 12332 [details]:

févr. 11 20:05:24 localhost [RPM][12937]: Transaction ID 602555c3 started
févr. 11 20:05:38 localhost [RPM][12937]: install kernel-desktop-5.10.14-1.mga8-1-1.mga8.x86_64: success
févr. 11 20:05:39 localhost [RPM][12937]: install dracut-051-4.mga8.x86_64: success
févr. 11 20:05:39 localhost [RPM][12937]: install kernel-desktop-5.10.14-1.mga8-1-1.mga8.x86_64: success
févr. 11 20:05:39 localhost [RPM][12937]: install plymouth-scripts-0.9.5-5.mga8.x86_64: success
févr. 11 20:05:39 localhost [RPM][12937]: install bootsplash-3.3.11-8.mga8.noarch: success
févr. 11 20:05:39 localhost [RPM][12937]: install plymouth-system-theme-0.9.5-5.mga8.x86_64: success
févr. 11 20:05:39 localhost [RPM][12937]: Transaction ID 602555c3 finished: 0


févr. 11 20:06:10 localhost [RPM][12937]: Transaction ID 602555f2 started
févr. 11 20:06:14 localhost [RPM][12937]: install mageia-theme-8.0-2.mga8.noarch: success
févr. 11 20:06:14 localhost [RPM][12937]: install monitor-edid-3.4-1.mga8.x86_64: success
févr. 11 20:06:14 localhost [RPM][12937]: install plymouth-plugin-label-0.9.5-5.mga8.x86_64: success
févr. 11 20:06:14 localhost [RPM][12937]: install plymouth-plugin-script-0.9.5-5.mga8.x86_64: success
févr. 11 20:06:14 localhost [RPM][12937]: install mageia-theme-8.0-2.mga8.noarch: success
févr. 11 20:06:14 localhost [RPM][12937]: install mageia-theme-Default-8.0-2.mga8.noarch: success
févr. 11 20:06:14 localhost [RPM][12937]: Transaction ID 602555f2 finished: 0

Note that dracut is pulled with plymouth-scripts, bootsplash and plymouth-system-theme and the kernel-desktop, but mageia-theme comes AFTER.
So, new theme can't land in generated initrd from this upgrade.
That's why reporter still see (and I also) the Mageia 7 bootsplash after rebooting, and that's why a simple
# dracut -f
within final system will regenerate initrd/plymouth good Mageia 8 theme.

Assigning to Martin W for ISO release and Donald to make sure mageia-theme is pulled with dracut or an other solution.

Not set it as release blocker, but high priority.
It should be fixed before Release ISO.

CC: (none) => mageia
Flags: (none) => in_errata7-
Priority: Normal => High
Status comment: (none) => Mageia 7 theme for Plymouth is carried over an upgrade, and user still see it after upgrade to M8.
Whiteboard: (none) => 8rc1
Keywords: (none) => USABILITY
Severity: normal => major
Source RPM: (none) => mageia-theme-8.0-2.mga8.src.rpm
Assignee: bugsquad => watersnowrock

Comment 5 Thomas Backlund 2021-02-12 16:13:01 CET
proper conflicts added to next kernel build to force the new theme to be installed before kernel generates initrd
Comment 6 Donald 2021-02-12 16:32:20 CET
Is there a way to have the initrd rebuild happen on theme install/update when no new kernel or other packages that will trigger a rebuild is installed, but skip the rebuild if there is also a kernel update?

The rebuild used to be triggered on Plymouth theme install, change or uninstall, at least there wasn't a need to add something to rebuild on updates for the theme change on mga2.
Comment 7 Thomas Backlund 2021-02-12 16:48:19 CET
yes, it is possible, but at the same time we try to avoid rebuilding the initrd many timies during install

basically we used to rebuild for radeon-firmware, microcode, bootsplash, ... other stuff possibly affecting initrd...

so preferably nowdays we try to ensure it's all there and then create the initrd...

but we probably need to review if the theme switching still recreates initrd, but that can wait for now...
Comment 8 Thomas Backlund 2021-02-12 16:53:05 CET
if the installer is running the upgrade, is sets an "DURING_INSTALL" flag that we can track, but an urpmi upgrade dont set that (it could, but it would need some clever coding to check that it's an actual distro upgrade and so on
Comment 9 Donald 2021-02-12 16:59:24 CET
(In reply to Thomas Backlund from comment #8)
> if the installer is running the upgrade, is sets an "DURING_INSTALL" flag
> that we can track, but an urpmi upgrade dont set that (it could, but it
> would need some clever coding to check that it's an actual distro upgrade
> and so on

Yeah that makes, although I was more meaning post-install, if the theme package needs to be updated. Pretty edge case to say the least though.
Comment 10 Thomas Backlund 2021-02-12 17:02:16 CET
(In reply to Donald from comment #9)
> (In reply to Thomas Backlund from comment #8)
> > if the installer is running the upgrade, is sets an "DURING_INSTALL" flag
> > that we can track, but an urpmi upgrade dont set that (it could, but it
> > would need some clever coding to check that it's an actual distro upgrade
> > and so on
> 
> Yeah that makes, although I was more meaning post-install, if the theme
> package needs to be updated. Pretty edge case to say the least though.

well, if that is needed, we simply add a versioned trigger that only runs for that update and regenerates the initrd.
Comment 11 Sébastien Morin 2021-02-12 17:53:13 CET
(In reply to Thomas Backlund from comment #8)
> if the installer is running the upgrade, is sets an "DURING_INSTALL" flag
> that we can track, but an urpmi upgrade dont set that (it could, but it
> would need some clever coding to check that it's an actual distro upgrade
> and so on

In my opinion, there's no need to bother: an urpmi upgrade is either done for testing, or by someone who is following certain steps on purpose. Therefore, we just need to tell the user/tester that he/she needs to run the appropriate command to achieve this goal, no coding to check anything automatically is really needed.
Comment 12 Donald 2021-02-12 18:14:33 CET
(In reply to Thomas Backlund from comment #10)
> (In reply to Donald from comment #9)
> > (In reply to Thomas Backlund from comment #8)
> > > if the installer is running the upgrade, is sets an "DURING_INSTALL" flag
> > > that we can track, but an urpmi upgrade dont set that (it could, but it
> > > would need some clever coding to check that it's an actual distro upgrade
> > > and so on
> > 
> > Yeah that makes, although I was more meaning post-install, if the theme
> > package needs to be updated. Pretty edge case to say the least though.
> 
> well, if that is needed, we simply add a versioned trigger that only runs
> for that update and regenerates the initrd.

All sorted then.
Comment 13 Lewis Smith 2021-02-12 20:14:45 CET
(In reply to Aurelien Oudelet from comment #4)
> Yeah, that's I was suspected mageia-theme is pulled with this RPM
> transaction:
> févr. 11 20:06:10 localhost [RPM][12937]: Transaction ID 602555f2 started
> but it is AFTER the RPM transaction with kernel-desktop which triggers the
> initrd rebuild (See timestamps !)
> Note that dracut is pulled with plymouth-scripts, bootsplash and
> plymouth-system-theme and the kernel-desktop, but mageia-theme comes
> AFTER.
> So, new theme can't land in generated initrd from this upgrade.
Good detective work!

Thanks to Thomas for the fix; & Donald for his input.
Await a successful post-upgrade report to close the bug fixed.

CC: lewyssmith => (none)

Comment 14 Aurelien Oudelet 2021-02-13 10:24:05 CET
(In reply to Thomas Backlund from comment #5)
> proper conflicts added to next kernel build to force the new theme to be
> installed before kernel generates initrd

So we need to wait for a new kernel build before General Availability of release ISO.
Comment 15 Sébastien Morin 2021-02-15 19:52:47 CET
Created attachment 12340 [details]
Log of the new successfull test on Feb. 15th

Tested again today and this is the result of the command:

journalctl --since "2021-02-15 22:00:00" | grep RPM > /home/sebastien/rpm-log-02-15.txt
Comment 16 Aurelien Oudelet 2021-02-16 15:04:48 CET
Yeah now that kernel-desktop-5.10.16-1.mga8 is in 8/core/release/ this is fixed.


It correctly pulls mageia-theme in the same RPM transaction with the kernel package which triggers initrd rebuild.

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