Public bug reported:
Running Ubuntu Precise 64 bit with Gigabyte GA-990FXA-UD3 and FX 8150
for a video editing rig. Two WD Caviar Greens, had to use mdadm to get a
RAID 0 working (yes, it's backed up!), but left dmraid installed until
now.
An update to dmraid_1.0.0.rc16-4.1ubuntu7_amd64.deb caused recognition
of three out of my five SATA drives to fail. The SSD, with no spinup
time, is read fine. Neither of my pair of Western Digital Caviar Greens
was read far enough to see the partition table and activate the mdadm
raid of two large single partitions, one on each disk. These two disks
had been set up as a chipset RAID 0, but since dmraid never found that
device I went with mdadm instead, while leaving dmraid installed. Later
found that Caviar Greens are notorious for being dropped by chipset RAID
controllers and some hardware RAID controllers. The combination of a
short time interval to parking the heads and a long spinup time is said
to cause that.
Having had a short on the same power strip last night, I then checked
for disk and power supply problems. If I only put one disk in the hot
swap slots, it was read fine. With both, neither was read. Sometimes i
could use "break" on the GRUB command line with just the SSD and one of
the big HDD's, then insert the other during the initramfs shell, then
open the encrypted volumes both over the RAID and on the SSD and proceed
with booting. Other times, the disk would be read but generate an error
parsing stripes, blocking cryptsetup from unlocking the 2 disk RAID o
volume.
I then put my older 5400 RPM 2TB drives in the same slots-and had worse
problems. Neither had ever been specified for inclusion in a chipset
RAID or an mdadm raid, yet one of them (probably the one with a 10s
spinup time, worse than a Caviar Green) not only would not read the
partition table, but hardware reset over and over again, blocking the
initramfs shell from ever spawning. The other 5400 RPM disk was fine.
Suspecting a power supply issue, I switched to another supply-no change.
Toggling between "RAID" and "AHCI" in the bios-no change. Finally I
decided software updates just before the short circuit incident, not the
power event, must have been responsible. I booted on just the SSD, made
a new initramfs using the backup partition, and the problem was gone!
Used the newer initramfs (and kernel) it came back. Rolled back the last
update on dmraid, and the problem was gone on both kernels
(3.2.0-18-generic and 3.2.0-19-generic), all my disks were read fine. I
then removed dmraid entirely since mdadm handles the software RAID I had
to use anyway, disks open fine. Chipset RAID with dmraid is supposed to
outperform mdadm raid, but I was unable to use it when I set the disks
up, so I had to go with mdadm, which on the other hand can go anywhere I
ever use those disks.
Conclusion: Either dmraid_1.0.0.rc16-4.1ubuntu7 can't exist alongside
mdadm, it causes disk errors on the SATA controllers used by the
Gigabyte GA-990FXA-UD3, or the combination of both programs (at this
version) on this board blocks disks from being read. It's chipset
and/or disk specific, my older Phenom II/ 785 chipset rig with another,
different set of disks, again in mdadm RAID, in another location was not
affected.
** Affects: dmraid (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/958334
Title:
dmraid_1.0.0.rc16-4.1ubuntu7 blocks reading some disks, resets others
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dmraid/+bug/958334/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
