zap51 commented on issue #7829: URL: https://github.com/apache/cloudstack/issues/7829#issuecomment-1679000228
@saffronjam > **However**, for some hypervisors I was unable to check this since the command `df -Th | grep nfs` got stuck (gave me no output and forced me to CTRL + C), same with `ls /mnt`. This coincidentally correlates to which cluster node that either fails because of too many attempts to wait for /mnt/k8sdisk/ or just takes longer time to mount it (the node was se-flem-016 just for reference). Just like I expected. Sometimes it is hard to deal with NFS. > I tried to reboot the 016-hypervisor and I am now able to run `df -Th | grep nfs.` You should have done `# umount -l /mnt` instead of a reboot and checked the problem instead. > @weizhouapache This leaves me with a question though. If the binaries fails to attach for any reason, how do we "reset" that cluster node so it tries to attach the ISO again? Please check if you can try running `# systemctl start setup-kube-system && systemctl start deploy-kube-system`. The former should attempt to re-attach the ISO and the latter will proceed with the deployment. > Quick update: > I was able to reproduce the issue, and the failing node was run on a hypervisor that can't run the command df -Th | grep nfs as described above. I will try to find some logs here. Please inspect `# dmesg -T` or `rsyslog`. You'll find hints there. Thanks, Jayanth -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
