Apologies for the late answer...
On 19/08/2024 à 07:50, Holger Wansing wrote:
Am 18. August 2024 21:50:53 MESZ schrieb Pascal Hambourg
<pas...@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 / ?
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.
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.
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.
