Create separate boot partition post-install

My boot partition is mounted at boot. I ran the sudo grub2-mkconfig -o /boot/grub2/grub.cfg command, then rebooted to a liveUSB tried clearing the boot folder by renaming it to /boot2 and creating an empty /boot folder, but when I rebooted, I ended up with a grub rescue prompt.

Another thing that confirms grub is ignoring the separate /boot partition is that before trying to empty the boot folder in the root partition through a liveUSB, I tried bind mounting the root partition with sudo mount --bind / /mnt/temp and do the renaming operation from there, but got an error that the folder is in use.

  1. Is my fstab line correct?
  2. Does the fact that I’m mounting a partition to a non-empty folder cause issues with booting?
  3. If all else fails, is there a simple way to reinstall Fedora and then restore all my packages and configuration, etc.
  1. yes
  2. no
  3. not necessary

I think that what is happening is that the initramfs file has the /boot image inside it and that with grub pointing to the wrong UUID it loads from there before the new /boot ever gets mounted.

Check the content of /boot/efi/EFI/fedora/grub.cfg and look at the UUID shown at the end of the the line beginning with search. If that UUID still is the one where the OS is installed and not the same as the one for the new /boot partition then it will need to be updated to point to the new /boot partition for proper booting. It should match the UUID used in the /etc/fstab entry

1 Like

So you pointed me in the right direction. The /boot/efi/EFI/fedora/grub.cfg was pointing to the UUID of the root partition. I changed it and rebooted and got a grub prompt again.

You mentioned the initramfs file. Do I have to regenerate the initramfs after changing the UUID in the grub.cfg file? How?

try sudo dnf reinstall grub2-efi grub2-common followed by sudo dracut --force
Note that the dracut command above will generate a new initramfs image for the currently running kernel, so if you are not able to boot to the newest installed kernel then I suggest that you select the newest kernel that will boot, even if it is the one from the live image and in a chroot environment, then run that command.
If that still does not fix the boot, then while in the chroot environment and with the new /boot (and /boot/efi) partitions mounted, try sudo dnf reinstall kernel* which will reinstall the latest kernel and will automatically generate the initramfs image for you.

You have not mentioned if you are able to properly boot to an older kernel, but with the problem you noted I have assumed it will not boot to any of the installed kernels.

So, I am able to boot the latest kernel, but not from the /boot partition. I copied the new files installed by the kernel updates to the boot folder in root and it boots properly. If I reinstall grub2-efi and grub-common and run dracut with the current setup, will the initramfs created work when I try changing the UUID in the grub.cfg again?

Once in grub rescue, how do I boot from the /boot partition? In that way, I could do all the steps while being booted from the correct kernel/partition. In that way I would avoid having to chroot which might be just as complex to do than manually boot from grub rescue.

I noticed that the help of the dracut command has some parameters that might be helpful. There are the -k, --filesystems, and --fstab.
The latter option is described as Use /etc/fstab to determine the root device. It doesn’t speak of the boot partition though.
Would running the sudo dracut --force --fstab or sudo dracut --force -k /boot from a system which is running from a kernel in a different folder solve the issue?

So, I abandoned the idea of booting from grub rescue and am focussed on trying to solve this issue from chroot, but I’m not sure what I need to do.
I found this post that gave me some hints.

Would following this procedure solve the issue?

  1. Boot a live Fedora 36 USB
  2. Mount my system’s root partition as /mnt
  3. Mount the new boot partition as /mnt/boot
  4. Mount the ESP partition as /mnt/boot/efi
  5. Run for dir in /dev /proc /sys /run; do mount --bind $dir /mnt/$dir ; done.
  6. chroot /mnt
  7. rm /boot/efi/EFI/fedora/grub.cfg
  8. sudo dnf reinstall grub2-efi grub2-common
  9. sudo dnf reinstall kernel*
  10. sudo grub2-mkconfig -o /boot/grub2/grub.cfg

That procedure should do the recovery for you. It will be important that you mount the new /boot partition in step 3 as you already stated.

Just for more clarity: → Step 7 will probably also require the use of sudo as will steps 2-5 unless you have already used su before you started at step 2. If you have used su while booted to the live media and before starting with step 2 then none of the steps will require the use of sudo.

Step 9 will run dracut as part of the install of the new kernel and build the new kernel files with the proper partition info

Yes, I was assuming that. Thanks, will try it later on and will report back.

The above procedure worked, but I had to modify steps 5 and 6 by adding sudo. Also, sudo is not required in chroot as you are working as the root user. So the correct procedure is as follows:

  1. Boot a live Fedora 36 USB
  2. Mount my system’s root partition as /mnt
  3. Mount the new boot partition as /mnt/boot
  4. Mount the ESP partition as /mnt/boot/efi
  5. Run for dir in /dev /proc /sys /run; do sudo mount --bind $dir /mnt/$dir ; done.
  6. sudo chroot /mnt
  7. rm /boot/efi/EFI/fedora/grub.cfg
  8. dnf reinstall grub2-efi grub2-common
  9. dnf reinstall kernel*
  10. grub2-mkconfig -o /boot/grub2/grub.cfg

Not quite true in the way you listed the steps.

When you initially start up to graphical mode from the live USB device you are active as liveuser. At that point a simple su command does place you as the root user before you perform steps 2-5 (you cannot perform the mount steps without having root privileges). Then, yes you are already running as root so sudo is not required for any of the following steps, 6-end.


As you can see from the prompt, initially the user is liveuser then after using su the user is root.

I always recommend that this be the procedure.

  1. Boot a live Fedora 36 USB
  2. su to root
  3. Mount my system’s root partition as /mnt
  4. Mount the new boot partition as /mnt/boot
  5. Mount the ESP partition as /mnt/boot/efi
  6. Run for dir in /dev /proc /sys /run; do mount --bind $dir /mnt/$dir ; done.
  7. chroot /mnt
  8. rm /boot/efi/EFI/fedora/grub.cfg
  9. dnf reinstall grub2-efi grub2-common
  10. dnf reinstall kernel*
  11. grub2-mkconfig -o /boot/grub2/grub.cfg

Note that I added as step 2 an su command and eliminated all use of sudo for the following steps.

I usually prefer using sudo command rather su. So, in steps 3 to 7 I used sudo. Then there was no need for sudo once I was in the chroot environment.

I normally do that also, but when working from a live USB boot and doing things that are obviously needing root privileges I shorten my commands by using su since I obviously know that what I am doing at that time is purely admin and can affect the entire system. Each of us has our own methods, and years of experience have taught me to be very cautious when using su or sudo.

The (probably best and safest) procedure is layed out in Fedora36 Docs, under “Reinstalling GRUB 2”:

https://docs.fedoraproject.org/en-US/fedora/latest/system-administrators-guide/kernel-module-driver-configuration/Working_with_the_GRUB_2_Boot_Loader/#sec-Reinstalling_GRUB_2

That doc is seriously out of date.
This is incorrect for rebuilding the uefi grub since fedora 32.

On UEFI-based machines, issue the following command as root:

~]# grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg

It should instead read
~]# grub2-mkconfig -o /etc/grub2-efi.cfg

Anyone using the command listed in that doc since F34 was released will totally screw up grub for future updates of grub or the kernel

1 Like

Oh-MY-God!!!

How come such docs are presented as actual and new then?

I p… my pants. I’ve been using the command in the doc for some weeks now!

Now, when I issue
grub2-mkconfig -o /etc/grub2-efi.cfg the mess-up becomes visible.

Would that apply to me too? I’m on a functioning system, as of yet.

If you used the command above, then yes those commands do apply to restore the normal update configuration.

The core of that issue is that when the main grub.cfg for efi boot was relocated from /boot/efi/EFI/fedora to /boot/grub2 they also changed the content of /boot/efi/EFI/fedora/grub.cfg to become a pointer to redirect grub to the actual config file at /boot/grub2/grub.cfg.

When a user overwrites that pointer then the system cannot update it with kernel updates so the user is left with manual grub updates with every kernel update.

Their system will boot but only with the latest grub config and kernel as it was the last time they manually did the update.

Those 3 commands will restore the default grub config for normal grub updates to follow.

Just an FYI. I reported that error in the fedora docs and was told it should be corrected sometime soon.

2 Likes

Thanks a lot, mate! If it hadn’t been for you posting this, I might just had more trouble than I hoped to bargain with!

:+1: