Mailinglist Archive: opensuse-bugs (15090 mails)
| < Previous | Next > |
[Bug 325738] YaST should not copy ifcfg-* config file in case of an system update to 10 .3
- From: bugzilla_noreply@xxxxxxxxxx
- Date: Thu, 20 Sep 2007 08:59:33 -0600 (MDT)
- Message-id: <20070920145933.8FE98CC7AC@xxxxxxxxxxxxxxxxxxxxxx>
https://bugzilla.novell.com/show_bug.cgi?id=325738#c12
Christian Zoz <zoz@xxxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |NEEDINFO
Info Provider| |coolo@xxxxxxxxxx
--- Comment #12 from Christian Zoz <zoz@xxxxxxxxxx> 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.
Christian Zoz <zoz@xxxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |NEEDINFO
Info Provider| |coolo@xxxxxxxxxx
--- Comment #12 from Christian Zoz <zoz@xxxxxxxxxx> 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.
| < Previous | Next > |