Redundant Array of Incompatible Disks

Some of you may or may not have heard of the new Indilinx based SSD drives. These MLC based SSDs are quite attractive in terms of pricing, and best of all no longer have the stuttering problems that were present in older non-intel MLC drives.

Probably the most well known of these knew SSD drives is the OCZ Vertex. Partially the reason for this success is the Anandtech article that profiles some of the inner workings behind how these OCZ drives came to be, but more particularly these drives are fast and (relatively) inexpensive. A plethora of benchmarks are available.

But obviously I'm not just here to extol the virtues of this drive - that's hardly the point of this blog. Verily, I offer you a darker side that is not discussed widely in the reviews that you read. I speak none other than the RAID support for the drive. If you look on the spec page for it, you'll find on the left that there is an apparent "RAID Support". While the deeper semantic discussion (read: ranting) of what that is supposed to constitute for drives in general are beyond this post, let us discuss it as relevant to this particular drive.

You see, it apparently means software RAID ONLY. As some denizens of the OCZ discussion forums have discovered, and I confirmed, getting the new Indilinx drives to work under apparently any hardware raid controller is an exercise in futility. You don't really even have to add it to a RAID volume - it simply needs to be connected to start flapping and spewing SCSI errors. There is no fix, and the only workaround that I found to work is to use a SAS expander.

In comparison, the Intel SSDs of both SLC and MLC varieties are well supported under hardware RAID, playing nice with most if not all configurations. So why the disparity? Is the problem with the firmware or (worse) with the Indilinx controller? More importantly, why market a "feature" that is basically not present? We just don't know. All we can do is wait and hope for it to be fixed, if it can be fixed.

In the meantime, there are some rather unhappy high-end users, a small portion of the user base, but a vocal one. More importantly, this makes the Indilinx drives unusable for enterprise RAID applications, delegating them instead to a more suitable role of hosting operating system volumes and the like. If the companies using these controllers want into that market, they'd better start cracking.

More 2008 unattended woes

So as some may know, it's possible to present Windows updates (security hotfixes, etc) to the unattended setup in the windowsPE stage. Just open up your WSIM, go to Insert, and then Packages, and point to the folder containing your update cabs. Fix the xml file later to point to the actual network paths where those files will be at during the installation.

Problem: The install takes something around half an hour longer to install ~150MB of updates over a gigabit link. With the /tempdrive switch. WTF? Well, still better than integrating them into the install.wim... which doesn't work. I'll have to try to install them in post, which I have yet to succeed in.

Drivers can be presented in a similar manner, by using Microsoft-Windows-PnpCustomizationsWinPE/DriverPaths. Put your RAID drivers and whatever other drivers you need here.

Problem: The install failed back to the WinPE cmd prompt whenever I presented a path for the Intel Chipset drivers, with the entire network mapping becoming broken and requiring a reboot. After some poking and prodding, and looking at the full debug SAMBA logs, I noticed that it was mainly complaining about one file - 5400.inf. "Hmm, that's the same chipset that I'm using...", thought I. Apparently, Windows installs that chipset driver, which causes some sort of a reinitialization of the networking stack, causing the whole thing to fail horribly. Sigh. Chipset drivers go in postinstall. Unfortunately, the "unattended" setup for the drivers in question provides a nice dialog box to the effect of "everything was aok" on which you need to click to continue. /facepalm

Next up on the fail roll call is a nice error from stage 2 of the 2008 unattended installation process (after the first reboot): "Windows Setup encountered an internal error while loading or searching for an unattend answer file." This gem which produces no output whatsoever in setuperr.log. After a lot of trial and error, this was narrowed down to a setting the gateway on one of the network interfaces. Did I mention that the unattended parameters for that are completely unintuitive? "NextHopAddress"? "Prefix"? Sigh.

What the deuce, Microsoft?

The most recent exclamation of that sort has arisen from the SNMP unattended configuration in Windows 2008. You see, configuring unattended SNMP settings in Windows 2003 was a fairly simple outpatient procedure, mostly documented in this somewhat old but for the most part still valid Microsoft KB. Personally, I found it too wordy for my tastes, and much rather read this file on an IBM website I found by chance while googling. Imagine that - nice documentation that is not from Microsoft on a Microsoft product¹. Oh, and being only able to put 3 hosts in the "Limit_Host" section does not apply to 2003. But I digress.

Getting back to the the topic at hand, I was building the SNMP unattended section for Windows 2008, when I encountered this: "You can configure only a single host with the A1 setting. Adding multiple hosts is not supported."

Adding multiple hosts is not supported.

Hwaht?! You took away a perfectly reasonable feature that was present in the unattend file of previous versions of Windows...why? Why must you do this to me Microsoft?²

P. S. Did I mention that I actually thought that doing unattended Windows 2008 would be simpler than unattended Windows 2003, because of the nicely documented and laid out Windows System Image Manager? I should have known better.


1. This is of course completely typical; most of the obscure Microsoft stuff can only be found in non-Microsoft places, with this exception.
2. Because it hates you and everything that you stand for. But we all knew that.

Fun with nLite and driver integration

For those of you who use nLite to integrate drivers, especially textmode drivers, you may have noticed that the the source folder grows every time you do this. Well, there is in fact a reason for that.

nLite creates a NLDRV folder under your I386/AMD64 directory, with incrementing sub-directories containing the actual drivers. I say incrementing, because every time you run nLite, even with exactly the same drivers, it adds them to those that were already there in NLDRV. While not particularly installation-breaking, it still causes a nice mess over multiple passes. "Ew", I thought. "Driver file mess? In MY WINDOWS SOURCES? It's more likely than you think." The brief thought of creating a new source every single time was dismissed immediately as too time consuming. So, it was time to hack away at it.

Looking at the overall changed files in the I386/AMD64 directory after the nLite run, a certain pattern emerged. The main things that changed was obviously the NLDRV folder, but also a number of INF files that serve as indexes for that folder, amongst other things. If I were to back those up in their original state, and then replace them, along with deleting the NLDRV folder, nLite would be none the wiser, and create a fresh driver structure.

After checking that the main inf files in question were not present on the service pack installation files, I reached for the original disks, and extracted the original inf files, overwriting the ones bloated by nLite, and deleting the NLDRV folder. After making a pass with nLite, I started an installation using the renewed sources, which promptly bombed with numerous missing file errors. Questions raced in my head "What did I do wrong? Why does the universe hate me? How many kittens does it take to compile a light bulb?"

I started over on a fresh install, unto which I slipstreamed the service pack. Checking for files changed by the service pack, the inf files were among them. ASDF. Apparently service packs update them using some method other than just overwriting. Right then. Time for another go. This time I was careful to overdo it, and backed up all inf files changed by the service pack, which made up my "backup". Of those, 8 files for I386, and 10 files for AMD64 made the cut as those that would be overwriting nLite's changes when driver updates would be needed.

Finally, after testing this method, it worked. A quick batch file for I386 is presented below for your convenience:

@echo off
echo Warning: About to remove integrated drivers from this nLite source!
pause

RD /S /Q .\I386\NLDRV
COPY /Y .\Clean\* .\I386\

echo Running nlite
"C:\Program Files\nLite\nlite.exe"

I keep this file in the root of the Windows source. You can also add some nlite.exe switches to, say, load the last preset automatically. The Clean folder contains the following files (remember, from an unmodified slipstreamed source):

DOSNET.INF
HIVECLS.INF
HIVEDEF.INF
HIVESFT.INF
HIVESYS.INF
INTL.INF
SETUPREG.HIV
TXTSETUP.SIF

For 64 bit, there's also HIVCLS32.INF and HIVSFT32.INF. Ultimately, I believe that only two files really need to be in the list, TXTSETUP.SIF and DOSNET.INF. But I'm feeling too lazy to triple check that far, especially since it would only shave exactly 0.0000288 seconds (calculated in my head, I'm THAT GOOD) off of the batch copy. This works to give me fresh and clean driver integration, and that's enough for the time being.

So regarding those spirals into madness...

At the insistence and urging of my coworkers, I will attempt to detail in this space (Collective groaning at yet another useless blog) some of the more interesting (Read: Wrist slashing material) technological exploits and challenges that I run into on professional and personal basis.

It is my hope that the readers will derive at least some modicum of insight from some of the topics that will (eventually) be posted (maybe), as they will typically be of reasonably obscure and bizarre issues with equally obscure solutions. At the very least, I fall back on the second hope that the readers will be amused by some of the absurdity that happens in the wondrous world of technology, and how I attempt to deal with it without incurring sanity loss.

Me? I'm just some guy that has a job that lets him play with latest hardware and software for a living. Somehow this isn't always (some of the time (almost never)) as exciting as it sounds, as you will no doubt find out in due course.

Strap yourself in - crashes are to be expected and welcomed with open arms, flowers, and keys to the server room.