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.
