Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.user > #243497

Re: udev applied to SDHC card. Two systems compared.

From "Alexander V. Makartsev" <avbetev@gmail.com>
Newsgroups linux.debian.user
Subject Re: udev applied to SDHC card. Two systems compared.
Date 2021-12-29 00:10 +0100
Message-ID <DztLs-ka-5@gated-at.bofh.it> (permalink)
References <DyR3r-1Xz-1@gated-at.bofh.it> <Dz28y-eA-5@gated-at.bofh.it> <Dzsml-7Nr-3@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


[Multipart message — attachments visible in raw view] - view raw

On 29.12.2021 01:59, peter@easthope.ca wrote:
>      From: "Alexander V. Makartsev" <avbetev@gmail.com>
>      Date: Mon, 27 Dec 2021 22:16:04 +0500
>> It is always better to make udev rules to identify target devices properly.
> Thanks Alexander.  Definitely my intention.
>
> 'KERNEL=="sd?1"' identifies two volumes, /dev/sda1 and /dev/sdb1.
>
> /dev/sda1 is approximately 6 GB.  'ATTR{size}=="7434240"'
> distinguishes the SD card from the HDD.  Therefore 'KERNEL=="sd?1",
> ATTR{size}=="7434240"' should identify the SD volume uniquely.
My point was, you could've used better or more identifiers to 
distinguish between devices, so there is no other device could ever 
interfere.
For example, what will happen if you plug in another drive with the same 
size?
It will be assigned as /dev/sdc1 and will have partition of the same 
size. Your rule will match and as a result will lead to undefined behavior.
It is much better to use identifiers like:
"ENV{ID_MODEL}" - internal information,
"ENV{ID_SERIAL_SHORT}" - unique serial number,
"ENV{ID_FS_UUID}" - unique identifier of filesystem.
Even if you clone filesystem to another device of same make/model, udev 
still will be able to tell them apart because of unique serial number.

Also, there is no information about *when* exactly "KERNEL" and 
"ATTR{size}" gets populated by udev, so by naming your custom rule 
"99-*.rules"
you will make it to be processed last, effectively bypassing possible 
race condition between the rules.
This could be the reason why two systems behave differently.

>> ... impossible to answer that question without actually looking at
>> these systems.
> Right oh.  "udevadm info" shows that udev identifies the device. The
> failure isn't in identification.  With configuration paralleling the
> SD card, a Kingston USB stick works in both systems .  Something
> peculiar about the SD card. I need to work on that.
>
> Thanks again,                            ... P.
You can also compare two systems using "udevadm info --attribute-walk"
Systems could have different card-readers based on different controllers 
and different usb hub devices.
They all could use different kernel modules and trigger different set of 
udev rules.

I'm sorry, if I wasn't clear enough in previous letter. English is an 
every day struggle for me.

-- 
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄⠀⠀⠀⠀

Back to linux.debian.user | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

udev applied to SDHC card.  Two systems compared. peter@easthope.ca - 2021-12-27 06:50 +0100
  Re: udev applied to SDHC card. Two systems compared. "Alexander V. Makartsev" <avbetev@gmail.com> - 2021-12-27 18:40 +0100
    Re: udev applied to SDHC card. Two systems compared. peter@easthope.ca - 2021-12-28 22:40 +0100
      Re: udev applied to SDHC card. Two systems compared. "Alexander V. Makartsev" <avbetev@gmail.com> - 2021-12-29 00:10 +0100
        Re: udev applied to SDHC card. Two systems compared. peter@easthope.ca - 2021-12-29 20:30 +0100
  Re: udev applied to SDHC card.  Two systems compared. David Wright <deblis@lionunicorn.co.uk> - 2022-01-03 05:30 +0100

csiph-web