On Thu, Mar 5, 2020 at 11:15 AM Larry Finger wrote:

On 3/5/20 11:09 AM, ITwrx wrote:

...

On 3/5/20 11:06 AM, Axel Braun wrote:

...

Hi, I'm just installing TW on a new machine. Partition proposal is 2GB for swap, with 16GB RAM. Following that proposal hibernation should never work. Is RAM =Swap size still a valid assumption? Viele Grüße Axel

when i installed TW there was an option for setting swap equal to ram, for just this reason. Maybe it's not there for all install images/options? maybe it's just hiding from you?

The requirement is that swap be as large as the compressed contents of RAM. A factor of 2 in the compression is a reasonable choice.

It's a bit complicated. 1. 50% RAM needs to be free to create the hibernation image, so first evict enough anon pages to swap 2. create the hibernation image in memory 3. compress and write out the hibernation image to *contiguous space* in the swap device Because the workload could result in locality usage of the swap partition such that there isn't enough contiguous space in the swap device, it could fail. Also, there's some non-deterministic aspects to eviction of anonymous pages, and that too can non-deterministically fail. https://lore.kernel.org/linux-mm/CAA25o9TvFMEJnF45NFVqAfdxzKy5umzHHVDs+SCxrC... It's fairly trivial to hit failure on the first step, if vm.swappiness=0 and you fill up RAM above 50% with e.g. just some Firefox tabs. If you really think you want vm.swappiness=0 you actually want vm.swappiness=1 to make sure you don't run into this problem. In reality, with an SSD or ZRAM backed, you're probably better off with vm.swappiness=100 because there's no meaningful difference in cost between reclaim on file pages and anonymous pages. I think swap 1:1 with RAM is reasonable for most use cases. But if the workload tends to produce a lot of swap, and/or less compressible pages, then you might need a bigger swap partition. Or split out hibernation images into a dedicated file, separate from swapfile (page file really). I'm not sure how likely that is on Linux. But making it reliable for the vast majority of workloads has been elusive. Quite a lot of people say they can't get it to work reliably, and then some say it works more reliably than S3 (suspend to RAM). *shrug* -- Chris Murphy -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thu, Mar 5, 2020 at 6:54 PM Carlos E. R. wrote:

On 06/03/2020 00.08, Chris Murphy wrote:

...

On Thu, Mar 5, 2020 at 11:15 AM Larry Finger wrote:

...

On 3/5/20 11:09 AM, ITwrx wrote:

...

On 3/5/20 11:06 AM, Axel Braun wrote:

...

Hi, I'm just installing TW on a new machine. Partition proposal is 2GB for swap, with 16GB RAM. Following that proposal hibernation should never work. Is RAM =Swap size still a valid assumption? Viele Grüße Axel

when i installed TW there was an option for setting swap equal to ram, for just this reason. Maybe it's not there for all install images/options? maybe it's just hiding from you?

The requirement is that swap be as large as the compressed contents of RAM. A factor of 2 in the compression is a reasonable choice.

It's a bit complicated.

1. 50% RAM needs to be free to create the hibernation image, so first evict enough anon pages to swap

Sorry, not true. I have often 10..15% of free ram and I hibernate fine.

I don't doubt it. Did you read the part I wrote after the comma? Try filling up RAM to 90% however you like, then capture /proc/meminfo, then hibernate, then resume, then capture /proc/meminfo. I think you'll see what's happened -- Chris Murphy -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

All, thanks for your answers so far.... Am Freitag, 6. März 2020, 09:19:02 CET schrieb Johannes Meixner:

On Mar 5 11:09 ITwrx wrote (excerpt):

...

... there was an option for setting swap equal to ram, for just this reason. Maybe it's not there for all install images/options? maybe it's just hiding from you?

I did not pay attention to that option but as far as I vaguely rememeber I saw it sometimes and sometimes not so it seems there is some "hidden secret magic decision maker" in YaST or in a lower-level tool or library that is used by YaST.

Right from the partitioning proposal there is no option to increase swap partition - standard proposal is 2GB. In expert partioner three is no such either In guided stetup is the option 'enlarge to RAM size for suspend' (BTW, the german translation 'RAM Größe für Suspend erweitern' is misleading/wrong!) for the swap space. What about an option 'Partitioning for Laptop' that considers this (for the wishlist)? So, summary from the discussion: - swap size less than physical RAM may be OK (compression) - better close some RAM consuming applications before hibernation - Swap = RAM is still a good choice Thanks Axel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Andrei Borzenkov wrote:

Отправлено с iPhone

...

6 марта 2020 г., в 12:49, Axel Braun написал(а):

In guided stetup is the option 'enlarge to RAM size for suspend' (BTW, the german translation 'RAM Größe für Suspend erweitern' is misleading/wrong!)

Warum? As non-native English and German speaker I do not see anything wrong here.

The English version says to "enlarge to RAM size" whereas the German version only says "enlarge RAM size". -- Per Jessen, Zürich (9.6°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am Freitag, 6. März 2020, 11:20:02 CET schrieb Johannes Meixner:

And - if I understand things correctly - the swap disk space is needed for what is called "hibernation" but not for what is caled "suspend" but I am no expert in this area of subtle wording differences.

Correct - in case of suspend the status of the RAM is kept. hibernation dumps it to the hard disk and allows switching the PC off completely. suspend still uses little power. Cheers Axel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fri, Mar 6, 2020 at 4:49 AM Michal Kubecek wrote:

On Friday, 6 March 2020 12:19 Axel Braun wrote:

...

Am Freitag, 6. März 2020, 11:20:02 CET schrieb Johannes Meixner:

...

And - if I understand things correctly - the swap disk space is needed for what is called "hibernation" but not for what is caled "suspend" but I am no expert in this area of subtle wording differences. Correct - in case of suspend the status of the RAM is kept. hibernation dumps it to the hard disk and allows switching the PC off completely. suspend still uses little power.

I really miss the good old times when these were called "suspend to RAM" and "suspend to disk". Can't help thinking that it was way more obvious which is which and what each of them does...

It's also valid to drop 'suspend' entirely and go with 'sleep' vs 'hibernate'. I agree 'suspend' is potentially ambiguous. -- Chris Murphy -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am Freitag, 6. März 2020, 10:45:19 CET schrieb Per Jessen:

...

Отправлено с iPhone

...

6 марта 2020 г., в 12:49, Axel Braun написал(а):

In guided stetup is the option 'enlarge to RAM size for suspend' (BTW, the german translation 'RAM Größe für Suspend erweitern' is misleading/wrong!)

Warum? As non-native English and German speaker I do not see anything wrong here.

The English version says to "enlarge to RAM size" whereas the German version only says "enlarge RAM size".

Yes, whoever maintains the translation, 'Suspend auf RAM Größe erweitern' would be a proper wording Cheers Axel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Dne pátek 6. března 2020 12:25:54 CET, Axel Braun napsal(a):

Am Freitag, 6. März 2020, 10:45:19 CET schrieb Per Jessen:

...

...

Отправлено с iPhone

...

6 марта 2020 г., в 12:49, Axel Braun написал(а):

In guided stetup is the option 'enlarge to RAM size for suspend' (BTW, the german translation 'RAM Größe für Suspend erweitern' is misleading/wrong!)

Warum? As non-native English and German speaker I do not see anything wrong here.

The English version says to "enlarge to RAM size" whereas the German version only says "enlarge RAM size".

Yes, whoever maintains the translation, 'Suspend auf RAM Größe erweitern' would be a proper wording

Login to <https://l10n.opensuse.org/translate/yast-storage/master/de/? checksum=8d6ad048cf5a230a> and fix it. :-) -- Vojtěch Zeisek https://trapa.cz/ Komunita openSUSE GNU/Linuxu Community of the openSUSE GNU/Linux https://www.opensuse.org/

On Fri, Mar 6, 2020 at 2:36 AM Andrei Borzenkov wrote:

Отправлено с iPhone

...

6 марта 2020 г., в 12:49, Axel Braun написал(а):

In guided stetup is the option 'enlarge to RAM size for suspend' (BTW, the german translation 'RAM Größe für Suspend erweitern' is misleading/wrong!)

Warum? As non-native English and German speaker I do not see anything wrong here.--

'suspend' means 'suspend-to-RAM' or ACPI S3. 'hibernate' means 'suspend-to-disk' or ACPI S4 or S5. If the idea of the option is to indicate "make swap partition equal to RAM so that hibernation is possible" then s/suspend/hibernate. So I agree it's confusing but it sounds like the word 'suspend' is also used in English for this option, therefore it's not really a German translation problem. -- Chris Murphy -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am Donnerstag, 5. März 2020, 19:23:08 CET schrieb Hans-Peter Jansen:

Am Donnerstag, 5. März 2020, 18:06:52 CET schrieb Axel Braun:

...

Hi, I'm just installing TW on a new machine. Partition proposal is 2GB for swap, with 16GB RAM. Following that proposal hibernation should never work. Is RAM =Swap size still a valid assumption?

Start with the guided partitioner..

Hm, guided setup encrypts root partition AND swap. Not sure if this is a good idea.... Cheers Axel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sun, Mar 8, 2020 at 12:49 PM Christian Boltz wrote:

If you are paranoid enough to encrypt your root partition (you should!), then you don't want to have parts of your RAM (like open documents or in worst case your disk encryption key) swapped out to unencrypted swap ;-)

a) use swap on ZRAM https://github.com/systemd/zram-generator b) encrypt swap using /dev/urandom key generated at each boot Both mean hibernation is not possible. One possible solution is in the hibernation+secure boot thread, which could also serve this use case: https://lists.opensuse.org/opensuse-factory/2020-02/msg00385.html

This is somewhat similar to the discussion if you really need to encrypt the root partition, or if encrypting /home is good enough. IMHO it isn't, because for example files in /tmp/ can also contain sensitive data which you don't want to have unencrypted. For example, when you click a PDF attached to a mail in KMail, it will get stored in /tmp/ before it gets opened.

/tmp really should be on tmpfs. The UI/UX of asking the user for two passphrases (boot separate from login) is not acceptable. And further, neither the GRUB nor initramfs environments are sufficiently sophisticated to support i18n, and a11y needs properly. Piecemeal effort here and there to only enhance the security of English language users, and users who restrict their passphrases to ASCII, is just not a modern solution. One possible way of partly solving this is using the TPM to seal the key used to encrypt sysroot. That means leaked user data can be exposed if the entire laptop is stolen, just by booting. Still another way of solving this is using the user supplied login passphrase as an fscrypt master key, to encrypt the files the user session leaks /var, but this requires ext4 or f2fs right now, since Btrfs does yet support in-kernel fscrypt (via VFS). I think that user data should only ever leak into /tmp or ~/, where /tmp is tmpfs by default, and ~/ is encrypted by default. One way of getting to encrypted ~/ by default might be systemd-homed, which has Btrfs support, and locks the LUKS volume upon S3 (suspend-to-RAM), i.e. the DEK is removed from memory.

Sidenote: I have no idea if suspend to disk works with encrypted swap - I don't have any swap to test.

It just makes things more complicated, it doesn't by itself make them more unreliable. They're already unreliable due to myriad ACPI bugs that kernel developers don't have the resources to work around. e.g. one of many S3 bugs that happen on linux but not on Windows, clearly identified kernel regression, and fairly clearly identified ACPI/firmware bug that somehow Windows must work around. https://bugzilla.kernel.org/show_bug.cgi?id=185521 Hypothetically, linux suspend-to-disk should be more reliable if it depends only on S5, rather than S4. However, this too is inconsistent. The're sufficient complexity in the reclaim code, and non-deterministic behavior in anonymous page eviction that hibernation entry can often fail. That makes it difficult to diagnose for even experienced developers and troubleshooters, let alone mere mortals. In the idealized case of suspend-to-disk in a qemu-kvm, hibernation entry fails perhaps 1/3 of the time. That kind of non-determinism in what should be completely deterministic, demonstrates this is a difficult problem. If this leaves a significant minority (let alone majority) who can't reliably hibernate, then is it really worth the development effort to create a generic signed and encrypted hibernation image possible? Or are efforts better spent elsewhere to preserve user data in low power situations? These aren't necessarily mutually exclusive, but it is possible that misaligned expectations result in delays. -- Chris Murphy -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 08.03.20 um 22:45 schrieb Stasiek Michalski:

Plymouth actually supports translating the boot screen, so I don't see why that couldn't be extended to the password prompt it can create. As

Translating the password prompt is not the issue -- basically just displaying a lock icon would probably do -- but try typing your password containing chinese characters or 💩 emojis. Or just with some umlauts. On an USB keyboard.

for a11n, we have gfxboot which does tts basically in grub. I would say

I seem to rememberthat gfxboot does "just" play pre-"recorded" sentences, but does not do tts.

both i18n and a11y are possible very early in the boot process, we just don't see much development in that front. -- Stefan Seyfried

"For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, Mar 9, 2020 at 4:44 AM Johannes Meixner wrote:

Hello,

On Mar 8 14:18 Chris Murphy wrote (excerpt):

...

/tmp really should be on tmpfs.

perhaps normally it "should" but I think it is not mandatory, cf.

https://en.opensuse.org/openSUSE:Tmp_on_tmpfs#.2Ftmp.2F_versus_.2Fvar.2Ftmp....

this text is older, perhaps it is outdated so that nowadays /tmp on tmpfs is perhaps mandatory?

I'm not sure whether it's mandatory, but is it the openSUSE default? If it is, then someone undoing that is customizing, and takes the ensuing risk in their own hands. -- Chris Murphy -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hello Radoslaw, Am Montag, 9. März 2020, 18:06:57 CET schrieb Radosław Wyrzykowski:

On niedziela, 8 marca 2020 19:49:43 CET Christian Boltz wrote:

...

Hello,

Am Sonntag, 8. März 2020, 17:19:19 CET schrieb Axel Braun:

...

Hm, guided setup encrypts root partition AND swap. Not sure if this is a good idea....

It is.

If you are paranoid enough to encrypt your root partition (you should!), then you don't want to have parts of your RAM (like open documents or in worst case your disk encryption key) swapped out to unencrypted swap

This is somewhat similar to the discussion if you really need to encrypt the root partition, or if encrypting /home is good enough. IMHO it isn't, because for example files in /tmp/ can also contain sensitive data which you don't want to have unencrypted. For example, when you click a PDF attached to a mail in KMail, it will get stored in /tmp/ before it gets opened.

Sidenote: I have no idea if suspend to disk works with encrypted swap - I don't have any swap to test.

It does work very well on my ThinkPad T440. I have my root and swap partitions encrypted with LUKS. The root partition includes /boot, so I use GRUB to decrypt it and keep a key in the initramfs so I don't have to put in the passphrase twice (I followed the guide at https://en.opensuse.org/ SDB:Encrypted_root_file_system). I haven't had any problems with that setup, but that, of course, depends on your machine.

Thanks for sharing this. I had used the setup with the key in initramfs as well, but in this case - root and swap encrypted - it doubled the time at startup to about 40s! Although reboot is not a very frequent thing - uptime on the laptop mostly between 7 and 14 days - this long waiting period is quite annoying. Lets see if some new insights come along, if not, I will probably go again for a separate, encrypted /home partition, as before. (But this is OT for this thread ;-) Cheers Axel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thu, Mar 5, 2020 at 12:20 PM Brüns, Stefan wrote:

On Donnerstag, 5. März 2020 18:06:52 CET Axel Braun wrote:

...

Hi, I'm just installing TW on a new machine. Partition proposal is 2GB for swap, with 16GB RAM. Following that proposal hibernation should never work.

Wrong. It needs sufficient space to save the memory contents it can not recreate otherwise, i.e. not disk buffers, no mmaped libraries, ...

You can determine the amount with $> grep Active.anon /proc/meminfo Active(anon): 6533548 kB

This can grow up to physicalmem+swap.

Right. To always have the ability to hibernate, the system needs: a. dynamic enabling of a swap file of up to 50% RAM so that anonymouse pages can be evicted to swap, thus freeing 50% RAM for the hibernation image to be created b. either a dedicated hibernation file; or a dynamically enabling yet another swap file for the exclusive use of the hibernation image. Tricky. But could be triggered by systemd hibernation.target only at hibernate time, to enable the necessary swap files.

Note, you can also use a swap file to hibernate. The kernel also tries to compress the memory before writing it to disk by default.

Swap files are supported on Btrfs since kernel 5.0. However, there isn't a standard interface for determining the offset for the hibernation image's location in the swap file. https://lore.kernel.org/linux-btrfs/20200127192548.GA683123@vader/ Help wanted. But also work is needed to get a Secure Boot compatible hibernation implementation, or it's pretty much pointless. x86_64 hardware comes with Secure Boot enabled since ages ago. -- Chris Murphy -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org