|Summary:||sys-boot/grub:2 on install media probably needs patch to handle 64-bit frambuffer addresses in EFI mode|
|Product:||Gentoo Linux||Reporter:||Morgan Wesström <gentoo-bugzilla>|
|Component:||Current packages||Assignee:||Mike Gilbert <floppym>|
|Severity:||normal||CC:||base-system, bkohler, release|
|Package list:||Runtime testing required:||---|
dmesg from affected machine
lspci -v from affected machine
Patch that resolves the problem.
Description Morgan Wesström 2019-02-09 18:51:17 UTC
Booting an Intel NUC8i5BEH in EFI mode from install-amd64-minimal-20190207T214502Z.iso results in black screen. Boot succeeds though because you can ssh remotely to the LiveCD environment. dmesg reveals one failure: [ 1.055159] efifb: invalid framebuffer address An Ubuntu bug tracks this to GRUB2 and was patched only 5 days ago. https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1785033 Could this patch be applied to the GRUB2 on the install media? It would also need to be applied to the GRUB2 in Portage because the same thing happens after you install Gentoo with genkernel and GRUB2 in EFI mode onto the machine in question and try to boot it. dmesg and lspci attached. Reproducible: Always Steps to Reproduce: 1. Boot from latest minimal install CD in EFI mode (on some modern hardware). 2. Screen goes black. 3. Live environment is running because ssh works. 4. dmesg reports efifb: invalid framebuffer address Actual Results: Screen goes black. Expected Results: Screen should display output.
Comment 1 Morgan Wesström 2019-02-09 18:52:01 UTC
Created attachment 564384 [details] dmesg from affected machine
Comment 2 Morgan Wesström 2019-02-09 18:52:26 UTC
Created attachment 564386 [details] lspci -v from affected machine
Comment 3 Morgan Wesström 2019-02-24 23:22:56 UTC
Created attachment 566386 [details, diff] Patch that resolves the problem. The following patch was downloaded from http://git.savannah.gnu.org/cgit/grub.git/patch/?id=886edba8770ccbc3def0af2a7d6b346d00d0af2f and I have applied it to the system in question and verified that it solves the problem.
Comment 4 Ben Kohler 2019-09-06 13:08:13 UTC
Looks like this patch is in grub-2.04-r1, so we just need to wait for this to be stabilized