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 <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 / ?
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.