-1

I followed Stephen Kitt's recommendation put / and /home under LVM, instead of leaving / in its own partition.

If /boot is in a logical volume for / (as by default it is), will moving the logical volume cause failure to boot?

This seems to be true if / filesystem is in a partition and /boot is in the / filesystem. It seems that we need to reinstall grub to be able to boot into the Lubuntu installed on the disk again.

I would like to know if LVM provides any advantage in this aspect.

Thanks.

Tim
  • 101,790
  • 1
    It is not recommended to put /boot into a logical volume, because an LV could cross disks, be non-contiguous and so on. – Stephen Harris Feb 27 '19 at 18:12
  • If you move the location of either / or /boot you will need to update those locations in /boot/grub/grub.cfg ... this is usually does using the grub-install tool. – RubberStamp Feb 27 '19 at 18:52
  • @RubberStamp Why does it seem that I don't have to https://unix.stackexchange.com/questions/503355/will-i-be-able-to-move-my-root-partition-without-failing-to-boot? – Tim Feb 27 '19 at 18:56
  • I haven't looked too closely at the previous question... however, the output of cat /boot/grub/grub.cfg |grep boot should provide some details that may answer both questions for you... or make it a little clearer. I'll see if I can figure out the previous question... – RubberStamp Feb 27 '19 at 19:00
  • In your previous question, the / directory was on /dev/sda3 and remained on /dev/sda3 ... the same is true for the rest of the mount points. Since none of your mount points changed drives (logical or otherwise), the boot locations didn't change. – RubberStamp Feb 27 '19 at 19:11
  • @RubberStamp I have updated the other question. Basically, even though none of my mount points changed drives (logical or otherwise), It seems that I will need to reinstall grub according to https://askubuntu.com/questions/299886/partitions-is-it-safe-to-move-partition-containing-boot and https://howtoubuntu.org/how-to-repair-restore-reinstall-grub-2-with-a-ubuntu-live-cd, but actually I don't need to, and why is that? Also see the previous question for output of cat /boot/grub/grub.cfg |grep boot. – Tim Feb 27 '19 at 19:19
  • Basic principal, grub needs all its components to be found to fully function. A fully functioning grub can read from LVM. To let grub boot your Linux distro, it must be able to read the kernel and initramfs. – 炸鱼薯条德里克 Feb 28 '19 at 00:20
  • @炸鱼薯条德里克 Could you try to answer my questions? Thanks. – Tim Feb 28 '19 at 00:22
  • Will doing something cause boot failure? How do we define "causing boot failure"? It's "able-to-boot before" and "unable-to-boot after". So we know able-to-boot before is satisfied, then is unable-to-boot after also satisfied? We have to know the situation after you doing something, which isn't given in the question. How do we define "providing any advantage in this aspect"? In what aspect? Advantage over what? Completely prevent boot failure from happening? Or making the failure happen more easily? – 炸鱼薯条德里克 Feb 28 '19 at 04:24

2 Answers2

0

Will doing something cause boot failure? How do we define causing boot failure? It's able-to-boot before and unable-to-boot after. So we know able-to-boot before is satisfied, then is unable-to-boot after also satisfied? We have to know the situation after you doing something, which isn't given in the question.

So Let's just assume you have following filesystem and partition scheme after doing something(It's just assuming, because you may have complex storage scheme setup and they can all affect the final result).

/dev/sda as your only physical disk(GPT partitioned), /dev/sda1 as your ESP, /dev/sda2 as LVM PV, which used by your only VG, which further contains two LV, one for / and one for /home. No other filesystem is on your system. I'm not gonna click your links, that's your responsibility.

Now, you use grub as bootloader, which is installed in the ESP. Because ESP isn't touched, UEFI firmware will successfully run your grub, which will function perfectly. But to boot your linux, grub needs to find your kernel and initramfs, and kernels(actually initramfs, but it's kernel arguments anyway, not important) needs to be told which device contains the / filesystem.

How did grub know where to find your kernel and initramfs? Clearly it can't search over all your filesystems, it has to be told by you. How? that's where grub.cfg becomes important. Which tells grub how to find the kernel and initramfs and what parameters to be passed to kernel.

So, where is your kernel anyway? When you install your OS, kernel and initramfs are always installed in the /boot of your new OS. But which filesystem anyway? That depends on how you mount these filesystems during installation. So, it's in your "/ filesystem", because you never set up a seperate /boot filesystem.

Where is your "/ filesystem"? In the one of your two LVs. Where's your device containing the / filesystem? It must be the same LV.

So, let's check the grub.cfg, if it's not written properly, OS would fail to boot, huh? But if it IS written corretly, grub will correctly find the kernel, initramfs and pass right parameters to the kernel.

Oh, I forgot that we are not able to check grub.cfg because it's not provided. So ... assuming again? No, according to manual of grub, grub.cfg supports so many complex configuration, which can all affect the final result, just as we mentioned before, so we're just gonna stop here. Doing too much assumption just let our answer becomes too far away from real-life.

-1

Because you cannot move a directory into something it contains:

$ tree .
.
└── one
    └── two

2 directories, 0 files
$ mv ./one ./one/two/
mv: rename ./one to ./one/two/one: Invalid argument

You cannot move / to another location, as that other location would be contained itself. This is a filesystem, not a Klein Bottle.

DopeGhoti
  • 76,081