Holger Wansing <hwans...@mailbox.org> writes:

> Hi,
>
> Am 8. August 2024 08:16:03 MESZ schrieb Pascal Hambourg 
> <pas...@plouf.fr.eu.org>:
>>On 07/08/2024 at 20:33, Holger Wansing wrote:
>>> 
>>> A recipe specific for server installations, which limits the swap to let's
>>> say 1G or 2G, because the machine has enough RAM built-in.
>>
>>What would be the other partitions in this "server" recipe ?
>>- /var/log as suggested by José Ángel Pastrana ?
>>- /srv ?
>
> I think, a separate /srv and /var would be useful.
>
>>>> limiting the swap size to the lower of
>>>> 100% RAM size and ~5% (open to discussion) disk space.
>>
>>Any opinions about this ?
>
> A good default IMO.

Sorry for being late to the party.

I also think this looks a lot better than what we currently have.

While we're changing things, could we distinguish between LVM recipes
and non-LVM ones?

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.

At present I'm doing that with this fragment of my preseed framework:

  https://hands.com/d-i/preseed/classes/partition/_/unfilled/

but we could include this as a feature of D-I if people thought it was
useful, and could presumably implement it without needing to allocate
and then remove the spare bit as I'm doing at present.

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.

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.

Cheers, Phil.
-- 
Philip Hands -- https://hands.com/~phil

Attachment: signature.asc
Description: PGP signature

Reply via email to