Hi, Am 23. August 2024 00:15:44 MESZ schrieb Pascal Hambourg <pas...@plouf.fr.eu.org>: >On 22/08/2024 at 17:19, Holger Wansing wrote: >> Pascal Hambourg <pas...@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 >>>> <pas...@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
