| 1 |
On 2013-03-31, Samuli Suominen <ssuominen@g.o> wrote: |
| 2 |
> On 31/03/13 04:06, Philip Webb wrote: |
| 3 |
>> 130329 Samuli Suominen wrote: |
| 4 |
>>> Attached new version again, more generic than before. |
| 5 |
>> |
| 6 |
>> I find this difficult to decipher. Who is it aimed at ? |
| 7 |
>> |
| 8 |
>> I've just updated to Udev 200 . Following the news item, |
| 9 |
>> I renamed /etc/udev/rules.d/70-persistent-net.rules : |
| 10 |
>> my script to start my I/net connection with DHCP failed. |
| 11 |
>> I restored the file to its old name & all works as usual : |
| 12 |
>> it has 'NAME="eth0"'. |
| 13 |
> |
| 14 |
> Aimed to everyone and it already answers your questions. I can answer |
| 15 |
> them differently here again, but if you read the news item, this all is |
| 16 |
> there: |
| 17 |
> |
| 18 |
> If kernel assigns eth0 to first network interface (driver/module) then |
| 19 |
> you can't rename to eth0, thus the rule you have is likely superflous |
| 20 |
> and it doesn't matter if you delete it or not -- you are currently |
| 21 |
> using "random" kernel names |
| 22 |
> What it might do is interfere with enabling of the new networking, so |
| 23 |
> you should propably symlink /etc/udev/rules.d/80-net-name-slot.rules to |
| 24 |
> /dev/null and delete the 70-persistent-net.rules and the behavior of |
| 25 |
> your system stays exactly as it's when you are writing this now, |
| 26 |
> using random kernel names, but if it's an system with only 1 network |
| 27 |
> card, it propably doesn't matter much as eth0 gets always used (almost |
| 28 |
> always) |
| 29 |
|
| 30 |
*almost* always? |
| 31 |
|
| 32 |
> Nothing is stopping you from leaving out the symlink either and |
| 33 |
> migrating to the new name despite using only 1 network card either, |
| 34 |
> it's still more reliable than the kernel names |
| 35 |
|
| 36 |
I wonder if the OP did change the network devices configuration and init |
| 37 |
scripts to handle the network device under the new name, it'd not be |
| 38 |
surprising to see everything failing if you *just* change the udev |
| 39 |
rules. |
| 40 |
|
| 41 |
> The logic really isn't that hard... It's documented everywhere... :-( |
| 42 |
|
| 43 |
Badly documented. We already had lots of misdocumentation with "you need |
| 44 |
an initrd for a separate /usr *starting with* udev-191". |
| 45 |
|
| 46 |
|
| 47 |
-- |
| 48 |
Nuno Silva (aka njsg) |
| 49 |
http://njsg.sdf-eu.org/ |
Archives