-
Notifications
You must be signed in to change notification settings - Fork 119
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
DRBD extension not working on arm / rock64 #251
Comments
There isn't enough information in the ticket. Is the |
Since the directory isn't present on the host I assume it's not, but I don't know how else to check. Linstor definitely isn't finding the DRBD module in any case, so it's not just a path issue. It is the same (latest) version yes : image: ghcr.io/siderolabs/drbd:9.2.4-v1.5.4 As stated the exact same config on two other x86 nodes does work fine, the issue is only on the rock64 which is arm64. |
you have |
you can check yourself that the extension does contain the files, so the problem is somewhere probably on your end:
|
Alright, after a lot of digging I think I figured it out. The issue is the rock64 doesn't really have enough memory to schedule much, and certainly not the piraeus-operator. Even without that the upgrade command just silently kills the node unless I use --stage, I'm guessing because there's not enough memory to run the installer + the whole stack at the same time. Using --stage I did manage to get drbd installed correctly, but that doesn't leave enough ram to schedule the piraeus-operator (it brings the node up to 107% usage). Nevermind, I'll get rid of that node, thanks for your help |
Hi,
Apologies I don't really know how to debug this, but on my rock64 when using the DRBD extension I seem to be missing the drbd module :
The same config deployed on x86 machines does have that directory populated with the .ko files as expected.
I tried using the tag and also the specific arm hash from here, to be sure but no luck when "upgrading" to the same version to rebuild the initramfs.
I can't access the display for that node, not sure which service log might explain why this is failing ?
Thanks
The text was updated successfully, but these errors were encountered: