https://bugzilla.novell.com/show_bug.cgi?id=325738 Katarina Machalkova changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=325738#c4 Stephan Kulow changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|Major |Critical Status|NEEDINFO |ASSIGNED Info Provider|coolo@novell.com | Flag|SHIP_STOPPER? |SHIP_STOPPER+ --- Comment #4 from Stephan Kulow 2007-09-20 03:03:13 MST --- if the two-liner is true, I'm all for it :) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=325738#c6 --- Comment #6 from Martin Vidner 2007-09-20 05:01:03 MST --- Created an attachment (id=173635) --> (https://bugzilla.novell.com/attachment.cgi?id=173635) 325738.diff OK, Katarina has prepared a fix: The ifcfg file corresponding to installation-time settings will not be created also if we are in the update mode. That would break the update in the rare case of network-updating a system that had no network before. To address that, we should also check whether there is *any* ifcfg (except ifcfg-lo) on the target system. Also, this will result in using the old ifcfg but new (installation-time) hostname, routes, and resolver. I hope that it is OK. In summary, the fix is simple but the implications are not. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=325738#c8 --- Comment #8 from Christopher Stender 2007-09-20 05:23:24 MST --- I hope you only changed the update case? In case of an update we shouldn't copy this file. This has the effect you described: If someone has no valid network configuration before, the update doesn't change anything. In case of a working network in 10.2 this setup also works in 10.3 and I think this is the way to go. No further changes. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=325738#c10 --- Comment #10 from Lukas Ocilka 2007-09-20 05:30:16 MST --- Because there is a new feature in inst-sys -- you can configure you network to use either DHCP or Static configuration. This configuration is not taken from the system just being updated. Anyway, I'm for implementing the fix -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=325738#c12 Christian Zoz changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO Info Provider| |coolo@novell.com --- Comment #12 from Christian Zoz 2007-09-20 08:59:33 MST --- Imho, worst solution is to mix old and new settings. I guess i have to explain the problem we encountered more detailed: Imagine there is a system with several NICs and each interface has its persistent interface name (in 10.2 it was in 30-network*rules). In this example let's say that the NIC that will be used for update had the name eth4. Now when we boot into installation system, these namings will not (and can not) be used. The interface now is called e.g. eth2. While updating packages sysconfig converts 30-network*rules into 70-persistent-net.rules and also converts all of the old network configuration files. At the end of stage 1 YaST copies ifcfg-eth2 into the installed system. When then updated system is booted for the first time, the old persistent names will be used again. That means, the interface which ifcfg-eth2 is for is now called eth4. Therefore it does not make sense to copy ifcfg files from instsys into updated system without at least checking for the right name of the interface. So far the example. If we use the network settings from instsys in the updated system or not is another question. But if we use it then complete and the ifcfg file must have the right name. If we don't use it, then also don't copy other network settings as resolver, routes, names and so on. I leave the question how to proceed here to the project manager. Fell free to ask me, but i'm in a confcall for the next hour. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=325738#c14 Christian Zoz changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO Info Provider| |mvidner@novell.com --- Comment #14 from Christian Zoz 2007-09-21 01:28:59 MST --- eth4 was just an example. 2 cards are enough to get it mixed. And every modern laptop has two cards. Even one card is enough if you gave it an individual name. Martin, can we savely remove all network modification? So that no settings get changed during update? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=325738#c16 Martin Vidner changed: What |Removed |Added ---------------------------------------------------------------------------- Info Provider|mvidner@novell.com |zoz@novell.com --- Comment #16 from Martin Vidner 2007-09-21 02:58:18 MST --- So the old behavior of copying the installation-time settings to the updated system has been there since ages (I stopped in 2004) and I could not find any related bugs. I can't think of possible breakage when we keep the old settings (except where there are no settings (comment 6). But still it is a substantial change at a very late stage. So let's also consider leaving the yast code as it is and modifying the ifcfg migration script instead. Comment 0:

It causes failure messages on system boot.

Without knowing the script, I imagine that it complains when it converts an ifcfg from an old name to a new one and the new one already exists (because yast has created it). So perhaps we could just delete the old file and let the new one prevail. Christian? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=325738 Andreas Jaeger changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|bnc-team-screening@forge.provo.novell.com |mvidner@novell.com -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=325738#c18 michal zugec changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #18 from michal zugec 2007-09-24 03:06:23 MST --- fixed in yast2-network-2.15.80 for update is not called save_network function at all -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.