fix(burn): trigger media-change via auto-eject so verify can mount#27
Merged
Conversation
After a burn with `-use-the-force-luke=notray` the kernel (and udisks2) kept the disc cached as "Blank BD-R" — the state at burn-start. SCSI probes via dvd+rw-mediainfo updated the kernel's TOC view but did not invalidate the udisks2 media-type cache; only a real media-change event does that. The post-burn verify therefore failed to mount until the user physically ejected + re-inserted the disc. Drop `-use-the-force-luke=notray` so growisofs performs its default post-burn eject, which generates the media-change event the kernel needs. `DiscIO.wait_for_disc_ready` then blocks until the disc is back in: a 10s settle pause lets the eject motor finish, then `eject -t` (close-tray) is retried on the schedule (0, 5, 15, 30, 50)s — five attempts with 5/10/15/20s spacing — to handle slow tray motors without racing the eject. Slim drives that can't motor the tray fall through to passive polling on `drive_status`; the user pushes the disc in, no prompt, no hard timeout, Ctrl+C aborts. Also surface mount-failure stderr from `tools/mount.py` and `tools/udisks.py` instead of swallowing it. That was what made this diagnosable in the first place: udisks2's "is not a mountable filesystem" message + `dvd+rw-mediainfo`'s "Disc status: appendable / Number of Sessions: 2" output pointed at the stale-cache hypothesis. Removes the now-obsolete `DiscIO.refresh_toc()`, `DiscIO.close_tray_if_open()`, and `tools.mediainfo.probe()`. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
-use-the-force-luke=notrayfromgrowisofsso its default post-burn eject generates the kernel media-change event that invalidates the cached "Blank BD-R" state. Without it, the OS keeps seeing the pre-burn disc andudisks2reports the freshly burned disc as not-mountable.DiscIO.wait_for_disc_ready(): 10s post-eject settle pause, theneject -t(close-tray) retried on the schedule(0, 5, 15, 30, 50)s(5 attempts, 5/10/15/20s spacing) for tray-load drives. Slim drives that can't motor the tray fall through to passive polling — user pushes the disc in, no prompt, no hard timeout, Ctrl+C aborts.tools/mount.py+tools/udisks.py(was swallowed before). This was what made the bug diagnosable:udisks2's "is not a mountable filesystem" combined withdvd+rw-mediainfo's "Disc status: appendable / Number of Sessions: 2" output pointed at the stale-cache hypothesis.DiscIO.refresh_toc(),DiscIO.close_tray_if_open(), andtools.mediainfo.probe()(SCSI probes do not invalidate the udisks2 media-type cache — only a real media-change event does).Test plan
ruff checkclean🤖 Generated with Claude Code