envycontrol
envycontrol copied to clipboard
bayasdev
Does not work on Silverblue
Hello,
As you may know, Fedora Silverblue has a read-only filesystem where only /etc and /var are writable directories. Unfortunately, since your Python script relies on putting udev rules in /lib which is read-only, a tiny modification is required to make this work: swapping every /lib (there are only two) in the script with /etc. As I'm not really familiar with scriping with Python, I don't know what would be the cleanest way to implement this without rendering this script unusable on other distros. I just wanted to make you aware of this current issue. For now, I will be modifying it locally for myself, until a solution is found.
Thank you for making Fedora usable for the unlucky Nvidia Optimus owners!
Hello there,
Thanks for letting me know.
Maybe we can try adding a flag called --silverblue or sth else that swaps
file paths starting /lib with /etc.
Greetings.
El jue, 30 de jun. de 2022 08:34, ActualDisaster2447 < @.***> escribió:
Hello, As you may know, Fedora Silverblue has a read-only filesystem where only /etc and /var are writable directories. Unfortunately, since your Python script relies on putting udev rules in /lib which is read-only, a tiny modification is required to make this work: swapping every /lib (there are only two) in the script with /etc. As I'm not really familiar with scriping with Python, I don't know what would be the cleanest way to implement this without rendering this script unusable on other distros. I just wanted to make you aware of this current issue. For now, I will be modifying it locally for myself, until a solution is found.
Thank you for making Fedora usable for the unlucky Nvidia Optimus owners!
— Reply to this email directly, view it on GitHub https://github.com/geminis3/envycontrol/issues/49, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALY7IYNYWXYXEAGPHI53ZH3VRWO65ANCNFSM52JMHQ3A . You are receiving this because you are subscribed to this thread.Message ID: @.***>
Thanks for responding so quickly! Yes, that would be awesome. The question is: Do you think that would change the behavior of the GNOME extension GPU profile selector? If so, then I would open an issue against that extension and see if the maintainer is open to adapt their code around this change.
The question is who would maintain it? Would it be submitted to the official Fedora repos? Even if not submitted to the Fedora repos, the RPM would require testing before getting published on GitHub. But all that aside: Would enough people benefit from this?
The reason why I am being so skeptical is because I don't have the expertise to do any of that/contribute and I don't want to waste dev time and QA on something that only I would benefit from.
You can put it on Copr. People can benefit from this as anyone running Fedora can just install the RPM on their system.
I don't like adding Coprs just like many other people don't. There is always this fear of them breaking updates. Also adding Coprs on Silverblue is not really that easy and a lot can go wrong. You basically have to copy a reference file (from Copr) into a directory and hope that rpm-ostree would pick the change up.
I would prefer an RPM from GitHub that I would manually install and update over Copr anyday.
That is understandable, just putting an RPM on Github releases works. I do not know packaging software very well (especially for RPM distributions), but it would be both convenient and helpful for rpm and rpm-ostree users.
From what I heard from others, there isn't much clear documentation for creating RPMs, but you can get help from others.
I also don't have experience with building and maintaining RPMs and I'm hesitant to ask for an RPM because of the lack of documentation.
https://www.redhat.com/sysadmin/create-rpm-package I found a decent source on how to.
I have also tried to replace /lib to /etc in the script and it does not work on Fedora Kinoite because /usr/share/sddm/scripts/Xsetup is read-only.
Update: Integrated and hybrid mode works. Only nvidia does not.
It seems that Silverblue is still not ready for the masses. I've been having a few other issues and contemplating switching back to Workstation because of this and other things.
I'm testing this fix on Fedora Silverblue and I can confirm that everything works. I think that it is broken with SDDM.
@sith-on-mars I don't have Silverblue (or any other ostree/inmutable distro) support planned
~~Note for people coming to this issue: You should be able to overlay the RPM package from the COPR build on Silverblue.~~
My bad, it looks like the script directly writes to /lib: https://github.com/bayasdev/envycontrol/blob/main/envycontrol.py#L202
This is not recommended, on any distributions, not just Silverblue. Custom local udev rules should be installed in /etc/... as /lib or /usr/lib is for distribution provided rules only.
I can confirm that simply cloning the repo and editing the python script to replace /lib/udev/ with /etc/udev/ in 2 places was enough to get this working for me running Fedora Silverblue 38 w/ Gnome Wayland
I forked it here if anyone wants to use it but you can easily edit the original script yourself as well.
I'll continue to add or update my version if people can commit some changes since I'm sure it can be improved for further compatibility. @bayasdev has indicated in the past that he has no plans to support immutable distros so hopefully this can help others somewhat.
@bayasdev , @ghost, others, I notice that arch wiki documents the /etc/udev location as:
udev rules written by the administrator go in /etc/udev/rules.d/, their file name has to end with .rules.
And /lib/udev (/lib is symlinked to /usr/lib on fedora ws 39) as:
The udev rules shipped with various packages are found in /usr/lib/udev/rules.d/
Also, ...
f there are two files by the same name under /usr/lib and /etc, the ones in /etc take precedence.
https://wiki.archlinux.org/title/Udev
So, if /etc/udev vs /usr/lib/udev is an intentional design choice, what is the harm in envycontrol switching to /etc/udev ? It seems lile the right thing to do in general. envycontrol is overriding shipped behavior - right?
If the user is not using systemd, then it seems a completely different approach might be needed anyway.
Just challenging the need for a -silverblue or -immutable flag as mentioned above in https://github.com/bayasdev/envycontrol/issues/49#issuecomment-1171441927
Thoughts?
Incidentally, I found a different approach for integrated mode that does not require messing with udev rules. See #157
