(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

Created attachment 8034 [details]
Output from journalctl kernel 4.4.13

Created attachment 8035 [details]
Output from journalctl kernel 4.1.15

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!

(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?

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]#

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

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

Sounds like Bug 18685 in Cauldron.

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.

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

(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

ok, seems the fix in question has been sent to -stable tree and will show up in 4.4.14 and 4.6.3

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

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..

*** Bug 18685 has been marked as a duplicate of this bug. ***

CC: (none) => luigiwalser

Unfortunately 4.4.13-2.mga5 doesn't fix it :o(

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?

(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 ?

@Thomas
Yes I did. My comment18 should be a direct confirmation of David's comment17 which referred to 4.4.13-2.mga5

ok, will dig into this

One thing.... could you try kernel-linus 4.4.13 too in case any of the mageia patches broke 4.4 series

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.

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...

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...

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.

what happends if you boot with "nomodeset" ?

(In reply to Thomas Backlund from comment #27)
> what happends if you boot with "nomodeset" ?

Yes!  Booting with nomodeset fixes it.  Thanks!!

(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.

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.

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

(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