Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#2,957 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
42/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
bash, linux
Lĩnh vực
devops

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.
Ngôn ngữ chính
Không có dữ liệu ngôn ngữ
Star
2.6k
Fork
86
Không có pull request nào được merge trong 30 ngày

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của ValveSoftware/SteamOS

Tất cả issue của ValveSoftware/SteamOS

Issue tương tự

Thêm issue về DevOps

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.