[arch-general] Was Fwd: [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

[Myra Nelson]

---------- Forwarded message ----------
From: Myra Nelson <myra.nelson at hughes.net>
Date: Sat, Jun 4, 2011 at 12:10
Subject: Re: [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
To: Public mailing list for Arch Linux development
<arch-dev-public at archlinux.org>


On Sat, Jun 4, 2011 at 11:30, Eric Bélanger <snowmaniscool at gmail.com> wrote:
> On Sat, Jun 4, 2011 at 4:58 AM, Tom Gundersen <teg at jklm.no> wrote:
>> On Sat, Jun 4, 2011 at 5:41 AM, Eric Bélanger <snowmaniscool at gmail.com> wrote:
>>> FWIW, the instructive comments in udev.conf doesn't mention "warning"
>>> as a valid value.
>>
>> Oops, I meant to say "info".
>
> I also tried info when I tried with debug. I didn't noticed any
> difference with debug as far as the excessive output go. I could try
> it again and check dmesg more carefully.
>
>
>>
>>> I tried it and the error message doesn't get
>>> printed.  Dmesg doesn't have the error message and the logs are
>>> useless since the error happens when the kernel is booting, i.e.
>>> rc.sysinit isn't running yet. I suppose it's mkinitcpio/udev related.
>>
>> If rc.sysinit is not running, then this is an mkinitcpio problem. I
>> guess the reason you are seeing it again might be a race? We have sped
>> things up quite a bit with this release, so things might race
>> differently than before.
>
> 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.
>
>>
>>> They work as expected. The error is not fatal.  My raid array gets
>>> assembled without user intervention. Either it is eventually done by
>>> the initscripts (I can't find where, I think that code parthas been
>>> removed) or by something else.
>>
>> My guess is that the error you are seeing is from udev in mkinitcpio,
>> and the udev in rc.sysinit works correctly. To change the error
>> reporting you would need to run mkinitcpio -p kernel26 after updating
>> udev.conf.
>
> I was updating my initcpio file when changing the udev.conf.
>
>>
>>>>> Also, my loopback interface  didn't started.  When I ran "/usr/sbin/ip
>>>>> link set up dev lo" manually in a terminal, it started fine. I don't
>>>>> know why it didn't work when booting up.
>>>>
>>>> Do you see anything in the above logs?
>>>
>>> I found the source of this error. My /usr is on it's own partition. So
>>> when rc.sysinit attemps to setup the loopback interface with
>>> /usr/sbin/ip, my /usr partition is not mounted yet. So it fails.  I
>>> don't know what would be the best way to fix. Maybe moving ip to /sbin
>>> or to postpone the lo interface  setup after the partitions are
>>> mounted.
>>
>> Ahhhh. I think this might cause many more problems than just the
>> loopback. In particular, anything called in udev rules may reside on
>> /usr. This means the rule will fail and it will not be rerun.
>>
>> Have a look at "grep /usr /lib/udev/rules.d/*" to see examples of what
>> might be broken.
>>
>> Most other distros, and upstream projects have given up on supporting
>> a separate /usr, so it will be buggy. I suggest moving your /usr to
>> your rootfs, regardless of this particular problem.
>>
>
> I recall you mentionning that on another ML thread. I wanted to ask
> you for details at the time but did get to.
> I'll move my /usr to my rootfs.  I use lvm2 so the
> resizing/repartionning should be easy.
>
>> As to the loopback device. I don't think it is a good idea to delay
>> this to after /usr is mounted. If anything we might want to move it
>> earlier in boot. That leaves moving ip out of /usr.
>>
>> Does anyone know the consequences of this? Do we want to keep
>> supporting a separate /usr?
>
> 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.
>
> Eric
>
>>
>> Cheers,
>>
>> Tom
>>
>

One quick question, why do I still have udev 169 and udev 171 starting. My
/usr is on a separate partition and my loopback is not starting, but everything
appears to work well. From the timing I would assume one is the mkinitcpio and
one is rc.sysinit but thought I would check first.

[myra at gandalf /var/log]:pacman -Qi udev
Name           : udev
Version        : 171-2

[myra at gandalf ~]:dmesg | grep udev
[    1.311992] udevd[86]: starting version 169
[    5.723615] udevd[598]: starting version 171

[myra at gandalf ~]:sudo tail -n 2000 /var/log/everything.log | grep udev
Jun  3 10:18:21 localhost [    1.318643] udevd[86]: starting version 169
Jun  3 10:18:21 localhost [    6.176941] udevd[609]: starting version 171
Jun  4 11:33:45 localhost [    1.311992] udevd[86]: starting version 169
Jun  4 11:33:45 localhost [    5.723615] udevd[598]: starting version 171


Myra

--
Life's fun when your sick and psychotic!



-- 
Life's fun when your sick and psychotic!