Back to collectionNode support separates restarting from upgrading
A member reported that a node had stopped and asked how to update and restart it, later specifying that it ran on a VPS. An ambassador first pointed to the restart procedure. When the member said the Linux client appeared to ask for staking rather than an update, the ambassador clarified that restarting and upgrading used different instructions. The conversation documents a support distinction, not a confirmed automatic-update or wallet-login defect.
A member reported that a node had stopped and asked how to update and restart it, later specifying that it ran on a VPS. An ambassador first pointed to the restart procedure. When the member said the Linux client appeared to ask for staking rather than an update, the ambassador clarified that restarting and upgrading used different instructions. The conversation documents a support distinction, not a confirmed automatic-update or wallet-login defect.
The member pasted a CLI startup banner showing version 1.1.14. That confirms what the shared text displayed, not that the node was successfully submitting work. Later, the member asked whether the setup was ready, and a directly linked participant reply said it was. A separate continuation said it appeared to be working, but its displayed author was absent. These are support responses and an apparent-recovery report, not an independently measured uptime result.
The operational lesson is to distinguish a downloaded release, a running client interface and a functioning operator. The exchange does not establish a network-wide outage, exact downtime, lost rewards or a completed repair verified by telemetry. The former daily-report number and implied firsthand institutional participation have been removed because this support record does not establish them.