When I installed Fedora, I didn’t create a separate boot partition.
Now I’m trying to change my setup to separate boot from root.
What I did:
Created a separate ext4 partition
Copied everything that was in the original /boot folder to the new partition
Created a new fstab entry for the new boot partition. UUID=long-list-of-letters /boot ext4 defaults 0 0
Rebooted
Everything seemed to work fine, but I realised that the original boot folder still contains the boot files etc. and I realised that my system is still booting from the boot folder in the root partition (new kernels not appearing in grub).
So, I booted from a liveUSB mounted the root partition, renamed /boot to /boot2 and created an empty /boot folder.
Rebooting gave me a grub prompt, so I reversed the last change and don’t know how to proceed.
I’m in an unusual situation where new kernels are installed in the new boot partition, but the system is booting from the boot folder under root.
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.
Is my fstab line correct?
Does the fact that I’m mounting a partition to a non-empty folder cause issues with booting?
If all else fails, is there a simple way to reinstall Fedora and then restore all my packages and configuration, etc.
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
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?
Boot a live Fedora 36 USB
Mount my system’s root partition as /mnt
Mount the new boot partition as /mnt/boot
Mount the ESP partition as /mnt/boot/efi
Run for dir in /dev /proc /sys /run; do mount --bind $dir /mnt/$dir ; done.
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
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:
Boot a live Fedora 36 USB
Mount my system’s root partition as /mnt
Mount the new boot partition as /mnt/boot
Mount the ESP partition as /mnt/boot/efi
Run for dir in /dev /proc /sys /run; do sudo mount --bind $dir /mnt/$dir ; done.
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.
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.