Thus spake martin f krafft (madd...@d.o):
> also sprach D. North <ro...@tditx.com> [2009.07.12.0535 +0200]:
> > mdadm: no devices found for /dev/md0
> > Segmentation fault
>
> I suggest you run a hardware and memory check.
Thank you for your reply....
Following your suggestion, I ran several memtest86 passes with no errors, a cpu
stress test from UBCD, and I have done a lot of bash-level dd & concurrent
multiple-file copies with no errors showing up in /var/log/messages or
/var/log/dmesg -- unfortunately, I really don't know how to stress the machine
further looking for errors -- any suggestions would be most appreciated.
I have also reseated the sata cables & moved them from hardware sockets for
'sata1/sata3' into sockets for 'sata0/sata1' (meaning the drives still
enumerate ata1/ata2), and that 'timing' problem seen in the initial report
('ata2: ACPI get timing mode failed (AE 0x300d)') seems to be gone, but the
boot failures continue to frequently occur without the sleep calls I put in
there as described in the initial report.
Also - somewhere along the line today, the UUIDs of the /dev/md0 members have
changed. I am not aware of anything I did to change them, and I do not know
exactly WHEN they changed. It concerns me quite a bit that the lower half of
the uuid's now match /dev/md1. Here are my updated and again-working array defs
from /etc/mdadm/mdadm.conf: (the commented array def WAS working prior to
today's re-testing)
# definitions of existing MD arrays
#####????#### ARRAY /dev/md0 level=raid1 num-devices=2
UUID=abdd9eb3:faeb7c80:e30e8841:87878c43
ARRAY /dev/md0 level=raid1 num-devices=2
UUID=abdd9eb3:faeb7c80:34b6d411:a56b552d
ARRAY /dev/md1 level=raid1 num-devices=2
UUID=8d97d0a5:41763dfc:34b6d411:a56b552d
I can do a fair amount of diagnostics here, but I sure could use some pointers
as to what to do, and with what tools.
Thanks.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
