Bug 32427 - kernel-desktop-6.4.16-3.mga9.x86_64 breaks plymouth
Summary: kernel-desktop-6.4.16-3.mga9.x86_64 breaks plymouth
Status: RESOLVED WORKSFORME
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 9
Hardware: All Linux
Priority: Normal major
Target Milestone: ---
Assignee: Kernel and Drivers maintainers
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-10-23 13:29 CEST by Barry Jackson
Modified: 2024-01-01 15:27 CET (History)
3 users (show)

See Also:
Source RPM: kernel-desktop-6.4.16-3.mga9.x86_64
CVE:
Status comment:


Attachments
output of journalctl -xb (357.69 KB, text/plain)
2023-10-23 13:40 CEST, Barry Jackson
Details

Description Barry Jackson 2023-10-23 13:29:19 CEST
Description of problem:

Plymouth only displays ??? with this kernel.

Reverting to kernel-desktop-6.4.9-4.mga9.x86_64 works correctly.

Steps to Reproduce:
Update to latest Mga9 kernel, reboot and plymouth display is replaced by ???.
Comment 1 Barry Jackson 2023-10-23 13:40:03 CEST
Created attachment 14083 [details]
output of journalctl -xb
Marja Van Waes 2023-10-23 14:17:29 CEST

CC: (none) => ghibomgx, marja11
Assignee: bugsquad => kernel

Comment 2 katnatek 2023-10-23 20:27:43 CEST
Try as root

dracut -fv

And reboot

Also try this https://bugs.mageia.org/show_bug.cgi?id=19642#c62 or other tips in the report
Comment 3 Barry Jackson 2023-10-23 23:23:31 CEST
(In reply to katnatek from comment #2)
> Try as root
> 
> dracut -fv
> 
> And reboot
> 
> Also try this https://bugs.mageia.org/show_bug.cgi?id=19642#c62 or other
> tips in the report

Yes, thanks, rebuilding the initrd as above fixed it, but surely the initrd should be rebuilt during install of the new kernel shouldn't it?
I'm obviously missing something.
Comment 4 katnatek 2023-10-24 00:01:21 CEST
(In reply to Barry Jackson from comment #3)
> (In reply to katnatek from comment #2)
> > Try as root
> > 
> > dracut -fv
> > 
> > And reboot
> > 
> > Also try this https://bugs.mageia.org/show_bug.cgi?id=19642#c62 or other
> > tips in the report
> 
> Yes, thanks, rebuilding the initrd as above fixed it, but surely the initrd
> should be rebuilt during install of the new kernel shouldn't it?
> I'm obviously missing something.

https://bugs.mageia.org/show_bug.cgi?id=19049

I don't see the default plymouth be affected before, but maybe it's related to your hardware
Comment 5 Giuseppe Ghibò 2023-10-24 00:08:04 CEST
(In reply to katnatek from comment #4)
> (In reply to Barry Jackson from comment #3)
> > (In reply to katnatek from comment #2)
> > > Try as root
> > > 
> > > dracut -fv
> > > 
> > > And reboot
> > > 
> > > Also try this https://bugs.mageia.org/show_bug.cgi?id=19642#c62 or other
> > > tips in the report
> > 
> > Yes, thanks, rebuilding the initrd as above fixed it, but surely the initrd
> > should be rebuilt during install of the new kernel shouldn't it?
> > I'm obviously missing something.
> 
> https://bugs.mageia.org/show_bug.cgi?id=19049
> 
> I don't see the default plymouth be affected before, but maybe it's related
> to your hardware

(In reply to Barry Jackson from comment #3)
> (In reply to katnatek from comment #2)
> > Try as root
> > 
> > dracut -fv
> > 
> > And reboot
> > 
> > Also try this https://bugs.mageia.org/show_bug.cgi?id=19642#c62 or other
> > tips in the report
> 
> Yes, thanks, rebuilding the initrd as above fixed it, but surely the initrd
> should be rebuilt during install of the new kernel shouldn't it?
> I'm obviously missing something.

If it wouldn't have created the initrd.img the first time, I doubt you could have booted. If you have preserved the older initrd .migand the grub.cfg you could try to find how the files differs from newer (working) to older.

Probably it's some other bug somewhere else, e.g. in the draxk bootloader refresh code. It's not the first time that I loose pieces (especially with EFI). IMHO the security there should be also improved, as we have entries in \EFI\ disappearing without knowing which packages the files belongs tooand their checksums.
Comment 6 Barry Jackson 2023-10-27 00:17:36 CEST
No I don't have the original initrd so maybe this should be closed until it maybe happens again.
Comment 7 Marja Van Waes 2023-11-04 21:19:45 CET
(In reply to Barry Jackson from comment #6)
> No I don't have the original initrd so maybe this should be closed until it
> maybe happens again.

Setting to unconfirmed for now. It can be closed as soon as your kernel is updated (unless it happens again, of course), there is a kernel in updates_testing.

Status: NEW => UNCONFIRMED
Ever confirmed: 1 => 0

Comment 8 Morgan Leijström 2024-01-01 15:27:28 CET
I assume operator have updated and not seen this any more.

So closing.

If you see this again please reopen.

Status: UNCONFIRMED => RESOLVED
Resolution: (none) => WORKSFORME
CC: (none) => fri


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