I have created a new thread in the bug section of the mailing list that provides some more detail and updated findings. I have also provided a link to a screen grab video that shows the entire output before grub appears to crash.
https://lists.gnu.org/archive/html/bug-grub/2020-12/msg00002.html It is more correct to say I am unable to LOAD the kernel rather than execute it. For older kernels I don’t get beyond the load stage. - David > On Dec 4, 2020, at 12:54 AM, Andrei Borzenkov <[email protected]> wrote: > > 03.12.2020 21:51, David Huffman пишет: >> I’m not using the configuration file (for now) to remove variables. I am >> doing everything from the command shell and I am not trying to boot the >> system. Just trying to execute the kernel. Babysteps. >> >> insmod efi_gop >> linux /boot/vmlinux >> boot >> > > And what happens? Do you get some error message, system freezes, or > what? What happens when running with debug enabled? > >> I just compiled 2.02 and it works fine, so there is something about the >> updates in 2.04 that seemed to have broken. > > If you have reproducible test case when 2.02 works and 2.04 does not you > should report it to grub development list or bug tracker. > >> >> - David >> >>> On Dec 3, 2020, at 9:48 AM, Hanson Char <[email protected]> wrote: >>> >>> I suppose you have done something like: >>> >>> sudo grub-mkconfig -o /boot/grub/grub.cfg >>> >>> ? Can you see the grub menu entries during UEFI boot? >>> >>>> On Dec 3, 2020, at 9:13 AM, David Huffman <[email protected]> wrote: >>>> >>>> I’ve changed the partition ID, but made no difference. I found that a >>>> different kernel level was able to execute. >>>> >>>> I am able to execute kernel 4.19.0-12-amd64 (debian 10.5), but am unable >>>> to execute kernel 2.6.32-358.el6.x86_64 (RHEL 6.0). Is there a minimum >>>> Linux kernel level supported with grub 2.04? >>>> >>>> Thanks, >>>> David >>>> >>>>> On Dec 2, 2020, at 2:38 PM, Hanson Char <[email protected]> wrote: >>>>> >>>>> Seems you are missing an EFI System partition which is necessary for UEFI >>>>> boot (EF00). >>>>> >>>>> FWIW, I’ve had success creating an EFI system partition using gdisk, >>>>> building+installing grub 2.04 from source, and UEFI boot on both Debian >>>>> and Centos. >>>>> >>>>> Regards, >>>>> Hanson >>>>> >>>>>> On Dec 2, 2020, at 12:55 PM, David Huffman <[email protected]> wrote: >>>>>> >>>>>> I have built 2.04 from source (no errors). I have a script to create a >>>>>> BIOS/UEFI bootable hard drive. The grub-install command I am running >>>>>> succeeds without errors, but the kernel does not seem to execute when >>>>>> booting from UEFI (BIOS is fine). >>>>>> >>>>>> Adding debug=all to the configuration file shows the execution stops at: >>>>>> (...last three lines) >>>>>> >>>>>> diskefiefidisk.c:595: reading 0x40 sectors at sector 0x48dc0 from hd1 >>>>>> diskefiefidisk.c:595: reading 0x40 sectors at sector 0x48e00 from hd1 >>>>>> diskefiefidisk.c:595: reading 0x40 sectors at sector 0x48e40 from hd1 >>>>>> > > Last three lines after *what*? Without knowing what you did it is > impossible to interpret debug output. > > Anyway, here grub reads some file from disk. When you start Linux kernel > with boot command, it is already loaded in memory and no disk read > should happen. You should see debug output from boot command. > >>>>>> If I use the grub /usr/lib/grub/x86_64-efi files (*.mod, kernel.img, >>>>>> etc) poached from Debian 10.5, the system executes the kernel properly. >>>>>> If I just swap out the x86_64-efi directory with the files I compiled, >>>>>> the kernel does not execute. I am using the grub-install program I >>>>>> compiled from source in both cases.The only difference are the files in >>>>>> lib/grub/x86_64-efi/. >>>>>> >>>>>> I have found references that linuxefi.mod was removed from grub and is a >>>>>> “distro patch”. This module appears to be missing from by source build >>>>>> but removing it from the debian grub files didn’t seem to make a >>>>>> difference. >>>>>> >>>>>> Here are the commands used to build: >>>>>> >>>>>> configure --with-platform=efi --target=x86_64 --disable-device-mapper >>>>>> —prefix=$GRUBDIR >>>>>> make >>>>>> make install >>>>>> >>>>>> Inside $GRUBDIR I have all of the files I would expect from the build. >>>>>> >>>>>> The disk has three partitions with an msdos partition table: >>>>>> >>>>>> # sfdisk -l /dev/sdb >>>>>> >>>>>> Disk /dev/sdb: 1305 cylinders, 255 heads, 63 sectors/track >>>>>> Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0 >>>>>> >>>>>> Device Boot Start End #cyls #blocks Id System >>>>>> /dev/sdb1 * 0+ 12- 13- 102400 83 Linux >>>>>> /dev/sdb2 12+ 25- 13- 102400 83 Linux >>>>>> /dev/sdb3 25+ 1305- 1280- 10279936 83 Linux >>>>>> /dev/sdb4 0 - 0 0 0 Empty >>>>>> >>>>>> /dev/sdb2 on /mnt type ext2 (rw) >>>>>> /dev/sdb1 on /mnt/boot/EFI type vfat (rw) >>>>>> >>>>>> Here is the grub-install commands used: >>>>>> >>>>>> FOR BIOS: >>>>>> grub-install —force --boot-directory=$TMPMNT/boot --target=i386-pc >>>>>> —directory=$GRUBDIR/i386-pc /dev/sdb >>>>>> >>>>>> FOR UEFI >>>>>> grub-install --removable --efi-directory=$TMPMNT/boot/EFI >>>>>> --boot-directory=$TMPMNT/boot --target=x86_64-efi >>>>>> --directory=$GRUBDIR/x86_64-efi /dev/sdb >>>>>> >>>>>> At this point I am not sure what else to look at to find out what is >>>>>> different between the modules and kernel.img file I compile and what is >>>>>> supplied with debian. Any assistance in tracking down the problem would >>>>>> be appreciated. >>>>>> >>>>>> >>>>>> - David
