Enabling S3 Deep Sleep in SIlverblue

Hello everybody,

I recently received a new laptop, a 2022 Zephyrus G14, that I have installed Fedora Silverblue 35 on. There is an issue with it wherein S3 sleep is not enabled by default. I found this resource which (should) enable the functionality. I am trying to convert the instructions to the equivalent ones used in Silverblue with systemd-boot. I know in place of editing the GRUB_CMDLINE_LINUX_DEFAULT line in the grub file, I can just use rpm-ostree kargs --editor, but I am clueless on what to do about this line:


Where would I make the equivalent change in Silverblue?

Also, is my approach in fixing the S3 sleep correct so far, in general? Really appreciate any support on this one. Thanks a bunch.

I have been doing more research since this initial post. The script that I linked simply generates a file acpi_override and places it into /boot. I have determined that other systemd-boot systems can simply modify the files in /boot/loader/entries, so I tried adding initrd /acpi_override to the end of the file /boot/loader/entries/ostree-1-fedora.conf. When I shutdown and booted up, I made sure to hold shift to get into the boot menu, and select the entry with my modification. When I do this, rpm-ostree breaks, probably due to a bad config. What am I doing wrong exactly? I feel like I am on the right path. I am essentially following the instructions outlined on the ArchWiki here, but with no success.

In my continued research, I discovered rpm-ostree initramfs, which feels like it should be the thing I am using. I understand it’s using dracut under the hood, which seems like the next thing I’ll have to learn about on this journey.

Regarding GRUB_EARLY_INITRD_LINUX_CUSTOM="acpi_override" - I think you make the change in /etc/default/grub as usual (see last paragraph of this comment) and then grub-mkconfig ....

Also, maybe I am wrong, but I do not think that Fedora or Silverblue currently uses systemd-boot.

You cannot use that on Silverblue. It must be done through rpm-ostree due to the atomic host setup.

Hi @jakfrost

Could you please elaborate on how to update into grub kernel command parameters using rpm-ostree ?


rpm-ostree kargs are for kernel arguments. Grub is handled differently with Silverblue.

fedora~$rpm-ostree kargs --help                                                                                                                        04/25/22-07:33:13
  rpm-ostree kargs [OPTION…]

Query or modify kernel arguments

Help Options:
  -h, --help                        Show help options

Application Options:
  --os=OSNAME                       Operation on provided OSNAME
  --deploy-index=INDEX              Modify the kernel args from a specific deployment based on index. Index is in the form of a number (e.g. 0 means the first deployment in the list)
  --reboot                          Initiate a reboot after operation is complete
  --append=KEY=VALUE                Append kernel argument; useful with e.g. console= that can be used multiple times. empty value for an argument is allowed
  --replace=KEY=VALUE=NEWVALUE      Replace existing kernel argument, the user is also able to replace an argument with KEY=VALUE if only one value exist for that argument 
  --delete=KEY=VALUE                Delete a specific kernel argument key/val pair or an entire argument with a single key/value pair
  --append-if-missing=KEY=VALUE     Like --append, but does nothing if the key is already present
  --delete-if-present=KEY=VALUE     Like --delete, but does nothing if the key is already missing
  --unchanged-exit-77               If no kernel args changed, exit 77
  --import-proc-cmdline             Instead of modifying old kernel arguments, we modify args from current /proc/cmdline (the booted deployment)
  --editor                          Use an editor to modify the kernel arguments
  --sysroot=SYSROOT                 Use system root SYSROOT (default: /)
  --peer                            Force a peer-to-peer connection instead of using the system message bus
  --version                         Print version information and exit

I tried adding initrd=/acpi_override to my kargs after reading this on the ArchWiki. I also disabled Secure Boot, since it says options are not respected if it is enabled. Still, nothing I try is working here.

So if you are using systemd-boot, none of the instructions would apply here. Fedora has been using the BLS since F33 I think, so the comment from the bugzilla noted by @jmennius likely doesn’t apply here.
You may be right in thinking to use rpm-ostree initramfs to make the change with. You can try it and reboot to verify success, then disable the local initramfs regeneration after.

I realized I made a fatal mistake from step 1. I assumed Silverblue used systemd-boot by default. I must’ve read it somewhere and clung to that idea in my mind. Sorry for the misunderstanding. I followed the instructions for GRUB for that script and it almost works fine as is. However, I have one issue.

So I added GRUB_EARLY_INITRD_LINUX_CUSTOM="acpi_override" to the end of /etc/default/grub. Then I ran grub2-mkconfig -o /etc/grub2.cfg. When booting, and holding shift, I press e to see what the generated entry looks like. By default, it’s trying to load my acpi_override file from /boot/ostree/fedora-.../acpi_override instead of /boot/acpi_override. Now I could move the file from the /boot directory into the /boot/ostree/fedora-... directory, but it would get overwritten after every system update, no? How can I make that not happen?

I actually got it working now! What I did may be a bit naive, but I added GRUB_EARLY_INITRD_LINUX_CUSTOM="../../acpi_override" to the end of /etc/default/grub and it worked!

@jakfrost I was specifically referring to the last paragraph of a specific comment, I will cite it here:

On Rawhide though the default is to use a BLS configuration now (GRUB_ENABLE_BLSCFG=true in /etc/default/grub) and the BLS support honours GRUB_EARLY_INITRD_LINUX_CUSTOM. The grub2-mkconfig sets the early_initrd variable in grubenv with the value set in GRUB_EARLY_INITRD_LINUX_CUSTOM, and the blscfg module pre-pends early_initrd to the initrd field in the BLS snippet. So there’s no need to take any action after a kernel install on a BLS configuration to have all the kernel entries to pre-pend the early initrds.

Which is, indeed, correct…

@jmennius I am going to try to append GRUB_ENABLE_BLSCFG=true to my /etc/default/grub, run grub2-mkconfig -o /etc/grub2.cfg again, and see how this goes whenever I get my next system update with a new kernel. Thank you for directing me to this information.

Do you think I’d have to remove the "../../" from my GRUB_EARLY_INITRD_LINUX_CUSTOM="../../acpi_override" on my next kernel update? I’m not exactly sure of how the filepath is supposed to work.

Whoops, apparently that option is already included by default in Fedora SB 35!

Regarding the path, I believe this is inside the boot partition. So if on your system you have it on /boot/acpi_overrides then most likely you can use value /acpi_overrides in grub configuration.
I am not sure how relative path should work though… what it is relative to?

When using GRUB_EARLY_INITRD_LINUX_CUSTOM=“acpi_override”,it puts it in /boot/ostree/fedora-.../acpi_override.

I actually have the file in /boot/acpi_override, so to get around it, I did this instead: GRUB_EARLY_INITRD_LINUX_CUSTOM="../../acpi_override". This causes the path to evaluate to /boot/ostree/fedora-.../../../acpi_override, which is the same as /boot/acpi_override.

I was just curious if there was a way to not use this prefix of /boot/ostree/fedora... by default, since I am working around it with relative paths anyway.

Also, if you start the GRUB_EARLY_INITRD_LINUX_CUSTOM with a /, it interprets it literally, it doesn’t start at the root. So you’ll end up with something like /boot/ostree/fedora...//.

By a happy coincidence, I got an update today for the kernel, 5.16 to 5.17. After doing my rpm-ostree update and rebooting, I can say that my changes did in fact persist! I’d say this issue is solved for me now. Thanks to everyone who gave input on this conversation. I will be writing up some documentation that may make it’s way over to asus-linux.org at some point on this topic, and others. Really appreciate the support everyone!

I have compiled a Gist of all the work necessary setting up a 2022 Zephyrus G14 with working suspend, as well as a nice Fedora Silverblue configuration below.

Thanks to everyone here who helped me troubleshoot, and thanks to the fine people in the asus-linux.org Discord who helped out, as well!

1 Like