Bugzilla – Bug 116537
network install starts a random interfaces after reboot
Last modified: 2008-07-16 15:46:47 UTC
install.inf contains alias: eth0 sungem, also the correct hwaddrs and other stuff, But yast starts eth0 even if the card which has the cable attached became eth1. there is no hwcfg-eth-id-${MAC-addr} file for the config to use.
Created attachment 49660 [details] bug116537.tar.bz2
Olaf, please attach /etc/install.inf (resp. /var/lib/YaST2/install.inf)
Created attachment 49722 [details] install.inf
it seems yast is not consistent regarding network. vnc, ssh and remoteX use /sbin/create_interfaces in the inst-sys to bring up the network. but remote install-source doesnt use this script. fix that.
Network -> mvidner (backup: msvec)
AFAIK during installation exactly /sbin/create_interfaces is used after reboot to set up the network in case of remote installation. What makes you thinking it's not the culprit in this case?
create_interface would have created a ifcfg-eth-id-$MAC, but this file isnt there. If you look at inst_finish.ycp, its not called for (instsource == remote || userinterface == remote), but only for (userinterface == remote).
Just found out, that create_interfaces is used only for s390, ssh and vnc. Let me look.
There's a check for the correct ethX after reboot, but the check doesn't work anymore. It uses ifconfig for enumerating devices and then looks up the HWAddr there and adapt ethX accordingly. The problem is that ifconfig doesn't list the devices despite all modules being loaded. -> it doesn't find out the correct device and thus stays with eth0. I wonder what changed again (this apparently worked some time ago).
The problem is that this command doesn't find the new device: /sbin/ifconfig -a | grep -i "HWaddr *00:30:65:f3:4c:ae" | cut -d" " -f1 Olaf, could you please check what's wrong? It should print 'eth1' in your case, but its output is empty.
it is eth1, maybe the driver was not registered when ifconfig was used?
I thought that too, but when it tries to load modules, the debug message with all loaded modules is printed and it includes both sungem and 8139too: 2005-09-12 17:43:00 <1> linux(14890) [YCP] clients/inst_netsetup.ycp:68 And that ifconfig check is done almost before, I mean no other operation affecting kernel modules is in between, so that's really strange. One test could be useful though: * add -a to ifconfig at /usr/share/YaST2/clients/inst_netsetup.ycp:55 * rm /etc/sysconfig/network/ifcfg-eth* /etc/sysconfig/hardware/hwcfg-* * touch /var/lib/YaST2/runme_at_boot * reboot -> this should run the 2nd inst stage - attach updated y2logs again
I have to copy install.inf to /etc for whatever reason, or hwaddr will be empty. that worked once. all drivers are loaded. instead of that ifconfig grep, do mac= interface=notfound for i in /sys/class/net/*/address do if ! test -f $i ; then continue ; fi read mac < $i if test "$mac" != "$hwaddr" ; then continue ; fi dosomething() break fi but instead of all that crap, use create_interfaces. why is remote source different from remote userinterface? that makes zero sense.
> I have to copy install.inf to /etc for whatever reason, or hwaddr will be > empty. that worked once. all drivers are loaded. Does it mean it worked OK? > but instead of all that crap, use create_interfaces. > why is remote source different from remote userinterface? > that makes zero sense. We should definitely pick one of those things and drop the other, but it's something for the next release.
no it doesnt work. will debug it further tomorrow.
(copied from the mailthread): On Wed, 14 Sep 2005, Olaf Hering wrote: > yast has currently 2 ways to bring up the network after initial reboot. > create_interfaces inside the inst-sys and inst_netsetup in the already > installed system. One has to go by the end of the week. I doubt the date makes sense, at least Martin should take a part and he Shares his Brain ATM ... > What pros and cons have both ways? inst_netsetup: - pros: can use all the infrastructure from network configuration - cons: requires yast infrastructure to be in place / running (*) create_interfaces: - pros: in bash -> easier for !yast people - cons: duplicates what's already done in yast (*) probably blocker for ssh/vnc installation ================================================= This is the problem of an installtionworkflow grown over the year. In most of the installation case s s390 (and ppc) are installing over the network. linuxrc has all the relevant parameters (adapter and IP). create_interfaces just saves those parameters into the installed system. I have no problem if this is done by YaST. But this sould be done in a way that all the different ifdefs for s390/ppc are removed.
so, what is the plan now? create_interfaces in inst-sys or the already installed system?
looking...
Michal's idea from a mail: maybe load_modules should be called before detecting new net device (inst_netsetup.ycp:53). if the module were not loaded, the device might not get found. Also, Olaf replied to comment 17: > inst_netsetup: > - pros: can use all the infrastructure from network configuration > - cons: requires yast infrastructure to be in place / running (*) Yes, /usr/lib/YaST2/startup/YaST2.Second-Stage would have to configure and bring up the network if either userinterface or install source is remote. Maybe we should just move create_interfaces into the /usr/lib/YaST2/startup/YaST2.Second-Stage calls?
What is the status here? A solution in sight?
*** Bug 148615 has been marked as a duplicate of this bug. ***
So, this still happens with 10.1? Then let'S move the report...
Martin, what can we do here? This seems to happen on other hardware as well.
I became lost in trying to figure out how to fix inst_netsetup. It should be really simple to just call create_interface for remote installation sources, but it would change autoyast behavior. What a mess.
There are quite many ways to set up the network during the installation(*) and therefore I prefer a fix that affects the least number of them. This means to fix inst_netsetup even though it imperfectly duplicates setup done elsewhere. I use Michal's suggestion from comment 20, loading the network modules before determining the interface to set up. The fix will be in yast2-network-2.13.31. *: The options are these. A cleanup is needed. -Linuxrc, passed to yast via install.inf (the variants do not make a difference to yast and I mention them for the sake of completeness) -- kernel command line -- info file -- interactively - create_interface (for remote UI) - inst_netsetup (for remote inst source) - autoyast profile, using the proposal as defaults - installation proposal, using install.inf data as defauts - interactive set-up in yast dialogs
*** Bug 132387 has been marked as a duplicate of this bug. ***
Why don't you write udev rules for persisten interface names early? You may just call /lib/udev/rename_netiface <iface>. If called with only one interface it does look for a free interface name (preferrably the current one), renames it if neccesaary and creates a udev rule. If we do that very early in installation system, then you may rely on interface names.
This still seems to be an issue.
*** Bug 157414 has been marked as a duplicate of this bug. ***
Unfortunately the fix in yast2-network-2.13.31 had been reverted in .33 and did not make it to Beta 7. The fix is back again in .34 and in Beta 8.
I just installed a system remotely with SLES10 Beta8. This system has a PCI NIC (eth1) and a PC-Card NIC (eth0). eth1 has a cable connected and was used for installation. But because the system is not a laptop (has a pc-card bridge on PCI-card) the package pcmciautils was not installed. Therefore there was only one network interface after first reboot (the PCI NIC), which would normally become eth0. Then installation will not proceed because of /etc/install.inf:Netdevice: eth1 But i chrooted into the system during package installation and called /lib/udev/rename_netiface eth0 /lib/udev/rename_netiface eth1 which created udev rules properly. So i could proceed installation after reboot. I don't know where to add this call to rename_netiface, but we should do that. Note that loading NIC modules in the right order would have not helped in this special case, because i had not got an interface for the pc-card without pcmciautils.
into same problem in the SL10.1 Beta8 I have, by a Network Installation with DHCP, by starting YaST2, eth1 on a RTL8169 (IP 192.168.100.XXX) and after first reboot eth1 with the IP from DHCP, on a NOT connected (pluged) RTL8139. Later on the installation, "ethx" was changed back? In the /etc/udev/rules.d/30-net_persistent_names.rules the RTL8169 has eth0 ?
Comment 33: Netdevice is not used. There is a hack around it involving the MAC address and this bug was about that hack not working if the interface does not exist. Both of you, Please attach the YaST logs: http://en.opensuse.org/Bug_Reporting_FAQ#YaST
ping?
Comment 33 was a proposal to replace a hack with a solution. What about that? The mentioned machine is hall@suse.de, but i cannot access it currently. I will check why.
Martin, hall.suse.de is reachable now.
Martin, ping!
The logs on hall show that create_interface was used. Looking further.
Created attachment 76148 [details] This are logs from a fresh SLES installation on this morning After first reboot, I have to switch the devices ?
Created attachment 76149 [details] This are logs from a fresh SLES installation on this morning After first reboot, I have to switch the devices ?
Created attachment 76152 [details] This are logs from a fresh SLES installation on this morning This are the logs from a fresh SLES installation this morning.
Comment on attachment 76149 [details] This are logs from a fresh SLES installation on this morning duplicate attachments
Comment 33: Christian, first of all, you should open a separate bug so that yast installs pcmciautils in your case. Actually, I suspect that since create_interface was used, everything would have gone fine even without the manual rename_netiface. Or did you really encounter a problem before fixing it? BTW, I will be in Nuernberg from tomorrow till Thursday.
Comment 43: Indeed, something is wrong and the code fails to determine the current interface name, just like on Friday with Kendy. Looking.
Well, LC_MESSAGES=C is not enough and I was parsing German and Czech output :( Using LANGUAGE and LC_ALL now in yast2-network-2.13.41
*** Bug 159189 has been marked as a duplicate of this bug. ***
*** Bug 157091 has been marked as a duplicate of this bug. ***