Many years later I can no longer reproduce this
** Changed in: mdadm (Ubuntu)
Status: Incomplete => Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/252365
Title:
mdadm does not add
Does Bug #550131 initramfs missing /var/run/mdadm dir (loosing state)
fix this?
--
mdadm does not add spares to arrays on boot
https://bugs.launchpad.net/bugs/252365
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs
I'd consider the missing modules issue as fix released, right?
Christian Reis, does the race still occur in recent releases?
Why is initramfs udev killed instead of transitioned to the rootfs?
https://wiki.ubuntu.com/ReliableRaid
** Changed in: initramfs-tools
Status: New = Fix Released
MNLipp, sbrady69: I think we are actually having a different problem
than this bug. Jan's issue is that the spare he has comes from a
separate controller (which isn't available in the stock initramfs he was
using). I spent a lot of time researching this yesterday, and found that
it's actually a
I confirm this same problem on Debian Lenny.
I was not able to fix the problem by adding: DEVICE /dev/hd[abcdef][12]
or DEVICE /dev/sd[abcdef][12] to mdadm.conf
this is for IDE hard drives, I assume support has degraded for such devices
--
mdadm does not add spares to arrays on boot
change amount of spares if this happens on debian lenny after update for
RAID 1 config. for some reason 2 devices, and 1 spare did not return
emails before, but now is. I have to change spares=1 to spares=0
--
mdadm does not add spares to arrays on boot
https://bugs.launchpad.net/bugs/252365
You
I can confirm the problem (for 9.04) and I have all disks on the same
controller (raid5 with 3 + 1 spare). The spare is recognized sometimes,
but not always.
Looking at the boot messages, I strongly suspect that it depends on the
sequence in which the disks become available to mdadm. Disks are
I have this same symptom, but all my disks are on the same controller,
so the issue is likely to be different. I wonder what is causing the
spares to not be picked up -- could it be mdadm --scan is not doing the
right thing?
--
mdadm does not add spares to arrays on boot
I have been advised on the linux-raid mailing list [1] that this problem
is more likely to be caused by mkinitrd than by mdadm, and that I should
therefore file a bug against initramfs-tools.
[1]: http://marc.info/?l=linux-raidm=123421650832520w=2
** Also affects: initramfs-tools
Importance:
I'm sorry for having let this bug linger for such a long time. I think I
have now found the proper solution to this problem.
Restating the problem: I have six disks, four of which are served by a
sata-sil24 controller, the other two being served by a sata-via
controller. The active partitions of
JanCeuleers: Your solution works!
My setup is similar to yours. I have a nVidia mainboard SATA controller
with the system disk and spare connected, and a Promise TX4 SATA PCI
card with four disks hosting a RAID5 volume. I added the modules sata_nv
and sata_promise to /etc/initramfs-tools/modules,
I can confirm this problem on Ubuntu Server 8.04. I have the same RAID5
configuration as the reporter (4 active disks, 1 spare).
In my case the spare isn't added to the array on boot no matter what
changes are made to mdadm.conf. Stating the devices explicitly doesn't
help.
$ cat
12 matches
Mail list logo
