Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

alpine linux not supported #67

Open
aSauerwein opened this issue Oct 26, 2023 · 3 comments
Open

alpine linux not supported #67

aSauerwein opened this issue Oct 26, 2023 · 3 comments

Comments

@aSauerwein
Copy link

Hi,

i tried this provider and could it be that alpine linux is not supported ?
the LUNs are created and mounted via iSCSI. So that's fine.
But when I try to use this pvc in a pod it is stuck in pending
reason

  Warning  FailedMount             6m10s (x20 over 37m)  kubelet                  MountVolume.MountDevice failed for volume "pvc-0b37a8dc-16fb-4b92-a8a6-4c45d66e3363" : rpc error: code = Internal desc = rpc error: code = Internal desc = Can't find device path [/dev/disk/by-path/ip-192.168.10.200:3260-iscsi-iqn.2000-01.com.synology:media1.pvc-0b37a8dc-16fb-4b92-a8a6-4c45d66e3363-lun-1]: file does not exist

from what I see is that the csi plugin tries to access the disk by /dev/disk/by-path which is created by udev and there is no systemd/udev in alpine linux.

is that true ? could we update the docs somewhere that systemd/udev is mandatory ?

@iamasmith
Copy link

Are you saying you are using Alpine for a node OS? Probably best to say a bit more about the config.

@aSauerwein
Copy link
Author

that's correct.
I have a 2 node k3s deployment
control plane and worker node on an alpinel inux
worker node on an rocky linux

the synology-csi is working fine on rocky linux but fails on the alpine node.

I think the reason for that is, that to mount the iSCSI disk the CSI is using /dev/disk/by-path but on alpine there is no such path

@iamasmith
Copy link

iamasmith commented Aug 11, 2024

Yes, I see what you mean, they get the iscsi sessions back using 'iscsiadm -m session' and use that in a format string based off that to determine the actual device ID of the connected disk.

Yes, it does look to be dependent on udev or some kind of mapper that will set these up and probably should be release noted.

It's also not particularly prominently mentioned that you need to install iscsiadm even either!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants