[opensuse-support] TW Grub EFI menu & memtest86+
I wanted to be able to run memtest without having to hunt for a DVD to boot, so I did zypper in memtest86+ Zypper responded as I expected. I now see a two line comment pair in /boot/grub2/grub.cfg marking20_memtest86+. /etc/grub.d/20_memtest86+ exists, 1932 bytes. I don't find any memtest entry in Grub's menu on reboot however. What more is needed? Shouldn't installing memtest86+ have automatically caused an entry to show up in the menu at boot time? Is grub2-mkconfig supposed to be run manually to do it? How do I even know whether the Grub menu I see at boot time belongs to TW rather than 42.3, 15.0 or Debian? /boot/efi/EFI/ has directories for all 4 OSes. efibootmgr does list TW's 0000 first: BootCurrent: 0000 BootOrder: 0000,0005,0006,0001,0007,0008 0000* opensuse-tw 0005* opensuse 0006* debian 0001* opensuse423 0003 Hard Drive # sata HD? 0007* Hard Drive # M.2 with nothing yet installed? 0004* CD/DVD Drive # normal mode? 0008* CD/DVD Drive # EFI mode? fdisk -l Disk /dev/sda: 298.1 GiB, 320072933376 bytes, 625142448 sectors Disklabel type: gpt ... Device Start End Sectors Size Type /dev/sda1 2048 657407 655360 320M EFI System /dev/sda2 657408 5375999 4718592 2.3G Linux swap /dev/sda3 5376000 10078207 4702208 2.2G Linux filesystem /dev/sda4 10078208 23185407 13107200 6.3G Linux filesystem /dev/sda5 23185408 55953407 32768000 15.6G Linux filesystem /dev/sda6 55953408 70699007 14745600 7G Linux filesystem /dev/sda7 70699008 85444607 14745600 7G Linux filesystem /dev/sda8 85444608 100190207 14745600 7G Linux filesystem /dev/sda9 100190208 114935807 14745600 7G Linux filesystem Disk /dev/sdb: 238.5 GiB, 256060514304 bytes, 500118192 sectors Disklabel type: gpt ... Device Start End Sectors Size Type /dev/sdb1 2048 657407 655360 320M EFI System -- "Wisdom is supreme; therefore get wisdom. Whatever else you get, get wisdom." Proverbs 4:7 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On 06/19/2018 06:52 PM, Felix Miata wrote:
I wanted to be able to run memtest without having to hunt for a DVD to boot, so
memtest is not on the DVD if you boot it in UEFI mode. My understanding, which could be wrong, is that "memtest" needs to be compiled to an efi binary, and made available as memtest86.efi (or other suitable name). Maybe a bug report (enhancement request) is appropriate. -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
20.06.2018 06:48, Neil Rickert пишет:
My understanding, which could be wrong, is that "memtest" needs to be compiled to an efi binary, and made available as memtest86.efi (or other suitable name).
Maybe a bug report (enhancement request) is appropriate.
http://forum.canardpc.com/threads/68001-NEW-%21%21-Memtest86-5-00-RC1-available-%21-Need-betatesters-%21?s=5cbbb17b2f615e5c7183d5ff78ab47fd&p=5467296&viewfull=1#post5467296 -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
Andrei Borzenkov composed on 2018-06-20 07:53 (UTC+0300):
Neil Rickert composed:
My understanding, which could be wrong, is that "memtest" needs to be compiled to an efi binary, and made available as memtest86.efi (or other suitable name).
Maybe a bug report (enhancement request) is appropriate.
I guess that explains why not memtest86+, but not why not memtest86 7.4, which according to https://www.memtest86.com/technical.htm can be loaded by lilo or grub. If that site has an example menuentry for Grub2, I'm missing it. I tried creating one using the efiboot.img from a burned 7.4 iso, but get error message: error: can't allocate kernel from this menuentry: menuentry "Memory test (memtest86 7.4)" { insmod part_msdos search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1 F6A8-27B2 linuxefi /MT74EFI.IMG } (whether .img is lower case or upper case in menuentry) chainloader instead of linuxefi produces a very long /EndEntire...cannot load image result. :-( -- "Wisdom is supreme; therefore get wisdom. Whatever else you get, get wisdom." Proverbs 4:7 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On 06/20/2018 03:25 AM, Felix Miata wrote:
I guess that explains why not memtest86+, but not why not memtest86 7.4, which according to https://www.memtest86.com/technical.htm can be loaded by lilo or grub. If that site has an example menuentry for Grub2, I'm missing it. I tried creating one using the efiboot.img from a burned 7.4 iso, but get error message:
That looks unlikely. The file "efiboot.img" appears to be an image file for a FAT file system. I suggest you instead try using: efi/boot/bootx64.efi (relative to the CD). The "file" command says that it is a DOS bootable, but the naming and content of that directory suggests that it is an efi binary that you can probably chainload. Note: I just loop mounted the iso, and looked in directory "efi". When I later looked at that file "efiboot.img", I tried loop-mounting that, and it had similar content to the efi/boot directory -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
Neil Rickert composed on 2018-06-20 20:07 (UTC-0500):
Felix Miata wrote:
I guess that explains why not memtest86+, but not why not memtest86 7.4, which according to https://www.memtest86.com/technical.htm can be loaded by lilo or grub. If that site has an example menuentry for Grub2, I'm missing it. I tried creating one using the efiboot.img from a burned 7.4 iso, but get error message:
That looks unlikely. The file "efiboot.img" appears to be an image file for a FAT file system.
I suggest you instead try using: efi/boot/bootx64.efi
(relative to the CD). The "file" command says that it is a DOS bootable, but the naming and content of that directory suggests that it is an efi binary that you can probably chainload.
Note: I just loop mounted the iso, and looked in directory "efi".
When I later looked at that file "efiboot.img", I tried loop-mounting that, and it had similar content to the efi/boot directory
Thanks for the suggestion. I tried copying efi/boot/bootx64.efi from the burned CD to /mt74x64.efi and using this menuentry: insmod part_msdos search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1 F6A8-27B2 chainloader (hd0,gpt1)/mt74x64.efi +1 It generates these error messages: error: no such device: F6A8-27B2. error: invalid sector size 65535. Next try after copying /mt74x64.efi to /bootx64.efi: insmod part_msdos search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1 F6A8-27B2 linuxefi (hd0,gpt1)/bootx64.efi chainloader +1 With or without the insmod, it generates these error messages: error: no such device: F6A8-27B2. error: invalid sector size 65535. error: invalid EFI file path. Next try after copying CD's bootx64.efi to / on sda3: insmod ext2 search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt3 --hint-efi=hd0,gpt3 --hint-baremetal=ahci0,gpt3 d8f505b4-9f5a-4f25-abea-f7738ede2de1 gb320usrlcl linuxefi (hd0,gpt3)/bootx64.efi chainloader +1 error: no such device: d8f505b4-9f5a-4f25-abea-f7738ede2de1. error: invalid sector size 65535. error: invalid EFI file path. Then: insmod ext2 search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt3 --hint-efi=hd0,gpt3 --hint-baremetal=ahci0,gpt3 d8f505b4-9f5a-4f25-abea-f7738ede2de1 gb320usrlcl chainloader (hd0,gpt3)/bootx64.efi error: no such device: d8f505b4-9f5a-4f25-abea-f7738ede2de1. error: invalid sector size 65535. Trying to find meanings of grub2 error messages for me has been fruitless, e.g.: <https://www.gnu.org/software/grub/manual/grub/html_node/Troubleshooting.html#Troubleshooting> is empty. :-( -- "Wisdom is supreme; therefore get wisdom. Whatever else you get, get wisdom." Proverbs 4:7 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On 06/20/2018 08:07 PM, Neil Rickert wrote:
I suggest you instead try using: efi/boot/bootx64.efi
Here is what I have since tried. I created a directory "/boot/efi/EFI/memtest". Note that "/boot/efi" is the mount point for the EFI partition, so that this is "EFI/memtest" relative to the EFI partition. I copied everything from CDROM/efi/boot/. to this new "memtest" directory. I then did: mv bootx64.efi memtest.efi rm bootia32.efi I then used, in grub.cfg: --- cut here --- menuentry 'memtest' { insmod part_gpt insmod fat search --no-floppy --fs-uuid --set=root 8E66-F434 chainloader /efi/memtest/memtest.efi } --- cut here --- I disabled secure-boot. And it worked. NOTES: Since I am using "shim", those "insmod" probably don't do anything because most modules are preloaded. If not using shim, you might need other "insmod". However, I would guess that whatever grub module is required to read the EFI partition is going to be preloaded anyway. That string "8E66-F434" is the UUID of the EFI partition. You would need to change that as appropriate. Did I mention that it seemed to work? I did stop it early. I should add that this was all done in a KVM virtual machine (where Leap 15.0 is installed). I have not tried on real hardware. -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
21.06.2018 07:23, Neil Rickert пишет:
NOTES: Since I am using "shim", those "insmod" probably don't do anything because most modules are preloaded. If not using shim, you might need other "insmod". However, I would guess that whatever grub module is required to read the EFI partition is going to be preloaded anyway.
Not always. When secure boot is enabled in openSUSE bootloader settings, the boot sequence is shim -> pre-built grub image. This pre-built image does include both GPT and FAT support. If secure boot is deactivated in openSUSE, it is normal grub2 purpose-built image which includes only drivers to access /boot/grub2. On EFI it likely means GPT support, but not FAT. Secure boot disabled in firmware and enabled in openSUSE is valid combination and simply means pre-built image will be used. -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
All of these worked: menuentry "memtest86 chainloaded from sda1 /EFI/BOOT/ UUID" --class memtest { search --set=root --no-floppy --fs-uuid 5a35be8c-8954-4df5-9da5-bf3f00861ca8 chainloader /EFI/BOOT/BOOTX64.EFI } menuentry "memtest86 chainloaded from sda1 /efi/boot/mt74x64.efi LABEL F6A8-27B2" --class memtest { search --set=root --no-floppy --label F6A8-27B2 chainloader /efi/boot/mt74x64.efi } menuentry "memtest86 chainloaded from sda1 /EFI/BOOT/ PARTUUID" --class memtest { search --set=root --no-floppy --fs-uuid F6A8-27B2 chainloader /EFI/BOOT/BOOTX64.EFI } menuentry "memtest86 chainloaded from sda1 /efi/boot/mt74x64.efi PARTUUID" --class memtest { search --set=root --no-floppy --fs-uuid F6A8-27B2 chainloader /efi/boot/mt74x64.efi } menuentry "memtest86 chainloaded from sda1 /efi/boot/mt74x64.efi LABEL GB3201ESP" --class memtest { search --set=root --no-floppy --label GB3201ESP chainloader /efi/boot/mt74x64.efi } menuentry "memtest86 7.4 EFI" { chainloader /efi/boot/mt74x64.efi } The first two menuentries produced long error messages, a pause, then memtest86 loaded and ran. The rest simply ran memtest86. /EFI/BOOT/BOOTX64.EFI and /efi/boot/mt74x64.efi came from the burned memtest86 7.4 .iso: /efi/boot/bootx64.efi I found the needed clues to success on a 3 year old post on: https://www.passmark.com/forum/memtest86/ Grub2 provides a wealth of ways to fail. :-p -- "Wisdom is supreme; therefore get wisdom. Whatever else you get, get wisdom." Proverbs 4:7 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
participants (3)
-
Andrei Borzenkov -
Felix Miata -
Neil Rickert