Hide Forgot
Description of problem: On my Optimus laptop, on a fresh boot, the switcheroo-control service does not start correctly and shows this status: systemctl status switcheroo-control.service ● switcheroo-control.service - Switcheroo Control Proxy service Loaded: loaded (/usr/lib/systemd/system/switcheroo-control.service; disabled; vendor preset: enabled) Active: inactive (dead) Restarting it manually with systemctl restart switcheroo-control.service makes it work fine until the next reboot. Version-Release number of selected component (if applicable): switcheroo-control-1.1-2.fc26 Additional information: I'm not using nvidia proprietary driver. 00:02.0 VGA compatible controller: Intel Corporation 4th Gen Core Processor Integrated Graphics Controller (rev 06) 01:00.0 3D controller: NVIDIA Corporation GK208M [GeForce GT 740M] (rev a1)
Created attachment 1383341 [details] systemctl status switcheroo-control.service
Have the same issue. Restarting manually won't work. sudo cat /sys/kernel/debug/vgaswitcheroo/switch throws 'Operation not permitted.' Version: switcheroo-control.x86_64 1.1-4.fc27 xorg-x11-drv-nouveau.x86_64 1:1.0.15-3.fc27 xorg-x11-drv-intel.x86_64 2.99.917-31.20171025.fc27
SELinux warnings?
(In reply to Bastien Nocera from comment #3) > SELinux warnings? Selinux is enforced, no warnings. Service is able to start after disabling Secure Boot in bios.
I'm going to say this is a kernel problem then.
As it stands, this is working as expected. When secureboot is on, debugfs is locked down. Per the patch, "Normal device interaction should be done through configfs or a miscdev, not debugfs." I think something needs to be done for vgaswitcheroo for secureboot.
*** Bug 1543427 has been marked as a duplicate of this bug. ***
This makes the option "Launch using Dedicated Graphics Card" in Gnome's right click menu disappear. So, to make use of the dGPU, I can only launch apps from terminal with the prefix, DRI_PRIME=1. I'm on 4.15.4-300.fc27.x86_64.
Can confirm this. The service doesn't run on boot and restarting it produces the exact same error. Running Fedora 27 up to date with 4.15.10-300.fc27.x86_64 and secure boot and hybrid graphics (intel + nvidia).
This message is a reminder that Fedora 26 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '26'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 26 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This affects Fedora 27 too. Please update the ticket.
Can confirm that witcheroo-control service does not start correctly, but as soon as I disable secure boot it works fine and brings the menu entry "Launch using Dedicated Graphics Card" on Gnome back.
Correct, but that's just a workaround right ?
Yup, I can confirm it affects 28 too.
(In reply to Laura Abbott from comment #6) > As it stands, this is working as expected. When secureboot is on, debugfs is > locked down. Per the patch, "Normal device interaction should be done > through configfs or a miscdev, not debugfs." I think something needs to be > done for vgaswitcheroo for secureboot. So this should be re-assigned back to switcheroo then?
not quite. It should probably be tracked under the kernel for now since it's secure boot related. Really if we're going to have a service relying on this it shouldn't be in debugfs anyway.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There are a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 28 kernel bugs. Fedora 28 has now been rebased to 4.17.7-200.fc28. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those.
The problem is still persisten with the newer kernel (4.17.7-200.fc28.x86_64).
This also happens on a Zenbook UX510UX with GeForce 950M. In dmesg, there is this output: [ 5.411221] Lockdown: switcheroo-cont: debugfs is restricted; see man kernel_lockdown.7 As mentioned before, disabling secure boot fixes this. Understandably, since enabling secure boot enforces kernel lockdown mode and thus debugfs restrictions. Switcheroo-control seems to query a specific path to check the switcheroo status: https://github.com/hadess/switcheroo-control/blob/master/src/switcheroo-control.c#L26 "/sys/kernel/debug/vgaswitcheroo/switch" Kernel lockdown mode seems to completely prohibit the use of debugfs so perhaps we need something to change in switcheroo itself, to have its status available via /proc maybe.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There are a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 28 kernel bugs. Fedora 28 has now been rebased to 4.20.5-100.fc28. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 29, and are still experiencing this issue, please change the version to Fedora 29. If you experience different issues, please open a new bug report for those.
Problem still reproducible on Fedora 29. With disabled secure boot everything is fine. Kernel version: 4.20.4-200.fc29.x86_64
Same here with Fedora 29 and kernel 4.20.7-200.fc29.x86_64. When secure boot is disabled everything works fine.
Hello, In case it can help, I can confirm the same issue on Fedora 30, with secure boot. It is a clean install (installed from the live CD, not through dnf). All packages were updated, and the system rebooted prior to the tests. Secure Boot is enabled. Restarting switcheroo-control doesn't work. Some details / additional information: # systemctl start switcheroo-control switcheroo-cont[801]: switcheroo-control could not query vga_switcheroo status: Operation not permitted systemd[1]: switcheroo-control.service: Main process exited, code=exited, status=1/FAILURE systemd[1]: switcheroo-control.service: Failed with result 'exit-code'. systemd[1]: Failed to start Switcheroo Control Proxy service. The switcheroo file is not readable by root: # cat /sys/kernel/debug/vgaswitcheroo/switch cat: /sys/kernel/debug/vgaswitcheroo/switch: Operation not permitted Kernel lockdown is visible in dmesg: Lockdown: switcheroo-cont: debugfs is restricted; see man kernel_lockdown.7 Installed packages: switcheroo-control.x86_64 1.1-7.fc30 xorg-x11-drv-intel.x86_64 2.99.917-41.20180618.fc30 xorg-x11-drv-nouveau.x86_64 1:1.0.15-7.fc30
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There are a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 30 kernel bugs. Fedora 30 has now been rebased to 5.2.9-200.fc30. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 31, and are still experiencing this issue, please change the version to Fedora 31. If you experience different issues, please open a new bug report for those.
This was worked around in this switcheroo-control update: https://bodhi.fedoraproject.org/updates/FEDORA-2019-dd1633d7cb