Commit 76d108e
M9.R.42.4: bump install driver timeout 900s -> 1800s for Phase 5 rsync
The first M9.R.42 install run hit the 900s wall-time limit DURING
Phase 5 rsync (livesys -> /mnt), not on the Phase 2 sgdisk path
M9.R.41 documented.
Evidence (extracted from /tmp/m9r42_install.qcow2 by converting to
raw + sfdisk -d after the timeout-kill):
/tmp/m9r42_install.raw1 : start=2048, size=1048576, type=esp (EF00)
/tmp/m9r42_install.raw2 : start=1050624, size=66058207, type=8300
EXT4-fs (vda2): mounted filesystem ... r/w <-- Phase 3 line in
the kernel ring
/tmp/m9r42_mnt: 542 MB of rsync'd live-root content visible
(bin/ boot/ etc/ usr/ ...)
So:
Phase 1 (hardware probe) OK
Phase 2 (disk apply) OK <-- sgdisk + udev + EXT4 all clean
Phase 3 (mount) OK
Phase 4 (install-root) started, partial rsync
Phase 5 (chroot setup) not reached
Phase 6 (boot install) not reached
Bumping the timeout to 1800s (30 min) covers the worst-case rsync of
the M9.R.41 base-rootfs (~1.5 GB live-root squashfs unpacked). No
behaviour change for fast hosts; the script still kills at the
timeout boundary.
This is the SAME shape as the M9.R.41 driver timeout bump that
covered the Phase 5 work — we just need more headroom now that the
M9.R.41-attributed Phase 2 race turns out to be a stale-binary
artifact (the M9.R.41.9 host /opt/repro/reprobuild/build/bin/repro
was never recompiled after the M9.R.41.9-12 reverts; my M9.R.42.1
fresh rebuild gave Phase 2 a clean run as documented in the M9.R.42
close-out evidence).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>1 parent 095d992 commit 76d108e
1 file changed
Lines changed: 1 addition & 1 deletion
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
18 | 18 | | |
19 | 19 | | |
20 | 20 | | |
21 | | - | |
| 21 | + | |
22 | 22 | | |
23 | 23 | | |
24 | 24 | | |
| |||
0 commit comments