[opensuse] After upgrade 12.3 to 13.1, eth0 rename problem
Hello all, I have upgraded my 12.3 test machine to 13.1, with the zypper dup method. The upgrade completed successiful, but, after the first reboot, i have the eth0 network device renamed to ens3. Strangely, also i have noticied the file /etc/udev/rules.d/70-persistent-net.rules is empty. [ 23.088553] 8139cp 0000:00:03.0 eth0: RTL-8139C+ at 0xffffc90000110000, 96:5a:31:24:4a:51, IRQ 10 [ 23.088607] 8139cp 0000:00:03.0: setting latency timer to 64 [ 23.419553] 8139too: 8139too Fast Ethernet driver 0.9.28 [ 23.578290] systemd-udevd[283]: renamed network interface eth0 to ens3 I can add a line to force that device to become eth0 with udev rules, but i don't know if is the better thing to do, or maybe can be something more is not working correctly? Cordially, Claudio. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed 20 Nov 2013 02:11:19 PM CST, Claudio ML wrote:
Hello all,
I have upgraded my 12.3 test machine to 13.1, with the zypper dup method. The upgrade completed successiful, but, after the first reboot, i have the eth0 network device renamed to ens3.
Strangely, also i have noticied the file /etc/udev/rules.d/70-persistent-net.rules is empty.
[ 23.088553] 8139cp 0000:00:03.0 eth0: RTL-8139C+ at 0xffffc90000110000, 96:5a:31:24:4a:51, IRQ 10 [ 23.088607] 8139cp 0000:00:03.0: setting latency timer to 64 [ 23.419553] 8139too: 8139too Fast Ethernet driver 0.9.28 [ 23.578290] systemd-udevd[283]: renamed network interface eth0 to ens3
I can add a line to force that device to become eth0 with udev rules, but i don't know if is the better thing to do, or maybe can be something more is not working correctly?
Cordially,
Claudio.
Hi A known change: http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterface... -- Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890) SLED 11 SP3 (x86_64) GNOME 2.28.0 Kernel 3.0.93-0.8-default up 2 days 15:24, 3 users, load average: 1.72, 0.98, 0.74 CPU Intel® B840@1.9GHz | GPU Intel® Sandybridge Mobile -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Il 20/11/2013 14:32, Malcolm ha scritto:
On Wed 20 Nov 2013 02:11:19 PM CST, Claudio ML wrote:
Hello all,
I have upgraded my 12.3 test machine to 13.1, with the zypper dup method. The upgrade completed successiful, but, after the first reboot, i have the eth0 network device renamed to ens3.
Strangely, also i have noticied the file /etc/udev/rules.d/70-persistent-net.rules is empty.
[ 23.088553] 8139cp 0000:00:03.0 eth0: RTL-8139C+ at 0xffffc90000110000, 96:5a:31:24:4a:51, IRQ 10 [ 23.088607] 8139cp 0000:00:03.0: setting latency timer to 64 [ 23.419553] 8139too: 8139too Fast Ethernet driver 0.9.28 [ 23.578290] systemd-udevd[283]: renamed network interface eth0 to ens3
I can add a line to force that device to become eth0 with udev rules, but i don't know if is the better thing to do, or maybe can be something more is not working correctly?
Cordially,
Claudio.
Hi A known change: http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterface...
Thank you. I understand the motivation of this change, can be a good thing, but with an update, i prefer to use the old naming system. So, i have supplied that command: ln -s /dev/null /etc/udev/rules.d/80-net-name-slot.rules And the devices after a reboot are returned to be named as before. Thank you again. Claudio. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2013-11-20 14:11, Claudio ML wrote:
Hello all,
I have upgraded my 12.3 test machine to 13.1, with the zypper dup method. The upgrade completed successiful, but, after the first reboot, i have the eth0 network device renamed to ens3.
That's intentional, get used to it... :-} -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar)
Carlos E. R. wrote:
On 2013-11-20 14:11, Claudio ML wrote:
Hello all,
I have upgraded my 12.3 test machine to 13.1, with the zypper dup method. The upgrade completed successiful, but, after the first reboot, i have the eth0 network device renamed to ens3.
That's intentional, get used to it... :-}
I don't think it is intended on an _upgrade_. -- Per Jessen, Zürich (3.8°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, Nov 20, 2013 at 1:32 PM, Per Jessen
Carlos E. R. wrote:
On 2013-11-20 14:11, Claudio ML wrote:
Hello all,
I have upgraded my 12.3 test machine to 13.1, with the zypper dup method. The upgrade completed successiful, but, after the first reboot, i have the eth0 network device renamed to ens3.
That's intentional, get used to it... :-}
I don't think it is intended on an _upgrade_.
I have some VMware appliances that intentionally boot up without the NIC configured, then I use "ifconfig eth0 up; dhclient eth0". I upgraded 2 of them during the 13.1 test cycle and both ended up having new names for the NICs. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2013-11-20 19:32, Per Jessen wrote:
Carlos E. R. wrote:
I have upgraded my 12.3 test machine to 13.1, with the zypper dup method. The upgrade completed successiful, but, after the first reboot, i have the eth0 network device renamed to ens3.
That's intentional, get used to it... :-}
I don't think it is intended on an _upgrade_.
It is. Actually, on dvd upgrades with RC1 or RC2 you get both, the old (configured) and the new (not configured), and neither works. You have to remove the old, and configure the new for network to work. -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar)
Carlos E. R. wrote:
On 2013-11-20 19:32, Per Jessen wrote:
Carlos E. R. wrote:
I have upgraded my 12.3 test machine to 13.1, with the zypper dup method. The upgrade completed successiful, but, after the first reboot, i have the eth0 network device renamed to ens3.
That's intentional, get used to it... :-}
I don't think it is intended on an _upgrade_.
It is. Actually, on dvd upgrades with RC1 or RC2 you get both, the old (configured) and the new (not configured), and neither works. You have to remove the old, and configure the new for network to work.
Hmm, I guess nobody could be bothered to test this in the upgrade context, I know I didn't have the time. Nonetheless, we should _not_ be renaming the network interfaces on an upgrade, regardless of how it is done. I'm pretty certain that was part of the discussion of the new naming scheme. For instance, what if the user has defined his own interface names, should we just walk right over those? Anyway, when upgrading, the system will have a "70-persistent-net.rules", surely the upgrade doesn't delete that. -- Per Jessen, Zürich (2.2°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2013-11-21 08:23 (GMT+0100) Per Jessen composed:
when upgrading, the system will have a "70-persistent-net.rules", surely the upgrade doesn't delete that.
If concerned it might happen, make it immutable before starting the upgrade process. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Per Jessen
Hmm, I guess nobody could be bothered to test this in the upgrade context, I know I didn't have the time. Nonetheless, we should _not_ be renaming the network interfaces on an upgrade, regardless of how it is done. I'm pretty certain that was part of the discussion of the new naming scheme. For instance, what if the user has defined his own interface names, should we just walk right over those? Anyway, when upgrading, the system will have a "70-persistent-net.rules", surely the upgrade doesn't delete that.
My Tumbleweed upgrade did not change 70-per....rules although it did touch the file. Also checked a diff to a backup and see no change. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2013-11-21 08:23, Per Jessen wrote:
Carlos E. R. wrote:
On 2013-11-20 19:32, Per Jessen wrote:
Carlos E. R. wrote:
I don't think it is intended on an _upgrade_.
It is. Actually, on dvd upgrades with RC1 or RC2 you get both, the old (configured) and the new (not configured), and neither works. You have to remove the old, and configure the new for network to work.
Hmm, I guess nobody could be bothered to test this in the upgrade context, I know I didn't have the time.
I did and I reported here. Twice.
Anyway, when upgrading, the system will have a "70-persistent-net.rules", surely the upgrade doesn't delete that.
I did not create that file; I do not know if it was present before the update (I can verify, though), and it did not exist after the upgrade. -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar)
Carlos E. R. wrote:
On 2013-11-21 08:23, Per Jessen wrote:
Carlos E. R. wrote:
On 2013-11-20 19:32, Per Jessen wrote:
Carlos E. R. wrote:
I don't think it is intended on an _upgrade_.
It is. Actually, on dvd upgrades with RC1 or RC2 you get both, the old (configured) and the new (not configured), and neither works. You have to remove the old, and configure the new for network to work.
Hmm, I guess nobody could be bothered to test this in the upgrade context, I know I didn't have the time.
I did and I reported here. Twice.
In bugzilla too?
Anyway, when upgrading, the system will have a "70-persistent-net.rules", surely the upgrade doesn't delete that.
I did not create that file; I do not know if it was present before the update (I can verify, though), and it did not exist after the upgrade.
No, that file is created automatically and I would very be surprised if it wasn't present before the upgrade. I certainly have it on my 12.3 systems. -- Per Jessen, Zürich (1.4°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
I did and I reported here. Twice.
In bugzilla too?
First, - I - understand why items are reported to Bugzilla. With that being said, I don't understand why people are always saying to report it to Bugzilla. I venture to bet that very few people (on this list alone) either have never logged into it and/or don't know how to report it. Personally, I have not logged in to it, in over 5 years. (The last time I logged into it, it was not very intuitive on what to do and report what.) In seems to me, that there should be a list of a handful of users to aid the novice user on how to report things. Just my 2 cents, Duaine -- Duaine Hechler Piano, Player Piano, Pump Organ - Tuning, Servicing & Rebuilding (314) 838-5587 / dahechler@att.net / www.hechlerpianoandorgan.com Home & Business user of Linux - 13 years -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu 21 Nov 2013 11:42:55 AM CST, Duaine Hechler wrote:
In seems to me, that there should be a list of a handful of users to aid the novice user on how to report things.
Hi Does this help? http://en.opensuse.org/openSUSE:Submitting_bug_reports -- Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890) SLED 11 SP3 (x86_64) GNOME 2.28.0 Kernel 3.0.93-0.8-default up 3 days 19:49, 3 users, load average: 0.42, 0.66, 0.74 CPU Intel® B840@1.9GHz | GPU Intel® Sandybridge Mobile -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, Nov 21, 2013 at 12:42 PM, Duaine Hechler
I did and I reported here. Twice.
In bugzilla too?
First, - I - understand why items are reported to Bugzilla.
With that being said, I don't understand why people are always saying to report it to Bugzilla.
Uhhh.. If you understand why bugzilla is helpful, then how can you not understand why people ask for it to be done? A few reasons: - email is ephemeral. If no one answers in 24 hours, likely it has been lost into the abyss. - bugzilla has prioritization capability and a "nag me" function, so someone assigned a bug entry gets a notification email every now and then that the bug is still open. I know, because I have one I've been ignoring for a couple of months! (But eventually I want to fix it. It's a new package and not yet in the distro so no one is affected by the bug.) - And I "suspect" SUSE employees can work on bugzilla entries on company time, but not sit and answer mailing list questions. So if you hope to get a SUSE employee involved you need to move to the medium they are encouraged to use. Greg -- Greg Freemyer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 11/21/2013 9:42 AM, Duaine Hechler wrote:
Personally, I have not logged in to it, in over 5 years.
Well, that's about how long it takes to get a bug fixes when reported on Bugzilla, so it might be time to log in again. :-o -- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2013-11-21 12:51 (GMT-0800) John Andersen composed:
Duaine Hechler wrote:
Personally, I have not logged in to it, in over 5 years.
Well, that's about how long it takes to get a bug fixes when reported on Bugzilla
Not always: https://bugzilla.novell.com/show_bug.cgi?id=823658 11 days :-) https://bugzilla.novell.com/show_bug.cgi?id=845606 3 days :-D https://bugzilla.novell.com/show_bug.cgi?id=845503 21 minutes :-p https://bugzilla.novell.com/show_bug.cgi?id=400552 still open after 65 months :-( So, it depends on nature of the bug, what app or component it applies to, whether it's actually an upstream problem, quality of report, and who it gets assigned to, among other things. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Duaine Hechler wrote:
I did and I reported here. Twice.
In bugzilla too?
First, - I - understand why items are reported to Bugzilla.
With that being said, I don't understand why people are always saying to report it to Bugzilla.
Because bugzilla is our bug-tracking system. If bugs aren't tracked, they're most often aren't fixed either. -- Per Jessen, Zürich (1.6°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2013-11-21 18:01, Per Jessen wrote:
Carlos E. R. wrote:
I did and I reported here. Twice.
In bugzilla too?
No, as nobody told me to do it. The idea is that you first post for comments, and if there is no suggestion of bugzilla and you hesitate, you don't do it. In fact, what I reported is similar to what the release notes say, although i solved the issue differently.
Anyway, when upgrading, the system will have a "70-persistent-net.rules", surely the upgrade doesn't delete that.
I did not create that file; I do not know if it was present before the update (I can verify, though), and it did not exist after the upgrade.
No, that file is created automatically and I would very be surprised if it wasn't present before the upgrade. I certainly have it on my 12.3 systems.
My upgrade test was done on a virtualized system, on vmplayer. I cloned a 12.3 virtual machine and upgraded it, so I have access to both. original:
eleanor3:~ # l /etc/udev/rules.d/70-persistent-net.rules -rw-r--r-- 1 root root 0 Oct 22 19:47 /etc/udev/rules.d/70-persistent-net.rules
upgraded:
-rw-r--r-- 1 root root 0 Nov 6 19:48 /etc/udev/rules.d/70-persistent-net.rules
-- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar)
Carlos E. R. wrote:
On 2013-11-21 18:01, Per Jessen wrote:
Carlos E. R. wrote:
I did and I reported here. Twice.
In bugzilla too?
No, as nobody told me to do it.
Carlos, please - nobody has tells me to open a bugreport, that's my decision. If something is not behaving the way it's supposed to and there's no good reason why it doesn't, bugzilla!
The idea is that you first post for comments, and if there is no suggestion of bugzilla and you hesitate, you don't do it.
Not an idea I subscribe to.
No, that file is created automatically and I would very be surprised if it wasn't present before the upgrade. I certainly have it on my 12.3 systems.
My upgrade test was done on a virtualized system, on vmplayer.
Ah, I see - yes, I just checked a xen instance, 70-persistent-net.rules is empty there too, presumably because it doesn't have any real hardware. I guess we're back to that it wasn't tested (where it matters, on real hardware). -- Per Jessen, Zürich (1.5°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
В Fri, 22 Nov 2013 08:16:03 +0100
Per Jessen
Ah, I see - yes, I just checked a xen instance, 70-persistent-net.rules is empty there too, presumably because it doesn't have any real hardware. I guess we're back to that it wasn't tested (where it matters, on real hardware).
I tested it in qemu with explicit MAC that is not ignored. First installed 12.3, then all updates (you need updates because stock 12.3 dropped support for persistent interface legacy names and it was added back as update). Verified that 70-persistent-net.rules was present and contained correct information. Updated to 13.1 (using offline method for a change). After reboot in 13.1 70-persistent-net.rules remained and interface name was eth0 as before. So it looks like it should work for real hardware. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
[24.11.2013 14:55] [Andrey Borzenkov]:
В Fri, 22 Nov 2013 08:16:03 +0100 Per Jessen
пишет: Ah, I see - yes, I just checked a xen instance, 70-persistent-net.rules is empty there too, presumably because it doesn't have any real hardware. I guess we're back to that it wasn't tested (where it matters, on real hardware).
I tested it in qemu with explicit MAC that is not ignored. First installed 12.3, then all updates (you need updates because stock 12.3 dropped support for persistent interface legacy names and it was added back as update). Verified that 70-persistent-net.rules was present and contained correct information. Updated to 13.1 (using offline method for a change). After reboot in 13.1 70-persistent-net.rules remained and interface name was eth0 as before.
So it looks like it should work for real hardware.
I can confirm this behaviour for an upgrade "inside" Tumbleweed (based on 12.3 -> based on 13.1). The file and the interface names were kept. Just my 2¢ Werner -- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andrey Borzenkov wrote:
В Fri, 22 Nov 2013 08:16:03 +0100 Per Jessen
пишет: Ah, I see - yes, I just checked a xen instance, 70-persistent-net.rules is empty there too, presumably because it doesn't have any real hardware. I guess we're back to that it wasn't tested (where it matters, on real hardware).
I tested it in qemu with explicit MAC that is not ignored. First installed 12.3, then all updates (you need updates because stock 12.3 dropped support for persistent interface legacy names and it was added back as update). Verified that 70-persistent-net.rules was present and contained correct information. Updated to 13.1 (using offline method for a change). After reboot in 13.1 70-persistent-net.rules remained and interface name was eth0 as before.
So it looks like it should work for real hardware.
Cool, thanks for testing this. I was pretty certain it was meant to work like you describe. -- Per Jessen, Zürich (0.8°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
В Thu, 21 Nov 2013 20:04:56 +0100
"Carlos E. R."
My upgrade test was done on a virtualized system, on vmplayer. I cloned a 12.3 virtual machine and upgraded it, so I have access to both.
original:
eleanor3:~ # l /etc/udev/rules.d/70-persistent-net.rules -rw-r--r-- 1 root root 0 Oct 22 19:47 /etc/udev/rules.d/70-persistent-net.rules
From 75-persistent-net-generator.rules on 12.3: # ignore VMWare virtual interfaces ENV{MATCHADDR}=="00:0c:29:*|00:50:56:*", GOTO="persistent_net_generator_end" So to test it under Vmware one would need to change MAC to something more "real".
On 21/11/2013 09:01, Per Jessen wrote:
In bugzilla too?
I wasted so much time in bugzilla... posted patches/fixes, so many things just ignored. After the perl authors told suse that minor releases were binary compat... do you think suse could allow minor release interoperabilty? Nope. After I posted patches and told them how to build gvim with ruby, python, and perl dynamically loaded at run time, (resulting in a binary that was only 2.2MB vs. the 8.4MB monster that's in 13.1.)... but best is if any of the libs are missing, the editor still runs -- but not with the suse version. If you don't have all the scripts you never needed built-in, you can't edit text. Why they forced that to be that way when the option to build with all of those script langs being supported in the vim make to be dynamic... it's .. 'sad'... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Linda Walsh wrote:
On 21/11/2013 09:01, Per Jessen wrote:
In bugzilla too?
I wasted so much time in bugzilla...
posted patches/fixes, so many things just ignored.
Yeah, I know what you mean, but we can't give up. -- Per Jessen, Zürich (1.5°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 20/11/2013 05:39, Carlos E. R. wrote:
On 2013-11-20 14:11, Claudio ML wrote:
Hello all,
I have upgraded my 12.3 test machine to 13.1, with the zypper dup method. The upgrade completed successiful, but, after the first reboot, i have the eth0 network device renamed to ens3.
That's intentional, get used to it... :-}
====
Or write a script to change it...
I got tired of my network scripts being renamed at random
with various levels of factory installs... so just wrote
my own...
I have a few scripts to deal with boot,
You won't be able to easily get "include"
to work without some more infrastructure support
that most people might not want... but
changes those to fixed filenames and source them.
(I'm willing to deal with the infrastructure overhead as
it lets me include / read in various files off of
a library path
(stdalias sets up various aliases
and rc.status reads in stuff to set that to set rc-status values,
(saved various files from 12.3 and earlier)...
I use my own copies of scripts where I need to since
the ones in factory and such started getting crippled....
I have assign_netinterface in /etc/local/bin, the libs in /etc/local/lib
If you want my include stuff I can post that too...but
it's not necessary if you hard code paths...
I have another script to bring up my network...
FYIW, "include" is my answer to letting bash have a library path.
#!/bin/bash -u
### BEGIN INIT INFO
# Provides: net-devices
# Required-Start: boot.udev boot.device-mapper
# Required-Stop: $null
# Default-Start: B
# Default-Stop:
# Short-Description: order net devices
# Description: order net devs if needed
### END INIT INFO
#include standard template:
_prgpth="${0:?}"; _prg="${_prgpth##*/}"; _prgdr="${_prgpth%/$_prg}"
[[ -z $_prgdr || $_prg == $_prgdr ]] && $_prgdr="$PWD"
if ! typeset -f include >&/dev/null ;then
source ${_LOCAL_DIR:=/etc/local}/bash_env.sh;
fi
export PATH="$/etc/local/bin:/etc/local/lib:$PATH"
export PS4='>>${BASH_SOURCE:+${BASH_SOURCE[0]}}#${LINENO}${FUNCNAME:+(${FUNCNAME[0]})}> '
# gvim=:SetNumberAndWidth
include stdalias
include rc.status
shopt -s extglob
alias dcl=declare sub=function
alias int=dcl\ -i map=dcl\ -A hash=dcl\ -A array=dcl\ -a
alias lower=dcl\ -l upper=dcl\ -u string=dcl my=dcl
alias map2int=dcl\ -Ai intArray=dcl\ -ia
sub warn () { local msg="Warning: ${1:-"general"}"
echo "$msg" >&2
}
sub die () { int stat=$?; local msg="Error. ${1:-"unknown"}"
echo "$msg (errno=$stat)" >&2
exit $stat
}
sysfs=/sys
sysnet=$sysfs/class/net
sys_modules=$sysfs/module
sub rev () {
(($#==0)) && { echo ""; return 0 ;}
my element=${1:?}; shift;
(($#==0)) && { echo "$element"; return 0;}
echo "$(rev "$@") $element"
}
sub rename_if () {
my old_name=${1:?} new_name=${2:?}
echo ip link set name "$new_name" dev "$old_name"
}
##inline data (should be in external file)
# eth5 is in twice -- once for before bonding once for after;
map hw2if=( [00:15:17:bf:be:b2]=eth0 [00:15:17:bf:be:b3]=eth1
[00:26:b9:48:71:e2]=eth2 [00:26:b9:48:71:e4]=eth3
[a0:36:9f:15:c9:c0]=eth4 [a0:36:9f:15:c9:c.]=~eth5
[a0:36:9f:15:c9:c2]=eth5
)
map if2hw=( [eth0]=00:15:17:bf:be:b2 [eth1]=00:15:17:bf:be:b3
[eth2]=00:26:b9:48:71:e2 [eth3]=00:26:b9:48:71:e4
[eth4]=a0:36:9f:15:c9:c0 [~eth5]=a0:36:9f:15:c9:c.
[eth5]=a0:36:9f:15:c9:c2
)
#
#needed_drivers=(e1000e bnx2 ixgbe bonding)
needed_drivers=(e1000e bnx2 ixgbe)
sub vrfy_drivers () {
int errors=0;
for i in ${needed_drivers[@]} ; do
if [[ ! -d $sys_modules/$i ]]; then
modprobe "$i" || {
warn "Module $i is not in kernel and can't be loaded"
errors+=1
}
fi
done
return $errors
}
sub get_net_IFnames_hwaddrs () {
vrfy_drivers
array pseudo_devs=(br bond ifb team)
string pseudo_RE='^(?:'"$(echo "${pseudo_devs[@]}"|tr " " "|")"')\d+$'
string netdev_pat="+([_0-9a-z])+([0-9])"
( cd "$sysnet" &&
for nm in $(eval "echo $netdev_pat" | tr ' ' "\n" |
sort | grep -Pv "$pseudo_RE"); do
echo "$nm $(<$nm/address)"
done )
}
map -x act_hw2if=() #actual values (to be read in)
map -x act_if2hw=()
map -x XIF=() #tmp array to hold exchanged IF's
sub read_actuals () {
my ifname hwaddr
while read ifname hwaddr; do
if [[ ${act_hw2if[$hwaddr]:-} ]]; then
act_hw2if[$hwaddr]+="+$ifname"
else
act_hw2if[$hwaddr]="$ifname"
fi
act_if2hw[$ifname]="$hwaddr"
done < <(get_net_IFnames_hwaddrs)
}
sub ifaddr_cmd () {
((${#act_hw2if[@]}==0)) && read_actuals
my hwaddr
for ifname in $(printf "%s\n" "${act_hw2if[@]}"|sort|tr "\n" " ") ; do
my first_ifn="$ifname"
if [[ $ifname =~ \+ ]] ; then
first_ifn="${ifname%%+*}"
fi
printf "%s\t%s\n" "$ifname" "${act_if2hw[$first_ifn]}"
done
}
sub start_cmd () {
remap_cmd "$@"
}
sub remap_cmd () {
((${#act_hw2if[@]}==0)) && read_actuals
my key ifname; int count=0
array ifnames=$(printf "%s\n" "${!if2hw[@]}"|sort|
grep -P '^[^~+]*$' |tr "\n" " ")
array rev_ifns=($(rev "${ifnames[@]}" ))
for key in "${rev_ifns[@]}"; do
int is_regex=0; ifname="$key"
if [[ ${key:0:1} == \~ ]];then ifname=${key:1}; is_regex=1; fi
my hwaddr="${if2hw[$key]:-""}"
my actual_hw="${act_if2hw[$ifname]:-""}"
my actual_if="${act_hw2if[$actual_hw]}"
if [[ ${actual_hw:-""} && ! $actual_hw =~ \+ ]]; then
if ((is_regex)); then [[ $actual_hw =~ $hwaddr ]] && continue
else [[ $actual_hw == $hwaddr ]] && continue; fi
if [[ ! ${act_if2hw[$ifname]:-} ]]; then
#Nobody has the name, use it
rename_if "$actual_hw" "$ifname" ; count+=1
else
rename_if "$actual_if" "X$ifname"; #don't count temp renames 2x
XIF["X$ifname"]="$hwaddr"
fi
fi
done
if ((${#XIF[@]}==0)); then echo "HW interfaces appear to be in order."; return 0; fi
int count=0
for ifname in "${!XIF[@]}"; do
hwaddr=${XIF[$ifname]};
ifname=${ifname#X}
my destname=${hw2if[$hwaddr]}
rename_if "$ifname" "$destname" ; count+=1
done
printf "%d interface%s renamed\n" $count "$( (($count!=1)) && echo "s" )"
}
hash switches=([ifmap]=1 [remap]=1 [start]=1)
sub help () {
echo "$_prg:"
echo "Options: -ifmap : show current hw# -> IF map"
echo " -remap : verify & remap ifnames if needed"
return 1
}
if (($#)) ; then
dcl op="${1#:-}"
if [[ ${switches[$op]:-} ]]; then
cmd="${op}_cmd"
shift
$cmd "$@"
else
echo "Unknown switch :-$op"
fi
else
help
fi
#!/bin/bash
#echo enter stdalias.shh
shopt -s expand_aliases extglob sourcepath; set -o pipefail
# NOTE: some aliases need immediate eval if they are used to construct
# following aliases!
#_cmd=_include_stdaliases_
#_cmd2=stdalias.shh_
#[[ $(type -t $_cmd) == function ]] && {
#echo "$_cmd claims to be function, so about to exec..."
#_include_stdaliases_
#exit;
#}
#[[ ${0##*/} != $_cmd2 || $(type -t $_cmd2) == function ]] && { $_cmd2; exit; }
#echo defining function include_stdaliases >&2
# NOTE: This function defines an alias that nullifies itself
# i.e. if aliases are defined, don't need to redefine them!
# But - note: funcs can be exported, aliases cannot, so children
# will only see function
function _include_stdaliases_ {
if [[ -z ${__SALIASES__:=""} ]]; then
readarray -t __ALIASES__<<-'funcdef'
eval "alias aka=alias"
eval "alias dcl=declare"
eval "alias my=declare"
aka sub=function
aka int=declare\ -i
eval "aka array=declare\ -a"
eval "aka string=declare"
eval "aka hash=declare\ -A"
eval "aka intConst=declare\ -ir"
eval "aka intArray=declare\ -ia"
eval "aka intHash=declare\ -iA"
aka stringX=declare\ -x
aka intX=declare\ -ix
aka intConstX=declare\ -ixr
aka disableErrEx='_DsErEx_=${-//*([^x])/}; [[ $_DsErEx_ ]] && set +x'
aka restoreErrEx='[[ $_DsErEx_ ]] && { unset _DsErEx_; set -x; }'
aka include_stdaliases=:
funcdef
typeset -x __SALIASES__="$(typeset -p __ALIASES__)"
fi
eval $__SALIASES__
for aldef in "${__ALIASES__[@]}" ;do
eval "$aldef"
done
}
_include_stdaliases_
#function pathof {
# local prog="$1"
# local path
# for path in $(IFS=:;echo $PATH );do
# path="$path/$prog"
# if [[ -f $path && -x $path ]]; then echo "$path"; return 0; fi
# echo "$prog"
# done
#}
#export -f $cmd
#export __SALIASES__ __ALIASES__
#set -x
#_prog_="$(pathof "$0")"
#if [[ ${0##*/} = $_cmd ]]; then _prog_=~/bin/lib/_stdaliases.shh ; fi
#echo about to exec "\"$_prog_\" \"$@\""
#exec "$_prog_" "$@"
#echo "Error exec of \"$_prog_\" failed: $!"
#exit 1
#int selftest=2+2
#echo "selftest=$selftest"
#. include
# vim: ts=2 sw=2
# aka include_stdaliases=:
# aka include='eval $( _include_h "$1")'
#!/bin/bash
# /etc/rc.status
# vim: syntax=sh
#
# Note -- this is not your mother's rc.status.. rescued from 11.3
# presystemd (law-20130604)
#
# Definition of boot script return messages
#
# The bootscripts should use the variables rc_done and rc_failed to
# report whether they failed or succeeded. See /etc/init.d/skeleton for
# an example how the shell functions rc_status and rc_reset are used.
#
# These functions make use of the variables rc_done and rc_failed;
# rc_done_up and rc_failed_up are the same as rc_done and rc_failed
# but contain a terminal code to move up one line before the output
# of the actual string. (This is particularly useful when the script
# starts a daemon which produces user output with a newline character)
#
# The variable rc_reset is used by the master resource control script
# /etc/init.d/rc to turn off all attributes and switch to the standard
# character set.
#
# \033 ascii ESCape
# \033[<NUM>G move to column <NUM> (linux console, xterm, not vt100)
# \033[<NUM>C move <NUM> columns forward but only upto last column
# \033[<NUM>D move <NUM> columns backward but only upto first column
# \033[<NUM>A move <NUM> rows up
# \033[<NUM>B move <NUM> rows down
# \033[1m switch on bold
# \033[31m switch on red
# \033[32m switch on green
# \033[33m switch on yellow
# \033[m switch off color/bold
# \017 exit alternate mode (xterm, vt100, linux console)
# \033[10m exit alternate mode (linux console)
# \015 carriage return (without newline)
#
# Do _not_ be fooled by non POSIX locale
export LC_ALL=POSIX
shopt -s expand_aliases
alias sub=function
alias dcl=declare
alias int=declare\ -i
# Make sure we have /sbin and /usr/sbin in PATH
case ":$PATH:" in
*:/sbin:*)
;;
*)
PATH=/sbin:/usr/sbin:/usr/local/sbin:$PATH
export PATH
;;
esac
int have_term=1
[[ $TERM == raw || $TERM == dumb || $TERM == unknown ]] && unset have_term
if [[ -t 1 && $have_term ]] ; then
esc='$\033'
extd="${esc}[1m" warn="${esc}[1;31m" done="${esc}[1;32m"
attn="${esc}[1;33m"
printf -v norm "${esc}[m\017"
printf -v stat "\015${esc}[${COLUMNS}C${esc}[10D"
rc_done="${stat}${done}done${norm}"
rc_running="${stat}${done}running${norm}"
rc_failed="${stat}${warn}failed${norm}"
rc_missed="${stat}${warn}missing${norm}"
rc_skipped="${stat}${attn}skipped${norm}"
rc_dead="${stat}${warn}dead${norm}"
rc_unused="${stat}${extd}unused${norm}"
rc_unknown="${stat}${attn}unknown${norm}"
rc_done_up="${esc}[1A${rc_done}"
rc_failed_up="${esc}[1A${rc_failed}"
rc_reset="${norm}${esc}[?25h"
rc_save="${esc}7${esc}[?25l"
rc_restore="${esc}8${esc}[?25h"
sub rc_cuu () { test $1 -eq 0 && return; echo -en "\033[${1}A"; }
sub rc_cud () { test $1 -eq 0 && return; echo -en "\033[${1}B"; }
sub rc_timer_on () {
# Draw seconds of running timout to column.
# Two arguments: timeout in seconds and offset
int n=$1 c=$2
(trap "exit 0" SIGTERM
while ((0
Linda Walsh wrote:
On 20/11/2013 05:39, Carlos E. R. wrote:
On 2013-11-20 14:11, Claudio ML wrote:
Hello all,
I have upgraded my 12.3 test machine to 13.1, with the zypper dup method. The upgrade completed successiful, but, after the first reboot, i have the eth0 network device renamed to ens3.
That's intentional, get used to it... :-}
==== Or write a script to change it... I got tired of my network scripts being renamed at random with various levels of factory installs... so just wrote my own...
FYI, you could have used YaST too. -- Per Jessen, Zürich (1.6°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 21/11/2013 23:09, Per Jessen wrote:
Linda Walsh wrote:
Or write a script to change it... I got tired of my network scripts being renamed at random with various levels of factory installs... so just wrote my own...
FYI, you could have used YaST too.
Yast runs at boot time? My scripts run at boot time during the boot[.d] stage before single user. The net name has to be right before the system comes up or many things expecting to listen on "eth0" will fail during system boot. That's what kept happening -- I'd reboot and couldn't login except by going back to the console and hoping some fabulous graphical prog hasn't tried to put it in a graphics mode, making the screen blank and useless. So... no remote login, no console login.. um... RESCUE DISK! ;-) *sigh*... too much of that and I just wrote my own scripts to ensure things were in the right state for bringup. Have another script that checks for bad symlinks (suse loves those cross-volume forward links -- like from root to some 'yet-to-be-mounted' partition. Then it checks for the libraries used by those programs and ensure they are on the same volume. Before any of that, though, it analyzes the mount structure and figures out which partitions are mounted on what and is able to tell which links are "bad-practice", forward links. I wonder, do you think Dracut might be able to be configured to put together a minimal root config that would allow a user's system to boot from root? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Linda Walsh wrote:
On 21/11/2013 23:09, Per Jessen wrote:
Linda Walsh wrote:
Or write a script to change it... I got tired of my network scripts being renamed at random with various levels of factory installs... so just wrote my own...
FYI, you could have used YaST too.
Yast runs at boot time?
Don't be silly. You can use YaST to write udev rules for renaming which are executed at boot-time. -- Per Jessen, Zürich (2.2°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 23/11/2013 07:15, Per Jessen wrote:
Linda Walsh wrote:
On 21/11/2013 23:09, Per Jessen wrote:
Linda Walsh wrote:
Or write a script to change it... I got tired of my network scripts being renamed at random with various levels of factory installs... so just wrote my own... FYI, you could have used YaST too.
Yast runs at boot time?
Don't be silly. You can use YaST to write udev rules for renaming which are executed at boot-time.
I HAD udev rules. They were upgraded/overwritten during the systemd taking-over udev fiasco. I needed a place to set them that was outside of udev/systemd, since they were part of the problem. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
В Thu, 21 Nov 2013 19:33:23 -0800
Linda Walsh
Or write a script to change it...
rename_if "$actual_if" "X$ifname"; #don't count temp renames 2x
this fails if interface name is already too long.
for ifname in "${!XIF[@]}"; do hwaddr=${XIF[$ifname]}; ifname=${ifname#X} my destname=${hw2if[$hwaddr]} rename_if "$ifname" "$destname" ; count+=1 done
This fails if after you initially renamed ethX to XethX kernel detected new interface and assigned it ethX again. What you try to achieve is much easier achieved by disabling on-demand module loading and loading ethernet drivers in fixed order. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 23/11/2013 00:30, Andrey Borzenkov wrote:
� Thu, 21 Nov 2013 19:33:23 -0800 Linda Walsh
�����: Or write a script to change it...
rename_if "$actual_if" "X$ifname"; #don't count temp renames 2x
this fails if interface name is already too long.
Which never happens in practice. If you have a test case where this fails from a customer system, I'll be happy to fix the script.
for ifname in "${!XIF[@]}"; do hwaddr=${XIF[$ifname]}; ifname=${ifname#X} my destname=${hw2if[$hwaddr]} rename_if "$ifname" "$destname" ; count+=1 done
This fails if after you initially renamed ethX to XethX kernel detected new interface and assigned it ethX again.
---- kernel won't assign it to ethX again, as it is taken. Besides, at the time this module is called, all ethernet interfaces needed for system operation are loaded.
What you try to achieve is much easier achieved by disabling on-demand module loading and loading ethernet drivers in fixed order.
---- Hard to do when they are built into the kernel. -- which is why I say, all of them are already loaded by the time this script runs.. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 23/11/2013 00:30, Andrey Borzenkov wrote:
� Thu, 21 Nov 2013 19:33:23 -0800 Linda Walsh
�����: Or write a script to change it...
rename_if "$actual_if" "X$ifname"; #don't count temp renames 2x
this fails if interface name is already too long.
One other thing -- I only rename interfaces that are in the way of my chosen interface names (eth0..ethX). So I already know the length of them and know that they are "way" under any length requirements. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (12)
-
Andrey Borzenkov
-
Carlos E. R.
-
Claudio ML
-
Duaine Hechler
-
Felix Miata
-
Greg Freemyer
-
John Andersen
-
Linda Walsh
-
Malcolm
-
Patrick Shanahan
-
Per Jessen
-
Werner Flamme