Closed PilotGuy772 closed 4 weeks ago
@bayasdev I added logic to cleanup() in my latest commit to address your concerns. I just have statements to check for EnvyControl's udev rules in /lib/udev/rules.d
and remove them if they exist.
@PilotGuy772 please take a look at the comments I left, and thank you for adding OSTree support to EnvyControl as it was a frequently requested feature 🙌🏼
@bayasdev All done (I think)
Thanks @PilotGuy772
Fixes https://github.com/bayasdev/envycontrol/issues/180 Fixes https://github.com/bayasdev/envycontrol/issues/114 Fixes https://github.com/bayasdev/envycontrol/issues/49
EnvyControl is configured right now to put udev rules in
/lib/udev
. The problem with this is that/lib/udev
is distinctly intended for udev rules from the distribution. It is NOT meant to be manipulated so heavily. Instead, system admins ought to use/etc/udev
to put custom rules.This ordinarily isn't a problem for EnvyControl because most distros don't care if you modify
/lib/
, but immutable distros like Fedora Silverblue do care./lib/
is not writable, but/etc/
is. There's a reason for that.This PR changes the udev directory to
/etc/udev/
, but everything still works as expected with this change. I also added logic to check if the distribution uses ostree by checking for/ostree
and/sysroot/ostree
, which are the two places where you would usually find the ostree directory. My amateur testing on Bluefin has shown that switching between integrated and hybrid modes works perfectly.