Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

SteamOS 3.9.2 -> 3.9.3 update hangs around 95%: holo-sync-var blocks looking up /etc after freezing /var

Aperta
  • Qualcosa non va?
#2,957 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
42/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
bash, linux
Ambito
devops

Direzione di ricerca

Start by reading /usr/lib/holo/holo-sync-var, especially build_etc_rsync_config and the /var freeze and unfreeze around sync_var_mountpoints; the report says the lookup of /etc/atomic-update.conf.d/*.conf blocks in OverlayFS. Compare the reported kernel stack and RAUC timeline with the sync flow, then investigate a safe way to avoid or recover from the blocked lookup. Done means the update completes without leaving /var frozen, including with a custom keep-list.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Your system information
  • Device: Steam Machine (Fremont)
  • Steam client version: 1792192922
  • SteamOS version: 3.9.2, build 20260925.101, updating to 3.9.3, build 20261015.100
  • Kernel during the failure: 7.2.7-valve1-1-neptune-72-gc8730d37f9c6
  • Opted into Steam client beta?: Yes (steamdeck_publicbeta)
  • Opted into SteamOS beta?: Yes (Branch=beta)
  • Have you checked for updates in Settings > System?: Yes
  • Updater package: steamos-customizations-jupiter 20260827.2-1
Please describe your issue in as much detail as possible:

Tried updating the Steam Machine from 3.9.2 to 3.9.3 and it got stuck around 95%. Rebooting then got stuck on the Steam logo too, so I ended up having to force it off. Tried the update again after booting and hit the same hang, this time with enough access left to see what was going on.

The image write itself finished. It was the post-install configuration sync that got stuck: holo-sync-var was in D state, waiting for write access to a filesystem it had just frozen.

Expected: the update finishes and asks for a reboot. Actual: the post-install step waits indefinitely, /var stays frozen, and unrelated processes start blocking too. Normal SSH login stopped working during the second attempt; a separate SSH connection with PAM disabled still worked, which let me inspect the stuck process.

I have a custom keep-list under /etc/atomic-update.conf.d/ for SSH configuration, Wake-on-LAN and Flatpak update units. I haven't reproduced this on a clean install.

Where it gets stuck

On the second attempt, RAUC reported All slots updated at 15:41:49 UTC, then entered /usr/lib/rauc/post-install.sh and stopped at:

# Syncing the var partitions from 'self' to 'other'
# Booted into slot A
# Update slot candidate is B

The blocked child was PID 5773, /bin/bash /usr/lib/holo/holo-sync-var all. Its syscall was openat, and reading the pathname argument from its memory gave:

/etc/atomic-update.conf.d/

Relevant kernel stack, with unrelated frames omitted:

task:holo-sync-var state:D pid:5773 ppid:5763
percpu_rwsem_wait+0x14e/0x1c0
__percpu_down_read+0x81/0x150
mnt_want_write+0x98/0xc0
ovl_lookup_layers+0x95f/0xb00 [overlay]
ovl_lookup+0x1a9/0x2c0 [overlay]
path_openat+0xaae/0x14c0
do_file_open+0x117/0x1d0
do_sys_openat2+0x7d/0xe0
__x64_sys_openat+0x61/0xa0

/etc is an overlay with its upper/work directories under /var/lib/overlays/etc/; /var is ext4. In the installed holo-sync-var, line 509 freezes /var, then sync_var_mountpoints calls rsync_etc_overlay, which calls build_etc_rsync_config. That function expands /etc/atomic-update.conf.d/*.conf at line 237. The unfreeze is at line 523, after the sync returns.

So the updater freezes the backing filesystem, then gets stuck looking up its configuration through the overlay, before it can reach its own unfreeze.

What released it

Ran sudo fsfreeze --unfreeze /var once through the working connection. The blocked processes immediately resumed. That attempt then failed at its own unfreeze with Invalid argument, since /var was already unfrozen.

Retried without rebooting. This time the sync finished and RAUC reported success:

15:41:49 UTC  post-install sync starts, then hangs
15:47:25 UTC  manual unfreeze releases it; keep-list processing resumes
15:47:26 UTC  attempt fails after its own unfreeze returns Invalid argument
15:48:03 UTC  next attempt reaches the same sync step
15:48:04 UTC  Installation c8245e0b succeeded

After rebooting, /etc/os-release reports 3.9.3 / 20261015.100, and Steam reports up to date.

My current guess is that the directory lookup needed to create missing OverlayFS trusted.overlay.origin metadata. OverlayFS has a lookup-time repair path that takes write access, which fits the stack and the fact that the next attempt passed. I didn't capture the directory's xattrs before releasing the freeze, so I can't claim that part is proven, or say what originally caused the metadata to be missing.

The updater package version is the same before and after the update; the installed holo-sync-var and post-install.sh match their package SHA-256 records. I haven't patched either script.

The expandable sections below contain the blocked task's kernel stack and a selected RAUC timeline, including the successful retry. Timestamps are normalized to UTC and the custom keep-list filename is anonymized. The live pathname capture above was taken separately from /proc while the process was stuck.

Kernel journal: blocked updater 
Kernel journal: blocked holo-sync-var task during the second attempt.
Timestamps normalized to UTC. Register values omitted.

2026-10-19T15:45:49+00:00 kernel[]: task:holo-sync-var   state:D stack:0     pid:5773  tgid:5773  ppid:5763   task_flags:0x400140 flags:0x00080000
2026-10-19T15:45:49+00:00 kernel[]: Call Trace:
2026-10-19T15:45:49+00:00 kernel[]:  <TASK>
2026-10-19T15:45:49+00:00 kernel[]:  __schedule+0x406/0x16e0
2026-10-19T15:45:49+00:00 kernel[]:  ? ilookup5+0x4c/0xb0
2026-10-19T15:45:49+00:00 kernel[]:  ? srso_alias_return_thunk+0x5/0xfbef5
2026-10-19T15:45:49+00:00 kernel[]:  ? ovl_lookup_trap_inode+0x20/0x80 [overlay 6f1239f5193666767a30a186d164daeb94bed60e]
2026-10-19T15:45:49+00:00 kernel[]:  schedule+0x27/0xa0
2026-10-19T15:45:49+00:00 kernel[]:  percpu_rwsem_wait+0x14e/0x1c0
2026-10-19T15:45:49+00:00 kernel[]:  ? __pfx_percpu_rwsem_wake_function+0x10/0x10
2026-10-19T15:45:49+00:00 kernel[]:  __percpu_down_read+0x81/0x150
2026-10-19T15:45:49+00:00 kernel[]:  mnt_want_write+0x98/0xc0
2026-10-19T15:45:49+00:00 kernel[]:  ovl_lookup_layers+0x95f/0xb00 [overlay 6f1239f5193666767a30a186d164daeb94bed60e]
2026-10-19T15:45:49+00:00 kernel[]:  ? srso_alias_return_thunk+0x5/0xfbef5
2026-10-19T15:45:49+00:00 kernel[]:  ? kmem_cache_alloc_lru_noprof+0x424/0x460
2026-10-19T15:45:49+00:00 kernel[]:  ovl_lookup+0x1a9/0x2c0 [overlay 6f1239f5193666767a30a186d164daeb94bed60e]
2026-10-19T15:45:49+00:00 kernel[]:  ? srso_alias_return_thunk+0x5/0xfbef5
2026-10-19T15:45:49+00:00 kernel[]:  ? __d_alloc+0x75/0x220
2026-10-19T15:45:49+00:00 kernel[]:  ? security_inode_permission+0x4f/0x130
2026-10-19T15:45:49+00:00 kernel[]:  path_openat+0xaae/0x14c0
2026-10-19T15:45:49+00:00 kernel[]:  do_file_open+0x117/0x1d0
2026-10-19T15:45:49+00:00 kernel[]:  ? do_getname+0x62/0x1d0
2026-10-19T15:45:49+00:00 kernel[]:  do_sys_openat2+0x7d/0xe0
2026-10-19T15:45:49+00:00 kernel[]:  __x64_sys_openat+0x61/0xa0
2026-10-19T15:45:49+00:00 kernel[]:  do_syscall_64+0xa6/0x670
2026-10-19T15:45:49+00:00 kernel[]:  ? srso_alias_return_thunk+0x5/0xfbef5
2026-10-19T15:45:49+00:00 kernel[]:  ? srso_alias_return_thunk+0x5/0xfbef5
2026-10-19T15:45:49+00:00 kernel[]:  ? __alloc_frozen_pages_noprof+0x1a0/0x370
2026-10-19T15:45:49+00:00 kernel[]:  ? srso_alias_return_thunk+0x5/0xfbef5
2026-10-19T15:45:49+00:00 kernel[]:  ? flush_tlb_func+0x288/0x2f0
2026-10-19T15:45:49+00:00 kernel[]:  ? srso_alias_return_thunk+0x5/0xfbef5
2026-10-19T15:45:49+00:00 kernel[]:  ? __mod_memcg_lruvec_state+0xdf/0x1a0
2026-10-19T15:45:49+00:00 kernel[]:  ? srso_alias_return_thunk+0x5/0xfbef5
2026-10-19T15:45:49+00:00 kernel[]:  ? lruvec_stat_mod_folio+0x93/0xd0
2026-10-19T15:45:49+00:00 kernel[]:  ? srso_alias_return_thunk+0x5/0xfbef5
2026-10-19T15:45:49+00:00 kernel[]:  ? __folio_mod_stat+0x2d/0x90
2026-10-19T15:45:49+00:00 kernel[]:  ? srso_alias_return_thunk+0x5/0xfbef5
2026-10-19T15:45:49+00:00 kernel[]:  ? folio_add_lru+0x4d/0x80
2026-10-19T15:45:49+00:00 kernel[]:  ? srso_alias_return_thunk+0x5/0xfbef5
2026-10-19T15:45:49+00:00 kernel[]:  ? do_wp_page+0x940/0x11f0
2026-10-19T15:45:49+00:00 kernel[]:  ? srso_alias_return_thunk+0x5/0xfbef5
2026-10-19T15:45:49+00:00 kernel[]:  ? __handle_mm_fault+0xaca/0x1110
2026-10-19T15:45:49+00:00 kernel[]:  ? srso_alias_return_thunk+0x5/0xfbef5
2026-10-19T15:45:49+00:00 kernel[]:  ? count_memcg_events+0xc5/0x180
2026-10-19T15:45:49+00:00 kernel[]:  ? srso_alias_return_thunk+0x5/0xfbef5
2026-10-19T15:45:49+00:00 kernel[]:  ? handle_mm_fault+0x1e5/0x2c0
2026-10-19T15:45:49+00:00 kernel[]:  ? srso_alias_return_thunk+0x5/0xfbef5
2026-10-19T15:45:49+00:00 kernel[]:  ? do_user_addr_fault+0x232/0x720
2026-10-19T15:45:49+00:00 kernel[]:  ? srso_alias_return_thunk+0x5/0xfbef5
2026-10-19T15:45:49+00:00 kernel[]:  ? do_syscall_64+0x5b/0x670
2026-10-19T15:45:49+00:00 kernel[]:  ? srso_alias_return_thunk+0x5/0xfbef5
2026-10-19T15:45:49+00:00 kernel[]:  ? exc_page_fault+0x75/0x160
2026-10-19T15:45:49+00:00 kernel[]:  entry_SYSCALL_64_after_hwframe+0x76/0x7e
2026-10-19T15:45:49+00:00 kernel[]:  </TASK>
RAUC journal: stalled attempt, recovery and successful retry 
Selected RAUC journal entries, 2026-10-19. Timestamps normalized to UTC.
The custom keep-list filename is anonymized; messages otherwise retain their wording.

2026-10-19T15:41:44+00:00 systemd[1]: Starting RAUC Update Service...
2026-10-19T15:41:49+00:00 rauc[5529]: installing https://steamdeck-images.steamos.cloud/steamdeck/20261015.100/steamdeck-20261015.100-3.9.3.raucb: All slots updated
2026-10-19T15:41:49+00:00 rauc[5529]: Starting post install handler: /usr/lib/rauc/post-install.sh
2026-10-19T15:41:49+00:00 rauc-override.sh[5529]: # Syncing the var partitions from 'self' to 'other'
2026-10-19T15:47:25+00:00 rauc-override.sh[5529]: # Keeping user defined files from '/etc/atomic-update.conf.d/example-additional-keep-list.conf'
2026-10-19T15:47:25+00:00 rauc-override.sh[5529]: # Keeping user defined files from '/etc/atomic-update.conf.d/custom-keep.conf'
2026-10-19T15:47:25+00:00 rauc-override.sh[5529]: # fsfreeze: /var: unfreeze failed: Invalid argument
2026-10-19T15:47:25+00:00 rauc-override.sh[5529]: # Error: Failed to sync var partitions
2026-10-19T15:47:26+00:00 rauc[5529]: Installation 2d58351e failed: Post-install handler error: Child process exited with code 1
2026-10-19T15:47:58+00:00 systemd[1]: Starting RAUC Update Service...
2026-10-19T15:48:03+00:00 rauc[6554]: installing https://steamdeck-images.steamos.cloud/steamdeck/20261015.100/steamdeck-20261015.100-3.9.3.raucb: All slots updated
2026-10-19T15:48:03+00:00 rauc[6554]: Starting post install handler: /usr/lib/rauc/post-install.sh
2026-10-19T15:48:03+00:00 rauc-override.sh[6554]: # Syncing the var partitions from 'self' to 'other'
2026-10-19T15:48:03+00:00 rauc-override.sh[6554]: # Keeping user defined files from '/etc/atomic-update.conf.d/example-additional-keep-list.conf'
2026-10-19T15:48:03+00:00 rauc-override.sh[6554]: # Keeping user defined files from '/etc/atomic-update.conf.d/custom-keep.conf'
2026-10-19T15:48:04+00:00 rauc[6554]: Installation c8245e0b succeeded
Steps for reproducing this issue:

This is the sequence that hit it twice here, not a confirmed minimal reproduction:

  1. Start from SteamOS 3.9.2 / 20260925.101 with a custom keep-list as described above.
  2. Apply the 3.9.3 / 20261015.100 update through Settings > System.
  3. The image write finishes, but progress stops around 95% during the /var configuration sync. Check for holo-sync-var blocked in ovl_lookup_layers / mnt_want_write.
Lingua principale
Nessun dato sulla lingua
Stelle
2.6k
Fork
86
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di ValveSoftware/SteamOS

Tutte le issue di ValveSoftware/SteamOS

Issue simili

Altre issue su DevOps

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.