Bug#627931: /etc/udev/rules.d/70-persistent-net.rules not generated

Bug#627931: /etc/udev/rules.d/70-persistent-net.rules not generated

[Marco d'Itri]

Does anybody have an opinion about this?

----- Forwarded message from Christian Hammers <chammers@netcologne.de> -----

From: Christian Hammers <chammers@netcologne.de>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: Bug#627931: /etc/udev/rules.d/70-persistent-net.rules not generated on
	VMware

Package: udev
Version: 164-3
Severity: normal


On VMware the creation of /etc/udev/rules.d/70-persistent-net.rules is
inhibited by the following block in 
 
/lib/udev/rules.d/75-persistent-net-generator.rules:
# ignore interfaces with locally administered or null MAC addresses
# and KVM and VMWare virtual interfaces
ENV{MATCHADDR}="?[2367abef]:*",        ENV{MATCHADDR}=""
ENV{MATCHADDR}="00:00:00:00:00:00",    ENV{MATCHADDR}=""
ENV{MATCHADDR}="00:0c:29:*|00:50:56:*", ENV{MATCHADDR}=""
ENV{MATCHADDR}="52:54:00:*|54:52:00:*", ENV{MATCHADDR}=""

Please remove the exception for VMware as it's possible to
choose different network drivers (vmxnet3/e1000) for virtual
machines and this have the same problem as normal PCs that
the system does not boot correctly after a new kernel is 
installed.

bye,

-christian-


-- System Information:
Debian Release: 6.0.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores)
Locale: LANGÞ_DE.UTF-8, LC_CTYPEÞ_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages udev depends on:
ii  debconf [debconf-2.0]   1.5.36.1         Debian configuration management sy
ii  libc6                   2.11.2-10        Embedded GNU C Library: Shared lib
ii  libselinux1             2.0.96-1         SELinux runtime shared libraries
ii  libudev0                164-3            libudev shared library
ii  libusb-0.1-4            2:0.1.12-16      userspace USB programming library
ii  lsb-base                3.2-23.2squeeze1 Linux Standard Base 3.2 init scrip
ii  util-linux              2.17.2-9         Miscellaneous system utilities

Versions of packages udev recommends:
ii  pciutils                      1:3.1.7-6  Linux PCI Utilities
ii  usbutils                      0.87-5     Linux USB utilities

udev suggests no packages.

-- debconf information:
  udev/new_kernel_needed: false
  udev/sysfs_deprecated_incompatibility:
  udev/title/upgrade:
  udev/reboot_needed:


----- End forwarded message -----

-- 
ciao,
Marco

Re: Bug#627931: /etc/udev/rules.d/70-persistent-net.rules not

[Kay Sievers]

On Wed, May 25, 2011 at 20:01, Marco d'Itri <md@linux.it> wrote:
> Does anybody have an opinion about this?

Let people who rely on persistent names edit the rules file by hand.
By manually/from-system-management -tools editing the rules file in
/etc.

The /etc/udev/rules.d/70-persistent-net.rules will stay for people to
configure their names, but they should *not* use ethX. The temporary
rename loop to swap names will likely be removed from udev.

We are going to drop the entire "magically create a rules file /etc to
keep names stable"-logic later this year, I expect.

We can not rename network devices in the kernel namespace (ethX)
reliably. It's impossible to get right to rename in a conflicting
namespace while kernel modules are loaded.

The whole thing does not scale with a lot of interfaces or on boxes
with many changes. The rules file just gets full of garbage over time.

We have problems with read-only rootfs and stateless boots.

The few people who rely on stable interface names, need to *configure*
them anyway for other reasons, assign IP addressen and such. Udev
should not try to be smart in the background and write state to disk
on its own.

In the future, udev will not do anything for any unconfigured
interface, not rename it, not write out a rule for the next reboot.
The majority of systems does not need these stable names, and the
current *magic* creates far too many problems. The deal does not seem
right and the fix it not to do it.

Kay

Re: Bug#627931: /etc/udev/rules.d/70-persistent-net.rules not

[Greg KH]

On Wed, May 25, 2011 at 08:42:47PM +0200, Kay Sievers wrote:
> In the future, udev will not do anything for any unconfigured
> interface, not rename it, not write out a rule for the next reboot.
> The majority of systems does not need these stable names, and the
> current *magic* creates far too many problems. The deal does not seem
> right and the fix it not to do it.

Yeah!

That sounds like the correct solution to me as well, thanks for planning
on doing this.

greg k-h

Re: Bug#627931: /etc/udev/rules.d/70-persistent-net.rules not

[Kay Sievers]

On Thu, May 26, 2011 at 09:12, Greg KH <greg@kroah.com> wrote:
> On Wed, May 25, 2011 at 08:42:47PM +0200, Kay Sievers wrote:
>> In the future, udev will not do anything for any unconfigured
>> interface, not rename it, not write out a rule for the next reboot.
>> The majority of systems does not need these stable names, and the
>> current *magic* creates far too many problems. The deal does not seem
>> right and the fix it not to do it.
>
> Yeah!
>
> That sounds like the correct solution to me as well, thanks for planning
> on doing this.

People who don't rely on it can already do:
  ./configure --disable-rule_generator

Which will not install any of the files that mangle udev rules ad
hotplug time. The big distros just need to coordinate with the people
who do the system-management tools, that these tools get updated to
allow editing the 70-persistent-net.rules file without udev ever
touching it.

They should also make sure, that network devices are never renamed in
the ethX namespace.

The current biosdevname solution with the lomX and slotX names which
Dell uses, seems to work well, and shows that we should not fear
moving to the proper solution.

It is either leaving the names completely up to the kernel and run
something like NetworkManager which does not care at all what names
the devices have, or the system has manually configured interfaces and
they get meaningful names like 'lom' (for on motherboard) or the PCI
slot number, or something like 'internal', 'external', 'dmz'.

The lom, slot logic, which is pretty simple, we might even want to
move inside the kernel after a while, when things have proven to work
reliably that way.

Only one thing seems sure for now, that udev must stop renaming things
in the kernel namespace. The details for the rest we will need to find
out. :)

Kay

Re: Bug#627931: /etc/udev/rules.d/70-persistent-net.rules not

[Marco d'Itri]

On May 25, Kay Sievers <kay.sievers@vrfy.org> wrote:

> We can not rename network devices in the kernel namespace (ethX)
> reliably. It's impossible to get right to rename in a conflicting
> namespace while kernel modules are loaded.
Can you tell me more about this? Because it worked well enough for the
last last 5 years.

> The whole thing does not scale with a lot of interfaces or on boxes
> with many changes. The rules file just gets full of garbage over time.
True, but these are corner cases.

> Only one thing seems sure for now, that udev must stop renaming things
> in the kernel namespace. The details for the rest we will need to find
> out. :)
Maybe you can get away with removing features, but I need to support the
ones used by my users so I am strongly opposed to removing this code
until other software will support all current use cases.
As you showed, distributions which do not feel like supporting it can
just disable it.

-- 
ciao,
Marco

Re: Bug#627931: /etc/udev/rules.d/70-persistent-net.rules not

[Kay Sievers]

 On Thu, May 26, 2011 at 15:16, Marco d'Itri <md@linux.it> wrote:
> On May 25, Kay Sievers <kay.sievers@vrfy.org> wrote:
>
>> We can not rename network devices in the kernel namespace (ethX)
>> reliably. It's impossible to get right to rename in a conflicting
>> namespace while kernel modules are loaded.
> Can you tell me more about this? Because it worked well enough for the
> last last 5 years.

It does not fit my idea of "well enough", quite the opposite. The most
important, it does not really solve a problem, but creates a lot of
new ones.

The whole idea of *automatic rules* and *persistence in the file
system* is wrong. Stuff that requires static names requires *manual*
configuration anyway, stuff that does not require static names, does
not need the crappy automagic we do.

You race against the kernel creating new interfaces, while we are in
progress renaming devices. A game we can never win. We actually have
real bugs for that, and can't solve them properly ever. Renaming stuff
in the same namespace without global locks is never going to work,
hence we need to stop pretending we can.

It does not scale. If you have thousands of interfaces, the file will
just be a total mess. People with boxes to 'test' stuff get thousands
of dead rule lines, one for every new device that gets plugged in.
It's just wrong to do that.

A said earlier, it was a mistake to ever try to do *automatic* rule
creation. We are absolutely sure not, that it was a mistake and we
will fix it by not continuing to do that.

>> The whole thing does not scale with a lot of interfaces or on boxes
>> with many changes. The rules file just gets full of garbage over time.
> True, but these are corner cases.

It's not. It's a real bug. That you and I have only one disk in our
box, is no reason for udev not to require to work with 40.000 disks
out-of-the-box. We must stop pretending and solving problems which are
actually no problems.

>> Only one thing seems sure for now, that udev must stop renaming things
>> in the kernel namespace. The details for the rest we will need to find
>> out. :)
> Maybe you can get away with removing features, but I need to support the
> ones used by my users so I am strongly opposed to removing this code
> until other software will support all current use cases.
> As you showed, distributions which do not feel like supporting it can
> just disable it.

When we get there, it will no longer be part of udev, deleted from the
sources. It was a mistake to make a promise we can't deliver. There
will be still infrastructure, the mechanics to rename and manage
interfaces, but there will be no policy to execute it by default, no
rules creator running at hotplug time.

People who want *auto* rules creation can add the files themselves,
they will not be provided by udev.

Kay

Re: Bug#627931: /etc/udev/rules.d/70-persistent-net.rules not

[Marco d'Itri]

On May 26, Kay Sievers <kay.sievers@vrfy.org> wrote:

> It does not fit my idea of "well enough", quite the opposite. The most
> important, it does not really solve a problem, but creates a lot of
> new ones.
My experience is clearly different, so looks like our respective user
bases have different needs. It almost always solves the problem of
interface names not changing after a reboot and breaking everything.

> You race against the kernel creating new interfaces, while we are in
> progress renaming devices. A game we can never win. We actually have
> real bugs for that, and can't solve them properly ever. Renaming stuff
> in the same namespace without global locks is never going to work,
> hence we need to stop pretending we can.
Again, it has worked well enough for my users for the last 5 years so it
cannot be so much broken.

> A said earlier, it was a mistake to ever try to do *automatic* rule
> creation. We are absolutely sure not, that it was a mistake and we
> will fix it by not continuing to do that.
While it may not cover all cases it still beats all the existing
alternatives. I will be ready to reconsider my position when new
software will appear to handle the currently supported cases.

> When we get there, it will no longer be part of udev, deleted from the
> sources. It was a mistake to make a promise we can't deliver. There
> will be still infrastructure, the mechanics to rename and manage
> interfaces, but there will be no policy to execute it by default, no
> rules creator running at hotplug time.
I can continue maintaining the scripts in my tree as long as it will be
needed, but removing support for renaming interfaces in the same
namespace (which, again, works fine for all my users) will be seriously
inconvenient.

-- 
ciao,
Marco

Re: Bug#627931: /etc/udev/rules.d/70-persistent-net.rules not

[Kay Sievers]

On Fri, May 27, 2011 at 03:26, Marco d'Itri <md@linux.it> wrote:
> On May 26, Kay Sievers <kay.sievers@vrfy.org> wrote:
>
>> It does not fit my idea of "well enough", quite the opposite. The most
>> important, it does not really solve a problem, but creates a lot of
>> new ones.
> My experience is clearly different, so looks like our respective user
> bases have different needs. It almost always solves the problem of
> interface names not changing after a reboot and breaking everything.

Sure, it works on more boxes than it fails. But the thing is that it
is just not needed for the majority of boxes. So the few ones where
the auto-setup is helpful don't justify all the problems this solution
brings.

We have to admit we had an idea, we tried to solve it, and it does not
work out, or is not needed. So we decided to stop doing it. It's just
not worth the trouble.

>> You race against the kernel creating new interfaces, while we are in
>> progress renaming devices. A game we can never win. We actually have
>> real bugs for that, and can't solve them properly ever. Renaming stuff
>> in the same namespace without global locks is never going to work,
>> hence we need to stop pretending we can.
> Again, it has worked well enough for my users for the last 5 years so it
> cannot be so much broken.

Nope, it doesn't work. We run all the renaming during bootup while we
still load kernel modules. The interface creation from inside the
kernel races against our renaming/name swapping. Names we just freed
to take them with a rename get re-used for newly created interfaces in
the kernel. These are real bugs with bug reports. We can never fix
that properly. It's a game we can only lose.

>> A said earlier, it was a mistake to ever try to do *automatic* rule
>> creation. We are absolutely sure not, that it was a mistake and we
>> will fix it by not continuing to do that.
> While it may not cover all cases it still beats all the existing
> alternatives. I will be ready to reconsider my position when new
> software will appear to handle the currently supported cases.

The only sensible option is to provide system-management tools to
specify stable custom names for interfaces based on whatever match
that fits. We should stop trying to solve problems which don't really
exist. Today's stuff handles other names than ethX just fine, and the
majority of boxes handles changing names at reboot just fine.

>> When we get there, it will no longer be part of udev, deleted from the
>> sources. It was a mistake to make a promise we can't deliver. There
>> will be still infrastructure, the mechanics to rename and manage
>> interfaces, but there will be no policy to execute it by default, no
>> rules creator running at hotplug time.
> I can continue maintaining the scripts in my tree as long as it will be
> needed, but removing support for renaming interfaces in the same
> namespace (which, again, works fine for all my users) will be seriously
> inconvenient.

Sure, that's up to the distro, what to do. It's just that upstream
will not continue to provide things that can't be fixed properly.

Just look at the VMware example: We excluded it because the auto-rules
crated trouble for VMware images, now people think they want it. It
just does not make sense to try to be smart here. We can't solve these
issues automatically. It sounds good, but it's bad in reality.

People who need persistent names, need it for a reason, they have a
custom matching network config. So they need to setup the interface
config they match against too. Udev will get out of their way, and
only do what it it told to do instead of trying to fix non-existing
problem, and create a ton of new ones that way.

Kay