On Sat, Jun 4, 2011 at 1:12 PM, Eric Bélanger <[email protected]> wrote: > On Sat, Jun 4, 2011 at 12:45 PM, Tom Gundersen <[email protected]> wrote: >> On Sat, Jun 4, 2011 at 6:30 PM, Eric Bélanger <[email protected]> >> 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 >> >
