How hard is it to set the service tag on a Dell motherboard?

Dell is a weird, weird place. A little while ago we had a server with a bad motherboard, one of the 5-volt lines was out of whack. No big deal, we’d just get a replacement part and swap it out (getting a Dell technician into Globalswitch datacentre is more hassle than it’s worth).

Our datacentre monkeytechnician replaced the motherboard without incident, but they did notice that there was now no service tag attached to the motherboard. This isn’t a problem, but it means the DRAC card can’t report its identity properly. We asked Dell for advice on writing the service tag to the new hardware, and they promised to send through details.

That evening we received two emails from two different Dell support staff, each with very different instructions on how to get the job done. Odd to say the least, but here goes.

Charlie attached a little utility called ASSET to the email. They’d decided it needed to be zipped up and password-protected (“the password is dell“). We soon understood why: inside was a little 10KiB .COM binary that a corporate virus scanner would probably flag as malicious. Understandable, but what are we going to do with a DOS executable?

First decompress the file to a bootable USB flashdrive. The utility must boot to DOS to make this work.

No. No no no no no, no. We are not going to scrounge up a DOS boot environment and schedule more downtime for the server. There has to be a better way.

Let’s try Arun’s method.

  1. Please download the Dell OMSA LiveCD and Users Guide from the following locations
  2. Once the ISO is loaded and you are in the GUI, launch a Terminal Session and cd to /root
  3. Then you can execute ./serviceTag -set 'servicetag'

Hang on, hang on, this is just an Ubuntu live CD with a bunch of Dell tools! And we’re still not going to take the server down so we can run some simple tool binaries. *sigh* At least we can extract the tools and call them directly, but it would’ve been nice if they just said so. Seriously, we would’ve even downloaded some arbitrary Java jarfile and run that if you asked us to. Instead, we’re supposed to download a 650MiB ISO, burn that to CD, then boot the disc to get at some utility that’s probably 20KiB in size.

That’s silly, we had a better idea: We loop-mounted the ISO and managed to unpack the fiddly SquashFS image that refused to directly mount on our workstation. A little poking around got us the serviceTag utility.

Now that we’ve got the utility, let’s see what its dependencies are once it’s out of the live CD environment:

[email protected]:~# ldd serviceTag =>  (0xf773f000) => not found => /usr/lib32/ (0xf7635000) => /lib32/ (0xf760b000) => /usr/lib32/ (0xf75ed000) => /lib32/ (0xf7473000)
     /lib/ (0xf7740000)

It looks like we’re missing libsmbios, what’s that? Google says, “The SMBIOS Specification addresses how motherboard and system vendors present management information about their products in a standard format by extending the BIOS interface on x86 architecture systems.” That almost sounds like a standard tool.

We dutifully installed the package for libsmbios and decided to try it out on a laptop to make sure it wouldn’t try to reboot the server or anything weird.

[email protected]:~# ./serviceTag
Existing Service Tag: LRBWGTZ

WTF, this is a Lenovo laptop! We returned to the oracle and begged for mercy, “Oh Great and Wise Googles, we implore you, what is the dealy-hoo with this serviceTag utility?”

It turns out that serviceTag is in fact a standard tool. It’s even packaged for Debian, and Redhat under a different name. You can install it for yourself and see your service tag on any piece of hardware.

To be fair, we can totally appreciate that Dell needs standardised solutions to customers’ problems, but the fact that neither of the suggestions were suitable for a live system is mindboggling, neither Windows nor Linux. That’s not how you maintain an SLA. Anchor is very proud of the fact that all our support staff are technical people, we just wish we could see that everywhere.