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.
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
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.
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
-h, --help Show help 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
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
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
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
By a happy coincidence, I got an update today for the kernel,
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!