Arch Linux User Repository

Ah. I see. Thank you for the tip! Much appreciated!

Please not that if you use configuration like this:

CFLAGS="-march=native -mtune=generic -O3 -pipe -fno-plt -fexceptions \ -Wp,-D_FORTIFY_SOURCE=3 -Wformat -Werror=format-security \ -fstack-clash-protection -fcf-protection \ -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer"

-march=native - this flag, there is a bug or incompatibility in protobuf and the protobuf parser crashed

I must use this:

/etc/makepkg.conf

CFLAGS="-march=x86-64 -mtune=generic -O3 -pipe -fno-plt -fexceptions \ -Wp,-D_FORTIFY_SOURCE=3 -Wformat -Werror=format-security \ -fstack-clash-protection -fcf-protection \ -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer"

-march=x86-64 - during the building of the project

I did not tested this with latest version of protobuf but in previevs version the protobuf crashed.

After updating the kernel to 7.2.2, and after a clean recompile and reinstall, the service starts up without error, but when starting the application, it crashes. Running it from the command line gives the following error:

❯ /opt/LenovoLegion/LenovoLegion
WARNING: All log messages before absl::InitializeLog() is called are written to STDERR
F0000 00:00:1787931251.958263    2302 map.h:1429] Check failed: it != end() key not found: 255
*** Check failure stack trace: ***
fish: Job 1, '/opt/LenovoLegion/LenovoLegion' terminated by signal SIGABRT (Abort)

EDIT (2026-08-29): Please ignore the above. After upgrading protobuf today to 36.0, the application works fine using kernel 7.2.2.

Ah. MSR interface switched on the kernel? Thank you very much! I'll do a git pull and recompile later today as I upgrade back to kernel 7.2.0 (I restored a snapshot with kernel 7.1.8 yesterday to keep things functioning).

New version is available with Linux kernel 7.2.X support.

After upgrading to kernel 7.2.0, I did a clean recompile and reinstall. The compile works fine, but when the installer is running the dkms install, I get the following error:

(3/6) Install DKMS modules
==> dkms install --no-depmod lenovo-legion-linux-toolkit-release/1.3.2 -k 7.2.0-1-cachyos
Error! Bad return status for module build on kernel: 7.2.0-1-cachyos (x86_64)
Consult /var/lib/dkms/lenovo-legion-linux-toolkit-release/1.3.2/build/make.log for more information.
==> WARNING: `dkms install --no-depmod lenovo-legion-linux-toolkit-release/1.3.2 -k 7.2.0-1-cachyos' exited 10

Unfortunately, the log file mentioned above doesn't exist. There's no "build" directory in "/var/lib/dkms/lenovo-legion-linux-toolkit-release/1.3.2".

You have to recompile the apps if you update your arch linux. Somtimes this is not necessary but I would sugest to recompile it for sure. You have to remove from cache the old build and reinstall. The package is not automaticaly recompiled and you have to do that manualy.

After running arch-update today, a new version of abseil-ccp was installed, giving another dependency error for the lenovo-legion-daemon.service:

...error while loading shared libraries: libabsl_log_internal_check_op.so.2601.0.0...

Since it's a dependency issue, recompiling and installing from the git repository worked fine, so I got it working again. Just thought I'd let you know. :)

Hello, thank you for choosing this apps. The main problem is that you have to recompile apps. Just use new version of package. The version 1.3.2 include hot fix for kernel 7.0.x.

First, thank you for releasing this package. It's the only package I've found that works for my Lenovo Legion Pro 7 16IAX10H.

It worked fine until this morning when I ran a Cachy-Update. Now the lenovo-legion-daemon.service won't start.

When trying to execute /opt/LenovoLegion/LenovoLegion-Daemon manually, I get the following error:

/opt/LenovoLegion/LenovoLegion-Daemon: error while loading shared libraries: libprotobuf.so.34.1.0: cannot open shared object file: No such file or directory

Checking what was updated in the Cachy-Update, I indeed find that the package protobuf was updated to version 35.0.

EDIT: Un-installing and re-installing the package gives the same error, but building the package manually from the git repository works fine.