On Sun 22 Oct 2023 at 10:17:35 (-0700), pe...@easthope.ca wrote:
> Appears that the failure reported by Karl Schmidt occurred when two
> devices matched the rule.
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040445
>
> Similar erroneous result here with only one matching device. Details
> below.
>
> Ideas?
In the light of how Karl's bug was solved, perhaps you could improve
your details. For example, writing ls -ld /dev/A* with a wildcard
seems reasonable, but head -n 13 /etc/udev/rules.d/10* conceals
the filename, which should be constructed according to certain rules
(no pun intended).
> =====================================
> In Debian 11.
> root@imager:~# cat /etc/deb*ver*
> 11.8
>
> root@imager:~# head -n 13 /etc/udev/rules.d/10* | tail -n 2
> KERNEL=="sd?3", SUBSYSTEM=="block", ATTR{size}=="60028928", \
> SYMLINK+="AY", OWNER="root", GROUP="root", MODE="700"
>
> root@imager:~# ls -ld /dev/A*
> lrwxrwxrwx 1 root root 4 Oct 22 07:00 /dev/AY -> sdb3
>
> # That, ^, is the correct result.
>
> In Debian 12.
> root@imager:~# cat /etc/deb*ver*
> 12.2
>
> root@imager:~# head -n 23 /etc/udev/rules.d/10* | tail -n 2
> KERNEL=="sd?3", SUBSYSTEM=="block", ATTR{size}=="60028928", \
> SYMLINK+="A1", OWNER="root", GROUP="root", MODE="700"
>
> root@imager:~# ls -ld /dev/A*
> lrwxrwxrwx 1 root root 4 Oct 22 06:53 /dev/A1 -> sda5
>
> # That, ^, is the wrong result. /dev/sda has no ATTR{size}=="60028928".
I don't doubt that both the filenames /are/ ok, but we lack any
knowledge of what is contained in the udev database that could
cause unexpected matches. (Choosing a partition with those keys
and attributes is odd IMO.)
> Simple tests similar to these reported by Karl and I are likely to
> produce failures in short order.
Karl posted the udev database, which revealed the error.
> Failure of salient features impairs the appeal of Debian. With
> removable storage routinely depending upon udev, successful operation
> really should be verified before a new Debian is released.
If I were trying to demonstrate a bug, I'd be revealing all the rules
(or grepping with a search string that would match all rules that
/could be/ involved), the udev database (or subsets thereof), and
some logs.
When I'm interested in what udev is doing, I run commands like:
# This method is for devices that get plugged in and removed:
#
# $ udevadm monitor -u -p
# is used to check what udev is doing when USB devices are (un)plugged.
# $ udevadm monitor -u -p -s block/partition
# filters out all but USB sticks etc.
# $ udevadm monitor -u -p -s block/disk
# filters out all but CDROM/DVD devices etc.
# This method is for devices that are built in:
#
# $ udevadm monitor -k -u -p
# is used to check what udev is doing when media are (un)loaded.
# $ udevadm monitor -k -u -p -s block/disk
# reduces the amount of output.
(That's from the comments in my rules file for mass storage stuff.)
If your udev rules are being run at boot time for internal devices,
I'm not certain how to start and log any monitoring early enough.
Sorry, you'd have to look that up.
Cheers,
David.
