Forum Moderators: bakedjake
I just need something that will let me grab the hard disk serial number from the command line. I know the information is available in IOCTL but I don't really want to have to code a routine for it.
Thanks,
TJ
?
<edit> ignore - that is the ethernet address </edit>
[edited by: bcolflesh at 4:31 pm (utc) on Feb. 9, 2004]
Or did you mean the model number? Because dmesg will give you model numbers.
Mind you maybe I could use the MAC address instead.
Jake - no, it's the serial number. I'm looking for something reasonably unique that I can ID a machine by. I say reasonably, as it's for a (relatively) small group of PC's so liklihood of a doubled-ID would be remote. Needs to be no more than 4 bytes.
I'm wondering if I could take the first 4 bytes of a MAC address now.....
<Edit : bcolflesh - just seen your edit but actually I think you may have inadvertently given me a better idea anyway ;-)>
Thanks,
TJ
[edited by: trillianjedi at 4:37 pm (utc) on Feb. 9, 2004]
something reasonably unique
What about 15 bytes from /dev/random?
Problem with MAC addresses is that some network card vendors set the MAC addresses to be the same. That may be a non issue for you, but just thought I'd bring it up.
As far as serials - yeah, only IDE drives have hardware serial numbers. So throw that out if you have machines with SCSI drives.
You could concatenate the hostid and MAC addy.
Needs to be 4 bytes long as I need cross-compatability with Windows unfortunately (Win stores Hard Disk ID as a DWord).
First (or maybe last) 4 bytes of a MAC address are likely to be pretty unique though?
TJ
#> hdparm -i /dev/hda/dev/hda:
Model=Maxtor 52049H3, FwRev=JAC61HU0, SerialNo=F3H238ZC
Config={ Fixed }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=8
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=39102336
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 *mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5
AdvancedPM=yes: disabled (255) WriteCache=enabled
Drive conforms to: ATA/ATAPI-6 T13 1410D revision 0: 1 2 3 4 5 6#>
Getting the MAC address is probably easier.
Problem with MAC addresses is that some network card vendors set the MAC addresses to be the same.
That sounds very unlikely to me, because it would keep those cards from connecting to each other.
[edited by: bird at 4:48 pm (utc) on Feb. 9, 2004]
because it would keep those cards from connecting to each other.
Heh - That's exactly how I found out about it. ;-) D-Link was notorious for it several years ago.
So it seems MAC addy might not be unique either. I need to be able to grab this occasionally, so needs to be something static in the sense that a user couldn't change whatever it is I'm looking at.
CPU serial number would be ideal here, but Intel stopped doing those after the PIII......
Thanks Bird - your post perfectly answers the original question. But it seems that will only produce a serial nunber for an IDE disk and not SCSI?
TJ
[edited by: trillianjedi at 4:48 pm (utc) on Feb. 9, 2004]
First (or maybe last) 4 bytes of a MAC address are likely to be pretty unique though?
It's probable in the small setting you mentioned - sounds like you could check them all and find out pretty quick.
What happens in situations w/more than 1 drive per machine?
What happens in situations w/more than 1 drive per machine?
It wouldn't make any difference. Especially if I use the MAC addy ;-)
If you meant more than one NIC - I'll just be grabbing the first one, so shouldn't matter.
TJ
That *should* be relatively unique.
But I'd stick with the MAC addy too, if you know they've all got different addresses.
Well, but in this case you have more urgent problems than determining a unique ID for some software...
First (or maybe last) 4 bytes of a MAC address are likely to be pretty unique though?
A certain number of bits at the beginning of the MAC address specify the manufacturer, and are therefore quite likely to be the same for most machines in a local network. For the remaining bits the manufacturer is supposed to come up with unique values. Therefore, only the full thing is garanteed to be unique across manufacturers (ignoring any screwups).
What happens in situations w/more than 1 drive per machine?
The same that happens with more than one ethernet card: Pick the prettiest one! ;)
What about the creation time (17:44) of /bin (or whatever)?
That's a clever idea - hadn't thought of that one. If I could translate that to a t_time value (# of seconds since 1/1/1970), that would be pretty damn unique. And exactly 4 bytes long (unsigned int).
TJ
$ hostid
a8c00101
Works well enough for most unix licencing software...
Sean
$ hostid
Interestingly, the first two bytes of mine are the same as yours:-
hostid
a8c06400
What is the hostid exactly? Is it designed to be unique? Perhaps randomly genereated on install?
TJ
Is it designed to be unique?
No. Documented problems with it, in fact, and most major OS vendors are dropping it.
See: [mail.gnu.org...]
But I do like your time/date stamp of /bin - and I have just checked and can convert that to number of seconds since 1/1/1970 within a 4 byte time_t.
About as unique as I'll ever need. Not much liklihood of two users of this sytem having both installed linux at exactly the same moment in time on exactly the same date ;-)
TJ
PS This is not for software protection - just to ID a particular server. No major problems if two happen to have the same ID anyway as this ID is coupled with IP address as a secondary (dynamic IP related system, hence IP alone is not enough).
