[arch-dev-public] [signoff] coreutils-8.12-2, initscripts-2011.06.2-1, net-tools-1.60-15, udev-171-2, yp-tools-2.12-2

Eric Bélanger snowmaniscool at gmail.com
Tue Jun 7 17:28:01 EDT 2011


On Sat, Jun 4, 2011 at 1:12 PM, Eric Bélanger <snowmaniscool at gmail.com> wrote:
> On Sat, Jun 4, 2011 at 12:45 PM, Tom Gundersen <teg at jklm.no> wrote:
>> On Sat, Jun 4, 2011 at 6:30 PM, Eric Bélanger <snowmaniscool at 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
>>
>


More information about the arch-dev-public mailing list