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


Groups > linux.debian.user > #243472 > unrolled thread

udev applied to SDHC card. Two systems compared.

Started bypeter@easthope.ca
First post2021-12-27 06:50 +0100
Last post2022-01-03 05:30 +0100
Articles 6 — 3 participants

Back to article view | Back to linux.debian.user


Contents

  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

#243472 — udev applied to SDHC card. Two systems compared.

Frompeter@easthope.ca
Date2021-12-27 06:50 +0100
Subjectudev applied to SDHC card. Two systems compared.
Message-ID<DyR3r-1Xz-1@gated-at.bofh.it>
Any ideas about why udev assigns a symlink on the desktop system and 
not on the Sharp Mebius laptop?

Thx,                        ... P.

Desktop machine.
peter@joule:/home/peter$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 11 (bullseye)
Release:        11
Codename:       bullseye

peter@joule:/home/peter$ uname -a
Linux joule 5.10.0-10-686-pae #1 SMP Debian 5.10.84-1 (2021-12-08) i686 GNU/Linux

Pertinent lines in /etc/udev/rules.d/10-local.rules.
# The green Nexttech SDHC card.
KERNEL=="sd?1", ATTR{size}=="7434240", SYMLINK+="GRNSD", \
 OWNER="peter", GROUP="users"
 
peter@joule:/home/peter$ ls /dev/G*
/dev/GRNSD

Laptop machine.
peter@mebius:/home/peter$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 11 (bullseye)
Release:        11
Codename:       bullseye

peter@mebius:/home/peter$ uname -a
Linux mebius 5.10.0-10-686-pae #1 SMP Debian 5.10.84-1 (2021-12-08) i686 GNU/Linux

Pertinent lines in /etc/udev/rules.d/10-local.rules.
# The green Nexttech SDHC card.
KERNEL=="sd?1", ATTR{size}=="7434240", SYMLINK+="GRNSD", \
 OWNER="peter", GROUP="users"

peter@mebius:/home/peter$ ls /dev/G*
ls cannot access 'dev/G*': No such file or directory

-- 
mobile: +1 778 951 5147
  VoIP: +1 604 670 0140
   48.7693 N 123.3053 W

[toc] | [next] | [standalone]


#243478 — Re: udev applied to SDHC card. Two systems compared.

From"Alexander V. Makartsev" <avbetev@gmail.com>
Date2021-12-27 18:40 +0100
SubjectRe: udev applied to SDHC card. Two systems compared.
Message-ID<Dz28y-eA-5@gated-at.bofh.it>
In reply to#243472
On 27.12.2021 10:32, peter@easthope.ca wrote:
> Any ideas about why udev assigns a symlink on the desktop system and
> not on the Sharp Mebius laptop?
I think it is impossible to answer that question without actually 
looking at these systems.
Perhaps it is a problem of poorly written rule that doesn't take into 
account difference between host devices,
or a race condition of some sort between the rules.
It is always better to make udev rules to identify target devices properly.

Here is a little howto, where I will use my USB drive as an example:
1. Let's make a '.rules' file and make sure it will be processed last:
     $ sudo touch /etc/udev/rules.d/99-myusbdrive.rules

2. Now we have to see what properties and environment variables udev 
made available for us, and
choose among them the ones that will always identify our currently 
plugged in device (I've skipped some output):
     $ udevadm info /dev/sdc1
     ...
     E: ID_VENDOR=Kingston
     ...
     E: ID_MODEL=DT101_II
     ...
     E: ID_SERIAL_SHORT=001CC0EC0000F031C7E50990
     ...
     E: ID_FS_LABEL=KINGSTON
     ...
     E: ID_FS_UUID=000C-123F
     ...

3. Using this information we can now add to file "99-myusbdrive.rules" 
something like this:
# Rule for Kingston DT101_II to assign symlink and ACL.
#
ENV{ID_VENDOR}=="Kingston", ENV{ID_MODEL}=="DT101_II", \
ENV{ID_SERIAL_SHORT}=="001CC0EC0000F031C7E50990", \
ENV{ID_FS_UUID}=="000C-123F", \
SYMLINK+="personalusb", OWNER="alex", GROUP="alex"

4. Now let's reconnect the device and check if '.rules' file worked:
     $ ls -la /dev/personalusb
     lrwxrwxrwx 1 root root 4 Dec 27 19:57 /dev/personalusb -> sdc1
     $ ls -la /dev/sdc1
     brw-rw---- 1 alex alex 8, 33 Dec 27 19:57 /dev/sdc1

Feel free to adjust the rule to meet your goals.

-- 
With kindest regards, Alexander.

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

[toc] | [prev] | [next] | [standalone]


#243492 — Re: udev applied to SDHC card. Two systems compared.

Frompeter@easthope.ca
Date2021-12-28 22:40 +0100
SubjectRe: udev applied to SDHC card. Two systems compared.
Message-ID<Dzsml-7Nr-3@gated-at.bofh.it>
In reply to#243478
    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.

> ... 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.


-- 
mobile: +1 778 951 5147
  VoIP: +1 604 670 0140
   48.7693 N 123.3053 W

[toc] | [prev] | [next] | [standalone]


#243497 — Re: udev applied to SDHC card. Two systems compared.

From"Alexander V. Makartsev" <avbetev@gmail.com>
Date2021-12-29 00:10 +0100
SubjectRe: udev applied to SDHC card. Two systems compared.
Message-ID<DztLs-ka-5@gated-at.bofh.it>
In reply to#243492

[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
⠈⠳⣄⠀⠀⠀⠀

[toc] | [prev] | [next] | [standalone]


#243517 — Re: udev applied to SDHC card. Two systems compared.

Frompeter@easthope.ca
Date2021-12-29 20:30 +0100
SubjectRe: udev applied to SDHC card. Two systems compared.
Message-ID<DzMO5-3lO-3@gated-at.bofh.it>
In reply to#243497
    From: "Alexander V. Makartsev" <avbetev@gmail.com>
    Date: Wed, 29 Dec 2021 03:49:14 +0500
> 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?

Acknowledged.  In the desktop system, this works and avoids the 
possibility of another /dev/sd?1 of identical size.
KERNEL=="sd?1", ENV{ID_SERIAL_SHORT}=="0201202010201000", SYMLINK+="GRNSD", \
 OWNER="peter", GROUP="peter"

The same fails in the laptop system as the ATTR{size} variant failed.

> ... by naming your custom rule "99-*.rules" you will make it to be 
> processed last, effectively bypassing possible race condition between the rules.

Each of these systems has only one local.rules file.  Nevertheless 
I renamed to 99-local.rules.

> Systems could have different card-readers based on different controllers ...

For test purposes I use one USB-SD adapter moved between the two systrems.

> ... different usb hub devices.

The Sharp Mebius laptop also has a PC card (PCMCIA) SD adapter where 
the SD also fails to work.  But it works in the SD socket in a XO-1.5.  
All evidence is consistent with a failure limited to the Sharp laptop.

I should have mentioned earlier that in a previous Debian release the 
same SD card worked in the Sharp laptop just as in the desktop system.  
(Don't remember which release.)  A bug report may be justified.

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

Assuming English is your 2nd or 3rd or 4th language, your English is 
excellent.  A person learning English after their first language tends 
to learn the grammar systematically.  Whereas I learned grammar mostly 
by osmosis.  =8~|

Thanks,                            ... P.


-- 
mobile: +1 778 951 5147
  VoIP: +1 604 670 0140
   48.7693 N 123.3053 W

[toc] | [prev] | [next] | [standalone]


#243616

FromDavid Wright <deblis@lionunicorn.co.uk>
Date2022-01-03 05:30 +0100
Message-ID<DBn8R-3J9-1@gated-at.bofh.it>
In reply to#243472
On Sun 26 Dec 2021 at 21:32:20 (-0800), peter@easthope.ca wrote:
> Any ideas about why udev assigns a symlink on the desktop system and 
> not on the Sharp Mebius laptop?

Because the slots you're pushing them into are of a different type.

> Desktop machine.

> Pertinent lines in /etc/udev/rules.d/10-local.rules.
> # The green Nexttech SDHC card.
> KERNEL=="sd?1", ATTR{size}=="7434240", SYMLINK+="GRNSD", \
>  OWNER="peter", GROUP="users"

And you will find your partition named something like /dev/sdb1.

> peter@joule:/home/peter$ ls /dev/G*
> /dev/GRNSD
> 
> Laptop machine.

> Pertinent lines in /etc/udev/rules.d/10-local.rules.
> # The green Nexttech SDHC card.
> KERNEL=="sd?1", ATTR{size}=="7434240", SYMLINK+="GRNSD", \
>  OWNER="peter", GROUP="users"

Here, you'll probably find your partition named something like
/dev/mmcblk0p1, which does not match "sd?1".

> peter@mebius:/home/peter$ ls /dev/G*
> ls cannot access 'dev/G*': No such file or directory

See also my post about SD cards' IDs in the two cases:

https://lists.debian.org/debian-user/2022/01/msg00038.html

Cheers,
David.

[toc] | [prev] | [standalone]


Back to top | Article view | linux.debian.user


csiph-web