Anyone have an idea if it would be a huge effort to get pxelinux to look for config files based on serial number (available in DMI on modern motherboards), much like we currently can use MAC address's. Lots of our hardware comes with the serial number stuck on the chassis but not the mac address. We'd like to move to pxelinux and still use the serial number as the key for figuring which config is to be used. For now I can have the system first boot a linux image that probes the hardware, posts the mac addr and serial number to a database that has the workload associated with the serial number. The database is then able to correlate both can trigger the creation of a pxelinux config file named after the mac addr associated with the serial number. But it would be nice to be able to do that in one step, rather than two. Thanks Scott
This what you looking for is the UUID. -----Original Message----- From: syslinux-bounces at zytor.com [mailto:syslinux-bounces at zytor.com] On Behalf Of Scott Mewett Sent: Friday, March 18, 2005 11:41 PM To: syslinux at zytor.com Subject: [syslinux] PXELinux and serial number Anyone have an idea if it would be a huge effort to get pxelinux to look for config files based on serial number (available in DMI on modern motherboards), much like we currently can use MAC address's. Lots of our hardware comes with the serial number stuck on the chassis but not the mac address. We'd like to move to pxelinux and still use the serial number as the key for figuring which config is to be used. For now I can have the system first boot a linux image that probes the hardware, posts the mac addr and serial number to a database that has the workload associated with the serial number. The database is then able to correlate both can trigger the creation of a pxelinux config file named after the mac addr associated with the serial number. But it would be nice to be able to do that in one step, rather than two. Thanks Scott _______________________________________________ SYSLINUX mailing list Submissions to SYSLINUX at zytor.com Unsubscribe or set options at: http://www.zytor.com/mailman/listinfo/syslinux Please do not send private replies to mailing list traffic.
You can basically cut and paste the code from dmi_scan.c (iirc) in linux to do the scan. The only somewhat hairy parts are that the DMI table can legally be anywhere in 32-bit address space, and need not be in e820 mapped memory. Wouldn't this be a good com32 extension? -- Michael> -----Original Message----- > From: syslinux-bounces at zytor.com > [mailto:syslinux-bounces at zytor.com] On Behalf Of H. Peter Anvin > Sent: Friday, March 18, 2005 8:06 PM > To: Scott Mewett > Cc: syslinux at zytor.com > Subject: Re: [syslinux] PXELinux and serial number > > > Scott Mewett wrote: > > > > What do you think? > > > > Slight correction... it allows 32-bit memory addresses so it > has to be > done in protected mode. However, pxelinux already contains > the code to > jump into and out of protected mode, so it's not a big deal. > > -hpa > > _______________________________________________ > SYSLINUX mailing list > Submissions to SYSLINUX at zytor.com > Unsubscribe or set options at: > http://www.zytor.com/mailman/listinfo/syslinux > Please do not send private replies to mailing list traffic. >
I built an (unreleased, non-oss) identical thing to what you describe below for internal use here a while back. It isn't that hard. I would say that you don't even need PXElinux support to get the serial number. What my system did is boot the system into a stripped-down Linux that grabbed the system serial number and applicable hardware config, then registered itself with a master server. At this point, the master server knows the MAC address and can set up PXElinux config files based on MAC address. -- Michael> -----Original Message----- > From: syslinux-bounces at zytor.com > [mailto:syslinux-bounces at zytor.com] On Behalf Of Scott Mewett > Sent: Friday, March 18, 2005 10:18 PM > To: H. Peter Anvin > Cc: syslinux at zytor.com > Subject: Re: [syslinux] PXELinux and serial number > > > Very cool. > > Were in the design stage of our project right now. I should > know in the next few weeks if it gets approved to build out a > working concept. If that happens then I'll try and get some > hardware or $$ donation for your effort. > > The general idea of the project is to build a managed pxe > system. External applications would register with a database > backed system to setup boot choices for a particular serial > number. The backend system would control the creation of the > tftp config files for pxelinux. For example a sysadmin would > go through a web page and create a profile for a server to be > kickstarted. The backend would create an appropriate pxelinux > config file for that serial number or mac address. The the > server would pxe boot using the config for that server. > > For that scenario you don't need a back end db, but we want > to expand it way beyond that, so that you can boot systems > for example without a config, go to a web page to show > unprovisioned servers and then create your config from there. > Once you finish your config on the web page the system would > take care of rebooting the box automatically so that the > install could start. We are also thinking of having systems > always pxe boot, even though the system may tell it to boot > of the hard disk. There may also be systems that will boot > and run over the network without using an OS on a hard disk. > We want all that controlled by the db backend. All of the > config files in the tftpboot dir could be recreated at will > using the data in the db. > > There are commercial systems that do some of this. But none > that really do everything we want or are too closed a system > to expand and do additional things. > > Is anyone aware of any open source systems that already do > some of this? Sorry if this is a little of topic. But since I > want to base it on pxelinux, I figured this would be a good > audience to bring it up with. > > It is my intention, if I get support from my employer, to > open source this system as well. I've been successful with > that on a couple other project I've done. > > Needless to say, pxelinux rocks. :-) > > Thanks > Scott > > > On Fri, 2005-03-18 at 18:03 -0800, H. Peter Anvin wrote: > > Scott Mewett wrote: > > > > > > Since there is only the serial number that we are looking > for, being > > > able to read all the table structures would not be necessary. > > > > > > What do you think? > > > > > > > Doesn't look too bad. Find the _DMI_ header in the BIOS ROM area, > > then > > it's just a linked list of tables, and the serial number is > in table 1. > > Get the index, and scan past the requisite number of > nulls, to find > > the appropriate string; if there is no _DMI_ header, if > table 1 doesn't > > exist or is less than 8 bytes long, the string number is zero, or > > finding double-null during the scan is an error, meaning no data is > > available. > > > > This should be doable. > > > > -hpa > > _______________________________________________ > SYSLINUX mailing list > Submissions to SYSLINUX at zytor.com > Unsubscribe or set options at: > http://www.zytor.com/mailman/listinfo/syslinux > Please do not send private replies to mailing list traffic. >
I am interested in the same thing, and noticed that someone on the list may have already done what we are discussing; I sent Markus a note so hopefully he gets back to us. Huber Markus huber at hsn.at <mailto:syslinux%40zytor.com?Subject=%5Bsyslinux%5D%20pxelinux%3B%20Service% 20Tag&In-Reply-To=> Fri Feb 13 22:45:48 PST 2004> I have now implemented the possiblity to load the > pxelinux boot configuration by using the Serial > Number (or Dell Service Tag)-> I use the smbios > functionality to retrieve the value!> I would be happy, if thing part of my software > could be integrated in the standard pxelinux distribution.> Is somebody interested, or whom should i contact for this issue?> lg> MarkusCONFIDENTIALITY NOTICE ======================This email message and any attachments are for the exclusive use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message along with any attachments, from your computer system. If you are the intended recipient, please be advised that the content of this message is subject to access, review and disclosure by the sender's Email System Administrator.