Two rule-two refusals have no counterfactual the Refusal row shape can hold #116

Activity

1. lesnik512

   added

   enhancementNew feature or requestNew feature or request

   on Sep 20, 2026
2. lesnik512 commented on Sep 20, 2026

   

   lesnik512

   on Sep 20, 2026

   MemberAuthor

   More actions

   Measured, podman 4.9.3, CI (run 35509724204 and its follow-up)

   nocopy works. The refusal message is wrong.

   The inconclusive "10 entries vs 3" from the first probe is fully explained: I was counting, not looking. Listing names instead:

   mounted at /etc          -> volume contains: group hostname hosts localtime mtab network
                                                nsswitch.conf passwd resolv.conf shadow
   mounted at /etc:nocopy   -> volume contains: hostname hosts resolv.conf
   

   The three survivors are podman's own runtime files — it writes /etc/hosts, /etc/hostname and /etc/resolv.conf into every container, and they land in the volume because the volume is mounted at /etc. Every one of the image's seven files (group, localtime, mtab, network, nsswitch.conf, passwd, shadow) is gone. nocopy suppresses the copy-up completely.

   It is also parsed rather than tolerated:

   -v vol:/etc:nocopy          exit=0
   -v vol:/etc:nosuchoption    exit=125  Error: invalid option type "nosuchoption"
   

   So (podman cannot express it) is false. podman expresses it in the short form and it does what Docker says it does; what cannot express it is --mount, which is the grammar compose2pod emits for a long-form volume (nocopy: invalid mount option, measured in the first probe).

   That makes it a LIMITATION, not a rule-two refusal — the same correction the drive-qualified bind got in #110, with the same escape available: -v <vol>:<target>:nocopy is a spelling compose2pod could emit for exactly this case. Whether to emit it is a separate decision from fixing the message.

   reservations.cpus: absence confirmed

   flags matching reserv:  --memory-reservation   (and --preserve-fds, which only matched the regex)
   --cpu-reservation 1     exit=125  unknown flag
   --cpus-reservation 1    exit=125  unknown flag
   

   --memory-reservation is the one that exists, and compose2pod already emits it for reservations.memory. An absence-assertion row over the candidate names is the right shape here.

   reservations.devices: not absence — something worse

   --gpus exists on podman 4.9.3, hidden:

   grep -i gpu over the whole help text:  (absent from --help)
   --gpus 'all'        exit=0
   --gpus '1'          exit=0
   --gpus 'nonsense'   exit=0
   --gpus ''           exit=0
   

   It accepts nonsense, so it validates nothing. On a runner with no GPU --gpus all adds no device, which proves little by itself — but an unvalidated flag means emitting it would compile, run, exit 0, and reserve nothing. That is the #104 / #114 failure mode exactly: a false green.

   So the refusal stands, and the reason is sharper than "no equivalent": podman has a stub that accepts anything and does nothing. The mechanizable row is not absence but non-validation — assert --gpus nonsense exits 0, and when a later podman starts rejecting it, the row goes red and the refusal gets re-examined.
3. lesnik512

   closed this as completedin #123on Sep 20, 2026