udev: only trigger the boot-disk loop device for optical drives

probe_gpt_boot_disk_needs_loop() sets ID_PART_GPT_AUTO_ROOT_DISK_NEEDS_LOOP
for any whole disk that holds the boot ESP/XBOOTLDR but whose partition table
the kernel cannot parse. Until now the udev rule turned that into a
systemd-loop@.service for every block device.

That is too broad: device-mapper devices also report kernel partition
scanning as disabled, but their partitions are managed in userspace by kpartx
(see 66-kpartx.rules). Setting up a loop device on top of them re-exposes the
same partition table a second time and only causes trouble.

Restrict the rule to optical drives, the one class that genuinely needs a
kernel-side loop device (El Torito GPT sector size mismatch, or drives that do
not support partition scanning) and that has no userspace partition manager of
its own.

Co-developed-by: Claude Fable 5 <noreply@anthropic.com>

rules.d/99-systemd.rules.in

@@ -90,9 +90,12 @@ SUBSYSTEM=="tpmrm", KERNEL=="tpmrm[0-9]*", TAG+="systemd", ENV{SYSTEMD_WANTS}+="
 SUBSYSTEM=="tpm", KERNEL=="tpm[0-9]*", TAG+="systemd"
 
 # If the kernel cannot parse the GPT partition table on the boot disk (e.g. due to a sector size
-# mismatch on a CD-ROM booted via El Torito, or because the device does not support partition
-# scanning), trigger a loop device to expose the partitions.
-SUBSYSTEM=="block", ENV{ID_PART_GPT_AUTO_ROOT_DISK_NEEDS_LOOP}=="1", \
+# mismatch on a CD-ROM booted via El Torito, or because the optical drive does not support partition
+# scanning), trigger a loop device to expose the partitions. Restrict this to optical drives: other
+# block devices that lack kernel partition scanning (most notably device-mapper) rely on userspace
+# partition managers such as kpartx (see 66-kpartx.rules), and a competing loop device would only cause
+# trouble.
+SUBSYSTEM=="block", ENV{ID_CDROM}=="1", ENV{ID_PART_GPT_AUTO_ROOT_DISK_NEEDS_LOOP}=="1", \
   ENV{SYSTEMD_WANTS}+="systemd-loop@.service"
 
 LABEL="systemd_end"