Diagnose the retry that follows a deleted package - #131
Conversation
Every attempt after the first fails on the open rather than on a checksum: pacstrap runs with --noconfirm, so pacman answers yes to "delete it?" and unlinks the package through the bind mount that makes the ISO's offline mirror the target's package cache. The failure screen then carried no diagnosis at all, because the only line it matched -- "is corrupted" under the target cache -- was written by the attempt that already scrolled away. A retry is the state most people are in by the time they read the screen, and it was the one case with nothing on it. pacman names the repository it read from in that error, not the cache it writes to, so the match keys on the mirror path rather than the target cache path. Where a log holds both attempts the checksum failure still wins: it is the one that names the cause, and the open failures after it are its wake. The verdict sends the reader to reboot instead of offering a remedy for the medium. Nothing can be weighed once the bytes are gone, and the deletion landed in the live session's RAM overlay rather than on the stick, so a reboot brings the ISO's copy back and the first error after it is the one that says what actually failed.
|
Reviewed at It is genuinely additive. All 95 lines are insertions. The parsing is right, and that was checked rather than assumed. Against the installed pacman 7.1.0 / libalpm 16.0.1 / libcurl 8.21.0: libalpm carries High — the branch does not fire on the retry it was written for. Medium — the one path that can fire is the one the message describes wrongly. On omacom/omarchy#7704, which this exists for. Two things were asked of the reporter by hand: the exact package filename, and the first error in Sequencing, for whoever decides the order. #132 edits this same file in this same region: it inserts Waiting on the author for a concrete reachable path in the shipped flow, or for a narrower change. Nothing was pushed to the branch: the first finding is a design question rather than a defect with an obvious patch, and tightening the regex for the second is not worth doing while the branch it guards is in question. |
1 participant
The failure screen names the install medium when pacman rejects a package off it, but only on the attempt that does the rejecting. Every attempt after that fails on the open instead: pacstrap runs with
--noconfirm, so pacman answers yes to "delete it?" and unlinks the package through the bind mount that makes the ISO's offline mirror the target's package cache. A retry's log carries nois corruptedline, nothing matches, and the screen falls back to the bare pacstrap error with the word USB nowhere on it. That is the state most people are in by the time they read the screen, because the attempt that explained it scrolled away with the first try.pacman names the repository it read from in that error, not the cache it writes to, so the match keys on the mirror path rather than on the target cache path:
Where a log holds both attempts the checksum failure still wins. It is the one that names the cause, and the open failures after it are its wake.
The new verdict sends the reader to reboot rather than offering a remedy for the medium. Nothing can be weighed once the bytes are gone, and the deletion landed in the live session's RAM overlay rather than on the stick, so a reboot brings the ISO's copy back and the first error after that is the one that says what actually failed.
Reported in omacom/omarchy#7704, where the undiagnosed retry is the exact error two people are stuck on. This does not stop the deletion itself — that is the read-write cache bind in
_mount_offline_package_cache, which #108 and #113 are both rewriting.Codex at xhigh reasoning reviewed the failure and confirmed the gap this closes: a retry log holding only the retrieval error produces no diagnosis, while an accumulated log that still carries the first attempt's line is diagnosed as before, which is the precedence kept here. Its independence is not currently guaranteed.