[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

[mangust]

On 06/04/2011 07:43 PM, Myra Nelson wrote:
> 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.
No need to merge /usr with rootsf. See this thread
http://mailman.archlinux.org/pipermail/arch-dev-public/2011-June/020564.html