I cannot boot properly with this commit:
commit 524b6c5b39b931311dfe5a2f5abae2f5c9731676
Author: Eric W. Biederman [off-list ref]
Date: Sun Dec 18 20:09:31 2011 -0800
sysfs: Kill nlink counting.
1) network systemd rule doesn't start network
What does that mean? What's a network systemd rule?
Oh, perhaps you call it a service file, not rule file?
Anyway this is a different bug. Revert of the patch above does not help.
The bug lays in the network layer. udev is unable to perform persistent
eth naming:
# ip link set eth0 name eth1 -- this one is OK
# ip link set eth1 name eth0
RTNETLINK answers: No such file or directory
thanks,
--
js
suse labs
From: Kay Sievers <hidden> Date: 2012-01-31 10:53:18
On Tue, Jan 31, 2012 at 11:41, Jiri Slaby [off-list ref] wrote:
On 01/30/2012 11:52 PM, Kay Sievers wrote:
quoted
2012/1/30 Jiri Slaby [off-list ref]:
quoted
I cannot boot properly with this commit:
commit 524b6c5b39b931311dfe5a2f5abae2f5c9731676
Author: Eric W. Biederman [off-list ref]
Date: Sun Dec 18 20:09:31 2011 -0800
sysfs: Kill nlink counting.
1) network systemd rule doesn't start network
What does that mean? What's a network systemd rule?
Oh, perhaps you call it a service file, not rule file?
Anyway this is a different bug. Revert of the patch above does not help.
Ok, fine. I checked too, and systemd does not play any silly games
with link counts.
The bug lays in the network layer. udev is unable to perform persistent
eth naming:
# ip link set eth0 name eth1 -- this one is OK
# ip link set eth1 name eth0
RTNETLINK answers: No such file or directory
Please make sure nothing tries to swap netif names in userspace. We
have given up that approach, because it is far too fragile to
temporary rename devices to be able to swap the names, and race
against the loading of new kernel network drivers at the same time.
This might be a new kernel problem here, but in general that approach
is just broken, we have have given up fiddling around here. Udev does
not do that anymore, and also the code that currently *can* be used to
do this, will be removed from udev in the future.
Network devices can only be renamed to a namespace that isn't ethX,
and which does not race against kernel names.
Does is work, if you rename the devices to something else than ethX?
Kay
On Tue, Jan 31, 2012 at 11:41, Jiri Slaby [off-list ref] wrote:
quoted
On 01/30/2012 11:52 PM, Kay Sievers wrote:
quoted
2012/1/30 Jiri Slaby [off-list ref]:
quoted
I cannot boot properly with this commit:
commit 524b6c5b39b931311dfe5a2f5abae2f5c9731676
Author: Eric W. Biederman [off-list ref]
Date: Sun Dec 18 20:09:31 2011 -0800
sysfs: Kill nlink counting.
1) network systemd rule doesn't start network
What does that mean? What's a network systemd rule?
Oh, perhaps you call it a service file, not rule file?
Anyway this is a different bug. Revert of the patch above does not help.
Ok, fine. I checked too, and systemd does not play any silly games
with link counts.
quoted
The bug lays in the network layer. udev is unable to perform persistent
eth naming:
# ip link set eth0 name eth1 -- this one is OK
# ip link set eth1 name eth0
RTNETLINK answers: No such file or directory
Please make sure nothing tries to swap netif names in userspace. We
have given up that approach, because it is far too fragile to
temporary rename devices to be able to swap the names, and race
against the loading of new kernel network drivers at the same time.
This might be a new kernel problem here, but in general that approach
is just broken, we have have given up fiddling around here. Udev does
not do that anymore, and also the code that currently *can* be used to
do this, will be removed from udev in the future.
Network devices can only be renamed to a namespace that isn't ethX,
and which does not race against kernel names.
I have two eth interfaces. The one on the motherboard is named eth0, an
added PCI card is eth1. But kernel enumerates them in the opposite order.
So udev does this sequence:
eth1 -> rename3
eth0 -> eth1
rename3 -> eth0
How it can do it differently? (This is openSUSE factory.)
Does is work, if you rename the devices to something else than ethX?
Negative:
# ip link set eth0 name krtek
# ip link set krtek name jezek
RTNETLINK answers: No such file or directory
thanks,
--
js
suse labs
From: Kay Sievers <hidden> Date: 2012-01-31 11:14:04
On Tue, Jan 31, 2012 at 12:00, Jiri Slaby [off-list ref] wrote:
On 01/31/2012 11:52 AM, Kay Sievers wrote:
quoted
On Tue, Jan 31, 2012 at 11:41, Jiri Slaby [off-list ref] wrote:
quoted
On 01/30/2012 11:52 PM, Kay Sievers wrote:
quoted
2012/1/30 Jiri Slaby [off-list ref]:
quoted
I cannot boot properly with this commit:
commit 524b6c5b39b931311dfe5a2f5abae2f5c9731676
Author: Eric W. Biederman [off-list ref]
Date: Sun Dec 18 20:09:31 2011 -0800
sysfs: Kill nlink counting.
1) network systemd rule doesn't start network
What does that mean? What's a network systemd rule?
Oh, perhaps you call it a service file, not rule file?
Anyway this is a different bug. Revert of the patch above does not help.
Ok, fine. I checked too, and systemd does not play any silly games
with link counts.
quoted
The bug lays in the network layer. udev is unable to perform persistent
eth naming:
# ip link set eth0 name eth1 -- this one is OK
# ip link set eth1 name eth0
RTNETLINK answers: No such file or directory
Please make sure nothing tries to swap netif names in userspace. We
have given up that approach, because it is far too fragile to
temporary rename devices to be able to swap the names, and race
against the loading of new kernel network drivers at the same time.
This might be a new kernel problem here, but in general that approach
is just broken, we have have given up fiddling around here. Udev does
not do that anymore, and also the code that currently *can* be used to
do this, will be removed from udev in the future.
Network devices can only be renamed to a namespace that isn't ethX,
and which does not race against kernel names.
I have two eth interfaces. The one on the motherboard is named eth0, an
added PCI card is eth1. But kernel enumerates them in the opposite order.
So udev does this sequence:
eth1 -> rename3
eth0 -> eth1
rename3 -> eth0
How it can do it differently? (This is openSUSE factory.)
A future udev will not help you doing that. We have given up
supporting this approach. Renaming is done during booting, at the same
time we load new kernel drivers, and all breaks in non-interesting
ways. Apart from all the other unsolvable problems with this model.
Pretending we are able to rename netif names in the same namespace the
kernel is allocating new names is just plain wrong. There are races
you can't control. The entire approach creates far more problems than
it solves. We just have to admit it was wrong to do that.
Custom/to-rename netif names can just not be ethX.
quoted
Does is work, if you rename the devices to something else than ethX?
Negative:
# ip link set eth0 name krtek
# ip link set krtek name jezek
RTNETLINK answers: No such file or directory
This is a command sequence you type manually?
You are sure that userspace is not working in the background,
triggered by uevents, and comes into your way here?
Kay
From: Kay Sievers <hidden> Date: 2012-01-31 11:59:09
On Tue, Jan 31, 2012 at 12:17, Jiri Slaby [off-list ref] wrote:
On 01/31/2012 12:13 PM, Kay Sievers wrote:
quoted
This is a command sequence you type manually?
Yea, and it is working with 3.3.0-rc1-next-20120124_64+. Not with
3.3.0-rc1-next-20120131_64+.
quoted
You are sure that userspace is not working in the background,
triggered by uevents, and comes into your way here?
Note that krtek exists after the first command. But cannot be renamed
further.
Yeah, I can confirm the problem here. I works fine with earlier
kernels and fails with the latest -next:
# uname -r
3.3.0-rc1-next-20120131+
# modprobe dummy
# ip link set dummy0 name foo0
# ip link set foo0 name bar0
RTNETLINK answers: No such file or directory
Kay
From: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Date: 2012-02-04 02:15:05
On Tue, 31 Jan 2012, Kay Sievers wrote:
Please make sure nothing tries to swap netif names in userspace. We
have given up that approach, because it is far too fragile to
temporary rename devices to be able to swap the names, and race
against the loading of new kernel network drivers at the same time.
That's a damn fair reason, but the loss of that functionality could cause
trouble. In fact, at first glance, to me it looks like this has a large
potential for unleashing untold pain and suffering in the sysadmin ranks
unless early userspace can emulate it somehow.
Is it possible to configure the kernel to use something other than "eth#" as
its initial namespace for netif names? Or is there some other way to get
eth1 to be what you need eth1 to be during userland boot?
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
From: Kay Sievers <hidden> Date: 2012-02-06 20:03:53
On Sat, Feb 4, 2012 at 03:14, Henrique de Moraes Holschuh
[off-list ref] wrote:
On Tue, 31 Jan 2012, Kay Sievers wrote:
quoted
Please make sure nothing tries to swap netif names in userspace. We
have given up that approach, because it is far too fragile to
temporary rename devices to be able to swap the names, and race
against the loading of new kernel network drivers at the same time.
That's a damn fair reason, but the loss of that functionality could cause
trouble. In fact, at first glance, to me it looks like this has a large
potential for unleashing untold pain and suffering in the sysadmin ranks
unless early userspace can emulate it somehow.
Is it possible to configure the kernel to use something other than "eth#" as
its initial namespace for netif names? Or is there some other way to get
eth1 to be what you need eth1 to be during userland boot?
I don't think there is a sane way to do that. Someone could add a
kernel command line parameter to switch ethX in the kernel to
something else, and create custom udev rules which match on device
properties and apply configured names which are ethX again. But for
all that, there will be no generally available support in common base
system tools, and we absolutely do not recommend anybody doing that.
Udev will not provide any help for that any more, not for automatic
device name reservation from a hotplug path, not for device name swaps
in the kernel namespace. It will only be allowed to rename devices to
a namespace that does not clash with the kernel's one.
People should use biosdevname's pci-slot names, or the on-board labels
names like DELL does for configuration-less stable names, or use
manually configured names 'internal', 'external' ,'dmz', 'vpn' and so
on.
I think we should stop pretending we can solve problems, resulting
from simple enumeration depending on device-discovery order. These
numbers can never be stable, can never reliably work in the reality we
are working with.
It's time to leave these false promises behind us and move on and that
means, no stable ethX names anymore.
Kay
From: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Date: 2012-02-08 02:00:44
On Mon, 06 Feb 2012, Kay Sievers wrote:
On Sat, Feb 4, 2012 at 03:14, Henrique de Moraes Holschuh
[off-list ref] wrote:
quoted
Is it possible to configure the kernel to use something other than "eth#" as
its initial namespace for netif names? Or is there some other way to get
eth1 to be what you need eth1 to be during userland boot?
I don't think there is a sane way to do that. Someone could add a
kernel command line parameter to switch ethX in the kernel to
something else, and create custom udev rules which match on device
properties and apply configured names which are ethX again. But for
all that, there will be no generally available support in common base
system tools, and we absolutely do not recommend anybody doing that.
What sort of impact analysis on userspace was done about this change?
Nobody in his right mind would go back to the dark ages of uncontrolled
ifnames. You're effectively forcing everybody with a clue away from the
eth# namespace.
Just to be very clear: the impact of this is the need to change the
interface names on potentially millions of lines of firewall rules and
scripts out there, as well as tracking down stuff (mostly scripts) that
special-cases the eth prefix.
Is there a really good reason why we cannot have a way to move the
kernel away from the eth# namespace at boot (through a kernel parameter,
maybe with the default namespace set at compile time), AND keep the
"common base system tools" support to assign ifname based on MAC
addresses that we have right now?
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
From: Kay Sievers <hidden> Date: 2012-02-08 03:50:37
On Wed, Feb 8, 2012 at 03:00, Henrique de Moraes Holschuh
[off-list ref] wrote:
On Mon, 06 Feb 2012, Kay Sievers wrote:
quoted
On Sat, Feb 4, 2012 at 03:14, Henrique de Moraes Holschuh
[off-list ref] wrote:
quoted
Is it possible to configure the kernel to use something other than "eth#" as
its initial namespace for netif names? Or is there some other way to get
eth1 to be what you need eth1 to be during userland boot?
I don't think there is a sane way to do that. Someone could add a
kernel command line parameter to switch ethX in the kernel to
something else, and create custom udev rules which match on device
properties and apply configured names which are ethX again. But for
all that, there will be no generally available support in common base
system tools, and we absolutely do not recommend anybody doing that.
What sort of impact analysis on userspace was done about this change?
None. It will just not be supported for new setups. Existing ones will
do what they always did.
Nobody in his right mind would go back to the dark ages of uncontrolled
ifnames. You're effectively forcing everybody with a clue away from the
eth# namespace.
Yes. It's a game we have lost and we will not win in the future. I
gave up, and I warn everybody who think it's simple to manage.
Just to be very clear: the impact of this is the need to change the
interface names on potentially millions of lines of firewall rules and
scripts out there, as well as tracking down stuff (mostly scripts) that
special-cases the eth prefix.
Yeah, and for good, ethX is a pretty much random kernel name, and I
personally will no longer work on conceptually broken infrastructure
that can never deliver what it seems to promise. In the longer run,
tools need to be fixed to automatically handle changing names, or not
care about the names at all, or names need to be explicitly set up
outside the ethX namespace to be predictable.
After years of working in that area I will stop to work on these hacks
to promise stable ethX names. It was just wrong, like enumerations
always are in hotplug setups.
Is there a really good reason why we cannot have a way to move the
kernel away from the eth# namespace at boot (through a kernel parameter,
maybe with the default namespace set at compile time),
Could work, but I don't think it is worth. Simple enumeration, and
automatic persistent on-disk device name reservation in a flat
number-range is just a very flawed concept. I'm not interested in
working on that, but that surely should not stop anybody from trying
and providing tools that can do that.
AND keep the
"common base system tools" support to assign ifname based on MAC
addresses that we have right now?
Not provided by udev's default setup, which did persistent name
reservation in the device hotplug path. It is already disabled and
will be entirely removed from the source tree some day. Other tools
can still try to provide that. But I declare that model as officially
failed and udev will not even try anything like that anymore.
People who need predictable interface names should just manually
configure custom/descriptive names, or names which are reliably
derived from the hardware, like firmware-provided names or the pci
slot number.
Kay