Crossflashing an IBM M1015 RAID controller to IT firmware

Note: This stuff worked for me. If you’re afraid you’ll brick your card, maybe you should just stick with the default firmware.

I just bought an IBM M1015 RAID controller for my ZFS server, as the old Intel SASUC8I did not support drives bigger than 2 TB. This IBM controller is usually available really cheaply on ebay.

It comes with a fairly basic RAID firmware that’ll do mirrors or stripes, but no RAID5. Supposedly, it should hand off non-raid drives transparently to the OS, but i wanted to load the LSI IT firmware that turns it into a dumb HBA instead. This is my process.

You’ll need the megarec and sas2flsh tools, the newest firmware for the LSI 9211-8I chipset and a DOS bootable USB stick.

The good people at http://www.servethehome.com/ibm-serveraid-m1015-part-4/ have created a .zip file with most of what you need, namely megacli.exe, megarec.exe, sbrempty.bin and sas2flsh.exe. You can get the latest firmware from http://www.lsi.com/support/Pages/download-search.aspx by searching for the “Host Bus Adapter” 9211-8I, which should get you 2118it.bin. You may want to grab Installer_P15_for_UEFI.zip while you’re there, if you’re using a UEFI based motherboard. More about that one later.

VERY IMPORTANT (i think): Before you touch the controller, you have to note the SAS address of the card. You can do this by looking at a label on the card or you can find it with the following command: megacli -AdpAllInfo -aAll

Somewhere a little down the wall of text you’ll see something like: HW Configuration ================ SAS Address : 500605b0046c5b90

Note this address for a few steps down the line.

When you boot off the USB stick, you first have to wipe the flash memory of the controller with the following commands: megarec -writesbr 0 sbrempty.bin megarec -cleanflash 0

After that you reboot and boot back on the USB stick.

To load the actual firmware, you run these commands: sas2flsh -o -f 2118it.bin -b mptsas2.rom (You can omit the “-b mptsas2.rom” if you’re not going to boot from the controller and the computer will boot a bit faster) sas2flsh -o -sasadd 500605b0046c5b90 (replace this address with what you got from megacli earlier)

Now, the fun part for those with UEFI motherboards. If sas2flsh reports “ERROR: Failed to initialize PAL. Exiting program.” when you try to flash the card, it is unable to do this from DOS. You have to get a UEFI shell (https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/EdkShellBinPkg/FullShell/X64/Shell_Full.efi worked for me on my 64 bit CPU) and put it on your usb stick. Then you have to load that shell, which on my Asus board was done by entering the BIOS settings, going into advanced mode, then from the exit menu loading the shell.

Once you’ve figured that out, you load the firmware in almost the same way as from DOS. First you have to change to the directory the files are in, in my case with the command “fs0:”. Then, the commands are: sas2flash.efi -o -f 2118it.bin -b mptsas2.rom sas2flash.efi -o -sasadd 500605b0046c5b90 (replace this address with what you got from megacli earlier)

If all goes well, when you reboot the card should report something like “LSI2008-IT” during startup.

SSH X-forwarding doesn't set the DISPLAY variable

I’ve just wasted quite a bit of time debugging a problem and google is less than helpful with the search terms i used. Here’s hoping this will attract it - and at least i’ll be able to find it myself :)

If you try to “ssh -X” and the remote end doesn’t set $DISPLAY, it’s probably because you’re missing xauth on the server.

Using Time Machine over iSCSI to a FreeBSD server

I’ve been using this solution since the time 8.0-RELEASE was still just a wet dream and other than the lack of the recover-during-install option from a local drive, it’s been rock solid.

Install the net/iscsi_target port. Enable it in rc.conf.

echo iscsi_target_enable="YES" » /etc/rc.conf

Edit the configuration to share a new device. My /usr/local/etc/iscsi/targets looks as follows:

extents file start length

extent0 /iscsi/iscsi-target0 0 320GB

target flags storage netmask

target0 rw extent0 10.1.2.3/32 The target file will be a sparse file, taking up no space and sucking up disk space as you write to it. Make sure you have the space available.

(Re)start the iscsi daemon.

/usr/local/etc/rc.d/iscsi_target start

Install globalSAN iSCSI Initiator for OS X. Configure the initiator on your Mac. System Preferences -> globalSAN iSCSI Under “Portals”, add your server using the default port number. Under “Targets”, mark the target it found for you and hit “Log on…” A prompt should come up saying you just connected a drive and that it’s not readable. Partition it however you want. I just used “Erase” and the default settings. Asking it to completely erase the device will fill your nice small sparse file, so only do that if you want it to take up all of the space. Head over to the Time Machine option in System Preferences, choose your shiny new drive and start going. This has been tested with FreeBSD 8.0-CURRENT, iscsi_target 20080207, OSX 10.5.4 and globalSAN iSCSI Initiator 3.3.0.43. iscsi_target is not bound to the kernel, so this should work just fine with anything that uses the netbsd iscsi_target code.

Update: If you get "target.c:1317: ***ERROR*** iscsi_write_data_decap() failed" and the backup fails it means that you've used GlobalSAN version 4.0.0.203 - downgrade to version 3.3.0.43 and everything should work"

Update 2: globalSAN doesn’t make a Lion/Mountain Lion compatible initiator. Boo.

Fixing the ZFS ashift problem on FreeBSD

As you’re probably aware (since you’re reading this), some of the new hard drives with “Advanced Format” lie about their sector size and thus the partitioning and/or file systems end up unaligned with the disk and performance suffers. Boo, Western Digital. You guys are worse than Hitler. But, since the WD20EARS was cheap and i didn’t think anyone would design something so stupid, i bought it.

Ofcourse, ZFS is smart enough to use the larger sector size through the “ashift” setting, but only if it actually knows the sector size of the drive. This option is set at pool (or rather VDEV) creation and can’t be changed.

The easy way around this is to use gnop to prevent the drive from lying.

zpool create tank raidz ada0 ada1 ada2

# zdb | grep ashift ashift: 9 Oe noes! 2^9 is 512, the wrong sector size. Let’s try that again.

zpool destroy tank

# gnop create -S 4096 ada0 # zpool create tank raidz ada0.nop ada1 ada2 # zdb | grep ashift ashift: 12 Woohoo! 2^12 is 4096, as it should be. Note that you only need to tag one of the drives. zpool is clever enough to use the largest size of them all. Also note that you need to do this every time you add a new VDEV, otherwise you’ll have varying ashift values within your pool. Only problem now is that the drive list is a bit ugly, but that’s easily fixed.

zpool status

pool: tank state: ONLINE scan: none requested config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 raidz1-0 ONLINE 0 0 0 ada0.nop ONLINE 0 0 0 ada1 ONLINE 0 0 0 ada2 ONLINE 0 0 0 # zpool export tank # gnop destroy ada0.nop # zpool import tank # zpool status pool: tank state: ONLINE scan: none requested config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 raidz1-0 ONLINE 0 0 0 ada0 ONLINE 0 0 0 ada1 ONLINE 0 0 0 ada2 ONLINE 0 0 0 There we go. Destroying the gnop node just removes the sector size override, the data is safe and sound. You’ve now got ashift set right without fiddling with patches and such.