generated from erix/meta
[BUG] Existing ext4 VM scenarios exceed their original QEMU deadlines #73
Labels
No labels
bug
ci
docs
duplicate
enhancement
help wanted
invalid
performance
phase-6
question
refactor
security
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
erix/integration#73
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
Existing ext4 positive VM scenarios reach their original 120-second QEMU deadline in two completed Integration CI runs. Both complete catalog runs fail, while the Rust and Markdown jobs pass. The failing scenario sets differ; this report records the observed failures without attributing them to filesystem semantics or host load.
Reproduction
The original push and pull-request CI executions at Integration
fd8a5cf0dbcf9a9cd3ddb6038370295e6ec2c8farun the maintained workflow and all 489 VM scenarios. Run 1705 reports seven failures and run 1706 reports four. These are two original executions, with no rerun, timeout increase or changed success oracle. An isolated clean-image reproduction has not yet been performed.Expected and actual behavior
Every positive scenario must reach its existing required witnesses inside its declared limit. Run 1705 reports
passed=482 failed=7 total=489; run 1706 reportspassed=485 failed=4 total=489. Each listed failure has actualqemu timed out after 120soutput and scenario status 1; the workflow ends with failed VM workers.All suffixes belong to
tests/scenarios/subsystem-e2fs-fat-ext4-<suffix>.toml. Retained timeout transcripts end their EriX markers atERIX_KERNEL:ROOTD_SMOKE:LOGD_REPLY_WAKE_OK=0000000000000001. That last printed marker does not identify the instruction executing at the deadline or prove a Logd defect.Environment and identity
fd8a5cf0dbcf9a9cd3ddb6038370295e6ec2c8fa; original source graph and artifact construction are recorded in each linked run.ci.yml, original push run 1705 and pull-request run 1706, with 489 maintained VM scenarios and the original 120-second QEMU ceiling.Evidence and prior checks
Original push run 1705 and original pull-request run 1706 retain the observed failures. Their Rust jobs each pass 320 and 321 tests, and Markdown passes. All six complete logs have no warning candidates. Expected negative-helper error output is distinct from the final VM failures. Do not treat successful reruns as a correction or widen the original limits.
Exact original-contract comparison: ten timeout serial dumps lack their required
ERIX_ROOTD:READY:VFS_IOmarker; the links case also lacksERIX_ROOTD:READY:VFS_EXT_LINKS. The geometry dump already contains its declared required substrings, but still reaches the deadline instead of the required exit. Marker presence cannot replace the exit and timeout checks. None of the eleven dumps contains its scenario's forbidden Kernel fault markers. This narrows the observed stage without proving which operation stalls or why.Tracking
Track under Phase 6 completion and the coordinated implementation review. The separate startup timing report and FAT32 timing report remain open; shared causation has not been established. Preserve original evidence, identify the failing stage with bounded diagnostics and validate any correction against these unchanged scenario oracles and the complete maintained suite.
Later original CI comparison — 22 September 2026: original Integration 1707 and 1708, at
9c62af2d2484b1ab0cadba768adc025dfd017485, both pass all 489 VM scenarios, Rust 320/321 tests and Markdown. All six complete job logs are retained and hash-verified, totaling 26,966,330 bytes with zero warning candidates. Both runs explicitly select Kernela9bdf6163813d378e0b4a164bceb839e24fbb6b7. These are later original runs on a different source graph, not retries of 1705/1706. Their success does not identify the cause or demonstrate a correction for the eleven previously retained ext4 timeouts; this report remains open.