[sles-beta] Changing lan adapter names, get stuck rebooting

Joel Barbieri Joel.Barbieri at merge.com
Wed Mar 19 13:01:25 MDT 2014


Some history on NIC naming and why the [mostly random and irritating] new interface names were originally created, or so my failing memory says from kernel posts...

People were unhappy with various network side effects...

Assume a physical box with 4 onboard NICS labeled on the back as:
1 2 3 4

The kernel might give you eth numbers...
0 1 2 3 [yay! we like this]
or [on some Dell systems]
3 2 1 0 [this made people unhappy]
or, weirder yet
0 2 3 1 [that's just mean; SLES10 era, NOT consistent either; some builds were clean, and some were not]

So the kernel developers switched [AFAIK] to "BIOS names," which gave us...
em1 em2 em3 em4 [meh, I miss my eth; time to code]

All of the above properly filled the udev persistent net [name changed a little between 10/11] file and stuck you whatever they came up with.

Since we MFG product on each SLES version, we had to write something to work through whichever silliness...

## pseudocode; my keyboard and MS Outbreak do bad things to my typing
##  my PIPE and BACKSLASH have gone AWOL; time to open the laptop and reset the KB connector

# parse for NIC drivers and store in var; good to process into a sorted, uniq list a la sort -u
DRV=$(hwinfo --netcard PIPE awk -vIGNORECASE=1 '/driver activation cmd/{gsub("BACKSLASH"","",$NF);print $NF}' PIPE sort -u)
# shutdown network
rcnetwork stop
# clear any real entries from udev persistent net rules file
grep -v UDEVPERSISTNETFILE > UDEVPERSISTNETFILE.$$;mv -f UDEVPERSISTNETFILE.$$ UDEVPERSISTNETFILE
# loop through $var and remove all drivers
for aa in $DRV
do
modprobe -r ${aa}
done
# re-add the things in some standardized order; e.g. sort -u list; and udev should re-populate
for aa in $DRV
do
  modprobe ${aa}; sleep 1
done
# udev persistent net rules should be populated
rcnetwork start

# and consider stuffing our values into "MODULES_LOADED_ON_BOOT" in /etc/sysconfig/kernel; though that should be overkill if udev and the persistent net rules are working as advertised
# and consider whether or not you want "MANDATORY INTERFACES", what you want them to be, or to just have them cleared.

Of course, I do not yet know how SLES12 handles this as I have been stuck on other projects at work, but I thought I would share how I overcame this.

-Joel

-----Original Message-----
From: sles-beta-bounces at lists.suse.com [mailto:sles-beta-bounces at lists.suse.com] On Behalf Of Beddingfield, Allen
Sent: Wednesday, March 19, 2014 1:08 PM
To: sles-beta at lists.suse.com
Subject: Re: [sles-beta] Changing lan adapter names, get stuck rebooting

So, to clarify - with the next beta, the expectation is that we should be able to go in and rename our interfaces in yast, without additional mucking around with the config files?  That would be great.
The new scheme is horrible...  in my testing, loading multiple VMs (identical virtual hardware - the MAC address should be all that is different), I get different interface names on different machines.  With the 70-persistent-net.rules, I don't see what was so broken with the eth* scheme.  One could always match a name to a MAC address.
--
Allen Beddingfield
Systems Engineer
The University of Alabama

________________________________________
From: sles-beta-bounces at lists.suse.com [sles-beta-bounces at lists.suse.com] on behalf of Frederic Crozat [fcrozat at suse.com]
Sent: Wednesday, March 19, 2014 12:46 PM
To: sles-beta at lists.suse.com
Subject: Re: [sles-beta] Changing lan adapter names, get stuck rebooting

Le mercredi 19 mars 2014 à 17:37 +0000, Joe Doupnik a écrit :
>      Likely probably many other people, I have no use for the current
> opaquely generated lan adapter names. There is no obvious tie to the
> hardware such as MAC address, in a readily visible fashion. Thus I used
> YaST (text mode) to modify the name to eth0. Yes, it can be done. The
> result was a conventional (at last) 70-persistent-net.rules item in
> /etc/udev/rules.d. My IPtables filter thanked me for that.
>      However, there is a dark side. Restarting the machine from power
> off causes the boot process to get stuck in a wait loop for wicked,
> saying "A start job is running for wicked managed network".
>      Seven and a half minutes later... the system went beyond that point
> and finished booting.
>      There is no wireless or similar arrangement here. No Network
> Manager. Just one Ethernet adapter in this ESXi virtual machine.
>
>      Problem two is to re-ask a question. Where are the systemd lan
> adapter names defined? Those ems32 style things. I have not been able to
> locate them. If found then perhaps reason could be brought to bear to
> return to usable eth0 etc. Having ifcfg-eth0 with real values would be a
> definite plus. The points at hand are clarity, easily located
> configurations, flexibility in operations, but so far in my learning
> process the systemd approach lacks each of these.

Network renaming (allowing you to have eth0 instead of en0s3..) was
broken in Beta2, this might explains why you were stuked.

This will be fixed in Beta3 and for Beta4, we will probably ship a
script to ease the creation of 70-persistent-net.rules based on MAC
address or bus address of the adapter.

For the documentation on the network precitable names, you can have a
look at
http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ as a initial step.

--
Frederic Crozat <fcrozat at suse.com>
SUSE

_______________________________________________
sles-beta mailing list
sles-beta at lists.suse.com
http://lists.suse.com/mailman/listinfo/sles-beta
_______________________________________________
sles-beta mailing list
sles-beta at lists.suse.com
http://lists.suse.com/mailman/listinfo/sles-beta


More information about the sles-beta mailing list