Rebuild EFI System Partition and Grub on a Hyper-V VM
Rebuild EFI System Partition and Grub on a Hyper-V VM
Hi,
Cloned a physical centos 7 machine disk image (which happened to have a debian boot on an alternative disk partition too)
using clonezilla
Machine is called Kelvin in this case.
Made a generation 2 vm in hyper-v 2019 and gave it enough space and ram etc. Disabled secure boot to stop
vm whining about signatures.
Booted clonezilla live and restored image to machine
Tried to boot and it failed - as expected , figured out the boot pattern so i could do it manually and deal
with changed kernel modules for "new" hardware and then regenerate and reinstall grub
Manual commands in this case were ...
set root=(hd0,gpt3)
linuxefi /boot/vmlinuz-3.10.0-1160.76.1.el7.x86_64 root=/dev/sda3
initrdefi /boot/initramfs-3.10.0-1160.76.1.el7.x86_64.img
boot
It still wont boot from the EFI System partition. What have I misunderstood or forgotten?
Many thanks for reading!
From /boot
[root@kelvin boot]# ls -l
total 270212
-rw-r--r-- 1 root root 153619 Jun 28 16:41 config-3.10.0-1160.71.1.el7.x86_64
-rw-r--r-- 1 root root 153619 Aug 10 17:25 config-3.10.0-1160.76.1.el7.x86_64
drwx------ 3 root root 4096 Jan 1 1970 efi
drwxr-xr-x. 2 root root 4096 Apr 16 2019 grub
drwx------. 6 root root 4096 Sep 20 13:33 grub2
-rw------- 1 root root 83303922 Sep 15 16:29 initramfs-0-rescue-ef2169dfabca4e4aba215a1bc9598367.img
-rw------- 1 root root 82408284 Oct 3 14:33 initramfs-3.10.0-1160.71.1.el7.x86_64.img
-rw------- 1 root root 82409410 Oct 3 15:14 initramfs-3.10.0-1160.76.1.el7.x86_64.img
-rw-r--r-- 1 root root 320652 Jun 28 16:42 symvers-3.10.0-1160.71.1.el7.x86_64.gz
-rw-r--r-- 1 root root 320674 Aug 10 17:25 symvers-3.10.0-1160.76.1.el7.x86_64.gz
-rw------- 1 root root 3622036 Jun 28 16:41 System.map-3.10.0-1160.71.1.el7.x86_64
-rw------- 1 root root 3622646 Aug 10 17:25 System.map-3.10.0-1160.76.1.el7.x86_64
-rwxr-xr-x 1 root root 6781544 Sep 15 16:29 vmlinuz-0-rescue-ef2169dfabca4e4aba215a1bc9598367
-rwxr-xr-x 1 root root 6777448 Jun 28 16:42 vmlinuz-3.10.0-1160.71.1.el7.x86_64
-rwxr-xr-x 1 root root 6781544 Aug 10 17:25 vmlinuz-3.10.0-1160.76.1.el7.x86_64
[root@kelvin boot]# dracut -f
[root@kelvin boot]# grub2-mkconfig -o /boot/efi/EFI/centos/grub.cfg
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-3.10.0-1160.76.1.el7.x86_64
Found initrd image: /boot/initramfs-3.10.0-1160.76.1.el7.x86_64.img
Found linux image: /boot/vmlinuz-3.10.0-1160.71.1.el7.x86_64
Found initrd image: /boot/initramfs-3.10.0-1160.71.1.el7.x86_64.img
Found linux image: /boot/vmlinuz-0-rescue-ef2169dfabca4e4aba215a1bc9598367
Found initrd image: /boot/initramfs-0-rescue-ef2169dfabca4e4aba215a1bc9598367.img
Found Debian GNU/Linux (9.8) on /dev/sda2
done
Reinstalled grub2 x86 efi packages to make sure they were there, then ...
[root@kelvin boot]# grub2-install /dev/sda
Installing for x86_64-efi platform.
Installation finished. No error reported.
[root@kelvin log]# efibootmgr -v
BootCurrent: 0003
Timeout: 0 seconds
BootOrder: 0003,0006,0005,0002,0000,0001
Boot0000* EFI SCSI Device AcpiEx(VMBus,,)/VenHw(9b17e5a2-0891-42dd-b653-80b5c22809ba,d96361baa104294db60572e2ffb1dc7f874a34564c1f944985f5b71234f08799)/SCSI(0,1)
Boot0001* EFI Network AcpiEx(VMBus,,)/VenHw(9b17e5a2-0891-42dd-b653-80b5c22809ba,635161f83edfc546913ff2d2f965ed0e9ad04273af154047899abe0384babbe4)/MAC(000000000000,0)/IPv4(0.0.0.00.0.0.0,0,0)
Boot0002* EFI SCSI Device AcpiEx(VMBus,,)/VenHw(9b17e5a2-0891-42dd-b653-80b5c22809ba,d96361baa104294db60572e2ffb1dc7f874a34564c1f944985f5b71234f08799)/SCSI(0,0)
Boot0003* centos HD(1,GPT,1529dc46-3803-4645-b8e4-8d08ecb11306,0x800,0x1dc800)/File(\EFI\centos\grubx64.efi)
Boot0005* debian HD(1,GPT,1529dc46-3803-4645-b8e4-8d08ecb11306,0x800,0x1dc800)/File(\EFI\debian\shimx64.efi)
Boot0006* Linux HD(1,GPT,1529dc46-3803-4645-b8e4-8d08ecb11306,0x800,0x1dc800)/File(\EFI\centos\grub.efi)
Just to confirm
-rwx------ 1 root root 9670 Oct 3 16:06 grub.cfg
-rwx------ 1 root root 126464 Oct 3 16:06 grubx64.efi
are both present in /boot/efi/EFI/centos
[root@kelvin boot]# lsblk -f
NAME FSTYPE LABEL UUID MOUNTPOINT
sda
├─sda1 vfat ACDA-AC2D /boot/efi
├─sda2 ext4 root 06887738-dacf-445b-8c31-bcc8f2b6bcf8
├─sda3 ext4 root76 5ec02c38-ba0e-403d-9bb0-c529163f5d40 /
├─sda4 swap swap 5f5b0ab2-d5c3-4029-8281-d8ebfb7ecd5b [SWAP]
└─sda5 ext4 disk1 24da41f0-d147-45b1-9cef-f404972c9ec8 /disk1
sr0
[root@kelvin boot]# awk -F\' '$1=="menuentry " {print i++ " : " $2}' /boot/efi/EFI/centos/grub.cfg
0 : CentOS Linux (3.10.0-1160.76.1.el7.x86_64) 7 (Core)
1 : CentOS Linux (3.10.0-1160.71.1.el7.x86_64) 7 (Core)
2 : CentOS Linux (0-rescue-ef2169dfabca4e4aba215a1bc9598367) 7 (Core)
3 : Debian GNU/Linux (9.8) (on /dev/sda2)
Still bombs out to grub> prompt when I try to boot it and requires me to copy n paste the 4 commands from the top to boot.
Regards,
Stephen.
Cloned a physical centos 7 machine disk image (which happened to have a debian boot on an alternative disk partition too)
using clonezilla
Machine is called Kelvin in this case.
Made a generation 2 vm in hyper-v 2019 and gave it enough space and ram etc. Disabled secure boot to stop
vm whining about signatures.
Booted clonezilla live and restored image to machine
Tried to boot and it failed - as expected , figured out the boot pattern so i could do it manually and deal
with changed kernel modules for "new" hardware and then regenerate and reinstall grub
Manual commands in this case were ...
set root=(hd0,gpt3)
linuxefi /boot/vmlinuz-3.10.0-1160.76.1.el7.x86_64 root=/dev/sda3
initrdefi /boot/initramfs-3.10.0-1160.76.1.el7.x86_64.img
boot
It still wont boot from the EFI System partition. What have I misunderstood or forgotten?
Many thanks for reading!
From /boot
[root@kelvin boot]# ls -l
total 270212
-rw-r--r-- 1 root root 153619 Jun 28 16:41 config-3.10.0-1160.71.1.el7.x86_64
-rw-r--r-- 1 root root 153619 Aug 10 17:25 config-3.10.0-1160.76.1.el7.x86_64
drwx------ 3 root root 4096 Jan 1 1970 efi
drwxr-xr-x. 2 root root 4096 Apr 16 2019 grub
drwx------. 6 root root 4096 Sep 20 13:33 grub2
-rw------- 1 root root 83303922 Sep 15 16:29 initramfs-0-rescue-ef2169dfabca4e4aba215a1bc9598367.img
-rw------- 1 root root 82408284 Oct 3 14:33 initramfs-3.10.0-1160.71.1.el7.x86_64.img
-rw------- 1 root root 82409410 Oct 3 15:14 initramfs-3.10.0-1160.76.1.el7.x86_64.img
-rw-r--r-- 1 root root 320652 Jun 28 16:42 symvers-3.10.0-1160.71.1.el7.x86_64.gz
-rw-r--r-- 1 root root 320674 Aug 10 17:25 symvers-3.10.0-1160.76.1.el7.x86_64.gz
-rw------- 1 root root 3622036 Jun 28 16:41 System.map-3.10.0-1160.71.1.el7.x86_64
-rw------- 1 root root 3622646 Aug 10 17:25 System.map-3.10.0-1160.76.1.el7.x86_64
-rwxr-xr-x 1 root root 6781544 Sep 15 16:29 vmlinuz-0-rescue-ef2169dfabca4e4aba215a1bc9598367
-rwxr-xr-x 1 root root 6777448 Jun 28 16:42 vmlinuz-3.10.0-1160.71.1.el7.x86_64
-rwxr-xr-x 1 root root 6781544 Aug 10 17:25 vmlinuz-3.10.0-1160.76.1.el7.x86_64
[root@kelvin boot]# dracut -f
[root@kelvin boot]# grub2-mkconfig -o /boot/efi/EFI/centos/grub.cfg
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-3.10.0-1160.76.1.el7.x86_64
Found initrd image: /boot/initramfs-3.10.0-1160.76.1.el7.x86_64.img
Found linux image: /boot/vmlinuz-3.10.0-1160.71.1.el7.x86_64
Found initrd image: /boot/initramfs-3.10.0-1160.71.1.el7.x86_64.img
Found linux image: /boot/vmlinuz-0-rescue-ef2169dfabca4e4aba215a1bc9598367
Found initrd image: /boot/initramfs-0-rescue-ef2169dfabca4e4aba215a1bc9598367.img
Found Debian GNU/Linux (9.8) on /dev/sda2
done
Reinstalled grub2 x86 efi packages to make sure they were there, then ...
[root@kelvin boot]# grub2-install /dev/sda
Installing for x86_64-efi platform.
Installation finished. No error reported.
[root@kelvin log]# efibootmgr -v
BootCurrent: 0003
Timeout: 0 seconds
BootOrder: 0003,0006,0005,0002,0000,0001
Boot0000* EFI SCSI Device AcpiEx(VMBus,,)/VenHw(9b17e5a2-0891-42dd-b653-80b5c22809ba,d96361baa104294db60572e2ffb1dc7f874a34564c1f944985f5b71234f08799)/SCSI(0,1)
Boot0001* EFI Network AcpiEx(VMBus,,)/VenHw(9b17e5a2-0891-42dd-b653-80b5c22809ba,635161f83edfc546913ff2d2f965ed0e9ad04273af154047899abe0384babbe4)/MAC(000000000000,0)/IPv4(0.0.0.00.0.0.0,0,0)
Boot0002* EFI SCSI Device AcpiEx(VMBus,,)/VenHw(9b17e5a2-0891-42dd-b653-80b5c22809ba,d96361baa104294db60572e2ffb1dc7f874a34564c1f944985f5b71234f08799)/SCSI(0,0)
Boot0003* centos HD(1,GPT,1529dc46-3803-4645-b8e4-8d08ecb11306,0x800,0x1dc800)/File(\EFI\centos\grubx64.efi)
Boot0005* debian HD(1,GPT,1529dc46-3803-4645-b8e4-8d08ecb11306,0x800,0x1dc800)/File(\EFI\debian\shimx64.efi)
Boot0006* Linux HD(1,GPT,1529dc46-3803-4645-b8e4-8d08ecb11306,0x800,0x1dc800)/File(\EFI\centos\grub.efi)
Just to confirm
-rwx------ 1 root root 9670 Oct 3 16:06 grub.cfg
-rwx------ 1 root root 126464 Oct 3 16:06 grubx64.efi
are both present in /boot/efi/EFI/centos
[root@kelvin boot]# lsblk -f
NAME FSTYPE LABEL UUID MOUNTPOINT
sda
├─sda1 vfat ACDA-AC2D /boot/efi
├─sda2 ext4 root 06887738-dacf-445b-8c31-bcc8f2b6bcf8
├─sda3 ext4 root76 5ec02c38-ba0e-403d-9bb0-c529163f5d40 /
├─sda4 swap swap 5f5b0ab2-d5c3-4029-8281-d8ebfb7ecd5b [SWAP]
└─sda5 ext4 disk1 24da41f0-d147-45b1-9cef-f404972c9ec8 /disk1
sr0
[root@kelvin boot]# awk -F\' '$1=="menuentry " {print i++ " : " $2}' /boot/efi/EFI/centos/grub.cfg
0 : CentOS Linux (3.10.0-1160.76.1.el7.x86_64) 7 (Core)
1 : CentOS Linux (3.10.0-1160.71.1.el7.x86_64) 7 (Core)
2 : CentOS Linux (0-rescue-ef2169dfabca4e4aba215a1bc9598367) 7 (Core)
3 : Debian GNU/Linux (9.8) (on /dev/sda2)
Still bombs out to grub> prompt when I try to boot it and requires me to copy n paste the 4 commands from the top to boot.
Regards,
Stephen.
Re: Rebuild EFI System Partition and Grub on a Hyper-V VM
The original machine was also in UEFI mode? Can you post the output from fdisk -u /dev/sda and I think it would be useful to see the content of the grub.cfg file.
Best way to cater for new hardware is to boot the rescue kernel at the bottom of the list then either yum reinstall kernel-3.10.0-1160.76.1.el7.x86_64 or dracut -f --kver 3.10.0-1160.76.1.el7.x86_64 (might need to be --kver=3.10.0-1160.76.1.el7.x86_64, not 100%). However you can only do that if you can get to the grub menu.
And no separate /boot partition?
Best way to cater for new hardware is to boot the rescue kernel at the bottom of the list then either yum reinstall kernel-3.10.0-1160.76.1.el7.x86_64 or dracut -f --kver 3.10.0-1160.76.1.el7.x86_64 (might need to be --kver=3.10.0-1160.76.1.el7.x86_64, not 100%). However you can only do that if you can get to the grub menu.
And no separate /boot partition?
The future appears to be RHEL or Debian. I think I'm going Debian.
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke
Re: Rebuild EFI System Partition and Grub on a Hyper-V VM
Hi,
Original physical host was EFI booting yet.
This is a portion of the grub.cfg pertaining to the default boot option only as it's quite large;
I did wonder if I needed to do something to tell it about any changing partition UUIDs as I don't completely understand those (I'm old) so wasn't certain. Here's a portion of the fstab that does work once I boot the machine
Finally , you're correct no separate boot partition , just the /boot/efi ;
Thanks for looking.
-Stephen.
Original physical host was EFI booting yet.
Code: Select all
[root@kelvin centos]# fdisk -u /dev/sda
WARNING: fdisk GPT support is currently new, and therefore in an experimental phase. Use at your own discretion.
Welcome to fdisk (util-linux 2.23.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.
Command (m for help): p
Disk /dev/sda: 343.6 GB, 343597383680 bytes, 671088640 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk label type: gpt
Disk identifier: 541822A1-88CF-41E8-AF6B-8AE03BE9E6AD
# Start End Size Type Name
1 2048 1953791 953M EFI System EFI System Partition
2 1953792 39061503 17.7G Linux filesyste primary
3 39061504 78125055 18.6G Linux filesyste primary
4 78125056 117186559 18.6G Linux filesyste primary
5 117186560 625141759 242.2G Linux filesyste primary
This is a portion of the grub.cfg pertaining to the default boot option only as it's quite large;
Code: Select all
### BEGIN /etc/grub.d/10_linux ###
menuentry 'CentOS Linux (3.10.0-1160.76.1.el7.x86_64) 7 (Core)' --class centos --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-3.10.0-1160.76.1.el7.x86_64-advanced-5ec02c38-ba0e-403d-9bb0-c529163f5d
40' {
load_video
set gfxpayload=keep
insmod gzio
insmod part_gpt
insmod ext2
set root='hd0,gpt3'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt3 --hint-efi=hd0,gpt3 --hint-baremetal=ahci0,gpt3 5ec02c38-ba0e-403d-9bb0-c529163f5d40
else
search --no-floppy --fs-uuid --set=root 5ec02c38-ba0e-403d-9bb0-c529163f5d40
fi
linuxefi /boot/vmlinuz-3.10.0-1160.76.1.el7.x86_64 root=UUID=5ec02c38-ba0e-403d-9bb0-c529163f5d40 ro crashkernel=auto rhgb quiet
initrdefi /boot/initramfs-3.10.0-1160.76.1.el7.x86_64.img
}
Code: Select all
#
# /etc/fstab
# Created by anaconda on Tue Apr 16 12:39:20 2019
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
UUID=5ec02c38-ba0e-403d-9bb0-c529163f5d40 / ext4 defaults 1 1
UUID=ACDA-AC2D /boot/efi vfat umask=0077,shortname=winnt 0 0
UUID=5f5b0ab2-d5c3-4029-8281-d8ebfb7ecd5b swap swap defaults 0 0
Code: Select all
[root@kelvin centos]# df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 3.9G 0 3.9G 0% /dev
tmpfs 3.9G 4.0K 3.9G 1% /dev/shm
tmpfs 3.9G 17M 3.9G 1% /run
tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup
/dev/sda3 19G 9.4G 7.9G 55% /
/dev/sda1 952M 18M 935M 2% /boot/efi
/dev/sda5 238G 65G 173G 28% /disk1
-Stephen.
Re: Rebuild EFI System Partition and Grub on a Hyper-V VM
I'm pretty sure that being dumped at the grub menu means it cannot find its grub.cfg for some reason, or perhaps that it has some catastrophic error in it. There is no fleeting glimpse of anything before it presents the grub menu that might be an error message? Also, can you post the output from ls -la /boot/efi/EFI/centos/grubenv
I think I see the problem,. In your efibootmgr output you have
and that long string starting 1529dc46 should match what you see in the output from blkid | grep sda1 - look in the PARTUUID= bit at the end. Or I also see it in the output from gdisk /dev/sda then press 'i' then 1. If you don't have gdisk installed then in it's in the EPEL repo.
I think the uuid either needs to change in the EFI settings or you have to change that Partition unique GUID to match the EFI settings (1529dc46-3803-4645-b8e4-8d08ecb11306).
Just looked and I think you can change the PARTUUID from gdisk using x for expert then c 'change partition GUID'.
I think I see the problem,. In your efibootmgr output you have
Code: Select all
Boot0003* centos HD(1,GPT,1529dc46-3803-4645-b8e4-8d08ecb11306,0x800,0x1dc800)/File(\EFI\centos\grubx64.efi)
I think the uuid either needs to change in the EFI settings or you have to change that Partition unique GUID to match the EFI settings (1529dc46-3803-4645-b8e4-8d08ecb11306).
Just looked and I think you can change the PARTUUID from gdisk using x for expert then c 'change partition GUID'.
The future appears to be RHEL or Debian. I think I'm going Debian.
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke
Re: Rebuild EFI System Partition and Grub on a Hyper-V VM
Hi,
I think the PARTUUID is correct , it matches, and is the PARTUUID of the EFI System Partition, the one that mounts eventually as /boot/efi. Each bootable operating system line in efibootmgr -v shows this same PARTUUID and the correspondig related bootloader, EFI\centos\grubx64.efi in the case of the centos 7.6 bootable. I think it might be the grubx64.efi that is failing to load a grub.cfg from the present working directory and bombing out to the grub> prompt - and the cfg is definitely there.
For reference:
[root@kelvin ~]# blkid
/dev/sda1: UUID="ACDA-AC2D" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="1529dc46-3803-4645-b8e4-8d08ecb11306"
/dev/sda2: LABEL="root" UUID="06887738-dacf-445b-8c31-bcc8f2b6bcf8" TYPE="ext4" PARTLABEL="primary" PARTUUID="6d3c9736-2df3-4ad4-94e2-8c9caca68dbd"
/dev/sda3: LABEL="root76" UUID="5ec02c38-ba0e-403d-9bb0-c529163f5d40" TYPE="ext4" PARTLABEL="primary" PARTUUID="bf2003f7-4a77-41fb-84e0-c4e5fb62b493"
/dev/sda4: LABEL="swap" UUID="5f5b0ab2-d5c3-4029-8281-d8ebfb7ecd5b" TYPE="swap" PARTLABEL="primary" PARTUUID="334d0e77-7656-4e5f-99c0-01c687cfdb26"
/dev/sda5: LABEL="disk1" UUID="24da41f0-d147-45b1-9cef-f404972c9ec8" TYPE="ext4" PARTLABEL="primary" PARTUUID="49b38c5a-ec57-49fc-a37a-735082440e41"
Grubenv is present;
[root@kelvin ~]# ls -la /boot/efi/EFI/centos/grubenv
-rwx------ 1 root root 1024 Sep 15 16:29 /boot/efi/EFI/centos/grubenv
There are no customisations in related 40_custom and the debian os is found on /dev/sda2 by os_prober (but we can ignore it pretty much and concentrate on centos)
I'm beginning to wonder if centos really does put it's grub.cfg for UEFI boot in the directory /boot/efi/EFI/centos together with the grub executable (such as grubx64.efi) - the mere prescence of the grub2 dir there as well makes me wonder - even though it is empty in this case.
Regards,
Stephen.
I think the PARTUUID is correct , it matches, and is the PARTUUID of the EFI System Partition, the one that mounts eventually as /boot/efi. Each bootable operating system line in efibootmgr -v shows this same PARTUUID and the correspondig related bootloader, EFI\centos\grubx64.efi in the case of the centos 7.6 bootable. I think it might be the grubx64.efi that is failing to load a grub.cfg from the present working directory and bombing out to the grub> prompt - and the cfg is definitely there.
For reference:
[root@kelvin ~]# blkid
/dev/sda1: UUID="ACDA-AC2D" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="1529dc46-3803-4645-b8e4-8d08ecb11306"
/dev/sda2: LABEL="root" UUID="06887738-dacf-445b-8c31-bcc8f2b6bcf8" TYPE="ext4" PARTLABEL="primary" PARTUUID="6d3c9736-2df3-4ad4-94e2-8c9caca68dbd"
/dev/sda3: LABEL="root76" UUID="5ec02c38-ba0e-403d-9bb0-c529163f5d40" TYPE="ext4" PARTLABEL="primary" PARTUUID="bf2003f7-4a77-41fb-84e0-c4e5fb62b493"
/dev/sda4: LABEL="swap" UUID="5f5b0ab2-d5c3-4029-8281-d8ebfb7ecd5b" TYPE="swap" PARTLABEL="primary" PARTUUID="334d0e77-7656-4e5f-99c0-01c687cfdb26"
/dev/sda5: LABEL="disk1" UUID="24da41f0-d147-45b1-9cef-f404972c9ec8" TYPE="ext4" PARTLABEL="primary" PARTUUID="49b38c5a-ec57-49fc-a37a-735082440e41"
Grubenv is present;
[root@kelvin ~]# ls -la /boot/efi/EFI/centos/grubenv
-rwx------ 1 root root 1024 Sep 15 16:29 /boot/efi/EFI/centos/grubenv
There are no customisations in related 40_custom and the debian os is found on /dev/sda2 by os_prober (but we can ignore it pretty much and concentrate on centos)
I'm beginning to wonder if centos really does put it's grub.cfg for UEFI boot in the directory /boot/efi/EFI/centos together with the grub executable (such as grubx64.efi) - the mere prescence of the grub2 dir there as well makes me wonder - even though it is empty in this case.
Regards,
Stephen.
Re: Rebuild EFI System Partition and Grub on a Hyper-V VM
Hi,
I've further noticed while looking at the original physical host to compare that the efibootmgr there used shimx64.efi first not grubx64.efi
OLD :
Boot0009* CentOS HD(1,GPT,1529dc46-3803-4645-b8e4-8d08ecb11306,0x800,0x1dc800)/File(\EFI\centos\shimx64.efi)
So now I am wondering if when I did my grub2-mkconfig followed by the grub2-install , did I select the wrong target type (x86_64.efi), as that seems to have changed the efibootmgr to call grubx64.efi and not shimx64.efi
My trouble is I dont fully understand the bootloading and chainloader process.
I can I think try changing the manually using efibootmgr and see what happens.
Regards,
Stephen.
I've further noticed while looking at the original physical host to compare that the efibootmgr there used shimx64.efi first not grubx64.efi
OLD :
Boot0009* CentOS HD(1,GPT,1529dc46-3803-4645-b8e4-8d08ecb11306,0x800,0x1dc800)/File(\EFI\centos\shimx64.efi)
So now I am wondering if when I did my grub2-mkconfig followed by the grub2-install , did I select the wrong target type (x86_64.efi), as that seems to have changed the efibootmgr to call grubx64.efi and not shimx64.efi
My trouble is I dont fully understand the bootloading and chainloader process.
I can I think try changing the manually using efibootmgr and see what happens.
Regards,
Stephen.
Re: Rebuild EFI System Partition and Grub on a Hyper-V VM
I think shim is used for secure boot and you have that disabled.
So that would end up being /dev/sda1/File(\EFI\centos\grubx64.efi) or /boot/EFI/centos/grubx64.efi. Does that exist?
Code: Select all
Boot0003* centos HD(1,GPT,1529dc46-3803-4645-b8e4-8d08ecb11306,0x800,0x1dc800)/File(\EFI\centos\grubx64.efi)
The future appears to be RHEL or Debian. I think I'm going Debian.
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke
Re: Rebuild EFI System Partition and Grub on a Hyper-V VM
Hi,
Yip, re shimx64.efi , I read about that a bit after posting and , yes, it's disabled although we are EFI (as Generation 2 hyper-v). Original system was using secure option hence difference.
and yes the grubx64.efi exists - /dev/sda1 being the EFI partition mounted on /boot/efi , therefore the file exists as /boot/efi/EFI/centos/grubx64.efi , with grub.cfg in the same directory.
Do you happen to know what the "1" after the HD( definition beginning is? I presume it is the disk number, however maybe the index starts at 1 and not 0. I am asking as when it bombs to the grub> prompt , I specify HD "0" to get it to boot manually as below. However if this was actually an issue I don't think it would find grub to bomb out too in the first place.
I'm just not convinced it's finding the grub.cfg at all but have no debug method.
set root=(hd0,gpt3)
Regards,
Stephen.
Yip, re shimx64.efi , I read about that a bit after posting and , yes, it's disabled although we are EFI (as Generation 2 hyper-v). Original system was using secure option hence difference.
and yes the grubx64.efi exists - /dev/sda1 being the EFI partition mounted on /boot/efi , therefore the file exists as /boot/efi/EFI/centos/grubx64.efi , with grub.cfg in the same directory.
Do you happen to know what the "1" after the HD( definition beginning is? I presume it is the disk number, however maybe the index starts at 1 and not 0. I am asking as when it bombs to the grub> prompt , I specify HD "0" to get it to boot manually as below. However if this was actually an issue I don't think it would find grub to bomb out too in the first place.
I'm just not convinced it's finding the grub.cfg at all but have no debug method.
set root=(hd0,gpt3)
Regards,
Stephen.
Re: Rebuild EFI System Partition and Grub on a Hyper-V VM
I missed that totally and it is the problem - grub, in common with C programmers, starts counting from 0 meaning the first hard disk.
The future appears to be RHEL or Debian. I think I'm going Debian.
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke
Re: Rebuild EFI System Partition and Grub on a Hyper-V VM
Hi,
I had a play around with making a new menu option using efibootmgr , and it turns out that first digit after the HD is the partition number containing the bootloader for the menuentry , so in actual fact '1' is correct - it's the /boot/efi partition and the bootloader (grubx64.efi) is in /boot/efi/EFI/centos as discussed.
On the positive side I'm learning a lot about disks and grub2
I had a play around with making a new menu option using efibootmgr , and it turns out that first digit after the HD is the partition number containing the bootloader for the menuentry , so in actual fact '1' is correct - it's the /boot/efi partition and the bootloader (grubx64.efi) is in /boot/efi/EFI/centos as discussed.
On the positive side I'm learning a lot about disks and grub2