Just to share, this is what I have done:
There is no need to perform grub-install since all the files are already there. What needs to be done subsequently is to create a new boot option at the partition sda1 using the EFI boot manager and pointing to the shim.efi bootloader:
# efibootmgr -c -L Fedora -l \\EFI\\fedora\\shim.efi
Then check its boot position (refer to PARTUUID using blkid if not sure):
# efibootmgr -v
BootCurrent: 0004
Timeout: 1 seconds
BootOrder: 0004,0000,0002,0001
Boot0000* Fedora HD(1,800,64000,<PARTUUID>)File(\EFI\fedora\shim.efi) <= NEW
...
and make sure that it is the first boot loader in the sequence:
# efibootmgr -o 0000,0002,0001,0004
For grub, what needs to be done is to change all instances of /boot location to point to the new partition:
# vi /boot/efi/EFI/fedora/grub.cfg
....
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt6
--hint-efi=hd0,gpt6 --hint-baremetal=ahci0,gpt6
....
Search and replace "gpt6" with "gpt2" (if /boot is moved from sda6 to sda2)
To prevent the OS from mounting the old /boot and /boot/efi partitions due to duplicate UUIDs, edit fstab:
# vi /etc/fstab
Replace the duplicate references of UUIDs with PARTUUID (if you are using GPT) or device node (e.g. /dev/sda1).
Reboot and you are done.
BLKRRPART tells the kernel to reread the partition table. man 4 sd
With BLKPG you can create, add, delete partitions as you please (from the kernel, not on disk of course). You have to tell the kernel the offset and size of individual partition, which implies that you must have parsed the partition table yourself beforehand. See Linux kernel: /include/uapi/linux/blkpg.h
I personally use partprobe (part of parted), which uses the latter approach, probably to support partition tables not supported by the kernel.
Best Answer
Though it was down voted ... possibly because someone thought it was not answering the question ... I think @Rony's answer is a good start at explaining what the
bootflag is about. (I was actually planning to begin my answer with an example similar to the one he provided.)I was all set to ramble off an answer about how the
bootflag is, at this point in time, an often ignored (as @Rony's example shows) historical remnant from a period when hard drives were smaller and bootloaders were much less sophisticated.But then I discovered this had already been said in this answer to this question: What is the "Bootable flag" option when installing a distro?
What's more there was also a link to a short article about the Boot flag which says
Well, this is embarrassing ...
When I claimed that the
bootflag was a "historical remnant" I was assuming this was the case because clearly GRUB had no need to use it. Surely Microsoft would also have "moved on".The well known quote usually attributed to Oscar Wilde turned out to be too true in this instance.
It appears that the MBR and PBR (Partition Boot Record) loaders used by the Windows operating systems DO expect the
bootflag to be set correctly.To test this I cleared the boot flag from all the partitions of a Windows 8 VM. (See below. If you're curious, here's a link to the pastebin of the complete BootInfo Script result)
When I cleared the flag from both partitions, I got the error message
FATAL: INT18: BOOT FAILUREwhen I attempted to boot. (I am not sure if that is from the Windows MBR bootloader or the VM's equivalent of a BIOS.)Just to see what would happen, I also set the
bootflag on the "wrong" partition,/dev/sda2instead of/dev/sda1. Doing that resulted in the window shown in the image below.<sigh/>This experience makes me wonder if Microsoft is still using the same MBR boot sector loader which they used for MS-DOS and Windows 3.0/3.1?