Skip to content

umbrelOS generates NetworkManager config in /run/ (tmpfs) — all network changes lost on reboot + OTA upgrade wipes manually installed packages #2125

@0d3bfd43ca84

Description

@0d3bfd43ca84

Environment

umbrelOS: upgraded from v1.5 to v1.7
Hardware: x86
Network: DHCP-free VLAN, dedicated Bitcoin segment, static IPs intended via nmtui

Root cause — NetworkManager config generated in /run/ (tmpfs)

umbrelOS generates NetworkManager connection profiles dynamically at boot, writing them to /run/NetworkManager/system-connections/ instead of the standard persistent path /etc/NetworkManager/system-connections/.
/run/ is a tmpfs — wiped on every reboot. Any network configuration change made via nmtui or nmcli is lost on the next boot, regardless of whether an OTA upgrade occurs.
Confirmed:

find /etc/NetworkManager -type f
/etc/NetworkManager/conf.d/10-cloudflaredns.conf
/etc/NetworkManager/NetworkManager.conf

Only NetworkManager.conf and conf.d/ — no connection profiles

find /run/NetworkManager -type f
/run/NetworkManager/resolv.conf
/run/NetworkManager/no-stub-resolv.conf
/run/NetworkManager/system-connections/br-8c7580c4e1f9.nmconnection
/run/NetworkManager/system-connections/docker0.nmconnection
/run/NetworkManager/system-connections/Wired connection 1.nmconnection
/run/NetworkManager/system-connections/lo.nmconnection
/run/NetworkManager/devices/4
/run/NetworkManager/devices/3
/run/NetworkManager/devices/2
/run/NetworkManager/devices/1

All connection profiles stored here — volatile storage

cat "/run/NetworkManager/system-connections/Wired connection 1.nmconnection" | grep -A3 ipv6
[ipv6]
addr-gen-mode=default
method=auto

Disabling IPv6 via nmtui, rebooting, and rechecking confirms IPv6 is re-enabled — the change was written to /run/ and lost on reboot.
This is the root cause of Issues 1 and 2 below, and renders nmtui functionally decorative in umbrelOS.

Issue 1 — Static IP configuration does not persist

Static IP configured via nmtui on v1.5 survived normal restarts at the time, but after the OTA upgrade the system reverted to DHCP with no warning. On a DHCP-free VLAN this caused total loss of network access with no console feedback about upgrade completion status.
Now confirmed as a consequence of the root cause above: connection profiles are regenerated from a boot-time template on every restart, silently overwriting any user configuration.
Expected: either persist connection profiles to /etc/NetworkManager/system-connections/ and respect them across boots, or expose first-class UI controls for static IP that write to a persistent layer. At minimum, warn before upgrade if network config will be reset.

Issue 2 — IPv6 cannot be disabled persistently

Disabling IPv6 via nmtui does not survive a reboot. The generated profile always contains method=auto, re-enabling IPv6 regardless of user configuration.
Same root cause as Issue 1.

Issue 3 — OTA upgrade removes manually installed packages

Prior to the upgrade, chrony was installed and configured with NTS:
server time.cloudflare.com iburst nts
Verified working pre-upgrade with chronyc authdata showing authenticated NTS sessions.
After the OTA upgrade, chrony was gone — replaced by the default systemd-timesyncd, which does not support NTS. Manual reinstallation post-upgrade restored NTS functionality:

Name/IP address         Mode KeyID Type KLen Last Atmp NAK Cook CLen
time.cloudflare.com      NTS     1   30  128   13    0    0    8   64

The A/B partition model replaces the OS layer on upgrade, silently removing manually installed packages without warning.
For a Bitcoin node, NTS is a meaningful security requirement — plain NTP is vulnerable to on-path clock manipulation, directly affecting block validation, Median Time Past consensus, Lightning Network timelocks, and P2P privacy fingerprinting.
Expected: preserve manually installed packages across OTA upgrades, or provide a documented persistence mechanism. At minimum, warn before upgrade if installed packages will be removed. Consider shipping chrony with NTS enabled by default for Bitcoin node deployments.

Issue 4 — DNS settings UI broken post-upgrade

After the upgrade, switching between local DNS and Cloudflare under Settings > Advanced settings returns an error and does not save. Leaving the DNS field empty under advanced configuration also prevents saving any changes.

Issue 5 — Console password timeout too short

Long passwords with special characters expire before entry is complete. The console resets to the username prompt, requiring the full login sequence to restart. This penalizes security-conscious setups that follow recommended password complexity practices.

Issue 6 — Ctrl+Alt+Del on console reboots immediately

Pressing Ctrl+Alt+Del on the console triggers an immediate reboot with no confirmation prompt. Unexpected and potentially destructive behavior for a server-style device.

Issues 1 and 2 — NetworkManager config generated in /run/ (tmpfs)
All network changes (static IP, IPv6) are lost on every reboot. Root cause: connection profiles written to volatile storage, regenerated from a boot-time template on each restart.

Issue 3 — OTA upgrade removes manually installed packages
chrony + NTS wiped by upgrade, replaced by default systemd-timesyncd. Root cause: A/B partition model replaces OS layer without preserving manual apt installs.

Issue 4 — DNS settings UI broken (Medium)
Cannot switch between local DNS and Cloudflare post-upgrade. Empty DNS field prevents saving.

Issue 5 — Console password timeout too short (Medium)
Long passwords expire mid-entry, resetting to login prompt.

Issue 6 — Ctrl+Alt+Del reboots immediately (Low)
No confirmation prompt on console reboot.


Issues 1, 2 and 3 share a structural root cause: umbrelOS does not provide a supported, durable mechanism for OS-level configuration in advanced deployments. For security-sensitive Bitcoin node setups, network config, installed packages and time sync need to survive both reboots and OTA upgrades predictably.

Happy to help test any proposed solution against a DHCP-free segmented VLAN setup with real hardware.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions