On 04/04/2014 8:17 AM, Michael Biebl wrote:
Am 04.04.2014 14:57, schrieb Dale Schroeder:
On 04/03/2014 11:28 PM, Michael Biebl wrote:
On 4. April 2014 05:43:10 MESZ, Stephen Powell <zlinux...@wowway.com>
wrote:
On Thu, 03 Apr 2014 22:14:28 -0400 (EDT), Michael Biebl wrote:
Actually, this doesn't tell the whole story. While it is true, that
upstream has deliberately removed that feature (for the reasons you
mentioned, renaming network interfaces within the same namespace is
racy), in the Debian udev package we decided to keep the old network
interface naming scheme and make the new predictable interface names
[0]
explicitly opt-in [1].
Yes, for the change in interface names to work properly, one must
specify net.ifnames=1 as a kernel boot option when using a kernel
compiled from Debian kernel sources.
So even in jessie, we still ship
/lib/udev/rules.d/75-persistent-net-generator.rules which is
responsible
for creating /etc/udev/rules.d/70-persistent-net.rules.
You may ship it, but it doesn't actually work. It may be useful during
installation, but if you erase the file after installation, it does not
get re-created, and if you add a new NIC after installation, the new
data for the new card does not get appended. Are you saying that, in
the
Debian version of systemd, this is supposed to work? If that is your
claim,
then in Debian, this is a bug after all.
If it doesn't work it's a bug
I can vouch that it doesn't work.
Also referencing one of Stephen's comments:
"If you only have one network interface of a given type, you
probably don't need this file. After all, if your machine only
has one ethernet interface, it's a pretty safe bet that it will
be called eth0."
That would be wonderful if it always worked that way; however, when I
replaced the NIC in a jessie system, there was no network connection and
lshw informed me that the new NIC was now eth1. That might be because
of the still existing persistent net rule. I did not try without the
file, which follows from the fact that I didn't know why the net rule
was not being updated in the first place.
That's not how it works. Once an interface has been added to
/etc/udev/rules.d/70-persistent-net.rules, that entry is not deleted
anymore.
That's what I suspected.
So, if you remove your old NIC and insert a new one, it's actually
expected that you get eth1 for the new interface name.
If you check /etc/udev/rules.d/70-persistent-net.rules, there should be
a new entry for the NIC (compare the MAC addresses)
Yes, I understand that.
can you post the output of ifconfig -a and your
/etc/udev/rules.d/70-persistent-net.rules, please
It was back in January when I filed the bug report, and I no longer
recall from which system I sent it; but following is the output from the
system on which I first encountered the problem. I tried three
different gigabit cards to replace the 100mbit that was present during
the install, none of which, as you can see, appeared in the net rules
file. Of the NIC's I tried, two had Realtek chips and one had Marvell.
At the time, I didn't know what was happening, so I stayed with the
slower NIC.
ifconfig -a
eth0 Link encap:Ethernet HWaddr 00:04:75:f0:fd:e2
inet addr:192.168.0.2 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::204:75ff:fef0:fde2/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:95301 errors:0 dropped:55 overruns:1 frame:0
TX packets:54026 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:19343268 (18.4 MiB) TX bytes:6583325 (6.2 MiB)
Interrupt:16 Base address:0xec00
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:5025 errors:0 dropped:0 overruns:0 frame:0
TX packets:5025 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:719601 (702.7 KiB) TX bytes:719601 (702.7 KiB
/etc/udev/rules.d/70-persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.
# PCI device 0x10b7:0x9200 (3c59x)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:04:75:f0:fd:e2", ATTR{dev_id}=="0x0",
ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
If I were to create my own additions to the rules file, I would be
uncertain as where to derive the correct values for dev_id and type.
The others are fairly self-explanatory. Looking at my router, all of
the dev_id values are 0x0 and type is 1, so I guess those are the
standard values.
Dale
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
