The StartOS registries are just multi-MB JSON files. They just need to be downloaded to be displayed. There’s certainly an unusual number of networks and devices that sporadically cause people have intermittent trouble reaching what is just a file on a website. I don’t know what it might be that would set off a firewall or whatever.
You mention a third registry, BIP-110, which is not a Start9 Registry.
I have done some additional testing, which may help narrow down the problem.
Current observations:
Internet connectivity is working (DNS resolution and outbound connectivity are OK).
SSH access works reliably.
startd.service is running normally.
systemctl --failed reports no failed services.
The Bitcoin node is running normally.
However, the problem is not limited to the registries.
I also receive Gateway Timeout / Timed out when trying to open the configuration pages of installed services (for example Bitcoin and Vaultwarden). The services themselves continue running, but their configuration pages never load.
This makes me wonder whether the issue is related to the communication between the web UI and startd rather than to registry downloads alone.
If this is a known issue in 0.3.5~1 that has already been fixed in a later release, I would appreciate knowing that before I spend more time debugging
Are there any startd-specific logs or diagnostic commands you would recommend before attempting an upgrade?
If there is a bug in an almost two year old version of StartOS, you’re the first to ever come across it. There are no later releases of that branch of the OS.
StartOS has since undergone a complete rewrite and v040 has been out for a few months now, you’re welcome to use it, either by upgrading or flashing anew.
Not really, that’s just the browser saying to can’t find the server, putting you back at square one. Is something blocking your client? is the server turned off or disconnected?
We’d have to know… recovery from what? We’d need to set up rolling system/kernel logs from before an instance of this issue, until it happens, then hope its logged. That’s of course, assuming there’s anything to log and anything wrong with the server. The most likely scenario is that there’s a missing driver that causes some sort of crash. Either way, if you legitimately discover a bug in an older version of StartOS, we’d only suggest you upgrade to the latest OS. I don’t see too much benefit of continuing down this path.
From the web browser loaded in kiosk mode? I’m afraid not.
I agree that upgrading to 0.4 is probably the long-term solution.
However, I am currently unable to upgrade because I no longer have a working Web UI or SSH access.
One point still confuses me.
The browser is clearly able to reach the server because:
curl https://localhost returns the StartOS HTML page.
The JavaScript bundle is returned successfully (HTTP 200).
Only the WebAssembly module returns:
GET /d8e64677bc0d492d.module.wasm
504 Gateway Timeout
Shortly afterwards, the graphical StartOS session became black, SSH stopped responding, while Debian itself continued running (tty2 login still works).
This makes me think the browser is not simply failing to reach the server. It seems that some internal StartOS component is no longer responding.
At this point my main problem is not fixing 0.3.5, but simply regaining enough access to perform the upgrade.
Would you recommend any recovery procedure to restore either the Web UI or SSH without reinstalling?
I wanted to post a short follow-up in case it helps someone else.
The network issue was resolved after switching to a wired Ethernet connection.
Using verbose SSH output confirmed that the server accepted my key, showing that the SSH server and key configuration were correct.
The remaining issue turned out to be local: the passphrase was not being entered correctly. Once it was entered manually, the SSH connection worked immediately.
Looking back, we made one mistake during the troubleshooting process. We focused too early on more complex possibilities instead of first verifying the obvious basics. In retrospect, establishing a wired Ethernet connection should have been one of the very first diagnostic steps.
If you have recently changed router settings or Wi-Fi credentials, I would recommend temporarily using an Ethernet connection while troubleshooting. Changes to network configuration can sometimes have unexpected side effects, as they did in our case, and can easily lead you in the wrong direction.
This simple step would likely have saved us a considerable amount of time.
Everything is now working correctly:
StartOS Web UI
SSH access
Linux shell
Network connectivity
Thanks again to everyone who contributed. Your suggestions helped us work through the problem systematically.