I’ll be honest, I don’t know that I’ve ever successfully swapped root partitions without ending up booted from recovery media at some point. It’s hard to set up a running session on a partition that’s separate from the booted one, with grub. But, going back to what you tried…
That’s your recovery image, though. That’ll work for booting, but… well, to be honest I’m not sure whether it’ll work for fixing this, it might make things worse. If nothing else it’ll complicate the process some.
But you might have that kernel installed, at least on your old root, based on your grub menuentries. If you’ve only upgraded the kernel once or twice, it’s possible. I know I don’t.
You can check it with sudo dnf -C list kernel --showduplicates from a running system. 5.0.9-301.fc30 was upgraded away long ago, on mine. Here’s what I get:
$ sudo dnf -C list kernel --showduplicates
Installed Packages
kernel.x86_64 5.1.20-300.fc30 @updates
kernel.x86_64 5.2.5-200.fc30 @updates
kernel.x86_64 5.2.7-200.fc30 @updates
Available Packages
kernel.x86_64 5.0.9-301.fc30 fedora
kernel.x86_64 5.2.8-200.fc30 updates
I need to update to the latest release 5.2.8-200.fc30, looks like. Fedora 30 originally shipped with 5.0.9-301.fc30 which explains why it’s available. But that kernel’s not installed on my system, so if I try to boot my root partition off it, that won’t work.
(None of the right modules will be installed, which means nothing that requires a kernel module will work — including mounting /boot/efi, which requires the vfat module. I found that out to my surprise last night, testing on my own laptop. Perhaps I have an old recovery, and that’s been corrected by now, because it made my recovery useless for… well… recovery.)
The only kernel-install add lines that would work for setting up my root partition would currently be 5.1.20-300.fc30, 5.2.5-200.fc30, or 5.2.7-200.fc30.
Grub’s os-prober has automatically been setting up entries to do that, with your current kernels, and it looks like 5.0.9-301.fc30 might be among them (assuming it checked that, and didn’t just blindly copy out-of-date enties). Those are the entries like this one:
The confusing thing is that it’s naming all of the entries the same (see this other thread about that), so you might want to manually edit those entries to read something like:
menuentry 'Fedora 30 (Server Edition) (5.0.9-301.fc30 on /dev/mapper/fedora-root)' ...
...
linux /vmlinuz-5.0.9-301.fc30.x86_64 root=/dev/dm-0
initrd /initramfs-5.0.9-301.fc30.x86_64.img
}
menuentry 'Fedora 30 (Server Edition) (5.2.7-200.fc30 on /dev/mapper/fedora-root)' ...
...
linux /vmlinuz-5.2.7-200.fc30.x86_64 root=/dev/dm-0
initrd /initramfs-5.2.7-200.fc30.x86_64.img
}
(If you run grub2-mkconfig after doing that, it’ll probably undo it, so if you do run it be prepared to edit those entry titles again.)
That way, at least you’ll know what you’re booting into, and have a fighting chance of it working. If you can boot into your old image like THAT, so that you have a working system running as you expect, then here’s what I’d do:
sudo mkdir /newroot
sudo mount -t ext4 /dev/mapper/root-lvroot /newroot
Then you can sudo vim /newroot/etc/fstab to edit the fstab on your new root volume, to make sure it’s correct (that it lists the / partition as /dev/mapper/root-lvroot). You can also check what kernel versions are available by looking in /newroot/lib/modules/. And if there are any problems with that volume, you’ll know when it tries to mount it.
After you’ve checked that, sudo umount /newroot, and just reboot to grub again without trying any more kernel-add or grub commands. Pick a boot entry that corresponds to one of the kernels you know are installed on /dev/mapper/root-lvroot (aka /newroot), and one-time edit the linux line to use root=/dev/mapper/root-lvroot. If it successfully boots into the new root volume, then you can use grub2-mkconfig and kernel-install add with your latest available kernel release, to set up boot entries that default to that volume.