Bug#735563: Bug #735563: udev: 70-persistent-net.rules not updated when adding or changing NIC
On Mon, 07 Apr 2014 12:38:15 -0400 (EDT), Brian Potkin wrote: ... 8. Observed there was a file, tmp-rules--70-persistent-net.rules, in /run/udev. It had entries for the machine's two interfaces. Yes, it seems that the temporary file is being created. It just isn't being copied to the permanent root file system once the permanent root file system gets mounted read-write. I have looked into this, and I believe that I have a fix for this bug. The Debian package maintainer may not like my version of the fix, and may elect to write his own version. And that is his prerogative. But at least I have something that seems to work. Apply the following patch: http://users.wowway.com/~zlinuxman/systemd/copyrules.patch then save your current version of /etc/udev/rules.d/70-persistent-net.rules by moving it to another directory, then shutdown and reboot. /etc/udev/rules.d/70-persistent-net.rules should be re-created during boot, which is the historical behavior. Thank you all for putting up with me. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735563: Bug #735563: udev: 70-persistent-net.rules not updated when adding or changing NIC
Hi,
Am 08.04.2014 11:59, schrieb Stephen Powell:
On Mon, 07 Apr 2014 12:38:15 -0400 (EDT), Brian Potkin wrote:
...
8. Observed there was a file, tmp-rules--70-persistent-net.rules, in
/run/udev. It had entries for the machine's two interfaces.
Yes, it seems that the temporary file is being created. It just isn't
being copied to the permanent root file system once the permanent
root file system gets mounted read-write. I have looked into this,
and I believe that I have a fix for this bug. The Debian package
maintainer may not like my version of the fix, and may elect to
write his own version. And that is his prerogative. But at least
I have something that seems to work.
Apply the following patch:
http://users.wowway.com/~zlinuxman/systemd/copyrules.patch
then save your current version of
/etc/udev/rules.d/70-persistent-net.rules by moving it to another
directory, then shutdown and reboot.
/etc/udev/rules.d/70-persistent-net.rules should be re-created
during boot, which is the historical behavior.
Thank you all for putting up with me.
You are absolutely right with the analysis.
What happened when I merged the udev into the systemd package, I dropped
the /etc/init.d/udev-mtab init script, which was responsible for doing
some /etc/mtab mangling, which is no longer necessary nowadays, with
/etc/mtab being a symlink to proc mounts.
Unfortunately, this script also contained the following code (i.e., the
same as yours):
# copy the rules generated before / was mounted read-write
for file in /dev/.udev/tmp-rules--* /run/udev/tmp-rules--*; do
dest=${file##*tmp-rules--}
[ $dest = '*' ] continue
cat $file /etc/udev/rules.d/$dest
rm -f $file
done
I guess we need to re-add this code as long as we support the old
persistent interface naming (it wasn't entirely clear back when I merged
the packages).
Ubuntu has named the upstart job /etc/init/udev-finish.
I consider to use the same name for the SysV init script and systemd
service file.
The SysV init script and systemd service file just need to ensure that
they run after $local_fs respectively local-fs.target.
In case of the systemd service file we should also add a
After=systemd-udev-settle.service, in case this service is pulled in
dynamically.
Sorry for the inconvenience.
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
Bug#735563: Bug #735563: udev: 70-persistent-net.rules not updated when adding or changing NIC
Am 08.04.2014 12:36, schrieb Michael Biebl:
# copy the rules generated before / was mounted read-write
for file in /dev/.udev/tmp-rules--* /run/udev/tmp-rules--*; do
dest=${file##*tmp-rules--}
[ $dest = '*' ] continue
cat $file /etc/udev/rules.d/$dest
rm -f $file
done
I'll probably stick this code into a small helper script
/lib/udev/copy-generated-rules and make the Upstart job, SysV init
script and the systemd service file just call that script.
Seems more sensible then copying it thrice.
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
Bug#735563: Bug #735563: udev: 70-persistent-net.rules not updated when adding or changing NIC
On Tue, 08 Apr 2014 06:36:37 -0400 (EDT), Michael Biebl wrote: Ubuntu has named the upstart job /etc/init/udev-finish. Debian has a file called /etc/init/udev-finish.conf, and I tried changing the similar logic there to reference directory /run/udev instead of /dev/.udev, but it didn't seem to have any effect. Adding the code to /etc/init.d/checkroot.sh did work, however. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735563: Bug #735563: udev: 70-persistent-net.rules not updated when adding or changing NIC
Am 08.04.2014 12:58, schrieb Stephen Powell: On Tue, 08 Apr 2014 06:36:37 -0400 (EDT), Michael Biebl wrote: Ubuntu has named the upstart job /etc/init/udev-finish. Debian has a file called /etc/init/udev-finish.conf, and I tried changing the similar logic there to reference directory /run/udev instead of /dev/.udev, but it didn't seem to have any effect. Adding the code to /etc/init.d/checkroot.sh did work, however. Sure, that file only works when you boot with Upstart as your init system. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#735563: Bug #735563: udev: 70-persistent-net.rules not updated when adding or changing NIC
On Tue, 08 Apr 2014 07:13:42 -0400 (EDT), Michael Biebl wrote: Stephen Powell wrote: Debian has a file called /etc/init/udev-finish.conf, and I tried changing the similar logic there to reference directory /run/udev instead of /dev/.udev, but it didn't seem to have any effect. Adding the code to /etc/init.d/checkroot.sh did work, however. Sure, that file only works when you boot with Upstart as your init system. That explains it, thank you. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735563: Bug #735563: udev: 70-persistent-net.rules not updated when adding or changing NIC
On Sat 05 Apr 2014 at 19:29:51 -0400, Stephen Powell wrote: In the past, the init scripts contained a work-around for this problem by re-directing output to a temporary file. Originally, this file was called /dev/.udev/tmp-rules--70-persistent-net.rules. In later releases, the name of the temporary file was changed to /run/udev/tmp-rules--70-persistent-net.rules. Once the permanent root file system was mounted read/write, the temporary file was appended to /etc/udev/rules.d/70-persistent-net.rules. This logic is either absent or incomplete in jessie. Try this. cd /etc grep -r tmp-rules . Compare the output on a wheezy system and a jessie system. I suspect that this is at least part of the problem. A way to fix this bug would be to implement Predictable Network Interface Names. The case is well made at at http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ and the Debian changelog does say Keep the old persistent network interface naming scheme for now The for now implies that the old way may not be around for ever in Debian; net.ifnames=0 seems to work for those who want to remain with it. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735563: Bug #735563: udev: 70-persistent-net.rules not updated when adding or changing NIC
On Mon 07 Apr 2014 at 09:54:37 +0100, Brian Potkin wrote: A way to fix this bug would be to implement Predictable Network Interface Names. The case is well made at at And then you remember having read https://lists.debian.org/debian-devel/2013/09/msg00180.html and https://lists.debian.org/debian-devel/2013/09/msg00186.html some time ago. Regards, Brian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735563: Bug #735563: udev: 70-persistent-net.rules not updated when adding or changing NIC
On Sat 05 Apr 2014 at 19:29:51 -0400, Stephen Powell wrote:
Thanks for your research, Brian. None of the above surprises me, based
It's about all I can do because my understanding of how udev works is
sparse. Continuing:
8. Observed there was a file, tmp-rules--70-persistent-net.rules, in
/run/udev. It had entries for the machine's two interfaces.
9. Updated the install, did a dist-upgrade and installed systemd. Deleted
70-persistent-net.rules and rebooted with init=/bin/systemd.
70-persistent-net.rules is not present afterwards.
10. Installed systemd-sysv and rebooted.
11. The 'ifconfig -a' output (without the 'lo' entry), is
eth0 Link encap:Ethernet HWaddr 00:40:f4:72:4e:e1
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
eth1 Link encap:Ethernet HWaddr 00:19:d1:4d:2a:70
inet addr:192.168.7.213 Bcast:192.168.7.255 Mask:255.255.255.0
inet6 addr: fe80::219:d1ff:fe4d:2a70/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:433 errors:0 dropped:0 overruns:0 frame:0
TX packets:36 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:44734 (43.6 KiB) TX bytes:3036 (2.9 KiB)
Interrupt:21 Memory:dffe-e000
12. 'cat /etc/udev/rules.d/70-persistent-net.rules' has
# PCI device 0x10ec:0x8139 (8139too)
SUBSYSTEM==net, ACTION==add, DRIVERS==?*,
ATTR{address}==00:40:f4:72:4e:e1, \
ATTR{dev_id}==0x0, ATTR{type}==1, KERNEL==eth*, NAME=eth0
A reboot without an 'rm' doesn't get the other interface added. There
is a tmp-rules--70-persistent-net.rules file containing the missing
(e1000e) interface.
The result above isn't obtained consistently; sometimes both
interfaces are shown and there is no tmp-rules file. Coincidentally
it seems to happen when the network cable to e1000e is unattached.
I have no idea what significance, if any, is to be attached to these
data. However, I'm now inclined to view the bugs in CUPS as more
tractable. :)
Regards,
Brian.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735563: Bug #735563: udev: 70-persistent-net.rules not updated when adding or changing NIC
On Fri 04 Apr 2014 at 06:28:48 +0200, Michael Biebl wrote: On 4. April 2014 05:43:10 MESZ, Stephen Powell zlinux...@wowway.com wrote: 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 The following was done on an install from d-i's Jessie Alpha 1 release. Only the base system was installed, so no DE. 1. Observed that 70-persistent-net.rules was created by 'Detect network hardware' and was present on first boot of the new system. 2. Adding a USB wireless adapter resulted in an entry being appended to 70-persistent-net.rules. 3. Deleted the file. 'udevadm trigger --action=add' re-created it with all interfaces present. 4. Deleted the file again and rebooted. 5. 70-persistent-net.rules did not exist but the udevadm command creates it. 6. Rebooted with 'net.ifnames=1' after deleting 70-persistent-net.rules. 7. Data is not added when the USB adapter is inserted, the udevadmn command has ceased to work and 70-persistent-net.rules is not present. Regards, Brian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735563: Bug #735563: udev: 70-persistent-net.rules not updated when adding or changing NIC
On Sat, 05 Apr 2014 10:16:10 -0400 (EDT), Brian Potkin wrote: The following was done on an install from d-i's Jessie Alpha 1 release. Only the base system was installed, so no DE. 1. Observed that 70-persistent-net.rules was created by 'Detect network hardware' and was present on first boot of the new system. 2. Adding a USB wireless adapter resulted in an entry being appended to 70-persistent-net.rules. 3. Deleted the file. 'udevadm trigger --action=add' re-created it with all interfaces present. 4. Deleted the file again and rebooted. 5. 70-persistent-net.rules did not exist but the udevadm command creates it. 6. Rebooted with 'net.ifnames=1' after deleting 70-persistent-net.rules. 7. Data is not added when the USB adapter is inserted, the udevadmn command has ceased to work and 70-persistent-net.rules is not present. Thanks for your research, Brian. None of the above surprises me, based on what I've learned so far. The problem is, at boot time, the /etc/udev/rules.d directory, which is part of the root file system, is not writable. Either the permanent root file file system is not mounted yet (the initial RAM file system is still mounted), or the permanent root file system is mounted, but it is still mounted read only at the time the boot code needs to create or update it. The two scenarios that have been discussed so far are (1) the file does not get created at boot time if it is missing, and (2) a new entry for a new NIC that is discovered at boot time is not appended to the file. Both of these scenarios involve writing to /etc/udev/rules.d/70-persistent-net.rules before the file is writable. In the past, the init scripts contained a work-around for this problem by re-directing output to a temporary file. Originally, this file was called /dev/.udev/tmp-rules--70-persistent-net.rules. In later releases, the name of the temporary file was changed to /run/udev/tmp-rules--70-persistent-net.rules. Once the permanent root file system was mounted read/write, the temporary file was appended to /etc/udev/rules.d/70-persistent-net.rules. This logic is either absent or incomplete in jessie. Try this. cd /etc grep -r tmp-rules . Compare the output on a wheezy system and a jessie system. I suspect that this is at least part of the problem. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735563: Bug #735563: udev: 70-persistent-net.rules not updated when adding or changing NIC
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. As of late, I've been building wireless routers using 2 NIC's and a wireless adapter, bridging one of the NIC's with the wireless. For this purpose, it really helps to have a persistent naming system, as much of the supporting software uses ethX in their config files. Gentlemen, I appreciate the input. Thanks for your help. Dale -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735563: Bug #735563: udev: 70-persistent-net.rules not updated when adding or changing NIC
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. 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) can you post the output of ifconfig -a and your /etc/udev/rules.d/70-persistent-net.rules, please -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#735563: Bug #735563: udev: 70-persistent-net.rules not updated when adding or changing NIC
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
loLink 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?
Bug#735563: Bug #735563: udev: 70-persistent-net.rules not updated when adding or changing NIC
On Fri, 04 Apr 2014 07:57:42 -0500, Dale Schroeder wrote: ... 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. ... Yes, that's exactly why. My comment was based on the assumption that you have no existing 70-persistent-net.rules file. If the file doesn't exist, and you replace the NIC in a single-NIC system, the new NIC will be eth0, the same as the old NIC. But if you have a 70-persistent-net.rules file, it reserves eth0 for the old MAC address (which is no longer present) and so the new one is eth1. So whether this bug is fixed or not, the new NIC will be eth1 on the first reboot after swapping NICs. That is working as designed. If you want the new NIC to be eth0 on the first boot, and you don't know its MAC address in advance, you must erase the 70-persistent-net.rules file prior to the shutdown to change NICs. (I recommend moving it to another directory, such as /root, rather than erasing it -- just in case.) Also, I need to correct some things I said earlier that are false or misleading. (1) net.ifnames=1 is required as a kernel command line option to enable the Predictable Network Interface Names feature of udev/systemd in Debian jessie, regardless of the kernel sources used to compile your kernel. (2) net.ifnames=1 is not required in order to use user-defined interface names in 70-persistent-net.rules, such as net0, net1, etc. It is required if you do not assign interface names in 70-persistent-net.rules and you want to use the system-generated names that come with the Predictable Network Interface Names feature, such as eno1, ens1, enp2s0, etc. I hope I haven't muddied the waters too much. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735563: Bug #735563: udev: 70-persistent-net.rules not updated when adding or changing NIC
On Thu, 03 Apr 2014 08:17:46 -0500, Dale Schroeder wrote:
It looks like that discussion is almost 3 years old.
Debian is just now switching to systemd. udev was a separate
package in wheezy. Under jessie it is part of systemd.
And the systemd version of udev has made some changes.
Do you know what the current status is with udev;
e.g. can static entries be generated manually?
/etc/udev/rules.d/70-persistent-net.rules will still work on
boot-up, if you have one. It just won't be maintained
automatically anymore. If you installed wheezy, then did
an upgrade to jessie, you should still have a 70-persistent-net.rules
file, because it is left over from wheezy. If you do a fresh
install of jessie using the jessie installer, I'm not sure if
a 70-persistent-net.rules file will be created by the installer
or not. I haven't tried that scenario. But you can always
create one manually if you like.
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. On the other hand, if your machine has two
ethernet interfaces, one will be called eth0 and the other will
be called eth1, but which interface gets which name is theoretically
unpredictable, and can theoretically change from one boot to the
next. It is for these situations that 70-persistent-net.rules
comes in handy.
So, for example, let's say your machine has two ethernet interface
cards, and you currently have a 70-persistent-net.rules file.
Now let's say that you have to replace one of them. You shutdown
your system, power it off, remove the cover, remove the old NIC,
insert the new NIC, replace the cover, power on, and boot Debian.
Logon to the console as root. Issue
ifconfig -a
and make a note of the MAC addresses of each interface. Now edit
the file /etc/udev/rules.d/70-persistent-net.rules. Compare the
MAC addresses in this file with the MAC addresses you recorded from
ifconfig -a
It is now obvious which old MAC address is missing and which new
MAC address is now present which wasn't there before. Find the
entry in /etc/udev/rules.d/70-persistent-net.rules that has the
old MAC address that is no longer present. Edit that line and change
the old MAC address to the new MAC address. Save the file and
exit the editor. Now shutdown and reboot.
There is one final caveat: kernel space interface names, such as eth0,
eth1, etc., are not recommended, because this may lead to race
conditions between the kernel and udev during boot. User-defined
names, such as net0, net1, etc. are recommended. Here's an example
/etc/udev/rules.d/70-persistent-net.rules file from one of my
dual-interface systems:
SUBSYSTEM==net, ACTION==add, DRIVERS==?*,
ATTR{address}==00:02:b3:af:c2:b1, ATTR{dev_id}==0x0, ATTR{type}==1,
KERNEL==eth*, NAME=net1
SUBSYSTEM==net, ACTION==add, DRIVERS==?*,
ATTR{address}==00:02:b3:af:c3:8d, ATTR{dev_id}==0x0, ATTR{type}==1,
KERNEL==eth*, NAME=net0
As you can see, I used net0 and net1 as interface names instead of
eth0 and eth1, respectively, as I did on my wheezy system. But this
means, of course, that any other configuration files that reference
the interface by name must be changed also. For example, if the
interfaces are controlled by ifupdown, change /etc/network/interfaces
to use the new names.
In short, this bug is not a bug. It is an intentional design change
made by upstream. 70-persistent-net.rules is not going to be created
or maintained automatically anymore. But it is still honored during
boot, if it is present; and you can now specify user-defined interface
names, which is the recommended practice.
--
.''`. Stephen Powell
: :' :
`. `'`
`-
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735563: Bug #735563: udev: 70-persistent-net.rules not updated when adding or changing NIC
Am 04.04.2014 03:12, schrieb Stephen Powell: In short, this bug is not a bug. It is an intentional design change made by upstream. 70-persistent-net.rules is not going to be created or maintained automatically anymore. But it is still honored during boot, if it is present; and you can now specify user-defined interface names, which is the recommended practice. 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]. 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. Michael [0] http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ [1] http://packages.qa.debian.org/s/systemd/news/20130719T130007Z.html -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#735563: Bug #735563: udev: 70-persistent-net.rules not updated when adding or changing NIC
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. [0] http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ [1] http://packages.qa.debian.org/s/systemd/news/20130719T130007Z.html -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735563: Bug #735563: udev: 70-persistent-net.rules not updated when adding or changing NIC
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
