of course, no need to update initrd. My mistake. I am sorry

No problem. Thanks! I'm not sure I we'd actually ever need that kernel command line, as I'm getting the eth0 name anyway, but I've added it to the grub config be safe.

Tom

EDIT: Thinking about this more: Why would this require any change to the initrd? Wouldn't simply changing /etc/default/grub and running update-grub be sufficient? Thanks.

Tom

of course, no need to update initrd. My mistake. I am sorry

you can set
GRUB_CMDLINE_LINUX="net.ifnames=0 biosdevname=0"
then update grub/initrd

then whatever will happen to init you should always get consistent eth0
remember though to etit interfaces.

Thanks! Just to clarify, being a bit new to this: I assume that the change there is in the /etc/default/grub file, and when you say update grub you mean update-grub, and as far as the initrd, is that "update-initramfs -u"?

I'm too used to Gentoo where I'm using syslinux and no initrd at all. Thanks!

EDIT: Thinking about this more: Why would this require any change to the initrd? Wouldn't simply changing /etc/default/grub and running update-grub be sufficient? Thanks.

Tom

fsmithred wrote:

Explanation: Hand-waving-argument, magic. I don't know. But I think you'll be ok when you move your system to different hardware.

Haha...glad it's not just me. Yes, it appears I'll be OK but it would be nice to understand why. Both are still a mystery to me...that is, how I'm getting eth0 without net.ifnames=0, and why I'm getting no 70-persistent-net.rules (or any other rules) with udev enabled. Don't look a gift horse in the mouth I guess .

EDIT: Totally OT: Any idea why wiki.debian.org is apparently blocking the commercial VPN I use? I get 403s...very annoying. I read some things from way back where this was supposedly corrected(?).

Thanks!
Tom

you can set
GRUB_CMDLINE_LINUX="net.ifnames=0 biosdevname=0"
then update grub/initrd

then whatever will happen to init you should always get consistent eth0
remember though to etit interfaces.

regarding VPN and  wiki.debian.org - I don't see this issue (using commercial VPN)

Explanation: Hand-waving-argument, magic. I don't know. But I think you'll be ok when you move your system to different hardware.

Haha...glad it's not just me. Yes, it appears I'll be OK but it would be nice to understand why. Both are still a mystery to me...that is, how I'm getting eth0 without net.ifnames=0, and why I'm getting no 70-persistent-net.rules (or any other rules) with udev enabled. Don't look a gift horse in the mouth I guess .

EDIT: Totally OT: Any idea why wiki.debian.org is apparently blocking the commercial VPN I use? I get 403s...very annoying. I read some things from way back where this was supposedly corrected(?).

Thanks!
Tom

This particular system has wicd on it, and there are settings for default wired and wireless interfaces. They're set to eth0 and wlan0. I added net.ifnames=0 so that the old names will be used.

Booted one laptop and was automatically connected with the wire. Wicd saw the nearby wireless signals.
Booted another laptop and was automatically connected. Wicd worked, too.
In both cases, the only interfaces were eth0 and wlan0. They did not increment.

Explanation: Hand-waving-argument, magic. I don't know. But I think you'll be ok when you move your system to different hardware.

Bug me in a couple of weeks to see if I tried it with eudev yet.

Has it been the last month that it moved from experimental to ascii?

That hasn't happened quite yet but will soon.

It has zero to do with "network manager".

Device nodes are generated dynamically at boot by udev.  This is one of the much vaunted "features".

You can, or could, still just revert to a static /dev, make all your device nodes and just bin udev altogether.  Though, it's a use case thing - horses for courses, etc.  (Full blown desktops, won't like it...)

Alternatives to udev, you'd probably have to port over and build from source yourself.

And again, while I haven't been able to test what device I get is I port this to another VM environment, I am getting the eth0 device without passing any kernel options, and I am not getting anything like the 70-persistent-net.rules at all even though udev is running. That's actually great, but I'm really bothered by the fact that nobody seems to know why that is.

Is this possible because I'm not using network manager?

Tom

It will not solve the OP's problem of persistent naming.  That used to be resolved by clearing /etc/udev/rules.d/70-persistent-net.rules (in this case it would need to be run on every shutdown).

Combining the two approaches should give the desired result ("eth0" as the sole network interface).

however this is actually systemd we're talking about, so it's a moving target.  What works now, may no longer work in 6 months' time.

It's probably more advisable to switch away from systemd/udev and invest time in learning the alternatives...

This is the problem covered by ralph.ronnquist's reply.

Meaning:  That if you have 2+ ethernet devices, the one day one is 0 the next day it is 1 and vice versa making your network configuration a mess, while long-named uids will be consistent??

What still confuses me a bit is understanding why I'm getting eth0 rather than the new complex names...unless that's because I'm not running network manager(?). I certainly haven't changed any boot parameters etc. I'm also a little thrown as to why I'm currently not getting that auto-generated udev file at all (70-persistent-net.rules) or any others, even though udev is clearly running.

I'm not complaining, and I'd love it if that continued...I'm just not clear why it's behaving that way. Currently I have "auto eth0" in /etc/network/interfaces and, again, no network manager installed. As far as I can see, the only thing that gets changed automatically is /etc/resolv.conf and only if I set eth0 up for dhcp rather than static. That's exactly what I want.

If anyone understands why it's behaving so nicely I'd like to understand.

On an unrelated note: This has been my first use of anything related to Debian and I'm pretty thrilled all in all. I can say for sure that apt puts yum into the trash heap it deserves for sure. One feature that blew me away is the fact that I was able to install Tcl expect without unwanted (suggested) dependencies of tk by using "apt-get install expect tk8.6-". Too cool. For a binary distribution that reminded me of the flexibility I have with Gentoo.

Thanks again!
Tom