Hi, 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>: > >> > >>> 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 / ?
Looking at above values, I could think about something like 8G. Of course, that would make the "separate home" and "separate home+var+tmp" recipes useless/senseless on minimal disks as 10G, but we cannot forcibly support such minimal disks with all recipes, of course. And for 20G or bigger, it would work, so yes, I would say 8G should be fine as minimum. We will need to check, what's the new minimum disk size, for which guided partitioning is possible (the installation-guide needs an update here - and for other facts as well). > >> 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. But that's nearly the same as the atomic recipe, isn't it? I think there is no real value in adding one more recipe. > 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. 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... > >> 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. 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... So, keep the logic simple, as a trade-off? I would be happy for more opinions on this proposal, BTW... Holger -- Holger Wansing <hwans...@mailbox.org> PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
