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:
GRUB_EARLY_INITRD_LINUX_CUSTOM="acpi_override"
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.
rpm-ostree kargs are for kernel arguments. Grub is handled differently with Silverblue.
fedora~$rpm-ostree kargs --help 04/25/22-07:33:13
Usage:
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.
@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.
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!