Hello,
i tried to install openSUSE 13.1 with command line
splash=0 vga=0x317 net.ifnames=0 ipv6.disable_ipv6=0 nomodeset
The network is configured during installation, access is possible.
After a reboot ifconfig shows interfaces, but access is not possible.
/etc/udev/rules.d/70-persistent-net.rules is empty, but in
/etc/sysconfig/network there are the ifcfg-files.
What can i do?
Host is openSUSE 12.2 with Virtualbox 4.3.6
Best regards
Predictable naming is now being used with systemd/udev enabled and
persistent naming has been dropped. Explained here
https://bugzilla.novell.com/show_bug.cgi?id=845649
However, you can reinstate the persistent network naming if you prefer.
Thanks for your answer.
I read this about persistent naming:
http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
https://fedoraproject.org/wiki/Talk:Features/ConsistentNetworkDeviceNaming
But i tried to use the old style with kernel-commmand-line:
splash=0 vga=0x317 net.ifnames=0 ipv6.disable_ipv6=0 nomodeset
at boot time / minimal installation.
Where the names stored?
ntop, for example, looks for the eth devices.
And what about smb.conf:
interfaces = eth* lo
?
Best regards
I don’t think that openSUSE is using /etc/udev/rules.d/70-persistent-net.rules anymore in 13.1.
Recommend if you’re able to do a non-network install (You ought to still be able to access source in your LAN if necessary by providing a working pre-boot that supports networking)
The network connection should then be set up automatically. If it’s not, then you should be able to use YAST to modify.
Also, since you’re using Virtualbox, aren’t you going about this wrong?
If this is a new install, you should be pointing the install source in the Guest properties, not in the command line to install
IMO,
TSU
ok guys, what’s the problem?
I try to install openSUSE 13.1 inside Virtualbox.
Network connections are available during installation, but after the last boot
they are not.
Again: older version don’t have this problem.
I installed openSUSE 13.1 yesterday on real hardware with old naming scheme,
this worked for a while, samba-performance on copy was very good.
I tried to change the names to the new naming scheme, so the names are not
predictable! On 3 attempts i got 3 differrent names.
Also the samba performance wehre very bad.
Therefor i want to have the old naming scheme with stable funtionality.
Best regards
They sound like separate issues to me, but perhaps someone else may offer clues.
Anyway, to answer your question about re-instating persistent naming, you need
1)The kernel parameter (as you already mentioned)
net.ifnames=0
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:1C:C4:CF:63:7A", NAME="eth0"
When I booted, I now have the following reported
# ifconfig
eth0 Link encap:Ethernet HWaddr 00:1C:C4:CF:63:7A
inet addr:192.168.1.12 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:815 errors:0 dropped:0 overruns:0 frame:0
TX packets:897 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:301364 (294.3 Kb) TX bytes:156937 (153.2 Kb)
Interrupt:18
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:74 errors:0 dropped:0 overruns:0 frame:0
TX packets:74 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:6676 (6.5 Kb) TX bytes:6676 (6.5 Kb)
I’m using network manager, so the changes work seamlessly. Now I will revert to predictable names again (as I only did this to help you). 
Interesting you created an entry in “70-persistent-net.rules” file and got it to work, when I looked at that file awhile back and found it empty, it surprised me (it’s been populated in earlier openSUSE and is still used in other distros) but I didn’t have the courage then to move ahead and test a configuration like you did.
When I saw it empty, I found what I thought would be relevant entries in
/etc/sysconfig/network/config
But, when I looked closer at the settings, they aren’t necessarily consistent with what exists.
So, it’s still unknown to me where these kinds of networking configurations are being made(maybe more clues would be in the network.service Unit file)
So, if someone who knows what is changing in the network subsystem configuration, it would be nice to know.
TSU
If you change the interface name in YaST->Network Devices->Network Settings, this is stored in “70-persistent-net.rules”. You don’t have to create the rules yourself.
To do this, select the interface on the “Overview” tab, click on “Edit”, switch to the “Hardware” tab and click on “Change” next to the device name.
http://wstaw.org/m/2014/02/07/Bildschirmfoto1.png
And no, “70-persistent-net.rules” DOES NOT contain any configuration. The configurations are in /etc/sysconfig/network/. “70-persistent-net.rules” only contains rules for the naming of the interfaces.
It’s well explained here
http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
What precisely has changed in v197?
With systemd 197 we have added native support for a number of different naming policies into systemd/udevd proper and made a scheme similar to biosdevname’s (but generally more powerful, and closer to kernel-internal device identification schemes) the default. The following different naming schemes for network interfaces are now supported by udev natively:
- Names incorporating Firmware/BIOS provided index numbers for on-board devices (example: eno1)
- Names incorporating Firmware/BIOS provided PCI Express hotplug slot index numbers (example: ens1)
- Names incorporating physical/geographical location of the connector of the hardware (example: enp2s0)
- Names incorporating the interfaces’s MAC address (example: enx78e7d1ea46da)
- Classic, unpredictable kernel-native ethX naming (example: eth0)
By default, systemd v197 will now name interfaces following policy 1) if that information from the firmware is applicable and available, falling back to 2) if that information from the firmware is applicable and available, falling back to 3) if applicable, falling back to 5) in all other cases. Policy 4) is not used by default, but is available if the user chooses so.
This combined policy is only applied as last resort. That means, if the system has biosdevname installed, it will take precedence. If the user has added udev rules which change the name of the kernel devices these will take precedence too. Also, any distribution specific naming schemes generally take precedence.
If you change the interface name in YaST->Network Devices->Network Settings, this is stored in “70-persistent-net.rules”. You don’t have to create the rules yourself.
That, I didn’t realise.
ok, guys i found it:
if you installed openSUSE 13.1 in a Virtulabox, the installation
did automaticly the package ‘virtualbox-guest-kmp-default-4.2.18_k3.11.6_4-2.5.1.x86_64’
After doing
zypper -n up
i had 3 packages:
virtualbox-guest-tools-4.2.18-2.5.1.x86_64
virtualbox-guest-kmp-default-4.2.18_k3.11.6_4-2.2.10.x86_64
virtualbox-guest-kmp-default-4.2.18_k3.11.6_4-2.5.1.x86_64
Remove one solved the problem:
rpm -e virtualbox-guest-kmp-default-4.2.18_k3.11.6_4-2.2.10.x86_64
After that i could install the guest tools:
cd /usr/src/linux
make clean
make oldconfig && make prepare
mount /dev/sr0 /media/dvd
cd /media/dvd
/bin/bash VBoxLinuxAdditions.run
cd /root
umount /media/dvd
eject /dev/sr0
Now i can choose the new and the old naming scheme, if i want and it worked after a reboot also.
NTOP for example will use ‘eth0’ in /etc/sysconfig/ntop
i have to change it manually.
Unfortunately it accepts only 127.0.0.1:3000, not :3000 anymore.
thanks a lot for your efforts.
That’s normal, and because of libzypp’s multi-version feature which is enabled by default for all kernel packages.
Remove one solved the problem:
rpm -e virtualbox-guest-kmp-default-4.2.18_k3.11.6_4-2.2.10.x86_64
After that i could install the guest tools:
cd /usr/src/linux
make clean
make oldconfig && make prepare
mount /dev/sr0 /media/dvd
cd /media/dvd
/bin/bash VBoxLinuxAdditions.run
cd /root
umount /media/dvd
eject /dev/sr0
But the packages above already do contain the guest tools.
Anyway, you removed the kernel module completely in effect by uninstalling one of the virtualbox-guest-kmp packages (the file only exists once).
But you should uninstall all of the other virtualbox-guest-* packages as well, if you install the guest tools from the .run file.
If you don’t do that, it will break again as soon as there’s an update to virtualbox.
It’s never a good idea to have the RPMs installed and their included files overwritten by .run files.
I was posting about
/etc/sysconfig/network/config
which includes
Type: string
Default: “eth*[0-9]|tr*[0-9]|wlan[0-9]|ath[0-9]”
When is not disabled using the NOZEROCONF variable, automatically
add a IPv4 linklocal route to the matching interfaces.
This string is used in a bash “case” statement, so it may contain
‘*’, ‘’, ‘]’ and ‘|’ meta-characters.
LINKLOCAL_INTERFACES=“eth*[0-9]|tr*[0-9]|wlan[0-9]|ath[0-9]”
From what I’ve been able to gather, parts of this file do seem to do something, but the part I quoted apparently does not.
Would be interesting if systemd allowed some way to modify the priority of the interface naming convention.
TSU
I agree with wolfi,
In other Forum threads I’ve described how I install VB Guest Additions, and I also recommend removing <all> existing VB packages before installing new. Something like
zipper rm virtualbox*
Since this is a virtualization issue, if you had searched the Virtualization Forums, you’d likely have found my VB Guest Additions postings instead of having to figure this out on your own, but still congrats for doing so.
I’d also remind you to read the VBox Help, it describes what you need to do to install/configure for updating if you want. Or, you can just periodically check for updates manually in the future.
TSU
This doesn’t have anything to do with interface naming.
This only specifies which interfaces are to be regarded as linklocal interfaces by zeroconf.
The file /etc/sysconfig/network/config has some global network settings, but the actual configuration of each interface is in /etc/sysconfig/network/ifcfg-*interfacename.
*The interface name gets assigned by udev according to its rules.
Yes, i did.
It's never a good idea to have the RPMs installed and their included files overwritten by .run files.
Why?
Best regards
When you install the Guest Additions from the mounted ISO, you are not installing and running the open source version of the Guest Additions provided by the RPMs, you are installing the proprietary version provided directly from Oracle.
By leaving the rpms installed (not removing), your local manifest would list the rpms as installed and marked for updating when a new open source version is released and available in the repos, and then should you pull the rpms for the new open source Guest Additions would overwrite your proprietary Guest Additions.
So, it’s important to remove any/all Guest Additions installed from the repos before you install the Guest Additions from the ISO.
TSU
No, they should be the same.
Where do you think openSUSE gets the guest additions from that they package? 
But of course the versions may differ.
By leaving the rpms installed (not removing), your local manifest would list the rpms as installed and marked for updating when a new open source version is released and available in the repos, and then should you pull the rpms for the new open source Guest Additions would overwrite your proprietary Guest Additions.
Right. The manual installation overwrites the files from the RPMs, and you may get some mixture of files between both which likely might to stop working then. Especially when there’s an update to the openSUSE packages. In that case your manually installed guest additions would probably be overwritten completely again.
I haven’t thought to investigate the Guest Additions source.
I just know that only some things work and others don’t, most obviously Host/Guest sharing and re-installing Guest Additions from the ISO (which of course is guaranteed consistent with the version of VBox running) fixes any problems.
TSU
Host/Guest sharing works fine here with openSUSE’s RPMs. And inserting and installing the guest additions should work the same as well, they are downloaded from the website automatically when you select “Install guest additions” in the menu and they are not found on the hard disk. (I only tried this with a Windows guest though until now)
From the manual:
Starting with version 4.0, VirtualBox is split into several components.
- The base package consists of all open-source components and is licensed under the GNU General Public License V2.
- Additional extension packs can be downloaded which extend the functionality of the VirtualBox base package. Currently, Oracle provides the one extension pack, which can be found at http://www.virtualbox.org and provides the following added functionality:
[LIST=1]- The virtual USB 2.0 (EHCI) device; see Section 3.10.1, “USB settings”.
- VirtualBox Remote Desktop Protocol (VRDP) support; see Section 7.1, “Remote display (VRDP support)”.
- Host webcam passthrough; see chapter Section 9.7.1, “Using a host webcam in the guest”.
- Intel PXE boot ROM.
- Experimental support for PCI passthrough on Linux hosts; see Section 9.6, “PCI passthrough”.
[/LIST]
The open source components (“base package”) should be the same no matter how you install them.
And the Extension package can be installed the same when using the openSUSE RPMs.