| Summary: | Boot failure with no working display on Peaq C1011 notebook with 32-bit kernels (64-bit kernels are OK) | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Herman Viaene <herman.viaene> |
| Component: | RPM Packages | Assignee: | Kernel and Drivers maintainers <kernel> |
| Status: | RESOLVED OLD | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | mageia, marja11, ouaurelien |
| Version: | 7 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | CVE: | ||
| Status comment: | |||
| Attachments: |
screen after correvy grub menu
ISO for testing EFI frame buffer display ISO for testing EFI frame buffer display (v2) Log from x86-64 Live USB |
||
|
Description
Herman Viaene
2020-10-29 16:15:45 CET
Thanks for the bug report. Could you provide the file /root/drakx/report.bug.xz as an attachment ? If you don't have the file, you can switch to console 2 (by pressing 'Ctrl-Alt-F2') during installation, put a floppy in floppy drive or plug a USB key/stick and type: 'bug' then press Enter. It will put report.bug on the floppy/key. Eventually, can you provide a screenshot taken by a smartphone of the non-functioning screen? Keywords:
(none) =>
NEEDINFO @Herman, Can you even test Cauldron i586 ISO? (I must be set this bug to Cauldron as we can't intervene on already released ISO). To run the installer stage 2 in text mode, at the GRUB boot menu, press 'e' to edit the boot command line and add the word "text". That will still use the selected VGA mode, but use the ncurses interface instead of the GUI. If you are using legacy boot, you can force the installer to use VGA text mode by removing the "vga=791" from the boot command line (or change it to "vga=0"). If you are using UEFI boot, the only option is to use the EFI frame buffer. That's a UEFI thing, not a limitation of our installer. CC:
(none) =>
mageia Created attachment 11969 [details]
screen after correvy grub menu
@ Aurelien
Once I get in this situation, there is nothing I can do anymore beside pressing the Power button. No response from any keyboard action or mouse.
@ Martin Changing vga=0 and adding text does not have any result at all. The story of the problem with the graphical installer has been unfolded in the qa-discuss ml. Should I instead make that a separate bug??? @ Herman, is that with legacy boot? The Phoenix Setup has UEFI Secure Boot : Disabled. I disabled it, because otherwise it refused to boot from the USB. There is no legacy option. (In reply to Herman Viaene from comment #7) > The Phoenix Setup has > UEFI Secure Boot : Disabled. > I disabled it, because otherwise it refused to boot from the USB. > There is no legacy option. Nor CSM/Compatibility ? No, not there. Created attachment 11971 [details]
ISO for testing EFI frame buffer display
My ASUS tablet with a 32-bit UEFI BIOS is the same - no CSM/legacy boot support. As said, the vga= options only apply to legacy boot, and are ignored when the Linux kernel is booted via UEFI. Although UEFI BIOSs support a text display mode, it is only available when the EFI boot services are running. Once the Linux kernel terminates them (which it does very early in the boot process), it must use the EFI frame buffer for display until it loads the real display driver for the hardware. Unfortunately the installer doesn't include/use the real display drivers, so it can only use the EFI frame buffer when booted via UEFI. And that doesn't seem to be working properly on your machine. I've attached a small test ISO to try to debug this. Please decompress it, dump it onto a USB stick, and boot from that. It should first display a few lines of information about the EFI frame buffer, using the EFI console output service, then, when you press any key, switch to using the EFI frame buffer directly and display a short message. Let me know what you see on your machine. Created attachment 11972 [details]
ISO for testing EFI frame buffer display (v2)
Updated version that outputs a bit more information.
Attachment 11971 is obsolete:
0 =>
1 Starting the iso says: BGR32mode FB base: 80000000 FB size: 1920 x 1080 FB format : R8 G8 B8 A8 FB stride : 7680 Press any key to continue.... Done that, gives me black screen with in the middle (somewhat to the left): Frame buffer active And that's the end. Well, there isn't anything wrong with that. A couple of stabs in the dark to try: 1. At the installer boot menu, press 'c' to get the grub command prompt, type terminal_output console to switch to text mode, press ESC to return to the boot menu (which should now be in text mode), and select "Install Mageia". 2. At the installer boot menu, press 'e' to edit the boot command line, and replace "$linux" by "linux" and "$initrd" by "initrd" (must do both), followed by Ctrl-X to boot the installer. If neither of those makes any difference, could you boot the 64-bit Live ISO, capture the system log by, as root, running journalctl -b | xz > journal.log.xz and attach the resulting journal.log.xz here. None of the two options make any difference at all. About the Live: do you mean the Live USB, or the Live installed on the HD?? The Live USB would be best. Created attachment 11973 [details]
Log from x86-64 Live USB
From the log, it is detecting a 1024x768 EFI frame buffer (which is the first choice display size used for the GRUB menu, so what I would expect). The next question is whether that is actually working. If you remove "splash quiet" from the boot command, normally you will see the first few lines of text output at a low resolution, then the kernel loads the real display driver and the resolution (and font appearance) changes. Does that happen, or do you not get the low resolution display at the start of the kernel boot process? Sorry for the continual questions, but this is a hard one to debug remotely. Issue with EFI FrameBuffer can come from GRUB to arbitrary set display resolution to 1024x768 for ex. instead of native screen resolution. When an UEFI firmware boots, it normally can detect native screen resolution and set it properly. For GRUB, a "GRUB_GFXPAYLOAD_LINUX=auto" option should be passed at installation time and at ISO construction, this will prevent kernel to switch EFI native resolution. Also, "GRUB_GFXMODE=auto" should also be set instead of an arbitrary one like 1024x768. On UEFI, "vga=" option passed to Kernel command line is deprecated and should not function well. But, as Martin W. said above, removing "splash quiet" from Kernel command line should prevent resolution switch. At last, if I really know about the graphic chipset in use, we could use some other workaround. When I remove "splash quiet" from the boot command, I get the first screenfull of messages at a lower resolution before the system switches to a higher resolution. @ Herman, When system switches higher resolution, can you read what it displays? If I could read fast enough, yes, everything is readable. Yeah, good! Finally, do you get Installer GUI or ncurses? Just a second, are we still on the right track???? I logged this bug on the i586, because I was hoping to overcome the graphics display problem on my Peaq notebook in this way. But now since Martin's question in Comment 14, I did the testing on the x86-64 Live iso, because it's the only iso that lets me see anything at all. But maybe that's the only way to get anywhere here. Anyway, I took the suggestion of Comment 3 I at that time applied to the i586 without result, and applied it now to the boot command of the x86-64 Live, taking the "Install" option , but that still brings me to the same graphical installation dialogues. @ Aurelien The x86-64 Live iso does the installation option in the installer GUI, whether or not I insert the "text" at the command line, that doesn't make any difference. @ Herman, yes, I asked you to test with the 64-bit Live because that is the only one that you reported works, and I'm trying to see what happens early in the kernel boot sequence, which is a hard if you don't have a working display. Could you now try booting the 64-bit classical installer, replacing "splash quiet" with "rd.break=cmdline". After 15 seconds of messages, I get to "Droppng to debug shell" and a CLI. Martin, are you on IRC mageia-dev? I don't normally use IRC, but will see if I can get on it. That CLI does not respond to any keyboard action. Is that what you expected??? That's quite likely because you don't have the CSM in your BIOS, the UEFI boot services will have been terminated, but the real keyboard driver hasn't been loaded yet. rd.break can stop at various checkpoints: cmdline|pre-udev|pre-trigger|initqueue|pre-mount|mount|pre-pivot|cleanup Can you try a few more options to see if/when the display breaks. (having trouble resetting my password on IRC - will probably have to register a new nick) Up to pre-trigger I get to the same breakpoint. With initqueue I get a lot further, but then the screen freezes: output still visible, but nothing happening anymore. The last screenfull concerns USB devices, then scsi sda usb sdb (there is the USB stick) usb Logitech input Logitech optical mouse and the last line: hid-generic 0003:046D:C05A.0005: input.hdraw4: USB HID v1.11 Mouse [Logitech Optical Mouse] on usb-0000:00:1.4.0-2.4/input0 And no response to the keyboard? (it may be that the shell prompt has scrolled off the screen due to the other messages) What about later breakpoints? You were right about scrolling off the screen. So I repeated that one, and it was OK, as were all subsequent others. Out of shere curiosity, I rebooted the x86-64 classic, made sure to delete the "splash quiet", and it went on in the installation procedure. I'm letting it run now and report back later. OK, if the 64-bit install works, the next step is to try the same things with the 32-bit installer, to see if we can pin down where that breaks. Classic i586, delete splash quiet, add rd.break=cmdline: no good, already broken. OK, seems to be a problem specific to the desktop586 kernel on your machine. Can you try the 8-beta1 32-bit CI ISO, to see if it is fixed in a newer kernel version. Just for my information, does the 64-bit CI ISO still work even with the "splash quiet" option. AFAIK, that option should have no effect, because the installer does not display the boot splash screen. 8-beta1 32-bit CI ISO is even worse.After choosing the USB to boot from, the screen goes black for some seconds, and then immediately I get the vibrating bands. So even the grub menu gets thru. 64 bit CI in default boot: Well, it didn't. That is the reason why I turned to the Live. I have built an updated 32-bit Mageia 7 Live ISO, using the desktop instead of desktop586 kernel. You can download it from https://hidrive.ionos.com/share/po4ts04kjl See if that works. That one at least boots to the grub menu, but removing splash quiet and adding rd.break=cmdline brings the bands after some seconds, no break. And also if you keep the default boot settings? Yes, the same, grub menu and then bands. The same whether I choose to run the Live or the installation option. OK, I'm out of ideas then. There are no such problems on my ASUS X205TA, which I believe has the same processor (Intel Atom Z3735F), so I think it must be something specific to your BIOS. I'm sorry, but I think you are going to be limited to running a 64-bit system on that machine for now. Keywords:
NEEDINFO =>
(none) Mageia 7 is EOL since July 1st 2021. There will not have any further bugfix for this release. You are encouraged to upgrade to Mageia 8 as soon as possible. @reporter, if this bug still apply with Mageia 8, please let us know it. @packager, if you work on the Mageia 7 version of your package, please check the Mageia 8 package if issue is also present. In this case, please fix the Mageia 8 version instead. This bug report will be closed OLD if there is no further notice within 1st September 2021. Since then, the Peaq notebook completely broke down, so I cann't do anything anymore sensible on this subject. (In reply to Herman Viaene from comment #46) > Since then, the Peaq notebook completely broke down, so I cann't do anything > anymore sensible on this subject. Thanks for the feedback. Closing, then, because you were the only one affected. Resolution:
(none) =>
OLD |