[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
---------- Forwarded message ---------- From: Myra Nelson <myra.nelson@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@archlinux.org> On Sat, Jun 4, 2011 at 11:30, Eric Bélanger <snowmaniscool@gmail.com> wrote:
On Sat, Jun 4, 2011 at 4:58 AM, Tom Gundersen <teg@jklm.no> wrote:
On Sat, Jun 4, 2011 at 5:41 AM, Eric Bélanger <snowmaniscool@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@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!
Hi Myra, On Sat, Jun 4, 2011 at 7:18 PM, Myra Nelson <myra.nelson@hughes.net> wrote:
One quick question, why do I still have udev 169 and udev 171 starting.
As you correctly assumed, the first one is in initramfs. What has happened is that your initramfs has not been updated (this happens on kernel upgrade) since you upgraded udev from 169. To get the same udev in both places, do "mkinitcpio -p kernel26" (though, if you don't, everything should still work ok even if the versions don't match).
My /usr is on a separate partition and my loopback is not starting, but everything appears to work well.
Thanks for the feedback. We'll have the loopback stuff sorted out soon. Cheers, Tom
On Sat, Jun 4, 2011 at 12:18, Myra Nelson <myra.nelson@hughes.net> wrote:
---------- Forwarded message ---------- From: Myra Nelson <myra.nelson@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@archlinux.org>
On Sat, Jun 4, 2011 at 11:30, Eric Bélanger <snowmaniscool@gmail.com> wrote:
On Sat, Jun 4, 2011 at 4:58 AM, Tom Gundersen <teg@jklm.no> wrote:
On Sat, Jun 4, 2011 at 5:41 AM, Eric Bélanger <snowmaniscool@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@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.
On 06/04/2011 07:43 PM, Myra Nelson wrote:
On Sat, Jun 4, 2011 at 12:18, Myra Nelson <myra.nelson@hughes.net> wrote:
---------- Forwarded message ---------- From: Myra Nelson <myra.nelson@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@archlinux.org>
On Sat, Jun 4, 2011 at 11:30, Eric Bélanger <snowmaniscool@gmail.com> wrote:
On Sat, Jun 4, 2011 at 4:58 AM, Tom Gundersen <teg@jklm.no> wrote:
On Sat, Jun 4, 2011 at 5:41 AM, Eric Bélanger <snowmaniscool@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@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
participants (3)
-
mangust
-
Myra Nelson
-
Tom Gundersen