1

I am installing Ubuntu Server, and I noticed that the guided lvm process will create a 512MB /boot/efi fat32 partition as well as a 1GB /boot ext4 partition. The rest of the HDD is then given to LVM to be used as / under a lv.

I understand the 512MB partition that will be mounted as /boot/efi is the EFI System Partition for EFI booting and requires fat32 formatting because EFI does not recognize more exotic filesystems.

However, I want to know why a separate 1GB /boot partition is also carved out.

In another install, I configured partitions manually and selected the "Use as boot device" option under a blank HDD. This created the 512GB ESP. Then, I

  • created a backup ESP on another HDD
  • created lvm-on-mdadm set up on the free space of both, for / .

After installation completed, the HDDs had 512MB ESPs, the free space was lvm-on-mdadm, and /boot was a subfolder of / . I didn't purposely not create a separate /boot partition, I just didn't know better.

User "user589808: says here that

The ESP - EFI System Partition - should not be confused with /boot (not required for most Ubuntu installations) and is a standard requirement.

On one hand, I don't want to go against guidelines and want to respect the defaults, but on the other hand, I am working with VM's on a machine that has a low amount of storage, and having a separate 1GB /boot partition that might not even get completely filled up (along with all the complexities that may be involved when resizing partitions) seems less ideal than have a lvm lv containing /boot as a subfolder. (I won't be using lvm-on-mdadm though, just lvm)

On a lvm or lvm-on-mdadm systems with ESP's, is a separate /boot partition required?

test
  • 13
  • Apparently /boot on a separate partition is related to grub - so if grub can support mdraid and lvm, why is it still necessary? – test May 27 '21 at 03:17
  • "1GB /boot partition that might not even get completely filled up" ... you should browse through the dupes of https://askubuntu.com/questions/171209/my-boot-partition-hit-100-and-now-i-cant-upgrade-cant-remove-old-kernels-to (and of the several dozen posts which haven't been marked as a duplicate yet but can be found by searching "boot 100"). – muru May 27 '21 at 03:19
  • @muru OK, I didn't know about this issue. So the /boot partition getting filled up is definitely a problem for a quite a few people. Wouldn't having /boot as a subfolder sharing space with the root lv simplify troubleshooting when that happens, though? Resizing just one LVM pv/lv, instead of resizing /boot and the lvm pv. (Or, just clearing out /boot's contents works too) – test May 27 '21 at 03:25
  • Sure, you can do various things depending on your situation. The installer just picks a safe default. – muru May 27 '21 at 03:26
  • Something else to consider -- if you deviate from the guidelines and have problems some day, there's a smaller chance that someone here can help you. I would consider the space for /boot as being required and to not deviate unless you're comfortable with fixing problems yourself when the time comes. If you're using a VM, maybe consider purchasing more space? – Ray May 27 '21 at 03:58
  • @muru It does seem like a reasonable default, now that I think about it – test May 27 '21 at 04:24
  • @user535733 maybe you should move that to an answer, and I will consider your recommendation about lvm it does make sense. – test May 27 '21 at 04:24
  • @Ray That makes sense, I didn't think about it that way. I guess you mean that a separate /boot that probably isn't written to often is less likely to become corrupt. Which is better than if /boot being a subfolder if / goes down. And both the above better than when mdadm, or luks, or lvm are layered on top and are broken, necessitating peeling through those layers, before being able to find /boot... – test May 27 '21 at 04:24
  • I think you meant to send that reply for me to @user535733 instead? Debian/Ubuntu is much better nowadays, but long time ago, I've had system problems that would have been impossible to solve if /boot wasn't separated. It's only 1 GB...though maybe you can get away with less? – Ray May 27 '21 at 04:31
  • @Ray no my comment was meant to you. I took what you said as implying that it's easier to stay with the guidelines and fix any problems with /boot than it is to fix problems with a /boot located inside more complex storage subsystems. – test May 27 '21 at 10:00
  • Ah! Ok...yes, that is what I was trying to say! I've used Ubuntu for quite some time, but I still don't feel confident about deviating from instructions related to the boot partition. Yes, maybe it's because I don't know any better... Hopefully someone else can give you a more well-informed opinion than mine! Good luck! – Ray May 27 '21 at 10:17

1 Answers1

1

Let's turn the wayback machine to about five or six years ago....

Back then a stock install of Ubuntu using the default settings did NOT use LVM, and /boot was simply a directory on the root drive. (You can have this simpler legacy behavior by un-selecting LVM during install).

Most folks who chose LVM did so because they wanted to encrypt their system. They didn't know what other uses LVM is good for (most folks still don't know). Ubuntu could not read the encrypted partition until after boot, so selecting LVM triggered creation of an unencrypted /boot partition.

About five-or-so years ago, changes in the boot (like EFI and SecureBoot) led to the creation of the EFI partition.

Starting in 20.04, the default setting of the installer switched from non-LVM to LVM, leading to the default creation of separate /boot partitions (in addition to EFI). Recall that you can un-select LVM to use the legacy /boot directory instead of creating a new partition.

Keep in mind that the software environment continues to evolve. EFI and LVM and separate /boot partitions might be replaced or subsumed by newer or better ideas in the future. It's happened before. More than once.


In your particular case ("working with VM's on a machine that has a low amounts of storage"), I'm not seeing a benefit to using LVM (nor EFI), so consider simplifying. If your host can run Snaps, you can run LXD containers which feel like VMs but are even leaner on resource requirements.

user535733
  • 62,253