Description of problem: M5 KDE Live on EFI hardware via USB key, the live system has normal virtual consoles Ctrl/Alt/Fn. After installation, the end system boots & works OK but there are no visible virtual consoles. Ctrl/Alt/Fn shows a blank screen, but not completely black. [Note: 1st re-boot after installation has graphic screen F2; subsequent re-boots on F1]. Graphics are ATI/Radeon HD 7310, screen 1920x1080. I doubt that EFI itself is relevant. This problem renders the installed system unuseable for me. Version-Release number of selected component (if applicable): Mageia 5 beta 3 round 4 (& earlier). How reproducible: Every time. Steps to Reproduce: 1. Install KDE LIVE x64 DVD. 2. Try Ctrl/Alt/Fn on the installed system. 3. Reproducible: Steps to Reproduce:
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, tmbSummary: 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 consolesSource 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.
CC: (none) => eeeemail
@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) => PATCHPriority: Normal => release_blockerCC: (none) => zen25000Assignee: bugsquad => tmbSummary: 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) => 416Source RPM: kernel => grub2
Assignee: tmb => zen25000
As this will be hard to do as the same file is package in both, I'll do it in drakboot.
Assignee: zen25000 => bugsquadSource RPM: grub2 => drakxtools
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 => RESOLVEDResolution: (none) => FIXED
*** Bug 15673 has been marked as a duplicate of this bug. ***