---------- 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! -- Life's fun when your sick and psychotic!
