Bug#1076952: [RFD] partman-auto: Update guided partitioning size limits for current and future needs
Hi,
Pascal Hambourg <pascal@plouf.fr.eu.org> wrote (Thu, 22 Aug 2024 13:59:12 +0200):
> On 19/08/2024 à 07:50, Holger Wansing wrote:
> > Am 18. August 2024 21:50:53 MESZ schrieb Pascal Hambourg <pascal@plouf.fr.eu.org>:
> >>
> >>> I wonder, if we could grow up the root partition in "separate /home" and
> >>> "separate /home, /var, /tmp" a bit (only relevant on small disks, most probably).
> >>
> >> By raising the minimal / partition size or its priority ?
> >> The former also raises the minimal disk space requirement, whereas the latter is detrimental to other partitions growth. As above, it is a trade-off.
> >>
> >>> On a 20G disk, I get 4,7G for root, on a 50G disk that's 6,4G.
> >>> In current release, an installed GNOME or KDE desktop would consume the whole
> >>> root then, disk full (according to https://d-i.debian.org/manual/en.amd64/apds02.html)
> >>
> >> Does this include the space required for two extra kernels ?
> >> apt autoremove keeps two kernels and removes the older only after the newer is installed, so there can transiently be three kernel installed.
> >
> > Those values are directly after installation I guess.
> > So without several kernel images.
> > That's why we should just have spare space on /.
>
> Then what should be the proper minimum size for / ?
Looking at above values, I could think about something like 8G.
Of course, that would make the "separate home" and "separate home+var+tmp"
recipes useless/senseless on minimal disks as 10G, but we cannot forcibly
support such minimal disks with all recipes, of course.
And for 20G or bigger, it would work, so yes, I would say 8G should be fine
as minimum.
We will need to check, what's the new minimum disk size, for which guided
partitioning is possible (the installation-guide needs an update here -
and for other facts as well).
> >> This is why I previously asked if there were intended use cases for built-in recipes which could be used as guidelines.
> >> For example, "allow to install and use a desktop environment within [TBD] GB disk space", and/or "allow to install and use a minimal (non-graphical) system within [TBD] GB disk space".
> >> Should the "small_disk" recipes be resurrected ?
> >
> > I wasn't aware of such recipes, but what could be the benefit?
>
> One unused "small_disk" recipe file remains in recipes-alpha and the
> description is still present in the debconf template.
>
> The benefit would be to allow automatic partitioning in less disk space
> than "normal" recipes when you do not need a desktop environment. Only
> biosgrub|esp, / and swap, no LVM, no separate /boot unless the
> architecture requires it.
But that's nearly the same as the atomic recipe, isn't it?
I think there is no real value in adding one more recipe.
> On 19/08/2024 at 12:41, Philip Hands wrote:
> > It would be nice if we could do something where one gets 1GB for systems
> > with tens or hundreds of GB, and have that scale down for tiny disks,
> > and scale up for huge, but we don't currently have a non-linear
> > possibility.
>
> Maybe the recipe format could be extended to support multiple linear
> segments, e.g. :
> min prio1 max1 prio2 max2...
> meaning "use prio1 between min and max1, then prio2 between max1 and
> max2..."
>
> But for now the only option is a trade-off between the minimum size and
> the priority.
>
> > BTW Do we really expect to be serving people with tiny disks with our
> > default multi recipe? I'd guess that they'd be more likely to either go
> > for everything on one partition, or configuring things to their exact
> > requirements.
>
> I asked several times if there were intended use cases for built-in
> recipes which could be used as guidelines, but I have not seen any clear
> answer yet.
Probably since such guidelines are not trivial to formulate: much different
szenarios, a wide ranch of hardware and similar might result in a higher
amount of entries to choose from, and too much choices are not always an
advantage...
> >> The /boot partition size is bigger than I expected in all LVM
> >> cases (...)
> >> This offset can be compensated by reducing /boot minimal size
> >> in recipes where /boot exists only with LVM.
> >>
> >> But it is not possible to do the same to the EFI partition or in recipes
> >> where /boot exists in both LVM and non-LVM schemes.
> >> Another workaround could be to define the EFI partition twice in recipes:
> >> - with $defaultignore and shifted minimum size,
> >> - with $lvmignore and normal minimum size.
> >> But it sounds like a hack again.
>
> I wasted quite some time working on this solution, calculating and
> testing the offsets in all cases. The offset compensation works very
> well, but then I realized what should have been obvious from the start:
> reducing partition minimum sizes in recipes affects the minimum disk
> space requirement and you could end up with smaller EFI and /boot
> partitions than intended, so this solution is flawed.
>
> I also considered adding an explicit "lvm" partition with the proper
> parameters and $defaultignore flag to the recipes, so that
> partman-auto-lvm does not create one. But it would not work with
> partman-auto-crypto which uses a "crypto" partition instead of a "lvm"
> partition.
>
> >> The only solution
> >> I can think of is to replace the LVM PV fixed arbitrary minimal size
> >> (and priority while we're at it) in partman-auto-lvm with the actual
> >> values. But this may affect existing custom LVM recipes in unpredictable
> >> ways. It is possible to apply the new behaviour only to built-in
> >> recipes, but then custom recipes based on new built-in recipes may
> >> produce unexpected results.
> >
> > Just leave it as is, ignoring the 260MB difference?
>
> IMO the difference is too big to be ignored. Also it makes the partition
> reach its maximum size (768M -> 1GB) with any disk size. If you're going
> that way, it would be more consistent to define a fixed size of 1GB in
> the recipe to hide the issue.
>
> I believe that the only real solution is to fix the lvm partition
> minimum size in partman-auto-lvm as described above, even though it may
> affect existing custom LVM/crypto recipes. Keeping bugs for
> compatibility is not good.
First, this is again a trade-off here.
And we can assume, that when LVM is used, the disk space is not of minimal
size, thus having the boot partition a bit bigger does not matter in LVM
cases (or in other words: when LVM is used, /boot will most probably reach
its max size anyway (?) ).
I'm unsure if I consider this a bug...
So, keep the logic simple, as a trade-off?
I would be happy for more opinions on this proposal, BTW...
Holger
--
Holger Wansing <hwansing@mailbox.org>
PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Reply to: