Bug#838919: closed by Ben Hutchings <ben@decadent.org.uk> (Re: Bug#838919: debian-installer: please calculate swap parition according to max RAM supported by the motherboard)
2016-09-26 19:30 GMT+03:00 Debian Bug Tracking System <owner@bugs.debian.org>:
> This is an automatic notification regarding your Bug report
> which was filed against the debian-installer package:
>
> #838919: debian-installer: please calculate swap parition according to max RAM supported by the motherboard
>
> It has been closed by Ben Hutchings <ben@decadent.org.uk>.
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Ben Hutchings <ben@decadent.org.uk> by
> replying to this email.
>
>
> --
> 838919: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838919
> Debian Bug Tracking System
> Contact owner@bugs.debian.org with problems
>
>
> ---------- Edelleenlähetetty viesti ----------
> From: Ben Hutchings <ben@decadent.org.uk>
> To: 838919-done@bugs.debian.org
> Cc:
> Date: Mon, 26 Sep 2016 17:27:23 +0100
> Subject: Re: Bug#838919: debian-installer: please calculate swap parition according to max RAM supported by the motherboard
> On Mon, 2016-09-26 at 10:23 -0400, Lennart Sorensen wrote:
>> On Mon, Sep 26, 2016 at 05:06:18PM +0300, Martin-Éric Racine wrote:
>> >
>> > Package: debian-installer
>> > Severity: wishlist
>> >
>> > As far as I can tell, d-i calculates the size of the swap partition
>> > according to the curently installed amount of RAM.
>> >
>> > Whenever the RAM is upgraded later on, the swap parition no longer
>> > fulfills its intended purpose, in cases when it would be needed to
>> > store hibernate images, since the parition was calculated to store
>> > a much smaller RAM image.
>> >
>> > A more desirable method would be for d-i to use 'dmidecode' to
>> > probe the system's memory controller for the maximum amount of RAM
>> > that is supported and to calculate the swap partition size
>> > according to that.
>>
>> Of course many people never upgrade their ram, and often going beyond 50%
>> of maximum gets very expensive.
>>
>> Also many people never suspend.
>>
>> Also dmidecode is x86 only and some older systems didn't have it, so it
>> wouldn't help the majority of architectures.
>>
>> So while it is an idea, I am not convinced it doesn't actually create
>> problems.
>
> Right, this proposal sounds like it would be worse than the current
> heuristic in general.
>
> A better way to deal with this is to use LVM and leave some space
> unallocated initially so it's possible to grow swap or whatever other
> partition needs it later.
The thing is, right now, the user has two choices:
1) Trust d-i to make the right choices once, even though more RAM is
likely to be added later on, at which point there won't be enough swap
to save the suspend image;
2) Perform every tiny step of the partitioning and filesystem creation
manually in order to take into consideration the memory controller's
maximum supported RAM capacity.
The former is inadequate, the later is overkill and honestly beyond
the lay user's skills.
How about being able to tell the automated partitioning variant how
much swap we want, but let it calculate the size of the other
partitions by itself?
Martin-Éric
Reply to: