12

I read somewhere that it is not recommended to put boot partition on lvm based partition. But, I'm doing it anyway. Then the only problem I've faced on this is sometimes when I install a new Linux distro and put it's boot partition on lvm, grub can't detect it. The grub-mkconfig command usually make a mistake on generating grub.cfg file. But, if this is the only problem on lvm based boot partition, I think it's okay. Because I know how to fix it, just give a proper address to the intended boot partition to boot and then everything goes fine.

So, is there anything other than this that lvm can cause problems? Because, in my opinion lvm is very flexible and didn't slow down the system.

13

It's not a performance problem, it's a troubleshooting and fixing things problem. /boot is the bootstrap location - in there is a few files that start off everything else in your system.

And sometimes you need to poke in there to fix a problem (such as grub config or similar).

If you have to do this, it's useful to have a lowest common denominators sort of filesystem, to make it as easy as possible if e.g. you have to remove the drive and put it in another box to edit a config file.

If you're in this position, you don't want to be having to 'fudge' your LVM into life just to be able to read it :).

  • 1
    Or simply that older versions of GRUB do not understand LVM. – tgharold Jul 5 '15 at 23:01
  • good point, also to mention that lvm is a complex setup, potentially involving several disks. If your boot loader depends on LVM, then for example you can't boot to single user mode to fix an issue with LVM (inclusing such banal issues as a failing disk) – asdmin Sep 12 '17 at 19:23
3

To me, if, as you say, grub can't detect your LVM /boot filesystem and grub-mkconfig usually makes a mistake on generating grub.cfg, that seems reason enough to avoid this configuration and switch to something that grub supports better. When you say "just give a proper address to the intended boot partition", I don't know what you mean by "address" or what exactly you're doing as a workaround, but honestly it sounds like a scary and fragile hack.

As a basic and virtually necessary feature, the bootloader can access a simple filesystem on a simple disk partition and load the next stage from there. That's all it really needs to do. More features in the bootloader, such as parsing containers like LVM and juggling multiple disks in the pre-boot environment, just means more Linux (kernel) features that need to be duplicated in grub (more code, more bugs) but will never quite exactly work the same way in both environments (more confusion) and more overall complexity. For bootstrapping, the simpler the better.

  • What I mean by address is device path. In kali linux, grub-mkconfig made mistake to give root path on /dev/dm-0 since it's not persistent. So, I changed it to proper path which is /dev/mapper/lvm-kali--boot in mycase. – Mas Bagol Apr 30 '15 at 16:01
  • I see. That's different. That's the root filesystem path (which gets added to the kernel command line as root=<path>) and has nothing to do with where /boot is located. grub-mkconfig should definitely not be getting that wrong. It should correspond to the output of grub-probe --target=device /. – Celada Apr 30 '15 at 16:15
  • Sorry, I mean /dev/mapper/lvm-kali--root not boot. Typo – Mas Bagol Apr 30 '15 at 16:27
  • Oh, I hadn't even noticed the typo. I read /dev/mapper/lvm-kali--root to begin with! – Celada Apr 30 '15 at 16:28
  • you can use a less common ( outside of the fips=1 world at least) option of boot=/dev/mapper/$UUID or $lvm-name – linuxdev2013 Mar 21 '18 at 19:08
0

I use “/boot” directory inside the LVM “/” filesystem for years on Fedora and never ever had problems.

You just have to take care to make that single physical disk where “/” lives the single one on your volume group. I have a “vgmain” volume group for this physical drive and a “vgdata” for all the rest. This is important if you need to carry your drive to another computer in a troubleshooting situation. LVM won't work if it is composed by multiple physical drives. But it will if it is composed by just one.

But I never had to go through this troubleshooting situation.

Latest Fedora installations won't let you do that automatically. You'll have to put your ”/boot” in a regular partition during install, then boot normally and then move the content manually to the LVM “/” filesystem. Make sure you reorganized things to look like “/boot” as a plain directory under LVM “/”, and “/boot2” as the old boot partition and then make a “grub install /dev/sda” or something similar. Reboot and then delete the “/boot2” filesystem and include the partition back to LVM, to be usable.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.