Red Hat Bugzilla – Bug 842150
grub2-mkconfig keeps adding rd.lvm=0 but root is on lvm
Last modified: 2012-07-23 07:45:58 EDT
Description of problem:
I have moved my physical install into an LV using dd. Once I booted into it and ran grub2-mkconfig and grub2-install the grub.cfg file has only entries in it with rd.lvm=0. This result in not being able to boot and be dropped in the dracut shell. Removing the rd.lvm=0 from within the grub-menu works and gives a succesfull boot.
Version-Release number of selected component (if applicable):
Move complete install (including /boot) into LVM and build and install a new GRUB2
Steps to Reproduce:
1. dd partitions into prepped LV's
2. prep new fstab on the target root lv
3. change uuid on LV's to cope with duplicate uuid's
4. run grub2-mkconfig -o /boot/grub2/grub.cfg (old install)
5. boot into new install
6. remove old partitions
7. run grub2-mkconfig -o /boot/grub2/grub.cfg (new install)
8. run grub2.install /dev/sda
dropped into dracut shell
As said, removing the rd.lvm=0 from the kernel line in grub.cfg makes it work. So, somehow, grub2-mkconfig (or os-prober) finds the os, the os lives on lvm, but still "rd.lvm=0" is added to the kernel line.
What is the content of /etc/default/grub ?
GRUB_CMDLINE_LINUX="rd.md=0 rd.lvm=0 rd.dm=0 SYSFONT=True KEYTABLE=us rd.luks=0 LANG=en_US.UTF-8 rhgb quiet"
Ah, I didn't know about this file.
However, it's still not very userfriendly. grub2-mkconfg *should* autodetect that root is on lvm and act accordingly, imho.
anaconda is responsible for creating the initial setup and tying the parts together. It creates this file to pass custom command line options to dracut to optimize it. If you "install" or make basic changes to your installation without using anaconda then you have to do everything that anaconda would have done - including updating this file.
I don't think it is feasible for grub to detect that the initrd is using dracut and automagically figure out which dracut options would be appropriate.
It seems to me like it would be better if the "need" for these command line options could be fixed differently. Either by dracut using them on demand without any boot time overhead or by being applied when dracut-the-tool generates the initrd.