I had a server running Windows 2003 that resided on a RAID5 array formed by Promise FastTrak SX4100, which I thought was hardware-based because of its dedicated processor and buffer memory and its ability to boot DOS and Windows. As it turns out, however, that controller is only hardware-assisted, with higher level logic carried out by x86 firmware running on host processor. Now that the aged motherboard (or processor?) has died, and I tried to migrate to a more modern UEFI-oriented hardware, the RAID controller cannot initialize even in legacy (BIOS) mode — it hangs when scanning disks, i. e. its firmware receives the control from UEFI/BIOS and prints welcoming messages on screen, but makes no progress in identifying connected SATA drives.

Therefore I thought I may have better luck running Windows inside a virtual machine with PCI card passed through to it, the more so that NT 5.2 is unlikely to be compatible with modern chipsets, while Qemu provides totally comfortable emulated environment in classic BIOS mode. The problem, however, is that SeaBIOS does not list the RAID controller as a bootable device, despite being able to communicate with it successfully.

That is:

The controller firmware does receive control and is able to initialize the RAID array before the boot menu is displayed by SeaBIOS, however that menu lacks any mention of the array disk.

The array configuration utility that can be invoked during POST process clearly shows that the array is healthy.

When Windows installer is run and loaded with RAID drivers, it also clearly displays the disk contents, proving its availability.

In other words, the array seems totally operational inside the VM environment, but for some season not recognized by SeaBIOS as a bootable device, although the later does support PCI devices for Boot ROM option, as is evident with iPXE network boot ROM built into SeaBIOS itself.

I also had an idea that GRUB may be of any help here, i. e. booting from SeaBIOS into GRUB (on a small separate disk) and then chain-loading to Windows. However I was not very successful at configuring it, since Linux environments do not see the array due to the lack of drivers and thus cannot assist with menu creation, yet GRUB itself is not too friendly nor verbose — I could not even understand whether it actually sees the array as a disk drive, or needs some drivers to be loaded beforehand, or any other prerequisites. Rescue kits like RescaTux or PartedMagic are not helpful either, since they are focused on repairing existing GRUB installations — not setting up new ones.

For reference, I experimented with Xen 4.7.2 using upstream Qemu 2.6.2 with SeaBIOS 1.9.1, on top of openSUSE 42.2 with Linux 4.4.62. Forums and mailing lists indicate that booting from PCI RAID was already possible in much older versions, for over a decade, so I assume that it is my particular setup to blame. But I cannot understand, is SeaBIOS indeed capable of booting from my RAID controller?

The ultimate goal is to get the server back by any means available, including by acquiring another compatible old hardware. But I just got curious with this specific technology, as virtual machines seemed more versatile and future-proof method of prolonging the life of legacy systems.

@MikhailKhirgiy That is Gigabyte H110-D3 (identified as H110-D3-CF in DMI) with firmware version F1 dated 2015-11-10; there was a couple of updates released since then, but none of them mentions any issues related to PCI. What makes you think the motherboard may be the one causing trouble?
– Anton SamsonovJun 4 '17 at 15:04

@MikhailKhirgiy That is exactly that I have already tried. Legacy only is the only mode that makes it possible to run real-mode ROMs; in default mode, the controller firmware does not receive control at all. However, as I said, the controller hangs during disk scan, which in turn blocks all further activity, — i. e. it is impossible to enter RAID configuration utility, impossible to enter UEFI/BIOS setup, impossible to proceed with system boot. Simply put, either the system starts in UEFI only and the controller is ignored, or in Legacy only and it hangs during initialization.
– Anton SamsonovJun 4 '17 at 15:40

2 Answers
2

Yes, SeaBIOS supports loading and running PCI option roms. Which apparently actually works as you can see the raid controller boot messages. The PCI rom then has to register any bootable disks, which is not happening here. Could be a configuration issue. Check the array configuration utility whenever you can configure the boot volume there. Could also be some bug or incompatibility ...

If that doesn't work out you can try something completely different: Connect the disks to some linux-supported sata controller, then check whenever dmraid is able to decode the raid volume. If that works you can attach it as simple disk to your win2k3 virtual machine.

As stated multiple times, that RAID controller is totally compatible with regular BIOS and thus is visible as boot device there. So it is SeaBIOS that may be non-compliant in the first place. As for *nix compatibility, theoretically Linux should support that controller in JBOD mode and FreeBSD should support it fully, but practically they do not at all. So I am not very optimistic about dmraid. Moreover, my question is not about getting data back, but bringing the entire server back without having to reinstall Windows.
– Anton SamsonovJun 5 '17 at 5:44

In theory it is totally compatible. In practice obviously not, otherwise it would have worked with the new mainboard. It's not clear who is non-compilant here. Could be seabios, but could be the raid option rom too.
– Gerd HoffmannJun 5 '17 at 6:44

You must found old motherboard with PCI V2.2 expansion slot and try to boot from raid controller.

Then install special drivers for KVM all virtual hardware (see below).

Make backup. Then boot from Linux live CD (by example from SystemRescueCD) and reduce size of partitions without changing the start position of boot and root partition​ (it's usually window's disk C:) by GParted program. You must have more 8Gb+RAM free unpartitioned size on logical RAID drive. Be sure that you can boot after it.

Duplicate logical disk by dd command to a file on a backup drive. Then connect disks to the new motherboard, install Linux on software RAID1

By example: you have 4 x 120Gb disks in RAID5 and one logical drive /dev/sda. You have only one partition /dev/sda1 which is Windows disk C:. It has 300Gb size after reducing by GParted. You mount another backup drive by command: mount /dev/sdb1 /mnt. Then copy first 301Gb of RAID disk to backup drive by command dd if=/dev/sda of=/mnt/disk-c.img bs=4M count=77056. When it is copied do umount /mnt.

Create soft RAID5 on free space. Create LVM group on it and LVM volume with size more than the image file.

Copy data from the image file to LVM volume. Attache this volume as RAW disk to virtual machine.

The whole point with booting from RAID5 is to avoid reinstalling Windows after changing its boot device. Your solution misses that point, as installing new disk controller drivers in advance does not tell Windows where its root partition will be moved to.
– Anton SamsonovJun 5 '17 at 5:35

I wrote that. I moved Windows 2000 hardware server to virtual without any problem. You need install drivers of all virtual devices before moving server to virtual machine. Also i wrote that don't change start sector of boot and root Windows partitions.
– Mikhail KhirgiyJun 5 '17 at 5:44

Well, my previous experience was the opposite: the ability to boot Windows is not just about having drivers for the disk controller, but also about specifying which drive and partition it resides on. It is just like specifying root= parameter for Linux kernel, only that not so easy as editing a GRUB config file. But I reserve the possibility that I may be wrong.
– Anton SamsonovJun 5 '17 at 5:51

By the way, regarding steps 3 and 4. How would it be possible to access the RAID volume from Linux live environments when Linux and BSD do not in fact support that controller? They do not see it even as a bunch of raw drives, not to mention as a single volume.
– Anton SamsonovJun 6 '17 at 5:18