Bug 18746

Summary: [vmware] No boot messages on tty1 and impossible to do a local text login since upgrade from kernel 4.1.15 to kernel 4.4.13, unless vga=788 parameter is removed
Product: Mageia Reporter: Stefan Puch <s.puch>
Component: RPM PackagesAssignee: Kernel and Drivers maintainers <kernel>
Status: RESOLVED OLD QA Contact:
Severity: normal    
Priority: Normal CC: luigiwalser, marja11, thierry.vignaud
Version: 5   
Target Milestone: ---   
Hardware: i586   
OS: Linux   
See Also: https://bugs.mageia.org/show_bug.cgi?id=18685
Whiteboard:
Source RPM: kernel-4.4.13-1.mga5.src.rpm CVE:
Status comment:
Attachments: Output from journalctl kernel 4.4.13
Output from journalctl kernel 4.1.15

Description Stefan Puch 2016-06-20 22:54:13 CEST
Description of problem:
Since upgrade from kernel-desktop-4.1.15-2.mga5 to kernel-desktop-4.4.13-1.mga5 I do not get any bootmessages from system services on tty1. The kernel messages are displayed, but after that the output stops. The console seems to be dead while the bot process itselfs goes on in background. After the boot process is finished it is not possible to access any tty{1,2,3,4} although the agetty processes are running.
'ps -A | grep tty' from remote connection via ssh lists them all

Work around:
Booting the old kernel 4.1.15 with exact the same paramters works fine.

There are no options like "quiet" or "splash" passed during boot time to the kernel.
Is any one able to confirm that?
Comment 1 Marja Van Waes 2016-06-21 10:40:23 CEST

(In reply to Stefan Puch from comment #0)
> Description of problem:
> Since upgrade from kernel-desktop-4.1.15-2.mga5 to
> kernel-desktop-4.4.13-1.mga5 I do not get any bootmessages from system
> services on tty1. The kernel messages are displayed, but after that the
> output stops. The console seems to be dead while the bot process itselfs
> goes on in background. After the boot process is finished it is not possible
> to access any tty{1,2,3,4} although the agetty processes are running.

I cannot imagine QA-team having missed that while testing the upgrade :-/

> 'ps -A | grep tty' from remote connection via ssh lists them all
> 
> Work around:
> Booting the old kernel 4.1.15 with exact the same paramters works fine.
> 
> There are no options like "quiet" or "splash" passed during boot time to the
> kernel.
> Is any one able to confirm that?

Maybe there's something specific to your system?

Can you please attach journalctl.txt that is the result of running, as root and, since iiuc that's the only possible way, via ssh (after booting the new kernel):

  journalctl -ab > journalctl.txt

Thanks :-)

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

Comment 2 Stefan Puch 2016-06-21 11:13:56 CEST
Created attachment 8034 [details]
Output from journalctl kernel 4.4.13
Comment 3 Stefan Puch 2016-06-21 11:14:20 CEST
Created attachment 8035 [details]
Output from journalctl kernel 4.1.15
Comment 4 Stefan Puch 2016-06-21 11:20:59 CEST
I attached one output for each kernel version to make it possible to compare

The last output I get on tty is
line 1137 in file journalctl-kernel-4.4.13.txt

"[drm] It appears like vesafb is loaded. Ignore above error if any."

After that the console is seems like dead (no output from systemd). Using old kernel 4.1.15 I'm able to monitor the different services starting...

If I can provide more informations please let me know. Thanks for your support!
Comment 5 Marja Van Waes 2016-06-21 11:28:24 CEST
(In reply to Stefan Puch from comment #4)

> 
> If I can provide more informations please let me know. Thanks for your
> support!

Yeah, the summary of this bug speaks of a minor issue: not seeing boot messages.

But the description talks about not being able to access any tty.

Do I correctly understand that you end up with a useless black screen, and that the only way to use that kernel is ssh'ing into this computer from another system?
Comment 6 Stefan Puch 2016-06-21 11:41:37 CEST
Sorry for the confusion.
Yes your understanding is correct. The screen is not fully black, because I can still see the last output from kernel (see comment4) but to access the system I have to use ssh when booting to "multi-user.target"

When I set the default to "graphical.target" the display manager comes up and I can use normal local logon. But switching back to console using strg+alt+f1, strg+alt+f2 etc. is not possible. There is no login prompt for tty although the agetty processes are running:

[root@sfc stefan]# systemctl get-default
multi-user.target
[root@sfc stefan]# ps -AF | grep tty
root       762     1  0  1152  1900   0 10:55 tty2     00:00:00 /sbin/agetty --noclear tty2 linux
root       763     1  0  1152  1988   0 10:55 tty1     00:00:00 /sbin/agetty --noclear tty1 linux
root      9652  8075  0  1647  2168   0 11:40 pts/0    00:00:00 grep --color tty
[root@sfc stefan]#
Marja Van Waes 2016-06-21 11:54:29 CEST

Summary: No bootmessages on tty1 since upgrade from kernel 4.1.15 to kernel 4.4.13 => No bootmessages on tty1 and impossible to do a local text login since upgrade from kernel 4.1.15 to kernel 4.4.13

Comment 7 Thierry Vignaud 2016-06-21 14:00:11 CEST
Have you tried remotely starting x11?

CC: (none) => thierry.vignaud
Summary: No bootmessages on tty1 and impossible to do a local text login since upgrade from kernel 4.1.15 to kernel 4.4.13 => [vmware] No boot messages on tty1 and impossible to do a local text login since upgrade from kernel 4.1.15 to kernel 4.4.13

Comment 8 Stefan Puch 2016-06-21 14:26:30 CEST
What exactly do you mean?

- As said in comment6 setting default to "graphical.target" works fine. The system boots to graphical login screen. Boot messages are not shown in-between.

- Booting to "multi-user.target" ssh'ing to the system and then running "systemctl start graphical.target" manually works also. But switching back to tty* gives only a screen with the last messages from kernel boot. Tested strg+alt+f1 up to strg+alt+f6 Graphical screen is on strg+alt+f3
Comment 9 David Walser 2016-06-23 01:14:39 CEST
Sounds like Bug 18685 in Cauldron.
Thierry Vignaud 2016-06-23 09:09:05 CEST

See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=18685

Comment 10 Stefan Puch 2016-06-23 09:29:45 CEST
David you are right, your description seems to be very very equal and it brought me to the right direction because you mentioned "Plymouth Boot Screen" and comment7 pointed to bootsplash.

I tried the parameter mentioned in Bug 18685 comment 7 by Charles Edwards splash=verbose and have /etc/sysconfig/bootsplash is set SPLASH=no but that doesn't solve the problem for me
My settings are SPLASH=auto (I never changed that) and no splash variable is passed to kernel.

So I did a second look into by menu.lst to analyse which parameters are passed to kernel-4.1.15-2.mga5 which still works as expected.

The parameters passed to kernel are
- 'BOOT_IMAGE=xxx'
- 'root=UID=xxx'
- 'vga=788'

and the last parameter seems to be a problem for the new kernel-4.4.13

On short:
Removing the parameter vga=788 from the parameter list brings back the boot messages from systemd and tty1-6 are working again. :)

I cannot explain what exactly happens, but that are my observations.
Marja Van Waes 2016-06-23 10:01:06 CEST

Summary: [vmware] No boot messages on tty1 and impossible to do a local text login since upgrade from kernel 4.1.15 to kernel 4.4.13 => [vmware] No boot messages on tty1 and impossible to do a local text login since upgrade from kernel 4.1.15 to kernel 4.4.13, unless vga=788 parameter is removed

Comment 11 Thomas Backlund 2016-06-23 10:09:38 CEST
Hm, I seem to remember about an upstream report about broken vmware with a possible kernel fix... I need to dig it up and see if its releated
Comment 12 Thomas Backlund 2016-06-23 10:12:47 CEST
(In reply to Stefan Puch from comment #10)

> The parameters passed to kernel are
> - 'BOOT_IMAGE=xxx'
> - 'root=UID=xxx'
> - 'vga=788'
> 
> and the last parameter seems to be a problem for the new kernel-4.4.13


Yeah, the vga= part tells kernel to activate vesa framebuffer so that is at fault, but its a subtle brakage as it works for most...

will look on it soon-ish
Comment 13 Thomas Backlund 2016-06-23 10:32:17 CEST
ok, seems the fix in question has been sent to -stable tree and will show up in 4.4.14 and 4.6.3
Comment 14 Stefan Puch 2016-06-23 10:47:18 CEST
ok, for documentation purpose you are probably referring to this patch

https://lkml.org/lkml/2016/6/22/914

ETA for 4.4.14-stable review is Fri Jun 24 22:34:00 UTC 2016.
Source https://lkml.org/lkml/2016/6/22/968
Comment 15 Thomas Backlund 2016-06-23 11:14:51 CEST
Yep,

And I just pushed a kernel-4.4.13-2.mga5 (wih 4.4.14-rc1 added) to buildsystem heading to  testing (and a kernel-4.6.2-3.mga6 that has 4.6.3-rc1 for cauldron users) so you can test if it actually fixes this issue

I will wait for final 4.4.14 before pushing for QA as I have some other pending fixes too..
Comment 16 David Walser 2016-06-23 15:19:14 CEST
*** Bug 18685 has been marked as a duplicate of this bug. ***

CC: (none) => luigiwalser

Comment 17 David Walser 2016-06-23 15:33:08 CEST
Unfortunately 4.4.13-2.mga5 doesn't fix it :o(
Comment 18 Stefan Puch 2016-06-24 09:51:48 CEST
Confirmed!
Booting with parameter vga= triggers the problem of missing boot messages on tty1. In line with that there is no option to do a local text login.

Removing the parameter works as a work around.
What else can we do to narrow the problem down?
Comment 19 Thomas Backlund 2016-06-24 11:14:07 CEST
(In reply to Stefan Puch from comment #18)
> Confirmed!
> Booting with parameter vga= triggers the problem of missing boot messages on
> tty1. In line with that there is no option to do a local text login.
> 
> Removing the parameter works as a work around.
> What else can we do to narrow the problem down?

did you test the 4.4.13-2 ?
Did that change anything ?
Comment 20 Stefan Puch 2016-06-24 13:12:50 CEST
@Thomas
Yes I did. My comment18 should be a direct confirmation of David's comment17 which referred to 4.4.13-2.mga5
Comment 21 Thomas Backlund 2016-06-24 13:20:59 CEST
ok, will dig into this
Comment 22 Thomas Backlund 2016-06-24 13:59:29 CEST
One thing.... could you try kernel-linus 4.4.13 too in case any of the mageia patches broke 4.4 series
Comment 23 David Walser 2016-06-24 14:08:00 CEST
Side note: I wouldn't have to use a vga= parameter on most systems if the kernel would just default to 1024x768 instead of the tiny 800x600.

No, kernel-linus isn't any better, so this is "Yet Another Upstream Kernel Regression" (TM).  There have been far too many of those the past few years.
Comment 24 Stefan Puch 2016-06-24 14:22:36 CEST
I just tested kernel-linus-4.4.13-1.mga5-1-1.mga5.i586 and can confirm comment23 from David. Same problem: vga parameter causes the problem...
Comment 25 Thomas Backlund 2016-07-20 14:13:48 CEST
A kernel-4.4.15-1 has been submitted to testing (currently building) with some additional vmwgfx fixes  ...


Please test with it when it's available...
Comment 26 David Walser 2016-07-20 21:08:40 CEST
Just tested it, still no dice :o(

After the bootloader the screen blanks and then you see (with a time in [] on the left):
sd 0:0:0:0 [sda] Assuming drive cache: write through

then the screen blanks and reverts to the text printed on the screen by the bootloader and then it stays stuck there.

On a 4.1 kernel, after the write through message, there's something about not being able to find pcnet32 and then the Welcome to Mageia 5 and the boot messages are printed below that.
Comment 27 Thomas Backlund 2016-07-20 21:56:38 CEST
what happends if you boot with "nomodeset" ?
Comment 28 David Walser 2016-07-21 19:32:37 CEST
(In reply to Thomas Backlund from comment #27)
> what happends if you boot with "nomodeset" ?

Yes!  Booting with nomodeset fixes it.  Thanks!!
Comment 29 David Walser 2016-07-22 00:03:24 CEST
(In reply to David Walser from comment #28)
> (In reply to Thomas Backlund from comment #27)
> > what happends if you boot with "nomodeset" ?
> 
> Yes!  Booting with nomodeset fixes it.  Thanks!!

nokmsboot apparently works too.
Comment 30 Stefan Puch 2016-08-07 20:35:46 CEST
I can confirm the test of David. If I boot with vga= parameter the screen blanks as before. If I set nomodeset parameter additionally everything works as expected.
Comment 31 Marja Van Waes 2016-08-26 11:42:40 CEST
Mass-reassigning all bugs with "kernel" in the Source RPM field that are assigned to tmb, to the kernel packagers group, because tmb is currently MIA.

Assignee: tmb => kernel

Comment 32 Marja Van Waes 2018-04-28 19:11:32 CEST
(In reply to David Walser from comment #29)
> (In reply to David Walser from comment #28)
> > (In reply to Thomas Backlund from comment #27)
> > > what happends if you boot with "nomodeset" ?
> > 
> > Yes!  Booting with nomodeset fixes it.  Thanks!!
> 
> nokmsboot apparently works too.

(In reply to Stefan Puch from comment #30)
> I can confirm the test of David. If I boot with vga= parameter the screen
> blanks as before. If I set nomodeset parameter additionally everything works
> as expected.

No idea whether anything was planned to let booting work without workaround, but now closing as OLD, because Mageia 5 has officially reached its End of Life on December 31st, 2017 https://blog.mageia.org/en/2017/11/07/mageia-5-eol-postponed/
It only continued to get important security updates since then, but non-security bugs have no chance of still getting fixed.

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