Here’s a quick way to get the service tag (serial number) of a Dell server remotely.
root@vmhost:~# dmidecode | grep "Serial Number" | head -n1
Serial Number: DJ6GH3H
sharp little beasties
Here’s a quick way to get the service tag (serial number) of a Dell server remotely.
root@vmhost:~# dmidecode | grep "Serial Number" | head -n1
Serial Number: DJ6GH3H
Yesterday I got an emergency call to fix a RHEL5 system that had taken a dive. The system was not booting and the sotware RAID1 containing the root filesystem had split.
I added the failed disk back into the RAID to see if it was really broken, or if it was just a gremlin. (This all happened after a massive storm).
Once the mirror started rebuilding the kernel began to spew out a continuous stream of these:
Mar 11 13:18:07 sparkus kernel: hdc: status timeout: status=0xd0 { Busy }
Mar 11 13:18:07 sparkus kernel: ide: failed opcode was: unknown
Mar 11 13:18:07 sparkus kernel: hdc: no DRQ after issuing MULTWRITE
Mar 11 13:18:07 sparkus kernel: ide1: reset: success
I thought “OK, that disk really is dead”. But I was wrong.
A bit of Googling suggested that “MULTWRITE” is a command unique to IDE disks, but this disk was SATA. It was also suspicious that the disk was mapped as “hdc”, not “sdc” where I would expect a SATA disk to appear on a modern kernel.
It turns out that the BIOS was set to present the SATA disks in “legacy mode”. Translation: “lie to the operating system and tell it the disks are IDE, even though they aren’t“.
I flipped the BIOS to show the disks as native SATA and brought the system back up. The disks mapped to “/dev/sdx“, the mirror started rebuilding with better throughput than before and the kernel errors ceased.
So folks, don’t let your BIOS lie to your kernel… unless you really need to.
OSX can do everything I want from day to day, but occasionally I want to play some San Andreas. Bootcamp and Windows should have had me playing Windows games on the Mac. Sadly, Bootcamp refused to partition my internal disk so I was stuck with no Windows and no San Andreas.
A ray of hope was the idea of installing Windows onto a blank external disk. Windows is not supposed to run from an external disk but it has been done before. The brave souls who made this work in the past still needed to re-partition their disk with Bootcamp though, something that wasn’t an option for me.
It turns out that it is possible to install Windows to a USB disk without using Bootcamp at all. Here’s the recipe:
This is the process I used. Step two is a pretty complex sub-procedure. It was produced by some serious Windows Wizards and is the core of what we are doing here. The rest is easy, these guys are good.
Now you are running Windows from the USB drive.
At this point, I must confess that I cheated. I did install the Bootcamp drivers into my XP install and I believe there is a serious trap here. The Bootcamp driver set contains drivers for the Intel USB controller, which it naturally tries to install. It pops up an uncertified driver warning before installing them. I told it not to install the USB drivers, since the entire operating system was hanging off that device. Replacing the drivers at that point seemed like a very bad idea to me.