On Sat, Jun 4, 2011 at 1:12 PM, Eric Bélanger <snowmaniscool@gmail.com> wrote:
On Sat, Jun 4, 2011 at 12:45 PM, Tom Gundersen <teg@jklm.no> wrote:
On Sat, Jun 4, 2011 at 6:30 PM, Eric Bélanger <snowmaniscool@gmail.com> wrote:
That's what I believe. I didn't mentionned it but dmesg contains output saying that the raid was assemble and all mirrors are active. So despite the error message from udevd, the kernel still manage to assemble the raid array. Also, I can't find the hook or config file that contains the mdadm command line displayed in the error message. I looked in /etc and /lib/initcpio but it's not there.
It is called from udev (both in the initramfs, which fails, and in the real fs, which succeeds). The rule is /lib/udev/rules.d/64-md-raid.rules. Could it be that your initramfs lacks some modules? I guess Thomas would know this better than me...
I could try my fallback initcpio. I don't remember if I tried that.
My /etc/mkinitcpio.conf has: MODULES="pata_amd ata_generic sata_nv sata_sil24 floppy dm-mod raid1 raid456"
HOOKS="base udev autodetect pata scsi sata usbinput keymap mdadm lvm2 filesystems" md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda2,/dev/sdb2
Same problem with fallback image. Using the info log level doesn't help at all. It scrolls too fast to read and it's not recorded anywhere. dmesg only contains a message that udevd has started, I guess it's because the output is produced by udevd and not the kernel. The logs are useless because the loggers are not running yet. I think I'll just ignore the message for now.
If I'm the only one with the problem, you can also keep things as they are now, i.e. not support /usr on a separate partition. As I'll be moving my /usr, that problem will become moot.
There probably will be more affected people once it reaches [core], so we should either decide not to support separate /usr, or fix it.
-t