Problem:
Expected outcome:
Foreman and Proxy versions:
Foreman and Proxy plugin versions:
Other relevant data:
Configure UEFI on target machine
Install Linux on target machine (Debian 9.5/CentOS 7)
boot target using Network
I’ve compared the pxegrub2_chainload template with the 1.19 version of foreman, they use the same mechanism.
I noticed that the grub search command does not return the disk device on which efi installation exists. As a workaround, I tried this:
menuentry "BTH: Chainload Grub2 EFI from ESP" {
insmod part_gpt
insmod fat
insmod chain
echo Chainloading Grub2 EFI from ESP, available devices:
for efi in (*,gpt*)/efi/*/*.efi (*,gpt*)/efi/*/*/*.efi (*,gpt*)/*.efi (*,gpt*)/*/*.efi ; do
regexp --set=1:efi_device '^\((.*)\)/' "${efi}"
if [ -e "${efi}" ]; then
echo "Found efi boot on ${efi} on device ${efi_device}. Attempting efi boot."
sleep 5
root=${efi_device}
chainloader "${efi}"
fi
done
}
Has anyone run into this problem?
lzap
October 8, 2018, 3:11pm
2
Our template assumes you only have your OS installed on the first disk (at least ESP is there).
Not sure where did you get your snippet from, this is our version:
<%#
kind: snippet
name: pxegrub2_chainload
model: ProvisioningTemplate
snippet: true
%>
<%
paths = ["fedora", "redhat", "centos", "debian", "ubuntu", "sles", "opensuse", "Microsoft", "EFI"]
-%>
menuentry 'Chainload Grub2 EFI from ESP' --id local {
unset root
echo Chainloading Grub2 EFI from ESP, available devices:
ls
echo -n "Probing ESP partition ... "
search --file --no-floppy --set=root /EFI/BOOT/BOOTX64.EFI
echo found $root
sleep 2
if [ -f ($root)/EFI/BOOT/grubx64.efi ]; then
chainloader ($root)/EFI/BOOT/grubx64.efi
<% paths.each do |path| %>
show original
I’m using the same snippet as you’ve posted. The OS is deployed on the first available disk. However, the output of the echo found $root statement is:
Do all distributions (installed on EFI systems) contain /EFI/BOOT/BOOTX64.EFI?
lzap
October 8, 2018, 5:56pm
5
It is likely there is a bug, most of us use Red Hat compatible systems and I have been testing this only with RHEL and CentOS. Can you list all files of Debians EFI ESP partition?
That was my assumption when I designed this, I can be terribly wrong. We can improve.
I’ve created a tree output for CentOS7 and debian.
Debian9 tree:
# tree /boot/
/boot/
├── config-4.9.0-7-amd64
├── efi
│ └── EFI
│ └── debian
│ └── grubx64.efi
├── grub
│ ├── fonts
│ │ └── unicode.pf2
│ ├── grub.cfg
│ ├── grubenv
│ ├── locale
│ │ ├── ast.mo
│ │ ├── ca.mo
│ │ ├── da.mo
│ │ ├── de_CH.mo
│ │ ├── de@hebrew.mo
│ │ ├── de.mo
│ │ ├── en@arabic.mo
│ │ ├── en@cyrillic.mo
│ │ ├── en@greek.mo
│ │ ├── en@hebrew.mo
│ │ ├── en@piglatin.mo
│ │ ├── en@quot.mo
│ │ ├── eo.mo
│ │ ├── es.mo
│ │ ├── fi.mo
│ │ ├── fr.mo
│ │ ├── gl.mo
│ │ ├── hu.mo
│ │ ├── id.mo
│ │ ├── it.mo
│ │ ├── ja.mo
│ │ ├── lt.mo
│ │ ├── nb.mo
│ │ ├── nl.mo
│ │ ├── pa.mo
│ │ ├── pl.mo
│ │ ├── pt_BR.mo
│ │ ├── ru.mo
│ │ ├── sl.mo
│ │ ├── sr.mo
│ │ ├── sv.mo
│ │ ├── tr.mo
│ │ ├── uk.mo
│ │ ├── vi.mo
│ │ ├── zh_CN.mo
│ │ └── zh_TW.mo
│ ├── unicode.pf2
│ └── x86_64-efi
│ ├── acpi.mod
│ ├── adler32.mod
│ ├── affs.mod
│ ├── afs.mod
│ ├── ahci.mod
│ ├── all_video.mod
│ ├── aout.mod
│ ├── appleldr.mod
│ ├── archelp.mod
│ ├── ata.mod
│ ├── at_keyboard.mod
│ ├── backtrace.mod
│ ├── bfs.mod
│ ├── bitmap.mod
│ ├── bitmap_scale.mod
│ ├── blocklist.mod
│ ├── boot.mod
│ ├── bsd.mod
│ ├── bswap_test.mod
│ ├── btrfs.mod
│ ├── bufio.mod
│ ├── cat.mod
│ ├── cbfs.mod
│ ├── cbls.mod
│ ├── cbmemc.mod
│ ├── cbtable.mod
│ ├── cbtime.mod
│ ├── chain.mod
│ ├── cmdline_cat_test.mod
│ ├── cmp.mod
│ ├── cmp_test.mod
│ ├── command.lst
│ ├── configfile.mod
│ ├── core.efi
│ ├── cpio_be.mod
│ ├── cpio.mod
│ ├── cpuid.mod
│ ├── crc64.mod
│ ├── cryptodisk.mod
│ ├── crypto.lst
│ ├── crypto.mod
│ ├── cs5536.mod
│ ├── ctz_test.mod
│ ├── datehook.mod
│ ├── date.mod
│ ├── datetime.mod
│ ├── diskfilter.mod
│ ├── disk.mod
│ ├── div.mod
│ ├── div_test.mod
│ ├── dm_nv.mod
│ ├── echo.mod
│ ├── efifwsetup.mod
│ ├── efi_gop.mod
│ ├── efinet.mod
│ ├── efi_uga.mod
│ ├── ehci.mod
│ ├── elf.mod
│ ├── eval.mod
│ ├── exfat.mod
│ ├── exfctest.mod
│ ├── ext2.mod
│ ├── extcmd.mod
│ ├── fat.mod
│ ├── file.mod
│ ├── fixvideo.mod
│ ├── font.mod
│ ├── fshelp.mod
│ ├── fs.lst
│ ├── functional_test.mod
│ ├── gcry_arcfour.mod
│ ├── gcry_blowfish.mod
│ ├── gcry_camellia.mod
│ ├── gcry_cast5.mod
│ ├── gcry_crc.mod
│ ├── gcry_des.mod
│ ├── gcry_dsa.mod
│ ├── gcry_idea.mod
│ ├── gcry_md4.mod
│ ├── gcry_md5.mod
│ ├── gcry_rfc2268.mod
│ ├── gcry_rijndael.mod
│ ├── gcry_rmd160.mod
│ ├── gcry_rsa.mod
│ ├── gcry_seed.mod
│ ├── gcry_serpent.mod
│ ├── gcry_sha1.mod
│ ├── gcry_sha256.mod
│ ├── gcry_sha512.mod
│ ├── gcry_tiger.mod
│ ├── gcry_twofish.mod
│ ├── gcry_whirlpool.mod
│ ├── geli.mod
│ ├── gettext.mod
│ ├── gfxmenu.mod
│ ├── gfxterm_background.mod
│ ├── gfxterm_menu.mod
│ ├── gfxterm.mod
│ ├── gptsync.mod
│ ├── grub.efi
│ ├── gzio.mod
│ ├── halt.mod
│ ├── hashsum.mod
│ ├── hdparm.mod
│ ├── hello.mod
│ ├── help.mod
│ ├── hexdump.mod
│ ├── hfs.mod
│ ├── hfspluscomp.mod
│ ├── hfsplus.mod
│ ├── http.mod
│ ├── iorw.mod
│ ├── iso9660.mod
│ ├── jfs.mod
│ ├── jpeg.mod
│ ├── keylayouts.mod
│ ├── keystatus.mod
│ ├── ldm.mod
│ ├── legacycfg.mod
│ ├── legacy_password_test.mod
│ ├── linux16.mod
│ ├── linuxefi.mod
│ ├── linux.mod
│ ├── loadbios.mod
│ ├── loadenv.mod
│ ├── loopback.mod
│ ├── lsacpi.mod
│ ├── lsefimmap.mod
│ ├── lsefi.mod
│ ├── lsefisystab.mod
│ ├── lsmmap.mod
│ ├── ls.mod
│ ├── lspci.mod
│ ├── lssal.mod
│ ├── luks.mod
│ ├── lvm.mod
│ ├── lzopio.mod
│ ├── macbless.mod
│ ├── macho.mod
│ ├── mdraid09_be.mod
│ ├── mdraid09.mod
│ ├── mdraid1x.mod
│ ├── memdisk.mod
│ ├── memrw.mod
│ ├── minicmd.mod
│ ├── minix2_be.mod
│ ├── minix2.mod
│ ├── minix3_be.mod
│ ├── minix3.mod
│ ├── minix_be.mod
│ ├── minix.mod
│ ├── mmap.mod
│ ├── moddep.lst
│ ├── modinfo.sh
│ ├── morse.mod
│ ├── mpi.mod
│ ├── msdospart.mod
│ ├── mul_test.mod
│ ├── multiboot2.mod
│ ├── multiboot.mod
│ ├── nativedisk.mod
│ ├── net.mod
│ ├── newc.mod
│ ├── nilfs2.mod
│ ├── normal.mod
│ ├── ntfscomp.mod
│ ├── ntfs.mod
│ ├── odc.mod
│ ├── offsetio.mod
│ ├── ohci.mod
│ ├── part_acorn.mod
│ ├── part_amiga.mod
│ ├── part_apple.mod
│ ├── part_bsd.mod
│ ├── part_dfly.mod
│ ├── part_dvh.mod
│ ├── part_gpt.mod
│ ├── partmap.lst
│ ├── part_msdos.mod
│ ├── part_plan.mod
│ ├── part_sun.mod
│ ├── part_sunpc.mod
│ ├── parttool.lst
│ ├── parttool.mod
│ ├── password.mod
│ ├── password_pbkdf2.mod
│ ├── pata.mod
│ ├── pbkdf2.mod
│ ├── pbkdf2_test.mod
│ ├── pcidump.mod
│ ├── play.mod
│ ├── png.mod
│ ├── priority_queue.mod
│ ├── probe.mod
│ ├── procfs.mod
│ ├── progress.mod
│ ├── raid5rec.mod
│ ├── raid6rec.mod
│ ├── random.mod
│ ├── read.mod
│ ├── reboot.mod
│ ├── regexp.mod
│ ├── reiserfs.mod
│ ├── relocator.mod
│ ├── romfs.mod
│ ├── scsi.mod
│ ├── search_fs_file.mod
│ ├── search_fs_uuid.mod
│ ├── search_label.mod
│ ├── search.mod
│ ├── serial.mod
│ ├── setjmp.mod
│ ├── setjmp_test.mod
│ ├── setpci.mod
│ ├── sfs.mod
│ ├── shift_test.mod
│ ├── signature_test.mod
│ ├── sleep.mod
│ ├── sleep_test.mod
│ ├── spkmodem.mod
│ ├── squash4.mod
│ ├── syslinuxcfg.mod
│ ├── tar.mod
│ ├── terminal.lst
│ ├── terminal.mod
│ ├── terminfo.mod
│ ├── test_blockarg.mod
│ ├── testload.mod
│ ├── test.mod
│ ├── testspeed.mod
│ ├── tftp.mod
│ ├── tga.mod
│ ├── time.mod
│ ├── trig.mod
│ ├── tr.mod
│ ├── true.mod
│ ├── udf.mod
│ ├── ufs1_be.mod
│ ├── ufs1.mod
│ ├── ufs2.mod
│ ├── uhci.mod
│ ├── usb_keyboard.mod
│ ├── usb.mod
│ ├── usbms.mod
│ ├── usbserial_common.mod
│ ├── usbserial_ftdi.mod
│ ├── usbserial_pl2303.mod
│ ├── usbserial_usbdebug.mod
│ ├── usbtest.mod
│ ├── verify.mod
│ ├── video_bochs.mod
│ ├── video_cirrus.mod
│ ├── video_colors.mod
│ ├── video_fb.mod
│ ├── videoinfo.mod
│ ├── video.lst
│ ├── video.mod
│ ├── videotest_checksum.mod
│ ├── videotest.mod
│ ├── xfs.mod
│ ├── xnu.mod
│ ├── xnu_uuid.mod
│ ├── xnu_uuid_test.mod
│ ├── xzio.mod
│ ├── zfscrypt.mod
│ ├── zfsinfo.mod
│ └── zfs.mod
├── initrd.img-4.9.0-7-amd64
├── lost+found
├── System.map-4.9.0-7-amd64
└── vmlinuz-4.9.0-7-amd64
CentOS7 tree:
# tree /boot/
/boot/
├── config-3.10.0-862.6.3.el7.x86_64
├── efi
│ └── EFI
│ ├── BOOT
│ │ ├── BOOTX64.EFI
│ │ └── fbx64.efi
│ └── centos
│ ├── BOOT.CSV
│ ├── BOOTX64.CSV
│ ├── fonts
│ │ └── unicode.pf2
│ ├── grub.cfg
│ ├── grubenv
│ ├── grubx64.efi
│ ├── mmx64.efi
│ ├── shim.efi
│ ├── shimx64-centos.efi
│ └── shimx64.efi
├── grub
│ └── splash.xpm.gz
├── grub2
│ └── grubenv -> /boot/efi/EFI/centos/grubenv
├── initramfs-0-rescue-6b17af8b36e6498a86e9e99c01d45921.img
├── initramfs-3.10.0-514.el7.x86_64.img
├── initramfs-3.10.0-862.6.3.el7.x86_64.img
├── initramfs-3.10.0-862.6.3.el7.x86_64kdump.img
├── symvers-3.10.0-862.6.3.el7.x86_64.gz
├── System.map-3.10.0-862.6.3.el7.x86_64
├── vmlinuz-0-rescue-6b17af8b36e6498a86e9e99c01d45921
└── vmlinuz-3.10.0-862.6.3.el7.x86_64
Even on a CentOS7 system, the UEFI chainloading did not succeed as well even though the file efi/EFI/BOOT/BOOTX64.EFI does exist.
I’m no grub expert
I had a similar issue with windows 2012 r2 uefi boot and sorted out with the below modification of the template:
<% paths.each do |path| %>
elif [ -f ($root)/EFI/<%= path %>/grubx64.efi ]; then
chainloader ($root)/EFI/<%= path %>/grubx64.efi
<% end -%>
+ elif [ -f ($root)/EFI/Microsoft/boot/bootmgfw.efi ]; then
+ chainloader ($root)/EFI/Microsoft/boot/bootmgfw.efi
else
echo File grubx64.efi not found on ESP.
echo Update 'pxegrub2_chainload' paths array with:
ls ($root)/EFI
Does the EFI/Microsoft/boot/ directory contain multiple .efi files?
lzap
October 10, 2018, 5:51am
9
I only tested this in libvirt VM, do not hesitate to send your patches to our community-templates repo please.
The problem is that grub2 only allows searching volumes by files not directories, that would be easier. I am gonna change that a bit so it tries to find the target EFI file instead of BOOTX64.EFI. I had impression that all OSes have that, I was wrong.
Can you tell me guys what ESP partition label did Windows and Debian OS installer set? We can also search by label too.
Once I have some patches, I’ll share them of course. I can test different HP machines equipped with EFI @ work to see if what works best. If you have patches available, I can help test them if you want.
I’m back in the office tomorrow, I’ll check which label are assigned to the EFI partition for debian.
The efi partition is not formatted with a (vfat) label per se. I’ve checked on CentOS as well as Debian and Arch Linux. I’ll keep digging though.
lzap
October 11, 2018, 1:09pm
12
This is on my radar, I just have some other duties. In the meantime please file a Redmine issue describing what does not work. Looks like we need to iterate through list of expected files for that search until we find the correct entry.
I’ll create an issue in Redmine for this. While trying different solutions, I now feel like Edison; I’ve found several ways not to chainload efi.
Sorry for the late answer. Here is the windows 2012 r2 EFI partition content:
PS Y:\EFI\Microsoft\Boot> dir
Directory: Y:\EFI\Microsoft\Boot
Mode LastWriteTime Length Name
---- ------------- ------ ----
d---- 10/4/2018 5:54 PM bg-BG
d---- 10/4/2018 5:54 PM cs-CZ
d---- 10/4/2018 5:54 PM da-DK
d---- 10/4/2018 5:54 PM de-DE
d---- 10/4/2018 5:54 PM el-GR
d---- 10/4/2018 5:54 PM en-GB
d---- 10/4/2018 5:54 PM en-US
d---- 10/4/2018 5:54 PM es-ES
d---- 10/4/2018 5:54 PM et-EE
d---- 10/4/2018 5:54 PM fi-FI
d---- 10/4/2018 5:54 PM fr-FR
d---- 10/4/2018 5:54 PM hr-HR
d---- 10/4/2018 5:54 PM hu-HU
d---- 10/4/2018 5:54 PM it-IT
d---- 10/4/2018 5:54 PM ja-JP
d---- 10/4/2018 5:54 PM ko-KR
d---- 10/4/2018 5:54 PM lt-LT
d---- 10/4/2018 5:54 PM lv-LV
d---- 10/4/2018 5:54 PM nb-NO
d---- 10/4/2018 5:54 PM nl-NL
d---- 10/4/2018 5:54 PM pl-PL
d---- 10/4/2018 5:54 PM pt-BR
d---- 10/4/2018 5:54 PM pt-PT
d---- 10/4/2018 5:54 PM qps-ploc
d---- 10/4/2018 5:54 PM ro-RO
d---- 10/4/2018 5:54 PM ru-RU
d---- 10/4/2018 5:54 PM sk-SK
d---- 10/4/2018 5:54 PM sl-SI
d---- 10/4/2018 5:54 PM sr-Latn-CS
d---- 10/4/2018 5:54 PM sr-Latn-RS
d---- 10/4/2018 5:54 PM sv-SE
d---- 10/4/2018 5:54 PM tr-TR
d---- 10/4/2018 5:54 PM uk-UA
d---- 10/4/2018 5:54 PM zh-CN
d---- 10/4/2018 5:54 PM zh-HK
d---- 10/4/2018 5:54 PM zh-TW
d---- 10/4/2018 5:54 PM Fonts
d---- 10/4/2018 5:54 PM Resources
-a--- 10/11/2018 7:22 AM 49152 BCD
-a--- 2/7/2018 9:25 AM 5023 boot.stl
-a--- 12/14/2017 12:49 AM 1629536 bootmgfw.efi
-a--- 12/14/2017 12:49 AM 1625952 bootmgr.efi
-a--- 11/21/2014 8:45 PM 1500504 memtest.efi
PS Y:\EFI\Microsoft\Boot>
Thank you for the listing. Do you know if the EFI implementation of Windows 8/10 is similar to Windows 12 r2?
I’ve altered the pxegrub2_chainload snippet which seems to work on both Debian and CentOS deployed systems (testing on virtual machines and physical HP machines). @lzap : Can you review the snippet?
<%#
kind: snippet
name: pxegrub2_chainload
model: ProvisioningTemplate
snippet: true
%>
menuentry 'Chainload Grub2 EFI from ESP' --id local {
insmod part_gpt
insmod fat
insmod chain
for efi in (*,gpt*)/efi/*/*.efi (*,gpt*)/efi/*/*/*.efi (*,gpt*)/*.efi (*,gpt*)/*/*.efi ; do
regexp --set=1:efi_device '^\((.*)\)/' "${efi}"
regexp --set=1:efi_path '(.*)/.*$' "${efi}"
regexp --set=1:efi_file '.*\/(.*)$' "${efi}"
if [ "$efi_file" == "grubx64.efi" ]; then
set root=$efi_device
set efi_found=true
break
fi
if [ "$efi_file" == "bootmgfw.efi" ]; then
set root=$efi_device
set efi_found=true
break
fi
done
echo "Found efi boot on $efi_path/$efi_file"
sleep 2
if [ -f $efi_path/$efi_file ]; then
chainloader $efi_path/$efi_file
else
echo File grubx64.efi nor bootmgfw.efi not found on ESP.
echo Update 'pxegrub2_chainload' paths array with:
ls ($root)/EFI
echo The system will halt in 2 minutes or
echo press ESC to halt immediately.
sleep -i 120
halt --no-apm
fi
}
menuentry 'Chainload into BIOS bootloader on first disk' --id local_chain_hd0 {
set root=(hd0,0)
chainloader +1
}
menuentry 'Chainload into BIOS bootloader on second disk' --id local_chain_hd1 {
set root=(hd1,0)
chainloader +1
}
If this provides a working solution, what do I need to do in order to add this to future foreman releases?
1 Like
I’m not sure. I never deployed Windows 8/10 using foreman but I think you can check EFI partition using “diskpart” command if you use windows 8/10 on your laptop/pc.
lzap
October 12, 2018, 12:12pm
18
Awesome! Would Grub2 pick also regular shell syntax of:
if [ "$efi_file" == "grubx64.efi" -o "$efi_file" == "bootmgfw.efi" ]; then
Also we want to search for shim.efi as well (actually as first), on Red Hats this is the signed shim which then loads (unsigned) Grub2. The question is if this will work in SecureBoot mode, we need to test.
But overall this is great improvement. Feel free to file PR into community templates so I can review and test from there.
I’ve made a mistake when creating an issue in the redmine for foreman. Bug #25185: Pxegrub2_chainload unable to determine disk containing /EFI/BOOT/BOOTX64.EFI - Templates - Foreman is under project templates and should be under project Foreman. How do I move the issue from project Templates to Foreman?
but it seems that the search is unable to determine which device should be used as root.
