Open Bonn93 opened 1 month ago
A workaround is removing noexec
of /var
. Have you tried it?
Longhorn can use and seems to create some data/folders under a desired path such as /data howver the engine-image-ei pods still appear to use /var/lib/longhorn
I wasn't sure how this was working, so I did a quick check. /var/lib/longhorn
is hardcoded as EngineBinaryDirectoryOnHost
in longhorn-manager. Longhorn-manager DOES use this directory to execute commands directly, and the path is also used to populate the specs of other components:
Currently, there is no way for Longhorn to avoid using /var/lib/longhorn
.
Dropping noexec from the mount does indeed work, but quite a hard conversation in a secured environment with CIS and STIG baselines in place. It's something I can work with, but I think getting a method to use a different dir would be ideal.
I see. We need to improve it. IIRC, we've seen the issues from the feedback several times. cc @innobead
Describe the bug
Installing 1.6.2 of longhorn on a k3s cluster fails with
engine-image-ei
pods inCrashLoopBackoff
. The cause appears to be that/var/lib/longhorn
is always used by this pod. The underlaying hosts have CIS L1 hardening items applied, and that /var/lib has thenoexec
option on the mount.Trying to modify the installation by using the
default-data-dir
and also editing any mounts to/var/lib
does not help. Longhorn can use and seems to create some data/folders under a desired path such as/data
howver theengine-image-ei
pods still appear to use/var/lib/longhorn
To Reproduce
noexec
Longhorn manager reports:
Expected behavior
Longhorn system is installed and stable. engine-image-ei pods are no the crash loop state.
Support bundle for troubleshooting
UI is not currently deployed or accessible, but working on this.
Environment
Additional context
I have tried using the YAML and setting so vars:
And also trying the change the mounts on