[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]

On Sat, Jun 4, 2011 at 12:18, Myra Nelson <myra.nelson at hughes.net> wrote:
> ---------- 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!

Answered part of my own question. Rebuilt mkinitcpio images and lost
udev 169. I assume the next step will be to migrate /usr to the rootfs.