[sf-lug] LVM (& /boot) Re: NEED INFO ABOUT BOOT SECTOR, SPACE LIMITS

[Michael Paoli]

LVM is wonderful* :-) (*slightly biased opinion),
but ... I don't know that *any* of the common boot loaders
can handle boot filesystem as LVM - though they can certainly
do root (/) filesystem as LVM, with a separate (non-LVM)
boot (typically /boot) filesystem.

I think actually most boot loaders are *relatively* restricted
on what they can handle for boot filesystem - some small to
fair set of filesystem types (depending upon boot loader, and in
some cases also what modules are loaded into the boot loader!),
they can handle md RAID-1 (or md and no RAID at all).
I think that's about it?  (and maybe some snazzy trickery
about reading stuff from a file on a filesystem the boot loader
can deal with, and doing things with the contents of that file -
e.g. uncompressing it in RAM and mounting it as yet another supported
filesystem type).

So ... LVM and /boot ... mostly not, as I at least currently
understand it - at least for /boot itself.  And since /boot
would be a partition (or close to it, such as md RAID-1, and the
boot loader just reading what it needs from one of those partitions)
expanding/growing it is rather non-trivial - as generally there's other
partition(s) right after it.  I generally advise size of /boot be
made ample, but not excessive - as growing it later is rather
annoyingly non-trivial, and if one wants to reclaim space from it
later, there also isn't particularly good easy way to do that and
usefully use that space elsewhere.

But also, at least for what I've seen, distributions that use or offer
to use LVM, generally suck up all remaining space - at least on first
disk - into LVM.  I think that's relatively wasteful of LVM's
capabilities ... but alas, it is (dead) simple.

I generally prefer, on first disk, carve out appropriate space
for /boot (separate partition and filesystem).  The remainder,
chunk into multiple partitions of equal size ... somewhere between
4 and 8 partitions - and give 'em all to LVM.  And *reasonably* but
not excessively size the remaining filesystems (and swap, if used - do
swap under LVM - not as partition(s)).  This makes reasonably growing
things later, if/when/as desired/appropriate, pretty dang easy (at
least if one hasn't sucked up all of the space on the disk).
And, if one later has need/reason to use partition(s) for something
else, so long as one has ample free space, whole partition(s) may
be "given up" from LVM - to use for whatever other purpose(s) (e.g.
most all of a whole different operating system or distribution
... and use either a common /boot filesystem - or a totally
separate one - such as on different bootable media).

One can also layer additional stuff under and/or atop LVM,
as reasonably appropriate and reasonably sane (some orders aren't
sane), e.g. LUKS (encryption), md RAID, zfs, etc.

> From: "Tom Turner" <seameadowlake at gmail.com>
> Subject: Re: [sf-lug] NEED INFO ABOUT BOOT SECTOR, SPACE LIMITS
> Date: Mon, 31 Jul 2017 16:15:04 -0700

> This url might (or might not) provide some relevant information about the
> "boot partition full" problem.
>
> https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1357093
>
> The above web-page includes links to other pages reporting the problem.
>
> I and thousands of others ran into this problem.  There simply was no way
> to clear out space, no "remove type" command would work.
>
> The cure was to >back up the data, and >re-install Linux, being certain to
> _not_ choose the LVM option.
>
> Another point, I believe that Synaptic is better than apt-get at
> uninstalling old versions of the kernel. Mr. Texstar, the guru behind
> PCLinuxOS is adamant that updates should be performed by using Synaptic,
> not apt-get.
>
> More information about the problem, from a post at the above url:
>
> Begin quote:
> "The issue here isn't so much the absolute space initially allocated to the
> /boot/ LV, it is that the installer allocates 100% of the Volume Groups
> space.
>
> The great advantage of LVM is that space can by dynamically allocated and
> removed from Logical Volumes as needed.
>
> If the installer were to leave 5% of the Volume Group unallocated it would
> be possible for the system to detect this out-of-space condition and extend
> the /boot/ LV:
>
> lvextend -l 50%FREE VG/boot
> resize2fs /dev/mapper/VG-boot # assuming ext file-system
>
> and at the same time display a prominent warning and options for
> automatically removing the superseded kernel versions."
> End quote.
>
> Hope this helps. Best regards, Tom
>
> On Sun, Jul 30, 2017 at 9:10 PM, Daniel Gimpelevich <
> daniel at gimpelevich.san-francisco.ca.us> wrote:
>
>> On Sun, 2017-07-30 at 19:02 -0700, Mikki wrote:
>> > Hi, Daniel and all
>> >
>> > Excellent question up for which I have no answer.  Here is a copy of the
>> screenshot of the message, embedded or attached, whichever works.
>> >
>> > Mikki
>>
>> By the way, the "Examine?" button in your screenshot may yield a few
>> clues, too.