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.

3 Answers 3


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, 2015 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, 2017 at 19:23

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

You just have to take care to make the 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, boot normally and then move the content manually to the LVM / filesystem. Make sure you reorganise things to look like /boot is a plain directory under LVM /, and /boot2 as the old boot partition and then grub install /dev/sd? for your correct path. Reboot, delete the /boot2 filesystem and include the partition back to LVM, to be usable.


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, 2015 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, 2015 at 16:15
  • Sorry, I mean /dev/mapper/lvm-kali--root not boot. Typo
    – Mas Bagol
    Apr 30, 2015 at 16:27
  • Oh, I hadn't even noticed the typo. I read /dev/mapper/lvm-kali--root to begin with!
    – Celada
    Apr 30, 2015 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 Mar 21, 2018 at 19:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .