Browse Source
":Z" relabels what it mounts to container_file_t, recursively and on disk, and init.sh lives in /etc/quadlets/zwave-js-ui. Mounting that directory into the container therefore left a script systemd could no longer execute: zwave-js-ui-init.service failed with 203/EXEC at every boot after the first start of the container, and the container's Requires= on it kept the container down too. A machine that survived its installation stopped surviving a reboot. Found on the target machine, not in review: the first installation works, because Ignition writes /etc with the right labels and the init service runs before the container. The fault only appears at the second boot. The README also gains a "Clearing the store" section. The seed is a first-boot mechanism, so an operator who deletes settings.json -- after rotating the security keys, for instance, since Z-Wave JS UI keeps its own copy of the old ones -- has to restart the init service explicitly. "systemctl restart zwave-js-ui.target" does not re-run it: it is RemainAfterExit=yes and already active. Getting that wrong leaves a container unhealthy forever with a happy driver, and authentication silently off. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>pull/11/head
2 changed files with 45 additions and 3 deletions
Loading…
Reference in new issue