Serial Number

David Henderson dhenderson at digital-pipe.com
Sat May 7 19:25:55 UTC 2011


On 05/06/2011 06:03 PM, Harald Becker wrote:
>   Hallo David!
>
>> 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
> versions.
>
> ... 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
> that information.
>
>> Also, if you're interested in seeing a serial number, plug in a newer
>> USB hard drive and look at its corresponding file under
>> /proc/scsi/usb-storage.
> 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
> that).
>
> 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
> manufacturers.
>
>> 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).
>
> --
> Harald
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://lists.busybox.net/mailman/listinfo/busybox

Hey Harald, thanks again for the continued help.    I'm not quite sure 
how else I could have specified I was looking for a way to obtain serial 
numbers other than saying "I'm looking for a way to obtain serial 
numbers". ;)

Based on package updates, I'd say that if there's that much frequent 
change to drive detection between each kernel release, things would 
grind to a halt.  For example, if the serial number detection was as 
problematic as specified above, I'd have to get new versions of udev 
everytime I upgraded to a new kernel (which isn't the case) just to be 
able to have a usable system.  There has to be a way to obtain this 
information from either proc or sys.  As specified in earlier replies, 
this currently works without problems in mainstream distro's, so I know 
it's possible - it's just unfortunate that they use udev and not mdev so 
I can see how. :)

Currently I am using my own script with mdev since it provides for much 
more flexibility in how devices get added to the system.  The 
information that does get passed by mdev's environment is very handy and 
it appears the only valuable piece of info needed but isn't included is 
just the serial number.

That's interesting that your computers don't have a /proc/scsi/scsi file 
or /proc/scsi/usb-storage directory.  Every system I have running in my 
house (4 total) has those items and their kernel versions range from 
several many releases back up to one of the newest.  What distro(s) are 
you using?

Dave


More information about the busybox mailing list