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 <dhuffma...@gmail.com> 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 <hanson.c...@gmail.com> 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 <dhuffma...@gmail.com> 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
>>>
>>> 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
>>>
>>>
>>>
>>
>
