Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#2,957 1 comentario 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
42/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
bash, linux
Área
devops

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.
Lenguaje dominante
Sin datos de lenguaje
Estrellas
2.6k
Forks
86
Sin PR fusionados en 30 d

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de ValveSoftware/SteamOS

Todos los issues de ValveSoftware/SteamOS

Issues similares

Más issues de DevOps

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.