[Sorry about the slow reply -- school holidays are making me afk a lot.] Holger Wansing <hwans...@mailbox.org> writes:
> Hi, > > Am 9. August 2024 22:08:09 MESZ schrieb Pascal Hambourg > <pas...@plouf.fr.eu.org>: >>On 09/08/2024 at 17:05, Philip Hands wrote: >> >>> I tend to install servers with something like the multi recipe, except >>> instead of devoting the bulk of the disk to /home I instead leave it >>> unallocated (which I do by allocating a spare volume, with keep set to >>> avoid wasting time formatting it, and I then remove in the late script). >>> That then gives the flexibility of easily adding volumes or extending >>> them, as needed by the system. >> >>Guided partitioning with LVM already provides a feature to reserve space in >>the VG. Maybe it could be extended to guided partitioning with plain >>partitions. > > @phil: is there a reason, why you do not use this built-in feature, but > instead invent the wheel again? > Maybe you were just not aware of this? Ah, that preseed scripting I talk about was done before that feature appeared, so had to work around the lack. Now that you mention it, it reminds me that I did have a plan to update the preseeding to take advantage of that feature ... but I seem to have completely forgotten about that since. Sorry about that. >>> The other thing I tend to when using multiple partitions is allocate >>> 1.5GB to /boot so that there's enough room for a grml image for use in >>> conjunction with the grml-rescueboot package. >> >>Isn't this a niche use case ? My understanding was that guided partitioning >>was primarily intended for general purpose use cases. > > +1 for considering this being a corner case, which does not need to > be supported by the default recipes. I was thinking that we've been working on a "A bit more than enough" sizing for /boot in every incarnation of the defaults, and they seem to repeatedly end up being too small, so if we had the top end of the range being a little bigger that would probably end up saving people some pain at some point in the future. Doing that has the side benefit of providing enough space for a rescue image (at present), which can be very useful. I know its a bit niche, but on the other hand I'd say that it's pretty frustrating for people to discover grml-rescueboot, and then realise that they don't have quite enough space to use it without running out of space on /boot during kernel upgrades, and that if they want to change that, they'll either have to do some rather advanced moving of partitions, or reinstall (despite still having e.g. 800GB spare on /home) If the disk they're installing onto is huge, then having the upper limit for /boot be 0.5GB larger will go unnoticed, whereas running out of space on /boot is generally pretty annoying, or worse. I'm mainly arguing for being a little more generous with /boot because we seem to have been too frugal in the past. >>> Would it be worth making the upper limit for /boot be 1.5G, and using a >>> scaling factor (if possible) that will only use that much for disks >>> larger than 1TB, say, as then its a small enough proportion to be no >>> loss even if people don't use it for grml. >> >>It is at least possible. The PRIORITY value in recipes represents a "scaling >>factor", in a rather convoluted way. Yeah, I've never been 100% sure that I've understood the way that works enough to predict the outcome with certainty, but I'm sure we can come up with something that would only use the extra space with larger disks. Cheers, Phil. -- Philip Hands -- https://hands.com/~phil
signature.asc
Description: PGP signature
