System details
Dell XPS 14 (DA14260), Intel Core Ultra / Meteor Lake, ov08x40 on IPU7, Omarchy 3.8.3, intel-ipu7-camera 1.0.5-1, systemd 260
What's wrong?
Package: intel-ipu7-camera 1.0.5-1 from the omarchy pacman repo (pkgs.omarchy.org). Its metadata URL points at the Intel enabling repo (TsaiGaggery/hurrican_omarchy_enabling), but the PKGBUILD/scriptlet/hook aren't public there, so filing where the package ships — please route to the packaging side as appropriate.
Problem
This is the same bug class 3.8.3 just fixed in the power-profile udev rule (#6091, 749a8c0) — one more instance shipped in a package. The sleep hook that intel-ipu7-camera installs (post_install/post_upgrade copy /usr/share/intel-ipu7-camera/camera-sleep-hook to /usr/lib/systemd/system-sleep/camera-sleep-hook) launches its post work with a fixed transient unit name:
post)
systemd-run --no-block --unit=camera-resume bash -c '
systemctl restart camera-init.service 2>/dev/null || true
systemctl reset-failed v4l2-relayd@ipu7.service 2>/dev/null || true
systemctl start v4l2-relayd@ipu7.service 2>/dev/null || true
'
;;With suspend-then-hibernate, systemd runs the system-sleep hook cycle around each leg. At the intermediate wake (end of HibernateDelaySec), the hook's post launches camera-resume.service; because it's --no-block, the machine proceeds into the hibernate leg and can freeze that unit mid-run into the hibernation image. On the real resume, the hook fires post again — and the second systemd-run fails because the unit name is taken:
Jul 13 21:10:09 <host> systemd-run[655762]: Running as unit: camera-resume.service
Jul 14 07:15:21 <host> systemd-run[655862]: Failed to start transient service unit: Unit camera-resume.service was already loaded or has a fragment file.
Jul 14 07:15:25 <host> systemd[1]: camera-resume.service: Deactivated successfully.
So the resume-side camera restart is silently skipped; whether the camera comes back depends on the thawed pre-hibernate unit happening to finish its work at a time when the hardware is ready — luck, not design. The same collision can also occur with two closely spaced suspend/resume cycles.
Suggested fix
Same shape as 749a8c0: make the unit name unique per invocation (or drop it entirely) and add --collect so failed units are garbage-collected:
systemd-run --no-block --collect --unit=camera-resume-$$ bash -c '...'
The hook body is idempotent (restart / reset-failed / start), so overlapping invocations are harmless. Keeping a camera-resume- prefix (rather than dropping the name entirely) preserves greppable journal forensics for suspend debugging, but either works.
I've applied the sed above locally and it works (unit names like camera-resume-1234.service, no collisions), but it's re-clobbered on every package upgrade since the scriptlet re-copies the hook — hence the report. Happy to test a fixed build.
System details
Dell XPS 14 (DA14260), Intel Core Ultra / Meteor Lake, ov08x40 on IPU7, Omarchy 3.8.3, intel-ipu7-camera 1.0.5-1, systemd 260
What's wrong?
Package:
intel-ipu7-camera 1.0.5-1from the omarchy pacman repo (pkgs.omarchy.org). Its metadata URL points at the Intel enabling repo (TsaiGaggery/hurrican_omarchy_enabling), but the PKGBUILD/scriptlet/hook aren't public there, so filing where the package ships — please route to the packaging side as appropriate.Problem
This is the same bug class 3.8.3 just fixed in the power-profile udev rule (#6091, 749a8c0) — one more instance shipped in a package. The sleep hook that
intel-ipu7-camerainstalls (post_install/post_upgradecopy/usr/share/intel-ipu7-camera/camera-sleep-hookto/usr/lib/systemd/system-sleep/camera-sleep-hook) launches itspostwork with a fixed transient unit name:With
suspend-then-hibernate, systemd runs the system-sleep hook cycle around each leg. At the intermediate wake (end ofHibernateDelaySec), the hook'spostlaunchescamera-resume.service; because it's--no-block, the machine proceeds into the hibernate leg and can freeze that unit mid-run into the hibernation image. On the real resume, the hook firespostagain — and the secondsystemd-runfails because the unit name is taken:So the resume-side camera restart is silently skipped; whether the camera comes back depends on the thawed pre-hibernate unit happening to finish its work at a time when the hardware is ready — luck, not design. The same collision can also occur with two closely spaced suspend/resume cycles.
Suggested fix
Same shape as 749a8c0: make the unit name unique per invocation (or drop it entirely) and add
--collectso failed units are garbage-collected:The hook body is idempotent (
restart/reset-failed/start), so overlapping invocations are harmless. Keeping acamera-resume-prefix (rather than dropping the name entirely) preserves greppable journal forensics for suspend debugging, but either works.I've applied the sed above locally and it works (unit names like
camera-resume-1234.service, no collisions), but it's re-clobbered on every package upgrade since the scriptlet re-copies the hook — hence the report. Happy to test a fixed build.