From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 431AA138010 for ; Sun, 31 Mar 2013 10:18:42 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id AB683E075C; Sun, 31 Mar 2013 10:18:36 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id BB271E073A for ; Sun, 31 Mar 2013 10:18:35 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 0773C33DB7C for ; Sun, 31 Mar 2013 10:18:35 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -0.874 X-Spam-Level: X-Spam-Status: No, score=-0.874 tagged_above=-999 required=5.5 tests=[AWL=0.472, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.344, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable Received: from smtp.gentoo.org ([IPv6:::ffff:127.0.0.1]) by localhost (smtp.gentoo.org [IPv6:::ffff:127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ASp1muHFlTvT for ; Sun, 31 Mar 2013 10:18:27 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id 7003833BEEC for ; Sun, 31 Mar 2013 10:18:24 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1UMFLZ-0005PH-VV for gentoo-dev@gentoo.org; Sun, 31 Mar 2013 12:18:45 +0200 Received: from rej5.kyla.fi ([82.130.49.149]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 31 Mar 2013 12:18:45 +0200 Received: from nunojsilva by rej5.kyla.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 31 Mar 2013 12:18:45 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: "Nuno J. Silva (aka njsg)" Subject: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt Date: Sun, 31 Mar 2013 10:18:03 +0000 (UTC) Message-ID: References: <51554C37.4000508@gentoo.org> <51556C3A.1020803@gentoo.org> <515570F2.2030902@flameeyes.eu> <515571D8.7030008@gentoo.org> <5155749A.5010302@flameeyes.eu> <51557B1B.9020408@gentoo.org> <51557D48.5010008@flameeyes.eu> <51558704.20904@gentoo.org> <20130331010601.GA965@ca.inter.net> <51578EC0.60004@gentoo.org> X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: rej5.kyla.fi User-Agent: slrn/pre1.0.0-18 (Linux) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Archives-Salt: 6372b667-ff81-4cb0-9bbc-d9b5ed5691bc X-Archives-Hash: a0020bce16cf25aeb227e4e289166f34 On 2013-03-31, Samuli Suominen wrote: > On 31/03/13 04:06, Philip Webb wrote: >> 130329 Samuli Suominen wrote: >>> Attached new version again, more generic than before. >> >> I find this difficult to decipher. Who is it aimed at ? >> >> I've just updated to Udev 200 . Following the news item, >> I renamed /etc/udev/rules.d/70-persistent-net.rules : >> my script to start my I/net connection with DHCP failed. >> I restored the file to its old name & all works as usual : >> it has 'NAME="eth0"'. > > Aimed to everyone and it already answers your questions. I can answer > them differently here again, but if you read the news item, this all is > there: > > If kernel assigns eth0 to first network interface (driver/module) then > you can't rename to eth0, thus the rule you have is likely superflous > and it doesn't matter if you delete it or not -- you are currently > using "random" kernel names > What it might do is interfere with enabling of the new networking, so > you should propably symlink /etc/udev/rules.d/80-net-name-slot.rules to > /dev/null and delete the 70-persistent-net.rules and the behavior of > your system stays exactly as it's when you are writing this now, > using random kernel names, but if it's an system with only 1 network > card, it propably doesn't matter much as eth0 gets always used (almost > always) *almost* always? > Nothing is stopping you from leaving out the symlink either and > migrating to the new name despite using only 1 network card either, > it's still more reliable than the kernel names I wonder if the OP did change the network devices configuration and init scripts to handle the network device under the new name, it'd not be surprising to see everything failing if you *just* change the udev rules. > The logic really isn't that hard... It's documented everywhere... :-( Badly documented. We already had lots of misdocumentation with "you need an initrd for a separate /usr *starting with* udev-191". -- Nuno Silva (aka njsg) http://njsg.sdf-eu.org/