Bug 15291

Having for the first time succeeded in installing the M5 Classic DVD, the resulting system shows the same symptoms. Hence the bug title amended accordingly. This renders the installed system unusable for me.

Summary: M5 beta KDE installation from Live has no visible virtual consoles => M5 beta & RC installations have no visible virtual consoles

Recent install of mga5 RC (Mar 16) on x86_64 laptop with nVidia 8700M GT graphics, kernel 3.19.1-desktop-2.

Virtual consoles work but produce coredumps on login.  Attached here is the latest journal file and the third coredump from the latest console login.  If all three are of interest I shall attach them later.  They are large binary files, all of the same size but whose contents differ (that is all diff -b told me).

mga4 3.14.32-desktop-1 on another Dell machine has no problem with virtual consoles.

CC: (none) => tarazed25

Created attachment 6081 [details]
Journal file to go with core dumps

March 17 entries around 21:01+ cover virtual console login, lines 3775-3845.

Created attachment 6082 [details]
latest core dump see comment 3

This is binary data so needs to be viewed in twin-hex or whatever.  Needs somebody with assembler coding skills to interpret I would imagine and familiarity with register and stack dumps.

That might be a KMS issue for terminals
What's the result of "lspcidrake -v|grep Card"?

CC: (none) => mageia, thierry.vignaud, thomas, tmb
Summary: M5 beta & RC installations have no visible virtual consoles => M5 beta & RC installations have no visible virtual consoles (+hostname segfaults)
Source RPM: (none) => kernel, hostname

<aside>
Dropping "(+hostname segfaults)" from the subject.

I suspect this was fixed in bind-utils after the report was made.

* Thu Feb 26 2015 colin <colin> 9.10.1.P2-2.mga5
+ Revision: 817024
- Drop Fedora patch rejected by upstream and now dropped from Fedora (which causes crashes rhbz#1172935)


The body contains no further references to hostname so I figure we should clarify this.
</aside>

Summary: M5 beta & RC installations have no visible virtual consoles (+hostname segfaults) => M5 beta & RC installations have no visible virtual consoles
Source RPM: kernel, hostname => kernel

I have the feeling we are talking about two different bugs here:
One is the black console bug, the other is the coredump bug.


I comment on the black console bug, because I experienced it too.
I have an UEFI system (Asrock Z97 Extreme4, UEFI Version P1.80) and installed 
MGA 5 Beta 3 via USB stick in UEFI mode. I also have a NVidia card with binary drivers. This leads to the black console framebuffers.

My solution is to edit /etc/defaults/grub and exchange the 

GRUB_GFXPAYLOAD_LINUX 

parameter from "Text" to either "auto" (safe and sure) or "1920x1080x32"
for FullHD console pleasure. Don't forget to run update-grub2 after editing!


As far as I understand (and I'm new to the UEFI arena so I might be wrong) the UEFI firmware initializes the EFI framebuffer and then starts grub2-efi. grub2-efi operates on the EFI framebuffer and before handing it over to the kernel it can change the mode (either with auto or with a more specific resolution). The kernel then only inherits the EFI framebuffer from grub and accesses it via the efifb driver which works nicely together with the binary Nvidia driver.


Len, maybe you could try this solution, too. But from your description your problem seems to be a different one, because in your situation the framebuffers actually work to begin with.

CC: (none) => Michael.Riss

Thanks Michael Comment 7. I will try the edit you suggest to see whether it helps, to aid resolution of this thing. It is not a work-around to live with.

On the same hardware noted in 'Description' I run - and regularly update - Mageia 4[.1] *without* the problem. It too uses necessarily grub2-efi. So something has changed for Mageia 5.

Several things:
- The pathname from Comment 7 is /etc/default/grub [not defaults].
- Both Mageia 4 & Mageia 5 have/had GRUB_GFXPAYLOAD_LINUX=text .
- Changed this in Mageia 5 (Classic) to GRUB_GFXPAYLOAD_LINUX=auto , ran
 # update-grub2
and re-booting into Mageia 5 did indeed reveal the virtual consoles. Well done Michael!
- On Mageia 4 the virtual console text size is small, and correctly left-aligned.
On Mageia 5 the text size is larger, and inset; presumably to some standard resolution less wide than 1920 x 1080.
Since Michael has the same screensize, does this mean that this is the vital factor?

The problem remains with 9/10 April 2015 Mageia 5 RC Gnome Live x64 ISO (at least) on real EFI h/w.

@Thomas, Barrry: see comment #9 about booting in blind mode.

Barry, we should maybe change the GRUB_GFXPAYLOAD_LINUX to auto in /etc/default/grub for new installations

Keywords: (none) => PATCH
Priority: Normal => release_blocker
CC: (none) => zen25000
Assignee: bugsquad => tmb
Summary: M5 beta & RC installations have no visible virtual consoles => M5 beta & RC installations have no visible virtual consoles on UEFI (blind mode)

(In reply to Thierry Vignaud from comment #11)
> @Thomas, Barrry: see comment #9 about booting in blind mode.
> 
> Barry, we should maybe change the GRUB_GFXPAYLOAD_LINUX to auto in
> /etc/default/grub for new installations


We should set it to auto atleast for efi systems.

legacy systems will probably be better of with text as that is the "safest" one to cover all systems

So:
- grub2     => keeps =text
- grub2-efi => switch to auto

Blocks: (none) => 416
Source RPM: kernel => grub2

As this will be hard to do as the same file is package in both, I'll do it in drakboot.

Created attachment 6265 [details]
fix kernel booting in blind mode (mga#15291)

commit fea2953faa318091440fbcbd3b632ae7c46d8965
Author: Thierry Vignaud <thierry.vignaud@...>
Date:   Tue Apr 14 07:50:22 2015 -0400

    fix kernel booting in blind mode (mga#15291)
    
    adjust gfxpayload on UEFI
---
 Commit Link:
   http://gitweb.mageia.org/software/drakx/commit/?id=fea2953faa318091440fbcbd3b632ae7c46d8965

Closing.
Thanks to Michael & Lewis for the test & solution!

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

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