mirror of
https://github.com/hirschmann/nbfc.git
synced 2026-04-25 16:45:53 +03:00
[GH-ISSUE #472] "Could not acquire EC lock" on Ubuntu 18.04 LTS #426
Labels
No labels
Stale
bug
config
discussion
duplicate
enhancement
experimental
feature
help-wanted
info
invalid
invalid
pull-request
question
up-for-grabs
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/nbfc-hirschmann#426
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @linkwh on GitHub (Apr 30, 2018).
Original GitHub issue: https://github.com/hirschmann/nbfc/issues/472
After having built and installed the software (1.5.2 and 1.5.3 beta) as explained on this website :
NBFC ran just fine on the same computer with Ubuntu 17.10.
Step 1 : start the service & check that the service is running
$ sudo systemctl start nbfc
$ sudo systemctl status nbfc
● nbfc.service - NoteBook FanControl service
Loaded: loaded (/etc/systemd/system/nbfc.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2018-04-30 16:35:48 CEST; 11min ago
Step 2 : read only mode works
$ nbfc.exe start -r
$ nbfc.exe status
Service enabled : True
Read-only : True
Selected config name : Asus Zenbook UX310UA
Temperature : 34
Fan display name : Fan #1
Auto control enabled : True
Critical mode enabled : False
Current fan speed : 0.00
Target fan speed : 0.00
Fan speed steps : 8
Step 3 : enabled mode does not work
$ nbfc.exe start -e
EC initialization failed: Could not acquire EC lock
$ nbfc.exe config -a "Asus Zenbook UX310UA"
EC initialization failed: Could not acquire EC lock
Additional info
mono-complete 4.6.2.7+dfsg-1ubuntu1 amd64
Linux 4.15.0-20-generic #21-Ubuntu SMP Tue Apr 24 06:16:15 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
@MonteyMontey commented on GitHub (Apr 30, 2018):
same issue for me
@Gele-CZ commented on GitHub (May 1, 2018):
Same problem as describes @linkwh (and @MonteyMontey). Tested on Ubuntu 16.04, 16.10 and 17.10 (everything OK), 18.04 not working with
EC initialization failed: Could not acquire EC lock.@stefanocirici commented on GitHub (May 4, 2018):
Same issue on 18.04 with UX430UQ.
From issue #414 seems to be a BIOS secure boot problem. However I cannot confirm it for Ubuntu (yet).
EDIT:
Just disabled Secure Boot and nbfc seems working. Wondering if it can be run with secure boot enabled...
@Gele-CZ commented on GitHub (May 5, 2018):
@stefanocirici: 👍
Disabled Secure Boot is already functional on my NTB (UX430UA).
@linkwh commented on GitHub (May 5, 2018):
Mine is an Asus computer (UX410UA), juste like @stefanocirici and @Gele-CZ
Could the problem be Asus-specific?
NBFC ran juste fine on Ubuntu 17.10 with secure boot enabled.
@linkwh commented on GitHub (May 5, 2018):
In can confirm that it runs fine on Ubuntu 18.04 without Secure Boot disabled.
Any idea on how to make it work with Secure Boot enabled?
@stefanocirici commented on GitHub (May 7, 2018):
@hirschmann could you please take a look at our problem? I would like to keep secure boot enabled.
@hirschmann commented on GitHub (May 10, 2018):
I don't have much spare time right now, but I'll try to reproduce this issue on the weekend.
In the meantime, you could try to stop the service, then delete
nbfc/Plugins/StagWare.Plugins.ECSysLinux.dlland restart the service.@stefanocirici commented on GitHub (May 10, 2018):
I've deleted the file and enabled Secure boot. On restart:
Without the
nbfc/Plugins/StagWare.Plugins.ECSysLinux.dllfile nbfc wont't start even in read only mode.This is my journal (only errors are shown):
@hirschmann commented on GitHub (May 10, 2018):
Thanks for your fast response 👍
The problem is caused by these "kernel lockdown" patches:
https://lkml.org/lkml/2017/4/5/652
In particular:
The ECLinux plugin uses
/dev/port/to access the EC :(The ECSysLinux plugin uses
/sys/kernel/debug/ec/ec0/io(debugfs) to access the EC :(Actually the ECSysLinux plugin can only be initialized because it only checks if the ec_sys kernel module can be loaded with write support enabled, but it should also check if it's actually possible to access the EC (this is a bug - I will fix it).
The good news:
There is a workaround, see #414 (@stefanocirici already posted this)
You don't have to completely disable secure boot. It's enough to "just" lift the kernel lockdown, see:
https://github.com/hirschmann/nbfc/issues/414#issuecomment-354274657
and
https://github.com/hirschmann/nbfc/issues/414#issuecomment-370253669
The bad news:
Currently, I don't know how to access the EC from user mode without lifting the kernel lockdown.
If someone has an idea, please let me know :)
@GitEscape commented on GitHub (Aug 9, 2018):
I'm new to Mint 19 and can't get the #414 script from @jgoclawski to work?
mandree's method works for me (kernel.sysrq=16), but I'm unsure if my lift_kernel_lockdown.service is booting properly, and none of the boot managers I've searched for seem to be available for M19 at the minute. I'm fresh to Linux from Windows, so I don't even know if the syntax in the two files is correct for Mint?
Another thought is that they might be plaintext files, although I C&Ped a genuine .sh to try and avoid that. It's not as easy to me as just creating a .bat and throwing it into Startup. Help appreciated!
[edit]
Oh, and NBFC is loaded and enabled at boot, as per systemctl status and is-enabled.
@GitEscape commented on GitHub (Aug 10, 2018):
BUT... lift_kernel_lockdown wasn't recognised with systemctl is-enabled, so I copied NBFC.service to another directory, filled it with the script and renamed it, and then made sure it was executable via Permissions before moving it back. And that's done it!
Good work @jgoclawski
@github-actions[bot] commented on GitHub (Nov 30, 2019):
This issue is stale because it has been open more than 180 days with no activity. If nobody comments within 7 days, this issue will be closed
@Demetrio92 commented on GitHub (Mar 14, 2021):
For me, disabling secure boot worked.
@rijnhard commented on GitHub (Apr 6, 2021):
have you tried adding the following kernel flag?
ec_sys.write_support=1