FakeRAID setup trouble – array schizophrenia

I decided to move my server from two separate 250GB SATA drives to a RAID-1, mirrored 1TB (2x1GB Seagate SATA drives) setup. I remembered my controller had an option of setting this when starting up, so I thought I was heading for a seamless install.

I created a RAID-1 array and booted Ubuntu since this was what I had handy. I sure enough had a disk called /dev/mapper/sil_bhaedcdcejba (the controller chip is called Sil3512). When I created partitions on it, they got mapped in some not too clear way to /dev/dm-0, /dev/dm-1 and so on, and that confused me for some time, because it was not 1:1, just some strange order. So I reverted to using the /dev/mapper ones, (longer to type, but not hopping around and changing order). My destination system was Debian, so I pretty much installed Ubuntu and ran debootstrap to do the rest. I installed Debian with it, and chrooted into the destination system to do fine-tuning, such as setting up /etc/fstab. I put /dev/mapper/sil_bhaedcdcejba1 there as the root and so on. Installed GRUB (the blasted 2.0 version, that I still hadn’t used to), and rebooted the system.

I googled some in the meantime, and I found out that the this type of setup is not a true RAID. It’s not the controller that is making all the work, and hiding physical disks from the OS, it’s the CPU that does it. But I had no actual choice, since the controller and the disks were already there, and figured oh well, it can’t be all that bad, can it?

When the system booted I discovered that of course I forgot to set up the root password. There was some fstab error anyhow, so I used the recovery mode to set up the password and my regular user to do su from. I discovered that for some reason there was no /dev/mapper/sil_* anymore. I did some fdisking, and rebooted the system, just in case. This time it even failed to let me in, saying that my password is not correct. Now I thought the last mount was read only, and the password got lost. I rebooted it one more time and once again landed in recovery mode. I made sure that the root fs got mounted rw, and that the password works, and worked some on the rest of the system. To my great surprise, the kernel was somehow able to boot from /dev/mapper/sil_*, but was not able to mount any other partitions from it. I had however /dev/sda{1-5} and /dev/sdb{1-5} with all the partitions that I previously setup. I compared the data on them, and discovered that the changes I made during setup from Ubuntu were applied to both sets – my fakeRaid was working ok. But all the changes I made after booting to Debian were only applied to /dev/sdb… Moreover, the system was booting from seemingly randomly chosen drive. Running update-grub detected two sets of identical operating systems, so now I was able to choose the one I wanted to boot from.

I picked this controller (Sil3512) because my old MoBo didn’t speak SATA. Looks like the el-cheapo SATA-RAID that it feautred is not the best thing to trust, or at least care should be taken when using it. The schizophrenia that it causes when the underlying OS doesn’t get what the BIOS is trying to suggest — because after all it’s nothing more than that, a suggestion from the BIOS that there is supposed to be a disk array here, got finally settled by installing dmraid package, that comes with a automatic kernel setup on Debian. A reboot and now the kernel knows /dev/mapper/*, and no longer has problems with mounting other partitions. /dev/sda* and /dev/sdb* still exist, but can not be mounted – as they should. I ran grub-update one last time, and this time it allowed me to boot from the array, and only from it, horray!

One of the articles of help was this one: FakeRaidHOWTO of Ubuntu.

And one interesting side note is, that some 50 years ago, a common method of “curing” schizophrenia in humans was to perform lobotomy – a separation of lobes of the brain. Mostly banned now for it’s inhumanity, it serves as an interesting example of the evolution of science.

My destination system was debian, so I pretty much installed Ubuntu and ran debootstrap to do the rest.I installed Debian with it, and chrooted into the destination system to do fine-tuning, such as setting up /etc/fstab. I put /dev/mapper/sil_bhaedcdcejba1 there as the root and so on. Installed GRUB (the blasted 2.0 version, that I still hadn’t used to), and rebooted the system.