Hi, Pascal Hambourg <pas...@plouf.fr.eu.org> wrote (Sat, 23 Nov 2024 15:05:15 +0100): > On 23/11/2024 at 14:32, Holger Wansing wrote: > > Pascal Hambourg <pas...@plouf.fr.eu.org> wrote (Sat, 23 Nov 2024 14:17:31 > > +0100): > >> On 23/11/2024 at 14:03, Holger Wansing wrote: > >>> > >>> but the main issue (a heavy swap partition eats up most disk space) is > >>> now solved with the server recipe, so I think it's ok to close this > >>> report. > >> > >> This bug report could even have been closed in 2020 after the > >> introduction of partman-auto/cap-ram. I just wanted to point out that > >> the issue is solved with all built-in recipes, not only the server one. > > > > Things have changed here recently: > > > > from 2020 until September of this year you were right: it worked with any > > recipe (because of cap-ram -> 1G). > > > > However, in October we pushed in an overhaul of recipes, to improve > > calculation of partition sizes, and in-line with this, the cap-ram > > functionality was disabled by default; we needed this, to be able to get > > swap sizes bigger than 1G in auto-partitioning (and with this, to make > > hibernation work again on many machines). > > > > So, *now* it's only working with the server recipe on such machines. > > I beg to disagree. The new PRIORITY values defined in other recipes > (atomic, home, multi, small_disk) were designed to limit the swap size > to approximately 5% of disk size. So even with cap-ram disabled, the > swap cannot eat most disk space with any recipe.
Ah, indeed I forgot that part. I should have known, that you understand that all better than I do ;-)) Holger -- Holger Wansing <hwans...@mailbox.org> PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
