On Sat, Aug 29, 2009 at 13:51, Juan Diego wrote:

about the network card problem, have you tried adding:

QUIRKS="predown"

to your netcfg config file I thought that quirks were removed?

On Sat, Aug 29, 2009 at 15:16, André Ramaciotti wrote:

That's what I thought too. Anyway, it didn't work, but I found out what the real problem was. For some reason, sometimes I got: Wireless -> eth0 Ethernet -> eth1

and other times I got: Ethernet -> eth0 Wireless -> eth1

so netcfg would fail reporting that eth0 doesn't support scanning. I think I solved the problem loading both modules manually so now I always have: Ethernet -> eth0 Wireless -> eth1

A custom udev rule would probably work too... check the wiki.

...

...

For some reason, sometimes I got: Wireless -> eth0 Ethernet -> eth1

and other times I got: Ethernet -> eth0 Wireless -> eth1

On Sun, Aug 30, 2009 at 00:32, Adriano de Moura wrote:

I've got that network interface "random" swap for quite some time now.  I wonder if there is something to do with the 2.6.31 kernel or the new udev

This is due to change in recent initscripts, not kernel or udev. Cannot reference the report now since bugtracker is down. This can be solved either by udev rules or specifying module options (like index=1) in modprobe config file. -- Roman Kyrylych (Роман Кирилич)

André Ramaciotti wrote:

On Sat, Aug 29, 2009 at 3:54 PM, Daenyth Blank

...

wrote:

...

On Sat, Aug 29, 2009 at 13:51, Juan Diego wrote:

...

about the network card problem, have you tried adding:

QUIRKS="predown"

to your netcfg config file

I thought that quirks were removed?

That's what I thought too. Anyway, it didn't work, but I found out what the real problem was. For some reason, sometimes I got: Wireless -> eth0 Ethernet -> eth1

and other times I got: Ethernet -> eth0 Wireless -> eth1

so netcfg would fail reporting that eth0 doesn't support scanning. I think I solved the problem loading both modules manually so now I always have: Ethernet -> eth0 Wireless -> eth1

SImplest, most Arch-like solution is to load the modules in the required order in the rc.conf MODULES array. I hope that's what you mean by "manually". :) T.

At Mon, 31 Aug 2009 11:07:36 +0300, Roman Kyrylych wrote:

On Mon, Aug 31, 2009 at 09:03, Tom K wrote:

...

SImplest, most Arch-like solution is to load the modules in the required order in the rc.conf MODULES array.

I believe this no longer works. MODULES are not processed in the order now.

-- Roman Kyrylych (Роман Кирилич)

Yes, with "manually" I meant that I put it in the MODULE arrays. It has been working for now. I'll take a look at custom udev rules later to see if it's worth the trouble.

Am Mon, 31 Aug 2009 10:24:19 +0200 schrieb Thomas Bächler :

Tom K schrieb:

...

SImplest, most Arch-like solution is to load the modules in the required order in the rc.conf MODULES array.

I hope that's what you mean by "manually". :)

With the asynchronous "trigger && load MODULES=() && settle", there is no way anymore to ensure module loading order! You need to fix this using persistent naming schemes, which is easy for network interfaces. It is also easy on alsa devices (index= option) and hard drives (uuid, label symlinks).

But it's not that easy with evdev devices like mouse and remote control. Unfortunately flyspray is still down. But the /dev/input/eventX bug with the inconsistent device naming for the mouse and the IR remote control is back since the latest initscripts update to 2009.08-1, even if the device naming is not switching at every reboot this time. Sometimes (usually) the mouse is /dev/input/event5 and the remote control is /dev/input/event4 and sometimes it's vice versa. A device in /dev/input/by-path does only exist for the mouse, not for the remote control anymore which was inconsistent anyway because of the order in which the modules cx8800 and cx8802 were loaded. Maybe it helps if udev would be updated to 146. It would be even better if the initscripts would be reverted, so that the order in which modules are loaded can be set in the MODULES array in /etc/rc.conf. As you can see these changes in the initscripts probably make the boot process a bit faster (on fast PCs), but lead to many other serious problems (inconsistencies in ALSA modules, DVB modules, ethernet modules, etc.). And only a few modules like the ALSA modules have and index option. As I've written in flyspray, I'm not really a friend of parallel booting, because it's not really the best idea, leads to inconsistencies and makes booting slower on slow PCs. And I don't think that it's user-friendly if people have to write their own udev rules for every device to get udev consistent. And this is definitively not KISS like. Heiko

Thomas Bächler wrote:

Tom K schrieb:

...

SImplest, most Arch-like solution is to load the modules in the required order in the rc.conf MODULES array.

I hope that's what you mean by "manually". :)

With the asynchronous "trigger && load MODULES=() && settle", there is no way anymore to ensure module loading order! You need to fix this using persistent naming schemes, which is easy for network interfaces. It is also easy on alsa devices (index= option) and hard drives (uuid, label symlinks).

OK... guess I'll dig through arch-dev-public to find the upside to that. :P

JM schrieb:

There appears to be an optional udev rule to sort this out (/etc/udev/rules.d/75-persistent-net-generator.rules.optional). Since I removed the ".optional" from the filename I am no longer experiencing this issue. However, this file is not described in the wiki and no one at #archlinux could explain to me what it does. Seems to work, though.

It's an upstream udev rule file, we just rename it as it seem so un-Arch. People who want these generated rules can rename it.