ralda at gmx.de
Fri May 6 22:03:25 UTC 2011
> Hey Harald. I'm familiar with UUID's, but that's not what I'm looking
> for. Serial numbers are strings of characters that manufacturers use
> to identify an exact, specific part or product (unlike a model number,
> for example, which gives an ID to a group of products).
Product serial numbers! ... sorry, your question was really misleading.
As far as I know, it is a mess to find a reliable way for extraction of
product serial numbers. It may even be difficult to obtain such numbers
between different devises of same type (like two PATA drives). On
devices from one manufacturer it may work, on an even newer device from
a different manufacturer it gives no or random values ... and don't
expect product serial number extraction to work on different kernel
... only USB storage devices (mostly flash based), seem to have reliable
product serial numbers.
> For instance, Dell uses a serial number for each computer they sell ...
I know product serial numbers ... but you need to tell, you are looking
for that kind of information.
> These are unique to every single piece of equipment so no two products
> of the same model or manufacturer will have the same one.
True ... but not every device allows reliable extraction of that number.
You (as a human) can read that number on the label, but is your computer
able to read that information in a way compatible with products from
other manufacturers. This even is not always true on different products
from the same manufacturer/brand.
> This string is available under /proc in various locations (as I've
> found out) and can be "encrypted" at times.
Different kernels try to extract as much information from the devices as
possible, but is this information reliable? I found it to be not
reliable, especially on changing kernel versions. It seems this is due
to missing standards on how such information is encoded on the devices.
A human may easily detect such information, but are there standardized
algorithms to extract such information for computer usage in a reliable way?
> hdparm can acquire this information as well,
Somewhere within textual information from the drives.
> but it only seems to work under certain conditions, so I can't use
> that reliably.
That's why it is normally not used for device identification.
> Other distro's use the serial number in their naming conventions
> (Debian based distro's use /dev/disk/by-id/...) so I know it's
> possible, ...
I do no more use Debian based distro's, but the ones I looked on, used
the UUID as "by-id" ... hence I assumed you are looking for the UUID
feature ... but may be your assumption is based on a flaw in the UUID
system/blkid ... in cases blkid can't reliably extract an partition
UUID, it tries to create an UUID from different information sources ...
but this information varies between kernel versions, which results on
different blkid results for the same device.
> I'm just at a loss of how to get this information with mdev. I would
> have figured that mdev would pass this as a variable value since it
> does so for Vendor, Model, etc.
If there would be a reliable product serial number, independent of
different kernel versions, mdev could propagate that information, I
think. It doesn't do this, as there is no simple reliable way to obtain
> Also, if you're interested in seeing a serial number, plug in a newer
> USB hard drive and look at its corresponding file under
Not every kernel and not every system has that information. I even heard
rumors about /proc/scsi informations (at least usb ones) are obsolete.
Such informations shall be placed under /sys ... so which kernel
versions do you use. Neither one of 5 systems here has
/proc/scsi/usb-storage. Not even my notebook, which runs one of the
newest kernel version (does nearly follow the last stable kernel branch).
> Depending on the drive caddy used, this value may or may not show up
> (which is why I was going to default to another set of info in its
> absence). The contents of the /proc/scsi/scsi (not /proc/scsi)
> contain various bits of info as well, but I've never seen it contain a
> serial number.
That is why mdev doesn't try to propagate such information ... it is not
reliable. As this it won't be used by many users which would lead to add
big overhead for obtaining and propagating unused information ... not
the way I would like it ... and not the Busybox way (as far I understand
If you like to name devices based on such information, let mdev run a
script of yours, pick up the information you like from /proc or /sys and
create your link to the device. What's wrong with that? mdev allows
running standard shell scripts. From there you can access all of /proc
and /sys ... but your script may need fixing whenever you have a change
in kernel version, or on unusual products from different device
> Does anyone know if there was a reason why the serial number wasn't
> included as part of the environment passed by mdev?
See above, as my assumption to that question. Try to find out a reliable
way to obtain that information from the kernel (different versions, not
only on a single installation, different drive types/buses, different
manufactures) and tell about that. So the mdev maintainer (or somebody
else) may be able to add that feature to mdev. Despite decision if that
information is widely used and legitimate the extra resource consumption.
... or in other words: The kernel lacks to present that information in a
reliable way to applications. IMHO you may/should go and ask the kernel
guys for such a reliable way (will be interesting to here what they tell
about that topic).
More information about the busybox