This is on an older HP Z400 workstation with HP Bios v3.57. It was working with Windows 10 on a single SATA drive. Then I installed a second disk on SATA, and installed Ubuntu 16.04 Desktop on that disk. Now I have a working Linux installation onto the new disk, /dev/sdb1, and it boots fine. The universe is right.
But wait, I cannot boot into Windows any more, even by changing the boot order of hard drives in the Bios, which I don't understand. The Windows disk appears on /dev/sda2 and the files are still there- I can browse them from the ubuntu desktop.
I thought it would be easy to upgrade Grub to give me a menu to choose Linux or Windows, but
sudo upgrade-grub and
sudo os-prober both fails with:
Error: ddf1 wrong # of devices in RAID set "ddf_[really long uuid]" [1/15] on /dev/sda
However, I am not using RAID and do not intend to. I simply want Windows on one disk and Linux on the other disk.
I have studied all the Bios screens, and the SATA raid controller screen, and have come to the conclusion:
SATA RAID cannot be turned off in the Bios of this HP. Unless I set it to 'IDE mode' which as I understand it will kill performance.
The SATA RAID configuration screen in the Bios says there are currently no RAID configurations and both disks are 'non-RAID disks'.
So why does
update-grub and similarly,
os-prober fail with a RAID set error?
Why can't I boot into Windows now, even by changing the boot order in the Bios?
That is two questions- but I suspect they are related somehow. I am not sure what other info is needed, please let me know, happy to clarify. Thanks!
more info, if I yank the SATA cable on the Linux disk, and then power on, I get a grub rescue prompt. What does this mean, that Ubuntu installed Grub onto the Windows disk?
Still have not solved the
wrong # of devices in RAID set problem. I was able to get the Linux OS to boot by yanking the SATA cable of the Windows disk, and then running boot-repair-disk (http://sourceforge.net/p/boot-repair-cd/home) Similarly, I was able to get the Windows OS to boot, by yanking the cable of the Linux disk, and then running boot-repair-disk again. Strangely, whenever both disks are connected, things will ultimately break down when GRUB fails to update because of
wrong # of devices in RAID set error.
So I am punting and repartitioning the new, larger disk to install both Linux and Windows onto the same disk. Hopefully this will avoid the pesky fake-raid errors (and it has).