Bug#1076952: [RFD] partman-auto: Update guided partitioning size limits for current and future needs
Hi,
Am 23. August 2024 00:15:44 MESZ schrieb Pascal Hambourg <pascal@plouf.fr.eu.org>:
>On 22/08/2024 at 17:19, Holger Wansing wrote:
>> 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>:
>>>>>
>>>>> Should the "small_disk" recipes be resurrected ?
>>>>
>>>> I wasn't aware of such recipes, but what could be the benefit?
>(...)
>>> 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?
>
>No, it would have lower minimum size for / and would not support LVM in order to save the space for a separate /boot.
>
>> I think there is no real value in adding one more recipe.
>
>A "small_disk" recipe would support much lower disk sizes than the other recipes.
Ok, understood.
If we raise the minimum size of the root partition now, it's plausible,
to resurrect the small_disk recipe.
>>> 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...
>
>It does not have to include many use cases. It could be simple, e.g.:
>- "atomic", "home" and "multi" are intended for workstations with a desktop environment;
>- "server" is intended for servers with data in /srv;
>- "small_disk" is intended for systems without a desktop environment on disks too small for other recipes.
>
>>>>> The /boot partition size is bigger than I expected in all LVM
>>>>> case(...)
>>>> 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...
>
>It is clearly a bug in partman-auto-lvm because the resulting sizes do not match the partman-auto-recipe specification. It remained unnoticed only because the EFI and /boot partitions had fixed sizes in recipes.
Ok, so if noone objects, I would vote for this solution.
@Pascal: Would you be able to provide a merge request for this in
partman-auto-lvm, please?
I would then locally build an installer image for testing with the
partman-auto and partman-auto-lvm changings (we don't have a method to
build an image via salsa-ci with two MR involved AFAIK).
>> So, keep the logic simple, as a trade-off?
>
>I'd prefer to fix the logic in partman-auto-lvm so that it matches the specification.
>
Holger
Reply to: