Unable to update to StartOS 0.4 – Filesystem I/O Error during download size calculation

StartOS Support
1

Hi!

I’m unable to upgrade my StartOS installation from 0.3.5 (Git Hash 39de098461833e4c56bd3509644ddf7f1a0fc4ca) to version 0.4. When I start the update, it stays on “Calculating download size” for a long time (around 15 minutes), then fails with the following error:

StartOS Update Failed

Update was not successful because of Filesystem I/O Error:

rsync error: 30 [Receiver] io timeout after 900 seconds -- exiting
rsync error: timeout in data send/receive (code 30) at io.c(200) [Receiver=3.2.7]

Some additional information:

  • I’m updating from the StartOS UI.

  • Regular service/package updates work without any issues.

  • The problem only occurs when trying to update the operating system itself to version 0.4.

  • The error consistently occurs after the “Calculating download size” stage.

Has anyone encountered this issue before or knows what could cause it? I’m happy to provide logs or run any diagnostic commands if needed. If there’s a debug mode or a command to capture the update logs, I’m happy to run it and provide the output. The failure is fully reproducible.

Thanks!

2

I narrowed the issue down:

  • The update launches:

  • The TCP connection to registry.start9.com:873 is successfully established.

  • rsync rsync://registry.start9.com/ works.

  • rsync --list-only rsync://registry.start9.com/0.4.0.1/x86_64/ also works.

  • However, any recursive rsync (even --dry-run into an empty directory) hangs at:

  • The same command works immediately over VPN. Without VPN it hangs both on StartOS and on a macOS machine on the same network.

This suggests the issue is related to connectivity to the rsync service on registry.start9.com:873 (possibly ISP/DPI filtering or routing), rather than the local filesystem. Is there an alternative registry, port, transport, or a way to perform the OS upgrade over HTTPS instead of native rsync?

3

If for some reason your ISP is having trouble or the connection is dropping, waiting is the best option.

In case you dont want to wait and want to use the more reliable update option, you can flash StartOS 0401 onto a USB thumbdrive.

Here are detailed instructions that are highly recommended you follow closely:

4

Thanks for the suggestion.

I don’t think this is a temporary ISP issue. I was able to narrow it down further.

The exact same recursive rsync operation hangs not only on StartOS, but also on a macOS machine on the same network. As soon as I route the traffic through a VPN, it works immediately.

This strongly suggests the problem is caused by network filtering or traffic restrictions rather than a transient connectivity issue. Unfortunately, this is a common situation in my country and is unlikely to resolve by simply waiting. It may affect many users here, not just me.

It might be worth considering an alternative transport for OS updates (for example HTTPS, a mirror, or another fallback mechanism) instead of relying solely on native rsync over TCP/873. That would make the update process much more resilient to ISP or network-level filtering.

Also, I noticed a small issue in the documentation. In the USB installation guide, under “1. Visit the Github release page to find the latest version of StartOS.”, the “Github release page” link currently returns 404.

For now I’ll use the USB installation method, but I think this is worth addressing as a robustness issue rather than treating it as an isolated ISP outage.