Bug 20583

Summary:	Every kernel from the Updates media will only boot to SDDM login session using Recovery mode
Product:	Mageia	Reporter:	Kristoffer Grundström <lovaren>
Component:	RPM Packages	Assignee:	Kernel and Drivers maintainers <kernel>
Status:	RESOLVED OLD	QA Contact:
Severity:	critical
Priority:	Normal	CC:	marja11
Version:	Cauldron	Keywords:	NEEDINFO
Target Milestone:	---
Hardware:	All
OS:	Linux
Whiteboard:
Source RPM:	kernel-desktop-latest	CVE:
Status comment:

Description Kristoffer Grundström 2017-03-27 22:53:28 CEST

Description of problem: I downloaded the sta2 DVD iso and burned it to a USB memory drive. That part went just fine. Booting the installation I chose to install Plasma, MATE, GNOME, Cinnamon and the only setting I touched in the Summary was the Screen resolution and the Firewall to open the port to SSH. After that I rebooted to a working SDDM login session and I logged into MATE. That worked fine. After that I added the medias (except for Testing and Backports) for Cauldron and ran the update process in the terminal and no fail that I could see. As I rebooted the computer I noticed that the latest kernel 4.9.17 couldn't boot to SDDM for some odd reason. I recall that I could try to boot the kernel into Recovery mode and then I decided to reboot into Recovery mode and run systemctl default and that way I could boot to SDDM login session. 

Version-Release number of selected component (if applicable): 4.9.17

How reproducible: Every boot.

Steps to Reproduce:
1. Boot the installation of the sta2 DVD iso.
2. Install GNOME, Plasma, Cinnamon, MATE as DE's.
3. Reboot and the first boot will work just fine.
4. Update using all the medias except Testing and Backports.
5. Reboot.
6. Voila! The kernel 4.9.17 won't boot unless you boot it into recovery mode and run systemctl default as root.

Comment 1 Kristoffer Grundström 2017-03-27 22:54:49 CEST

The computer just seems to freeze when you boot normally. I waited at least 45 minutes to see if the kernel was unusually slow, but nothing happened.

Comment 2 Kristoffer Grundström 2017-03-27 22:56:11 CEST

What log files do you need?

Comment 3 Kristoffer Grundström 2017-03-27 22:56:59 CEST

I tested the previous kernels and I got the same result.

Comment 4 Marja Van Waes 2017-03-28 08:38:14 CEST

(In reply to Kristoffer GrundstrÃ¶m from comment #2)
> What log files do you need?

So the only boot that worked fine, was the first one, and the second one went wrong?

Please attach good.txt that is the result of running, as root:

     journalctl -ab1 > good.txt

and attach bad.txt that is the result of running as root:

     journalctl -ab2 > bad.txt

(or attach a more recent "bad one")

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

Marja Van Waes 2017-03-28 08:38:27 CEST

Keywords: (none) => NEEDINFO

Marja Van Waes 2017-03-28 08:38:39 CEST

Component: New RPM package request => RPM Packages

Comment 5 Kristoffer Grundström 2017-03-28 11:14:46 CEST

I don't know why, but I can boot normally again if I remove the noiswmd and nomodeset (I added the nomodeset part to the kernel boot command line to solve a previous graphics problem as I wasn't sure if it has been resolved yet) and modprobe.blacklist=nouveau .

Weird, but true.

So, who can add that workaround to the next kernel?

Comment 6 Marja Van Waes 2021-07-02 23:33:04 CEST

(In reply to Kristoffer Grundström from comment #5)
> I don't know why, but I can boot normally again if I remove the noiswmd and
> nomodeset (I added the nomodeset part to the kernel boot command line to
> solve a previous graphics problem as I wasn't sure if it has been resolved
> yet) and modprobe.blacklist=nouveau .
> 
> Weird, but true.
> 
> So, who can add that workaround to the next kernel?

You didn't add the requested log files :-þ

Anyway, it's years later and doesn't seem to be a problem anymore, closing.

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