This message was deleted.
# elemental
a
This message was deleted.
c
I assume you're on Rancher 2.7.0 stable version of the elemental operator from
Copy code
<oci://registry.opensuse.org/isv/rancher/elemental/stable/charts/rancher/elemental-operator-chart>
and it's all LAN ? rpis to Rancher
s
Rancher 2.7.0 - yes Elemental Operator - I was on the stable (1.0.2 I think is what the chart pulled) but I upgraded to 1.1.0 to try as well.
No, it is not all LAN. Pi is on home network connecting to Rancher in AWS (but same configuration worked for VirtualBox VM).
There shouldn't be any firewall or VPNs in the mix.
c
ok, that's a possible scenario but yeah it opens questions about networking / filtering
and you're kubernetes version Rancher is running on ?
https://github.com/rancher/elemental-operator/issues/176 points to isses with Secrets for the ServiceAccount
s
It's v1.21.12+rke2r2 (needs updated)
c
"*The issue is in the operator when using kubernetes 1.24*."
we generally use in dev / test the latest versions, so it might be that the operator needs a more recent version
although I understand @many-tiger-3407 provided a fix
s
I can try deploying latest from main branch of elemental-operator
Right - the first issue said the second link was a fix.
c
I'm not saying it's the issue, just trying to guess here
s
And that should have been in both 1.0.2 and 1.1.0
I think
I can try deploying latest dev/main.
c
if it's not too much a hassle, you can give a try, that will help narrow down the possibilities
s
If that doesn't work I could also try standing up a local Rancher MCM instance to rule out some networking funniness.
c
but, in general, Elemental being fairly recent, we mostly worked and tested with k8s > 1.24
s
Gotcha
One thing I did have to do that is non-standard...
The elemental-operator runs as a privileged container.
c
but the issues at first sight look network related
1
s
We have PSP on cluster that prevents this.
I attached a PSP that allows this to the elemental-operator to allow the pod to startup. But there is no option in the Helm chart for this.
Was thinking of writing a GitHub issue to request.
And/or the new 1.25+ approach
c
I think it's worth a GitHub issue, it soes not look like you're missing something obvious
1
s
Thanks for your feed back! I'll poke around some more and update here.
👍 1
Attempted both fixes: 1. elemental-operator - upgraded to latest of main and latest container image 2. Installed local Rancher 2.7.0 (docker install/v1.24.4+k3s1), redeployed cluster Yaml files to local Rancher 3. Updated USB registration Yaml and rebooted Raspberry Pi
Same results
I believe it's an error in marshaling/unmarshaling the system data.
c
ok, I'm currently in the process of installing on USFF format x86 systems, but when I'm done, I'll switch back to RPi
I'll try with an AWS cluster actually
1
s
Thanks! Here's the info of the downloaded rpi.raw ISO I used to make the bootable USB
Copy code
md5sum rpi.raw
a6181a673b70691dfc19a09dfd8c5a68  rpi.raw
@careful-piano-35019 did you have a chance to try the RPi again?
c
not yet, sorry. Possibly Friday
s
No problem. Thanks again for the help.
@careful-piano-35019 this problem wasn't just a Raspberry Pi problem it would seem. After the changes mentioned in this thread I was able to resolve the issues for both Raspberry Pi and VirtualBox nodes correctly https://rancher-users.slack.com/archives/C028DVCAYLD/p1673458165577919
👍 1
c
All good now ?
s
Yes, I was able to register my Pi 4 with Rancher!
One quick follow-up question if you don't mind. I did have to do this with a Rancher Server I have deployed in AWS and have a valid public CA because the rancher-agent did not like the self signed certificate.
Am I missing something? Is there an easy way to test with a local Rancher Server (docker deploy or Rancher Desktop k3s cluster) and maybe using sslip.io for the URL that will work instead of needing a public CA?
c
Yes I've done it with a local cluster without a public CA