1 |
Bob Sanders <rsanders@×××.com> posted 20081118163554.GB160178@×××.com, |
2 |
excerpted below, on Tue, 18 Nov 2008 08:35:54 -0800: |
3 |
|
4 |
> Bob Sanders, mused, then expounded: |
5 |
>> |
6 |
>> Actually, it's even easier - just delete |
7 |
>> /etc/udev/rules.d/70-persistent-net.rules and reboot. Udev will create |
8 |
>> a new /etc/udev/rules.d/70-persistent-net.rules with the correct |
9 |
>> information. |
10 |
>> |
11 |
> I'll caveat this a bit. It works fine in simple cases - onboard GigE. |
12 |
> But in systems with add-in ethernet, GigE, or 10GigE cards, |
13 |
> /lib/udev/write_net_rules will usually make the add-in card eth0. Some |
14 |
> Quad GigE cards have rather weird port setups or PCI-bridge addressing |
15 |
> schemes that end up with port 2 of 4 as eth0. |
16 |
> |
17 |
> In those cases, it's best to write 70-persistent-net.rules the way you |
18 |
> want it. But remember - the mac addr has to be lower case, and all the |
19 |
> syntax correct or udev will re-write it. |
20 |
|
21 |
It's also worth noting for those using ~arch udev, that there was an |
22 |
issue with persistent-net.rules in udev-132, which is now masked. |
23 |
|
24 |
I run an all ~arch system, and while I didn't configure a persistent net |
25 |
(only one Ethernet interface to worry about, eth0 it should be and has |
26 |
been), udev-132 caused problems for me due to that file anyway. For some |
27 |
reason, with udev-132, my Broadcom Tigon-3 based device was triggering |
28 |
two different entries, the first a generic entry matching the MAC |
29 |
address, the second also matching the MAC address but with a bit more |
30 |
detail. The first was setup as eth0, so when the second, apparently the |
31 |
actually active one, appeared, it got set to eth1. |
32 |
|
33 |
Luckily I had seen the post-inst warning about possible persistent- |
34 |
net.rules problems, and while I had blown it off earlier as not having |
35 |
any such configured, knew where to look as a result of that warning when |
36 |
things went wrong. Except the warning said just delete the file and |
37 |
retrigger, and that didn't seem to work. I ended up editing the detailed |
38 |
entry it created pointing at eth1, to point to eth0 instead. That fixed |
39 |
the problem. |
40 |
|
41 |
That was yesterday. With today's update, I see udev-132 is now masked |
42 |
and it wanted to downgrade. But since I already had fixed the problem on |
43 |
my own, I just added a udev-132 entry to my package.unmask file and kept |
44 |
it. One of the bugs mentioned in the masking entry says udev-133 is |
45 |
available upstream, but it wasn't in portage yet when I did today's |
46 |
updates. It's possible I'll have to tweak things again for it, since I |
47 |
tweaked them special for -132. Oh, well. Just part of working with |
48 |
~arch, I guess. If I wasn't up for the challenge of dealing with |
49 |
occasionally broken ~arch packages, my interest in computers would |
50 |
instead be something like an interest in watching the turntable in the |
51 |
microwave go round and round... or perhaps being a brainless TV zombie |
52 |
getting programmed by all the stupid ads... boring! |
53 |
|
54 |
-- |
55 |
Duncan - List replies preferred. No HTML msgs. |
56 |
"Every nonfree program has a lord, a master -- |
57 |
and if you use the program, he is your master." Richard Stallman |