On 06/04/2011 07:43 PM, Myra Nelson wrote: > On Sat, Jun 4, 2011 at 12:18, Myra Nelson <myra.nelson@xxxxxxxxxx> wrote: >> ---------- Forwarded message ---------- >> From: Myra Nelson <myra.nelson@xxxxxxxxxx> >> 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@xxxxxxxxxxxxx> >> >> >> On Sat, Jun 4, 2011 at 11:30, Eric Bélanger <snowmaniscool@xxxxxxxxx> wrote: >>> On Sat, Jun 4, 2011 at 4:58 AM, Tom Gundersen <teg@xxxxxxx> wrote: >>>> On Sat, Jun 4, 2011 at 5:41 AM, Eric Bélanger <snowmaniscool@xxxxxxxxx> 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@gandalf /var/log]:pacman -Qi udev >> Name : udev >> Version : 171-2 >> >> [myra@gandalf ~]:dmesg | grep udev >> [ 1.311992] udevd[86]: starting version 169 >> [ 5.723615] udevd[598]: starting version 171 >> >> [myra@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
