Udev : renaming my network interface
Clash Royale CLAN TAG#URR8PPP
I just installed RHEL 6.3 on a Dell 1950 server.
This server as two GBit ports, Gb0 and Gb1.
For some obscure reason, udev chose to name Gb0 eth1 and Gb1 eth0.
This is definitly not a good find for me and just gives confusion.
So I modified the configuration in /etc/udev/rules.d/70-persistent-net.rules:
# PCI device 0x14e4:0x164c (bnx2)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTRaddress=="00:20:19:52:d3:c0",
ATTRtype=="1", KERNEL=="eth*", NAME="eth1"
# PCI device 0x14e4:0x164c (bnx2)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTRaddress=="00:20:19:52:d3:be",
ATTRtype=="1", KERNEL=="eth*", NAME="eth0"
I just changed the "NAME" field on the file in order to reflect what I want.
I rebooted the server and it didn't worked.
In the dmesg log I can read the following :
udev: renamed network interface eth1 to rename5
udev: renamed network interface eth0 to eth1
udev: renamed network interface rename5 to eth0
Any idea on what is wrong here?
Why is udev switching like this? I have another similar server, where I do not have this issue.
linux rhel udev
edited Dec 1 '17 at 23:32
JamesThomasMoon1979
257210
asked Sep 17 '13 at 16:56
Hugo
1,02471625
|
show 1 more comment
I just installed RHEL 6.3 on a Dell 1950 server.
This server as two GBit ports, Gb0 and Gb1.
For some obscure reason, udev chose to name Gb0 eth1 and Gb1 eth0.
This is definitly not a good find for me and just gives confusion.
So I modified the configuration in /etc/udev/rules.d/70-persistent-net.rules:
# PCI device 0x14e4:0x164c (bnx2)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTRaddress=="00:20:19:52:d3:c0",
ATTRtype=="1", KERNEL=="eth*", NAME="eth1"
# PCI device 0x14e4:0x164c (bnx2)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTRaddress=="00:20:19:52:d3:be",
ATTRtype=="1", KERNEL=="eth*", NAME="eth0"
I just changed the "NAME" field on the file in order to reflect what I want.
I rebooted the server and it didn't worked.
In the dmesg log I can read the following :
udev: renamed network interface eth1 to rename5
udev: renamed network interface eth0 to eth1
udev: renamed network interface rename5 to eth0
Any idea on what is wrong here?
Why is udev switching like this? I have another similar server, where I do not have this issue.
linux rhel udev
edited Dec 1 '17 at 23:32
JamesThomasMoon1979
257210
asked Sep 17 '13 at 16:56
Hugo
1,02471625
so what is the assignment now? still Gb0==eth1 & Gb1==eth0?
– umläute
Sep 17 '13 at 17:10
once checkgrep -R 'rename5' /etc/udev/rules.d/because in logs why it is showingrename5is any other rule for the same ?
– Rahul Patil
Sep 18 '13 at 3:03
I've done similar thing for network interfaces and it shows just like that in the log (if you follow the logic in it, it just assigns a bogus name to original eth1 so that it can rename original eth0 to eth1). So according to the log everything should be ok. Are you sure the names are not ok yet?
– zagrimsan
Sep 18 '13 at 7:09
The assignment is still wrong : Gb0==eth1 & Gb1==eth0. Its like the changes I made in the file are not applied. I don't have any trace of rename5 in /etc/udev/rules.d/. What I understand is when kernel boot eth0 and eth1 are boot but udev switch them. eth0 => eth1 and eth1 => eth0
– Hugo
Sep 18 '13 at 8:18
Have you found a solution? I am struggling with this problem too. On normal boot, I end up with p1p1 and p1p2. But since I have plugged a network cable on p1p2, on some boot (not all, which is weird), I end up with p1p1 and rename3!?!? Udev is renaming eth1 to rename3 instead of p1p2 for whatever reason. This of course break the network i/f configuration and firewall X-( Not that I am on Ubuntu
– Huygens
Apr 5 '14 at 22:09
|
show 1 more comment
I just installed RHEL 6.3 on a Dell 1950 server.
This server as two GBit ports, Gb0 and Gb1.
For some obscure reason, udev chose to name Gb0 eth1 and Gb1 eth0.
This is definitly not a good find for me and just gives confusion.
So I modified the configuration in /etc/udev/rules.d/70-persistent-net.rules:
# PCI device 0x14e4:0x164c (bnx2)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTRaddress=="00:20:19:52:d3:c0",
ATTRtype=="1", KERNEL=="eth*", NAME="eth1"
# PCI device 0x14e4:0x164c (bnx2)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTRaddress=="00:20:19:52:d3:be",
ATTRtype=="1", KERNEL=="eth*", NAME="eth0"
I just changed the "NAME" field on the file in order to reflect what I want.
I rebooted the server and it didn't worked.
In the dmesg log I can read the following :
udev: renamed network interface eth1 to rename5
udev: renamed network interface eth0 to eth1
udev: renamed network interface rename5 to eth0
Any idea on what is wrong here?
Why is udev switching like this? I have another similar server, where I do not have this issue.
linux rhel udev
edited Dec 1 '17 at 23:32
JamesThomasMoon1979
257210
asked Sep 17 '13 at 16:56
Hugo
1,02471625
I just installed RHEL 6.3 on a Dell 1950 server.
This server as two GBit ports, Gb0 and Gb1.
For some obscure reason, udev chose to name Gb0 eth1 and Gb1 eth0.
This is definitly not a good find for me and just gives confusion.
So I modified the configuration in /etc/udev/rules.d/70-persistent-net.rules:
# PCI device 0x14e4:0x164c (bnx2)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTRaddress=="00:20:19:52:d3:c0",
ATTRtype=="1", KERNEL=="eth*", NAME="eth1"
# PCI device 0x14e4:0x164c (bnx2)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTRaddress=="00:20:19:52:d3:be",
ATTRtype=="1", KERNEL=="eth*", NAME="eth0"
I just changed the "NAME" field on the file in order to reflect what I want.
I rebooted the server and it didn't worked.
In the dmesg log I can read the following :
udev: renamed network interface eth1 to rename5
udev: renamed network interface eth0 to eth1
udev: renamed network interface rename5 to eth0
Any idea on what is wrong here?
Why is udev switching like this? I have another similar server, where I do not have this issue.
linux rhel udev
linux rhel udev
edited Dec 1 '17 at 23:32
JamesThomasMoon1979
257210
asked Sep 17 '13 at 16:56
Hugo
1,02471625
edited Dec 1 '17 at 23:32
JamesThomasMoon1979
257210
asked Sep 17 '13 at 16:56
Hugo
1,02471625
edited Dec 1 '17 at 23:32
JamesThomasMoon1979
257210
edited Dec 1 '17 at 23:32
JamesThomasMoon1979
257210
edited Dec 1 '17 at 23:32
JamesThomasMoon1979
257210
257210
asked Sep 17 '13 at 16:56
Hugo
1,02471625
asked Sep 17 '13 at 16:56
Hugo
1,02471625
asked Sep 17 '13 at 16:56
Hugo
1,02471625
1,02471625
so what is the assignment now? still Gb0==eth1 & Gb1==eth0?
– umläute
Sep 17 '13 at 17:10
once checkgrep -R 'rename5' /etc/udev/rules.d/because in logs why it is showingrename5is any other rule for the same ?
– Rahul Patil
Sep 18 '13 at 3:03
I've done similar thing for network interfaces and it shows just like that in the log (if you follow the logic in it, it just assigns a bogus name to original eth1 so that it can rename original eth0 to eth1). So according to the log everything should be ok. Are you sure the names are not ok yet?
– zagrimsan
Sep 18 '13 at 7:09
The assignment is still wrong : Gb0==eth1 & Gb1==eth0. Its like the changes I made in the file are not applied. I don't have any trace of rename5 in /etc/udev/rules.d/. What I understand is when kernel boot eth0 and eth1 are boot but udev switch them. eth0 => eth1 and eth1 => eth0
– Hugo
Sep 18 '13 at 8:18
Have you found a solution? I am struggling with this problem too. On normal boot, I end up with p1p1 and p1p2. But since I have plugged a network cable on p1p2, on some boot (not all, which is weird), I end up with p1p1 and rename3!?!? Udev is renaming eth1 to rename3 instead of p1p2 for whatever reason. This of course break the network i/f configuration and firewall X-( Not that I am on Ubuntu
– Huygens
Apr 5 '14 at 22:09
|
show 1 more comment
so what is the assignment now? still Gb0==eth1 & Gb1==eth0?
– umläute
Sep 17 '13 at 17:10
once checkgrep -R 'rename5' /etc/udev/rules.d/because in logs why it is showingrename5is any other rule for the same ?
– Rahul Patil
Sep 18 '13 at 3:03
I've done similar thing for network interfaces and it shows just like that in the log (if you follow the logic in it, it just assigns a bogus name to original eth1 so that it can rename original eth0 to eth1). So according to the log everything should be ok. Are you sure the names are not ok yet?
– zagrimsan
Sep 18 '13 at 7:09
The assignment is still wrong : Gb0==eth1 & Gb1==eth0. Its like the changes I made in the file are not applied. I don't have any trace of rename5 in /etc/udev/rules.d/. What I understand is when kernel boot eth0 and eth1 are boot but udev switch them. eth0 => eth1 and eth1 => eth0
– Hugo
Sep 18 '13 at 8:18
Have you found a solution? I am struggling with this problem too. On normal boot, I end up with p1p1 and p1p2. But since I have plugged a network cable on p1p2, on some boot (not all, which is weird), I end up with p1p1 and rename3!?!? Udev is renaming eth1 to rename3 instead of p1p2 for whatever reason. This of course break the network i/f configuration and firewall X-( Not that I am on Ubuntu
– Huygens
Apr 5 '14 at 22:09
so what is the assignment now? still Gb0==eth1 & Gb1==eth0?
– umläute
Sep 17 '13 at 17:10
so what is the assignment now? still Gb0==eth1 & Gb1==eth0?
– umläute
Sep 17 '13 at 17:10
once check
grep -R 'rename5' /etc/udev/rules.d/ because in logs why it is showing rename5 is any other rule for the same ?– Rahul Patil
Sep 18 '13 at 3:03
once check
grep -R 'rename5' /etc/udev/rules.d/ because in logs why it is showing rename5 is any other rule for the same ?– Rahul Patil
Sep 18 '13 at 3:03
I've done similar thing for network interfaces and it shows just like that in the log (if you follow the logic in it, it just assigns a bogus name to original eth1 so that it can rename original eth0 to eth1). So according to the log everything should be ok. Are you sure the names are not ok yet?
– zagrimsan
Sep 18 '13 at 7:09
I've done similar thing for network interfaces and it shows just like that in the log (if you follow the logic in it, it just assigns a bogus name to original eth1 so that it can rename original eth0 to eth1). So according to the log everything should be ok. Are you sure the names are not ok yet?
– zagrimsan
Sep 18 '13 at 7:09
The assignment is still wrong : Gb0==eth1 & Gb1==eth0. Its like the changes I made in the file are not applied. I don't have any trace of rename5 in /etc/udev/rules.d/. What I understand is when kernel boot eth0 and eth1 are boot but udev switch them. eth0 => eth1 and eth1 => eth0
– Hugo
Sep 18 '13 at 8:18
The assignment is still wrong : Gb0==eth1 & Gb1==eth0. Its like the changes I made in the file are not applied. I don't have any trace of rename5 in /etc/udev/rules.d/. What I understand is when kernel boot eth0 and eth1 are boot but udev switch them. eth0 => eth1 and eth1 => eth0
– Hugo
Sep 18 '13 at 8:18
Have you found a solution? I am struggling with this problem too. On normal boot, I end up with p1p1 and p1p2. But since I have plugged a network cable on p1p2, on some boot (not all, which is weird), I end up with p1p1 and rename3!?!? Udev is renaming eth1 to rename3 instead of p1p2 for whatever reason. This of course break the network i/f configuration and firewall X-( Not that I am on Ubuntu
– Huygens
Apr 5 '14 at 22:09
Have you found a solution? I am struggling with this problem too. On normal boot, I end up with p1p1 and p1p2. But since I have plugged a network cable on p1p2, on some boot (not all, which is weird), I end up with p1p1 and rename3!?!? Udev is renaming eth1 to rename3 instead of p1p2 for whatever reason. This of course break the network i/f configuration and firewall X-( Not that I am on Ubuntu
– Huygens
Apr 5 '14 at 22:09
|
show 1 more comment
5 Answers
5
active
oldest
votes
While this is rather late, I fixed my issue by removing the
KERNEL="eth*",
part of the rule in /etc/udev/rules.d/70-persistent-net.rules file. This works because, once UDEV has renamed the device to "rename*", this part will stop the rule matching. So, removing it allows the correct name to be assigned to the correct device regardless of what UDEV has called it in the meantime.
answered Sep 25 '14 at 10:06
Ancaglon
9112
This solved it for me also on ubuntu 14.04. Exactly the same behaviour as the OP (except that the rename was to pXpY).
– ndemou
Jun 5 '15 at 11:53
add a comment |
In my case, the issue is coming from the fact that the mac address for each interface was set in three files :
/etc/udev/rules.d/70-persistent-net.rules
/etc/sysconfig/network-scripts/ifcfg-eth0
/etc/sysconfig/network-scripts/ifcfg-eth1
We need consistency between ifcfg file and net.rules for the mac address.
answered Jan 5 '15 at 15:51
Hugo
1,02471625
1
/etc/sysconfigis on redhat/centos linux. On Ubuntu those files would be under/etc/network/if-up.d
– nmgeek
Jun 8 '16 at 15:15
add a comment |
I was able to resolve this by simply deleting /etc/udev/rules.d/70-persistent-net.rules and rebooting.
edited Dec 15 at 19:58
GAD3R
25.3k1750106
answered Aug 30 '15 at 2:59
Clayton Dukes
17113
add a comment |
have you tried creating a blank /etc/udev/rules.d/80-net-name-slot.rules ?
since Udev v197, udev has implemented predictable network interface names, by creating a blank file in that path then rebooting, you should have your interface names back to what they were.
i answered a similar question at : Creating eth0 with consistent network device naming
edited Apr 13 '17 at 12:37
Community♦
1
answered Sep 25 '13 at 20:00
cesar
417414
1
This fixed two of my three network devices. Instead of a blank file, I created a link to /dev/null. I expect either approach would work.
– MrMas
Nov 2 '16 at 17:21
add a comment |
It also might happen because eth0, eth1, wlan0, wlan1 etc. are standard kernel names (in case of non-persistent scheme naming). In udev documentation it's said:
NAME
The name to use for a network interface. See systemd.link(5) for a higher-level mechanism for setting the interface name. The name of a device node cannot be changed by udev, only additional symlinks can be created.
So never use eth*, wlan* etc. names for udev rules.
answered Mar 3 at 13:58
cy8g3n
216
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f91085%2fudev-renaming-my-network-interface%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
5 Answers
5
active
oldest
votes
5 Answers
5
active
oldest
votes
active
oldest
votes
active
oldest
votes
While this is rather late, I fixed my issue by removing the
KERNEL="eth*",
part of the rule in /etc/udev/rules.d/70-persistent-net.rules file. This works because, once UDEV has renamed the device to "rename*", this part will stop the rule matching. So, removing it allows the correct name to be assigned to the correct device regardless of what UDEV has called it in the meantime.
answered Sep 25 '14 at 10:06
Ancaglon
9112
This solved it for me also on ubuntu 14.04. Exactly the same behaviour as the OP (except that the rename was to pXpY).
– ndemou
Jun 5 '15 at 11:53
add a comment |
While this is rather late, I fixed my issue by removing the
KERNEL="eth*",
part of the rule in /etc/udev/rules.d/70-persistent-net.rules file. This works because, once UDEV has renamed the device to "rename*", this part will stop the rule matching. So, removing it allows the correct name to be assigned to the correct device regardless of what UDEV has called it in the meantime.
answered Sep 25 '14 at 10:06
Ancaglon
9112
This solved it for me also on ubuntu 14.04. Exactly the same behaviour as the OP (except that the rename was to pXpY).
– ndemou
Jun 5 '15 at 11:53
add a comment |
While this is rather late, I fixed my issue by removing the
KERNEL="eth*",
part of the rule in /etc/udev/rules.d/70-persistent-net.rules file. This works because, once UDEV has renamed the device to "rename*", this part will stop the rule matching. So, removing it allows the correct name to be assigned to the correct device regardless of what UDEV has called it in the meantime.
answered Sep 25 '14 at 10:06
Ancaglon
9112
While this is rather late, I fixed my issue by removing the
KERNEL="eth*",
part of the rule in /etc/udev/rules.d/70-persistent-net.rules file. This works because, once UDEV has renamed the device to "rename*", this part will stop the rule matching. So, removing it allows the correct name to be assigned to the correct device regardless of what UDEV has called it in the meantime.
answered Sep 25 '14 at 10:06
Ancaglon
9112
answered Sep 25 '14 at 10:06
Ancaglon
9112
answered Sep 25 '14 at 10:06
Ancaglon
9112
answered Sep 25 '14 at 10:06
Ancaglon
9112
9112
This solved it for me also on ubuntu 14.04. Exactly the same behaviour as the OP (except that the rename was to pXpY).
– ndemou
Jun 5 '15 at 11:53
add a comment |
This solved it for me also on ubuntu 14.04. Exactly the same behaviour as the OP (except that the rename was to pXpY).
– ndemou
Jun 5 '15 at 11:53
This solved it for me also on ubuntu 14.04. Exactly the same behaviour as the OP (except that the rename was to pXpY).
– ndemou
Jun 5 '15 at 11:53
This solved it for me also on ubuntu 14.04. Exactly the same behaviour as the OP (except that the rename was to pXpY).
– ndemou
Jun 5 '15 at 11:53
add a comment |
In my case, the issue is coming from the fact that the mac address for each interface was set in three files :
/etc/udev/rules.d/70-persistent-net.rules
/etc/sysconfig/network-scripts/ifcfg-eth0
/etc/sysconfig/network-scripts/ifcfg-eth1
We need consistency between ifcfg file and net.rules for the mac address.
answered Jan 5 '15 at 15:51
Hugo
1,02471625
1
/etc/sysconfigis on redhat/centos linux. On Ubuntu those files would be under/etc/network/if-up.d
– nmgeek
Jun 8 '16 at 15:15
add a comment |
In my case, the issue is coming from the fact that the mac address for each interface was set in three files :
/etc/udev/rules.d/70-persistent-net.rules
/etc/sysconfig/network-scripts/ifcfg-eth0
/etc/sysconfig/network-scripts/ifcfg-eth1
We need consistency between ifcfg file and net.rules for the mac address.
answered Jan 5 '15 at 15:51
Hugo
1,02471625
1
/etc/sysconfigis on redhat/centos linux. On Ubuntu those files would be under/etc/network/if-up.d
– nmgeek
Jun 8 '16 at 15:15
add a comment |
In my case, the issue is coming from the fact that the mac address for each interface was set in three files :
/etc/udev/rules.d/70-persistent-net.rules
/etc/sysconfig/network-scripts/ifcfg-eth0
/etc/sysconfig/network-scripts/ifcfg-eth1
We need consistency between ifcfg file and net.rules for the mac address.
answered Jan 5 '15 at 15:51
Hugo
1,02471625
In my case, the issue is coming from the fact that the mac address for each interface was set in three files :
/etc/udev/rules.d/70-persistent-net.rules
/etc/sysconfig/network-scripts/ifcfg-eth0
/etc/sysconfig/network-scripts/ifcfg-eth1
We need consistency between ifcfg file and net.rules for the mac address.
answered Jan 5 '15 at 15:51
Hugo
1,02471625
answered Jan 5 '15 at 15:51
Hugo
1,02471625
answered Jan 5 '15 at 15:51
Hugo
1,02471625
answered Jan 5 '15 at 15:51
Hugo
1,02471625
1,02471625
1
/etc/sysconfigis on redhat/centos linux. On Ubuntu those files would be under/etc/network/if-up.d
– nmgeek
Jun 8 '16 at 15:15
add a comment |
1
/etc/sysconfigis on redhat/centos linux. On Ubuntu those files would be under/etc/network/if-up.d
– nmgeek
Jun 8 '16 at 15:15
1
1
/etc/sysconfig is on redhat/centos linux. On Ubuntu those files would be under /etc/network/if-up.d– nmgeek
Jun 8 '16 at 15:15
/etc/sysconfig is on redhat/centos linux. On Ubuntu those files would be under /etc/network/if-up.d– nmgeek
Jun 8 '16 at 15:15
add a comment |
I was able to resolve this by simply deleting /etc/udev/rules.d/70-persistent-net.rules and rebooting.
edited Dec 15 at 19:58
GAD3R
25.3k1750106
answered Aug 30 '15 at 2:59
Clayton Dukes
17113
add a comment |
I was able to resolve this by simply deleting /etc/udev/rules.d/70-persistent-net.rules and rebooting.
edited Dec 15 at 19:58
GAD3R
25.3k1750106
answered Aug 30 '15 at 2:59
Clayton Dukes
17113
add a comment |
I was able to resolve this by simply deleting /etc/udev/rules.d/70-persistent-net.rules and rebooting.
edited Dec 15 at 19:58
GAD3R
25.3k1750106
answered Aug 30 '15 at 2:59
Clayton Dukes
17113
I was able to resolve this by simply deleting /etc/udev/rules.d/70-persistent-net.rules and rebooting.
edited Dec 15 at 19:58
GAD3R
25.3k1750106
answered Aug 30 '15 at 2:59
Clayton Dukes
17113
edited Dec 15 at 19:58
GAD3R
25.3k1750106
edited Dec 15 at 19:58
GAD3R
25.3k1750106
edited Dec 15 at 19:58
GAD3R
25.3k1750106
25.3k1750106
answered Aug 30 '15 at 2:59
Clayton Dukes
17113
answered Aug 30 '15 at 2:59
Clayton Dukes
17113
answered Aug 30 '15 at 2:59
Clayton Dukes
17113
17113
add a comment |
add a comment |
have you tried creating a blank /etc/udev/rules.d/80-net-name-slot.rules ?
since Udev v197, udev has implemented predictable network interface names, by creating a blank file in that path then rebooting, you should have your interface names back to what they were.
i answered a similar question at : Creating eth0 with consistent network device naming
edited Apr 13 '17 at 12:37
Community♦
1
answered Sep 25 '13 at 20:00
cesar
417414
1
This fixed two of my three network devices. Instead of a blank file, I created a link to /dev/null. I expect either approach would work.
– MrMas
Nov 2 '16 at 17:21
add a comment |
have you tried creating a blank /etc/udev/rules.d/80-net-name-slot.rules ?
since Udev v197, udev has implemented predictable network interface names, by creating a blank file in that path then rebooting, you should have your interface names back to what they were.
i answered a similar question at : Creating eth0 with consistent network device naming
edited Apr 13 '17 at 12:37
Community♦
1
answered Sep 25 '13 at 20:00
cesar
417414
1
This fixed two of my three network devices. Instead of a blank file, I created a link to /dev/null. I expect either approach would work.
– MrMas
Nov 2 '16 at 17:21
add a comment |
have you tried creating a blank /etc/udev/rules.d/80-net-name-slot.rules ?
since Udev v197, udev has implemented predictable network interface names, by creating a blank file in that path then rebooting, you should have your interface names back to what they were.
i answered a similar question at : Creating eth0 with consistent network device naming
edited Apr 13 '17 at 12:37
Community♦
1
answered Sep 25 '13 at 20:00
cesar
417414
have you tried creating a blank /etc/udev/rules.d/80-net-name-slot.rules ?
since Udev v197, udev has implemented predictable network interface names, by creating a blank file in that path then rebooting, you should have your interface names back to what they were.
i answered a similar question at : Creating eth0 with consistent network device naming
edited Apr 13 '17 at 12:37
Community♦
1
answered Sep 25 '13 at 20:00
cesar
417414
edited Apr 13 '17 at 12:37
Community♦
1
edited Apr 13 '17 at 12:37
Community♦
1
edited Apr 13 '17 at 12:37
Community♦
1
1
answered Sep 25 '13 at 20:00
cesar
417414
answered Sep 25 '13 at 20:00
cesar
417414
answered Sep 25 '13 at 20:00
cesar
417414
417414
1
This fixed two of my three network devices. Instead of a blank file, I created a link to /dev/null. I expect either approach would work.
– MrMas
Nov 2 '16 at 17:21
add a comment |
1
This fixed two of my three network devices. Instead of a blank file, I created a link to /dev/null. I expect either approach would work.
– MrMas
Nov 2 '16 at 17:21
1
1
This fixed two of my three network devices. Instead of a blank file, I created a link to /dev/null. I expect either approach would work.
– MrMas
Nov 2 '16 at 17:21
This fixed two of my three network devices. Instead of a blank file, I created a link to /dev/null. I expect either approach would work.
– MrMas
Nov 2 '16 at 17:21
add a comment |
It also might happen because eth0, eth1, wlan0, wlan1 etc. are standard kernel names (in case of non-persistent scheme naming). In udev documentation it's said:
NAME
The name to use for a network interface. See systemd.link(5) for a higher-level mechanism for setting the interface name. The name of a device node cannot be changed by udev, only additional symlinks can be created.
So never use eth*, wlan* etc. names for udev rules.
answered Mar 3 at 13:58
cy8g3n
216
add a comment |
It also might happen because eth0, eth1, wlan0, wlan1 etc. are standard kernel names (in case of non-persistent scheme naming). In udev documentation it's said:
NAME
The name to use for a network interface. See systemd.link(5) for a higher-level mechanism for setting the interface name. The name of a device node cannot be changed by udev, only additional symlinks can be created.
So never use eth*, wlan* etc. names for udev rules.
answered Mar 3 at 13:58
cy8g3n
216
add a comment |
It also might happen because eth0, eth1, wlan0, wlan1 etc. are standard kernel names (in case of non-persistent scheme naming). In udev documentation it's said:
NAME
The name to use for a network interface. See systemd.link(5) for a higher-level mechanism for setting the interface name. The name of a device node cannot be changed by udev, only additional symlinks can be created.
So never use eth*, wlan* etc. names for udev rules.
answered Mar 3 at 13:58
cy8g3n
216
It also might happen because eth0, eth1, wlan0, wlan1 etc. are standard kernel names (in case of non-persistent scheme naming). In udev documentation it's said:
NAME
The name to use for a network interface. See systemd.link(5) for a higher-level mechanism for setting the interface name. The name of a device node cannot be changed by udev, only additional symlinks can be created.
So never use eth*, wlan* etc. names for udev rules.
answered Mar 3 at 13:58
cy8g3n
216
answered Mar 3 at 13:58
cy8g3n
216
answered Mar 3 at 13:58
cy8g3n
216
answered Mar 3 at 13:58
cy8g3n
216
216
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f91085%2fudev-renaming-my-network-interface%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
so what is the assignment now? still Gb0==eth1 & Gb1==eth0?
– umläute
Sep 17 '13 at 17:10
once check
grep -R 'rename5' /etc/udev/rules.d/because in logs why it is showingrename5is any other rule for the same ?– Rahul Patil
Sep 18 '13 at 3:03
I've done similar thing for network interfaces and it shows just like that in the log (if you follow the logic in it, it just assigns a bogus name to original eth1 so that it can rename original eth0 to eth1). So according to the log everything should be ok. Are you sure the names are not ok yet?
– zagrimsan
Sep 18 '13 at 7:09
The assignment is still wrong : Gb0==eth1 & Gb1==eth0. Its like the changes I made in the file are not applied. I don't have any trace of rename5 in /etc/udev/rules.d/. What I understand is when kernel boot eth0 and eth1 are boot but udev switch them. eth0 => eth1 and eth1 => eth0
– Hugo
Sep 18 '13 at 8:18
Have you found a solution? I am struggling with this problem too. On normal boot, I end up with p1p1 and p1p2. But since I have plugged a network cable on p1p2, on some boot (not all, which is weird), I end up with p1p1 and rename3!?!? Udev is renaming eth1 to rename3 instead of p1p2 for whatever reason. This of course break the network i/f configuration and firewall X-( Not that I am on Ubuntu
– Huygens
Apr 5 '14 at 22:09