Bug#987503: swap partition only 1 GB instead of at least 1 x RAM size

[Johannes Schauer Marin Rodrigues]

Hi,

On Wed, 14 Sep 2022 12:29:13 +0200 Pascal Hambourg  
wrote:
> Sorry to insist, but IMO this issue should really be worked out. I once
> suggested the following simple formula :
> 
>  max swap size = min(RAM size, disk space * R)
> 
> with R being a ratio between 0 and 100% to be defined.
> 
> For example with R=5%, the swap size would be limited to either the RAM size
> or 5% of available disk space, whichever is lower.
> 
> Doesn't that sound reasonable for most setups, at least more than the current
> formula ?

the default partitioning scheme now has made hibernation impossible for three
whole stable releases. I have no experience in writing d-i code but just so
that *something* happens I submitted this merge request to partman-auto:

https://salsa.debian.org/installer-team/partman-auto/-/merge_requests/12

This MR keeps the partman-auto/cap-ram setting because it has now been in
partman-auto for so long that likely other users of d-i have started depending
on its existence. Instead, I raised the limit imposed by partman-auto/cap-ram
while at the same time adding a new setting I called partman-auto/perc-ram
which (if I'm reading the code correctly) should cap the swap size at X percent
of the remaining free disk space. This way, d-i should continue to work even in
situations where there is more RAM than disk space for which commit 7966fcd was
designed in the first place.

This is a draft MR because it is untested. Maybe somebody could help and review
and test it.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#987503:

[Richard Hartmann]

On Sun, Jul 9, 2023 at 7:48 PM Cyril Brulebois  wrote:

> For the avoidance of doubt, the relevant partman-auto code is present
> in buster, bullseye, and bookworm.

Thanks for the correction; I was under the impression that this has
been more recent. I don't install my systems very often, basically
only when I get a new machine. Debian Just Works(TM), as you certainly
know. Now that I think about it, I do remember that I had to partition
the Gen 7 by hand as well though I had forgotten the details as to
why.

Bug#987503:

[Rainer Dorsch]

Am Sonntag, 9. Juli 2023, 19:35:53 CEST schrieb Richard Hartmann:
> I tried hibernation on Thinkpad X1 Carbon Gen 1, Gen 5, Gen 7, and Gen
> 11. They all work. As per
> https://chaos.social/@waldi/110683468203241035 , I believe that the
> definition of "modern system" Waldi refers to means catering to a
> Windows world, something not deeply relevant to the Debian use case.

I can a a data point:

For a new HP Laptop 17-cp2xxx with an AMD Ryzen 5 7520U hibernation also works 
flawless with an correctly sized swap partition.

Regards
Rainer


-- 
Rainer Dorsch
http://bokomoko.de/

Bug#987503:

[Cyril Brulebois]

Richard Hartmann  (2023-07-09):
> As such, the current behavior is a breaking change for laptop users and
> leaves them with a broken system; when they realize why hibernation does
> not work they need to reinstall the system or reformat by hand with all
> the data moving that entails.
> 
> The fact that we're stuck with this for a whole stable release cycle
> makes things even worse.

I read your message as if that was some kind of recent regression.

For the avoidance of doubt, the relevant partman-auto code is present
in buster, bullseye, and bookworm.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#987503:

[Richard Hartmann]

I tried hibernation on Thinkpad X1 Carbon Gen 1, Gen 5, Gen 7, and Gen
11. They all work. As per
https://chaos.social/@waldi/110683468203241035 , I believe that the
definition of "modern system" Waldi refers to means catering to a
Windows world, something not deeply relevant to the Debian use case.

Steve's point about servers with more RAM than local storage caters a
nice use case to the detriment of the default. It does not design for
the common case with significantly more local storage than RAM, and
certainly violates the principle of least surprise.
Server operators are also more likely to have automation, change
control, Q processes, custom install options, hardware, etc. than
normal users. In other words: They are more likely to diverge from the
default settings.

Desktop users likely do not care, or notice, either way.


Using only part of the local storage and reserving more with LVM is
certainly not the default use case, either. It is also not the default
behavior of the guided installation.

As such, the current behavior is a breaking change for laptop users
and leaves them with a broken system; when they realize why
hibernation does not work they need to reinstall the system or
reformat by hand with all the data moving that entails.


The fact that we're stuck with this for a whole stable release cycle
makes things even worse.


Richard

Bug#987503: SWAP=115% of RAM (?)

[Rainer Dorsch]

I just run into the same issue.

https://lists.debian.org/debian-boot/2023/07/msg00049.html

Many thanks Josch for sharing the partman-auto workaround in

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987503#30

worked well for me.

Just to get another datapoint, I checked a Manjaro system I recently installed 
and it did not have an issue with hibernation, but worked flawless.

It has 8 GB of RAM, 224 GB of SSD and manjaro created a swap partition of 
about 9 GB or (around 115% or the RAM size).

Drives:
  Local Storage: total: 223.57 GiB used: 89.31 GiB (39.9%)
  ID-1: /dev/sda vendor: SanDisk model: SDSSDA240G size: 223.57 GiB

MiB Spch:   7793,0 total,   1537,6 free,   2590,4 used,   3665,0 buff/cache
MiB Swap:   9011,2 total,   7391,3 free,   1619,9 used.   4096,0 avail Spch

Wouldn't it be a rather quick solution to add two options to partman (desktop/
laptop or server optimized), which either creates a swap partition of 
sufficient 
size or keeps the 1GB partition? Would probably work for more than 80% of the 
desktop/laptop users.

Thanks
Rainer

-- 
Rainer Dorsch
http://bokomoko.de/

Bug#987503: swap partition only 1 GB instead of at least 1 x RAM size

[Wes Frazier]

Just hit this on Debian Bookworm.

Just a thought, but couldn't the laptop-detect package come in handy here? 
Switching the algorithm for swap size, based on if the target hardware is a 
laptop or not?

- Wes

Bug#987503: swap partition only 1 GB instead of at least 1 x RAM size

[Diederik de Haas]

On Saturday, 25 February 2023 08:46:21 CET Bastian Bittorf wrote:
> There was an argument by steve:
> "waste hundreds of gigabytes on swap space."
> 
> => If a computer has "hundreds of gigabytes" of RAM
> (and so swap), you do not care - you have enough resources anyway.

The use-case which was the cause for this change was a system with:
- 384 GB RAM !
- 128 GB disk (2x128GB in RAID-1 to be exact)

> If you are in a special situation, where you have
> more RAM than diskspace, you should better do a manual partitioning,
> an not the other way: most people have more diskspace than RAM.

The use-case above seem quite unusual to me. Maybe not in professional cloud 
environments, but I don't have any experience with that.

> My usecase (which is broken now) is suspend-to-disk (32 GB RAM, 2TB disc)

This is quite a common use case for laptops. Failure to do so can/will result 
in data loss.
FWIW: to save on energy, I'm now also doing that on my PC, which has 64GB RAM 
which I presume is somewhat large for now. I'm a control freak and an 
experienced user, so I always do manual partitioning, so I didn't run into 
this bug.

> The change was introduces by:
> https://salsa.debian.org/installer-team/partman-auto
> 
> commit 7966fcdbeea345432836c685e425fd59a8628b44

>From that commit:
> Template: partman-auto/cap-ram
> Type: string
> Default: 1024
> Description: for internal use; can be preseeded
> 
>  Cap RAM size to specified size in MB, when calculating the swap
>  partition size. Defaults to 1024, meaning 1GB, and since swap is
>  maximum 200% of RAM in the default recipes, it results in swap
>  partitions to be capped at 2GB. To revert to previous behaviour of
>  uncapped swap size with respect to available ram, preseed this key to
>  any string, e.g. partman-auto/cap-ram=false

So the default was changed to accomodate a system with more RAM (384GB) then 
disk space (128GB). That amount of RAM is huge and I'd guess quite uncommon 
and that amount of disk space is quite small.
Taking that as default does not make sense to me.

Breaking suspend to disk for the majority of users with potential/likely data 
loss (a browser often uses >2GB), seems ill-advised.

Having ppl with more RAM then disk space use preseeding to change the default, 
seems like a better 'default' and way to deal with that.

On Thursday, 8 December 2022 13:05:48 CET Bastian Blank wrote:
> On Thu, Dec 08, 2022 at 11:35:43AM +0100, Jan Kowalsky wrote:
> > So: please set a default again which is reasonable for laptops and
> > workstations. We always recommend debian for desktops to our customers.
> 
> The current default is suitable.  Hibernation does not work on any
> modern x86 machine and you don't want to have huge swap on desktop
> machines as it only adds latency.

Hibernation does work on my machine.
If you regularly use swap space during normal operation, you just have too 
little RAM and the appropriate fix is to buy more RAM.
But I don't see a/the problem when the use-case is hibernation?

So I too think the default behavior should be changed.

My 0.02

signature.asc
Description: This is a digitally signed message part.

Bug#987503: swap partition only 1 GB instead of at least 1 x RAM size

[Bastian Bittorf]

This bug is open since nearly 2 years  
and needs a fix, please do it.

It is absolutely annoying to workaround such issues.
If there is anything where i cant help, i will do so.

There was an argument by steve:
"waste hundreds of gigabytes on swap space."

=> If a computer has "hundreds of gigabytes" of RAM
(and so swap), you do not care - you have enough resources anyway.

If you are in a special situation, where you have
more RAM than diskspace, you should better do a manual partitioning,
an not the other way: most people have more diskspace than RAM.

My usecase (which is broken now) is suspend-to-disk (32 GB RAM, 2TB disc)

The change was introduces by:
https://salsa.debian.org/installer-team/partman-auto

commit 7966fcdbeea345432836c685e425fd59a8628b44
Author: Julien Cristau 
Date:   Mon Mar 9 20:05:35 2020 +0100

Fix installs with more RAM than disk space

Import from Ubuntu: Introduce partman-auto/cap-ram, to allow capping RAM
size as used for swap partition calculations. This allows us to cap the
minimum size of swap partitions size to 1*CAP, and their maximum size to
a maximum of 2 or 3*CAP depending on architecture. Default is set to
1024, thus capping swap partitions to between 1 and 3GB. LP: #1351267,
closes: #949651, #950344.  Patch from Dimitri John Ledkov.

Thanks & bye,
Bastian Bittorf

Bug#987503: swap partition only 1 GB instead of at least 1 x RAM size

[Jason Quinn]

I was also bitten by this bug with the Debian bookworm alpha1 era
installer. This is not a wishlist kind of bug; This is a bug of grave
severity. Breaking hibernation is unacceptable and is a key feature of
modern operating systems for both laptop and desktop users. If the
idea behind the 1GB default is to cater to the server world, then
somewhere the installer needs to either prompt the user to say what
kind of installation it is (desktop or server) or to offer a choice
between the two camps so the installer picks better defaults.

I completely don't understand the comments about hibernation not
working on x86. I'm going to disregard that unless there's a
clarification.

Thanks to Johannes (in Message #30) for suggesting a solution. Other
workarounds found on the web suggest tinkering with systemd's
SYSTEMD_BYPASS_HIBERNATION_MEMORY_CHECK variable and re-configuring
the GRUB menu (see
https://bbs.archlinux.org/viewtopic.php?pid=1928690#p1928690). I
haven't tried these yet but the Debian installer shouldn't burden
users with such low-level tinkering.

This is going to push potential Debian users to other distros after
they discover hibernate doesn't work.

Bug#987503: swap partition only 1 GB instead of at least 1 x RAM size

[Pascal Hambourg]

On 30/12/2022 at 01:03, Joshua McNeil wrote:

On Thu, 8 Dec 2022 13:05:48 +0100 Bastian Blank  wrote:


Hibernation does not work on any
modern x86 machine and you don't want to have huge swap on desktop
machines as it only adds latency.

(...)

Hibernation works just fine on all of my modern x86_64 machines when the
swap space is sufficient. Could you elaborate on why you believe it doesn't?


I am interested too. The only restriction I am aware of is that 
hibernation is currently disabled when UEFI secure boot is enabled 
(until the hibernation image can be validated with the TPM, IIRC). Has 
secure boot become mandatory on all modern x86 machines ? My most recent 
one is 10 years old, I'm afraid it does not qualify as "modern".



I agree that in many cases swap causes degraded
performance for modern systems.


Can you explain why unused swap space causes degraded performance ?
I mean, how does 8 GB unused swap is different from 1 GB unused swap ?
It was my naive understanding that performance was affected by swap 
activity, not swap size.

Bug#987503: swap partition only 1 GB instead of at least 1 x RAM size

[Joshua McNeil]

On Thu, 8 Dec 2022 13:05:48 +0100 Bastian Blank  wrote:
>
> The current default is suitable.  Hibernation does not work on any
> modern x86 machine and you don't want to have huge swap on desktop
> machines as it only adds latency.
>
> Bastian
>

I recently ran into this issue while considering Debian for desktop and
laptop usage and would also like to request increasing the swap default to
at least the size of RAM.

Hibernation works just fine on all of my modern x86_64 machines when the
swap space is sufficient. Could you elaborate on why you believe it doesn't?

If the primary objective was reducing memory latency I would suggest
instead modifying the default vm.swappiness which would actually affect how
often swap is used. I agree that in many cases swap causes degraded
performance for modern systems. However, hibernation is a good use for it.

In my experience when hibernation fails Debian appears less battery
efficient on laptops due to the need to retain power to memory when the lid
is closed. Ensuring the default  swap size is sufficient to support
hibernation helps improve this experience.

Bug#987503: swap partition only 1 GB instead of at least 1 x RAM size

[Pascal Hambourg]

On 08/12/2022 at 13:05, Bastian Blank wrote:


Hibernation does not work on any modern x86 machine


Why ?

Bug#987503: swap partition only 1 GB instead of at least 1 x RAM size

[Bastian Blank]

On Thu, Dec 08, 2022 at 11:35:43AM +0100, Jan Kowalsky wrote:
> So: please set a default again which is reasonable for laptops and
> workstations. We always recommend debian for desktops to our customers.
> But if many things are not really suitable for Desktops people will
> avoid debian.

The current default is suitable.  Hibernation does not work on any
modern x86 machine and you don't want to have huge swap on desktop
machines as it only adds latency.

Bastian

-- 
Worlds are conquered, galaxies destroyed -- but a woman is always a woman.
-- Kirk, "The Conscience of the King", stardate 2818.9

Bug#987503: swap partition only 1 GB instead of at least 1 x RAM size

[Jan Kowalsky]

Hi all,

we do second this. While we always installed workstations automatically
with debian preseeding and the default receipts (lvm encrypted) we
noticed the defaults suddenly changed in bullseye.

I would support the assumption that for server installations this is
not a big issue since one (at least we) do special partitioning any way
for servers.

So: please set a default again which is reasonable for laptops and
workstations. We always recommend debian for desktops to our customers.
But if many things are not really suitable for Desktops people will
avoid debian.

Thanks
Jan

-- 
datenkollektiv.net OHG
Böhmische Str. 14
01099 Dresden
Tel: (0351) 41 88 66 00
E-Mail: carsten.ungewit...@datenkollektiv.net
http://www.datenkollektiv.net
Registergericht: Amtsgericht Dresden HRA 11427

Bug#987503: swap partition only 1 GB instead of at least 1 x RAM size

[Pascal Hambourg]

Hello,

On 09/09/2022 at 16:54, Johannes Schauer Marin Rodrigues wrote:

>  partman-auto/cap-ram=1024

(...)

Description: for internal use; can be preseeded
  Cap RAM size to specified size in MB, when calculating the swap
  partition size. Defaults to 1024, meaning 1GB, and since swap is
  maximum 200% of RAM in the default recipes, it results in swap
  partitions to be capped at 2GB.


This description is not even correct. The maximum size is 1 GB, not 2 GB 
due to the current settings in the default recipes :


min  prio max
100% 512 200% linux-swap

In the current algorithm, whenever prio <= min, the increment factor is 
set to 0 so the final size is capped to the min value and can never 
reach the max value.


To achieve the described behaviour, prio should be > 100%.

(Also, when looking at partman-auto recipes, I spotted other possible 
inconsistencies. For instance, the minimum size for / in multi_scheme 
(2000) is bigger than in home_scheme (1500) which is bigger than in 
atomic_scheme (800 or 900). Isn't it illogical that the minimum size 
decreases when it needs to contain more stuff ?)



Maybe this helps somebody. Thanks to pham from the #debian-boot IRC channel for
this tip!


You're welcome josch !

Sorry to insist, but IMO this issue should really be worked out. I once 
suggested the following simple formula :


max swap size = min(RAM size, disk space * R)

with R being a ratio between 0 and 100% to be defined.

For example with R=5%, the swap size would be limited to either the RAM 
size or 5% of available disk space, whichever is lower.


Doesn't that sound reasonable for most setups, at least more than the 
current formula ?

Bug#987503: swap partition only 1 GB instead of at least 1 x RAM size

[Johannes Schauer Marin Rodrigues]

Hi,

On Sun, 5 Sep 2021 10:37:13 +0200 Pascal Hambourg  
wrote:
> On Sun, 25 Apr 2021 17:33:28 + Martin  wrote:
> > Also I assume, that desktop PCs are more oftenly installed
> > relying on d-i defaults, while servers are typically installed
> > by experienced admins.
> 
> I agree and am afraid that the new swap size will bite many users who 
> want hibernation on desktop or laptop PCs and use guided partitioning. 
> Besides, I cannot even imagine anyone using guided partitioning on a server.
> 
> > I'ld prefer the solution suggested in #780208, because it helps
> > in other cases, too.
> 
> Guided partitioning using LVM allows to reserve some free space in the 
> volume group, which can be used later to extend logical volumes.

if, like me, you have found this bug after wondering about the 1 GB small swap
partition on your brand-new Debian installation, here is a workaround that lets
the guided partitioner select a swap size roughly equal to your RAM size.

In the installer menu, press "e" to edit the default installation option. In
the line that says "linux /install.amd/vmlinuz" add the following separated by
a space after vmlinuz:

partman-auto/cap-ram=n

Then press Ctrl-x or F10 to boot debian-installer with your changes. This will
result in uncapped swap size which should be fine for normal laptops and
desktops. If instead you want to set a fixed cap at a certain number of MB, you
can instead add:

partman-auto/cap-ram=1024

This will cap the swap size to 1024 MB. This is currently the default. Increase
this value to get a larger swap partition (size is given in MB) or replace it
by a arbitrary string like the "n" above to not have swap size capped at all.
Here is the description of cap-rm from partman-auto.templates in the
partman-auto source package:

Description: for internal use; can be preseeded
 Cap RAM size to specified size in MB, when calculating the swap
 partition size. Defaults to 1024, meaning 1GB, and since swap is
 maximum 200% of RAM in the default recipes, it results in swap
 partitions to be capped at 2GB. To revert to previous behaviour of
 uncapped swap size with respect to available ram, preseed this key to
 any string, e.g. partman-auto/cap-ram=false

Maybe this helps somebody. Thanks to pham from the #debian-boot IRC channel for
this tip!

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#987503: swap partition only 1 GB instead of at least 1 x RAM size

[Richard Z]

If hibernation is broken by default it would be wise to disable it
completely because some systems may trash or lockup if they attempt to
hibernate with 1G of RAM.

Bug#987503: swap partition only 1 GB instead of at least 1 x RAM size

[Pascal Hambourg]

Hello all,

On Sun, 25 Apr 2021 17:33:28 + Martin  wrote:

On 2021-04-24 21:40, Steve McIntyre wrote:


There is no such thing as a "correct" formula, though. The old formula
was similarly causing lots of hassle for people installing on servers
who didn't want to waste hundreds of gigabytes on swap space.


There may not be a correct formula, but there are saner values than 
others. AFAIK, "swap size = RAM size" is considered a sane default for 
hibernation so e.g. I think that 16 GB swap in 500 GB disk space with 16 
GB RAM is saner than 1 GB in most cases. On the other hand 1 GB swap in 
8 GB disk space with 256 MB RAM is insane (yes I still have one such 
machine).


What about something like "swap size = min(RAM size, disk space * R%)" 
(with R to be defined) ?



Also I assume, that desktop PCs are more oftenly installed
relying on d-i defaults, while servers are typically installed
by experienced admins.


I agree and am afraid that the new swap size will bite many users who 
want hibernation on desktop or laptop PCs and use guided partitioning. 
Besides, I cannot even imagine anyone using guided partitioning on a server.



I'ld prefer the solution suggested in #780208, because it helps
in other cases, too.


Guided partitioning using LVM allows to reserve some free space in the 
volume group, which can be used later to extend logical volumes.

Bug#987503: swap partition only 1 GB instead of at least 1 x RAM size

[Martin]

Hi Steve,

On 2021-04-24 21:40, Steve McIntyre wrote:
> On Sat, Apr 24, 2021 at 04:14:16PM -0400, Martin wrote:
> >Please restore the correct formula, thank you! (Or even allow
> >users to chose a swap size for the auto-partioner (e.g. if a
> >users already plans to upgrade the RAM, see #780208).
>
> There is no such thing as a "correct" formula, though.

OK, I put it this way: "Please restore the formula, that used to
work well since many releases for myself and many others, YMMV."

I was bitten by this bug, because I didn't even check swap size,
blindly trusting in the hundreds of times I installed Debian. So
I had my lovely new system and hibernation was broken. It took
me a while to realise, that swap space was too small :-(

> The old formula
> was similarly causing lots of hassle for people installing on servers
> who didn't want to waste hundreds of gigabytes on swap space.

I see. My servers only have 8..64 GB of RAM, but are not that
restricted on disk space, that a wasting 8..64 GB were dramatic.

And then: Why 1 GB of swap? Why not 0 GB then? Looks like a
mistake/typo to me.

Also I assume, that desktop PCs are more oftenly installed
relying on d-i defaults, while servers are typically installed
by experienced admins. The latter would use advanced methods of
partioning, either manually or using automated tools.

> We could probably do with an "is this a server or a desktop" up-front,
> but we don't have that yet.

I'ld prefer the solution suggested in #780208, because it helps
in other cases, too. But for the moment reverting to the old
behaviour would be very helpful.

Cheers

Bug#987503: swap partition only 1 GB instead of at least 1 x RAM size

[Steve McIntyre]

Control: severity -1 wishlist

Hi Martin!

On Sat, Apr 24, 2021 at 04:14:16PM -0400, Martin wrote:
>Package: debian-installer
>Version: bullseye-rc1
>Severity: important
>Tags: d-i
>
>I installed using the graphical UI and selected automatic
>partitioning with encrypted LVM, with all files in '/'.
>RAM size is 16 GB, SSD has 1 TB.
>
>To be able to hibernate the system, a swap partition of at least
>1 x RAM size is necessary. d-i did this correctly since many
>releases, but in bullseye it is broken at the moment.
>
>Please restore the correct formula, thank you! (Or even allow
>users to chose a swap size for the auto-partioner (e.g. if a
>users already plans to upgrade the RAM, see #780208).

There is no such thing as a "correct" formula, though. The old formula
was similarly causing lots of hassle for people installing on servers
who didn't want to waste hundreds of gigabytes on swap space.

We could probably do with an "is this a server or a desktop" up-front,
but we don't have that yet.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
  Mature Sporty Personal
  More Innovation More Adult
  A Man in Dandism
  Powered Midship Specialty

Bug#987503: swap partition only 1 GB instead of at least 1 x RAM size

[Martin]

Package: debian-installer
Version: bullseye-rc1
Severity: important
Tags: d-i

I installed using the graphical UI and selected automatic
partitioning with encrypted LVM, with all files in '/'.
RAM size is 16 GB, SSD has 1 TB.

To be able to hibernate the system, a swap partition of at least
1 x RAM size is necessary. d-i did this correctly since many
releases, but in bullseye it is broken at the moment.

Please restore the correct formula, thank you! (Or even allow
users to chose a swap size for the auto-partioner (e.g. if a
users already plans to upgrade the RAM, see #780208).