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

[Beddingfield, Allen]

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