https://rancher.com/ logo
Join Slack
Powered by
This message was deleted.
# elemental
a
This message was deleted.
f
The troubleshooting doc may be helpful: https://elemental.docs.rancher.com/troubleshooting-upgrade In particular I would inspect the jobs and the 
apply-os-upgrader-*
pods in the downstream cluster
q
hmm is IMAGE_TAG the var which needs to be higher then the current one? not VERSION?
f
If you are referring to the 
suc-upgrade
script logic, yes this is the logic that determines whether an image is higher version: https://github.com/rancher/elemental/blob/main/framework/files/usr/sbin/suc-upgrade#L25 However if lower or equal then I would not expect the node to keep being cordoned, the actual upgrade should just be skipped and the job should complete successfully
q
then it makes sense. it was "latest" on both versions as i was playing around with custom images. will build new images now with correct image_tag values. thx
after filling out image_tag with 0.1 and then another upgrade with 0.2 it worked. i wished the ui would give some feedback. also i found today upgradeContainer: envs: - name: FORCE value: "true" so this would also allow a lower or the same version i guess?
f
yes indeed, FORCE is used for downgrades, somehow, if you are not able to simply boot from the previous snapshot
there is a long standing issue about showing upgrade statuses, if you'd like to provide feedback: https://github.com/rancher/elemental-operator/issues/433 currently the only way to verify it is to check the upgrade plan on the downstream clusters: https://elemental.docs.rancher.com/upgrade-lifecycle#verifying-successful-upgrades
Elemental relies on the system-upgrade-controller to run OS upgrades: https://github.com/rancher/system-upgrade-controller
Open in Slack
PreviousNext
Powered by