Bug 112909

Created attachment 47501 [details]
YaST2 logs

From the yast point of view everything looks normal:
Devs=$["eth":$["id-00:00:1c:b5:a4:32":$["BOOTPROTO":"dhcp", "BROADCAST":"",
"IPADDR":"", "MTU":"", "NAME":"DELTA Electronics DECchip 21142/43",
"NETMASK":"255.255.255.0", "NETWORK":"", "REMOTE_IPADDR":"", "STARTMODE":"auto",
"UNIQUE":"rBUF.TKxDWpk5UB7", "USERCONTROL":"no", "_aliases":$[],
"_nm_name":"bus-pci-0000:01:08.0"]
]]

What happens when you call rcnetwork start?

same here. 

rcnetwork start starts everything as it is supposed to do. 

Unfortunately i don't have this problem. Can someone reproduce it?

cp /var/lib/YaST2/install.inf /etc
touch /var/lib/YaST2/runme_at_boot
rm /etc/sysconfig/network/ifcfg-eth-*
reboot

do you want to know what happens or do you need some logs? If so which?

btw. dhcp works after doing the stuff you requested.

But feel free to get my hardware and try a fresh install if that helps

I just made the same experience at kukuks machine. So thanks for your testing.

I have also a problem with the network. 
 
Setting up network interfaces: 
    lo 
    lo        IP address: 127.0.0.1/8 
doneWaiting for mandatory devices:  eth-id-00:11:11:e6:a5:af 
19 18 17 16 15 14 13 12 <notice>checkproc: /opt/kde3/bin/kdm 2955 
11 10 9 8 7 6 5 4 3 2 1 0 
    eth-id-00:11:11:e6:a5:af            No interface found 
failedSetting up service 
network  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .failed 
 
I login as root and start yast2 network, all values are correct, finish the 
module and then I have an interface. 
 
After reboot it is gone.  
 
I attache some logs, ... 
 

Created attachment 47559 [details]
var/log/ from tait.suse.de

Created attachment 47560 [details]
/etc/sysconfig/network/ifcfg-eth-id-00:11:11:e6:a5:af

Michael has another problem.

I'm still looking for someone who can reproduce the initial problem:
"Interface is available, but not or incomplete set up"

Got it and can reproduce it. I compare timestamps in rcnetwork and during
installation time is changing if you don"t use UTC in your system clock. 

So, it should not happen, if UTC is used?  Thorsten, Jana, do you use UTC?

YaST2 should use UTC one that machine, but it did not.
In the system eyes I'm using localtime. Yet Another YaST2 bug :(

YaST says I am using Local Time. The time settings were weird on this system 
anyway. 

For me YaST say i am using UTC  

*** Bug 106040 has been marked as a duplicate of this bug. ***

In /work/built/mbuild/oran-zoz-2 is a sysconfig package that fixes this problem. 
(After next sync also in ftp.suse.com/pub/people/zoz/sysconfig)
If somebody will install again, please update to this package before first reboot.

As soon as /mnt/sbin/ifup exists:
killall -STOP y2base
rpm -Uhv -r /mnt .....
killall -CONT y2base

submitted package --> initial problem fixed

Michaels problem will be handled in bug 113408

Same problem in beta4 if I use local time which is the default.

With UTC it does seem to work during my test.

confirming. reproduced this (even on x86_64)

Local time is proposed by YaST only if there is a windows partition found. 

and according to the logs from comment #1 windows partition was found.

Seems YaST2 always finds a windows partition. My testmachine never had Windows
installed and there is no windows partition on it, but YaST2 claims:

clients/inst_timezone.ycp:236 windows partition found: assuming local time

(this is still from Beta3).

Add comments #24-26: These comments belong to #114333.  The problem here is 
a network problem that occurs if localtime is used.

The localtime default is the bugreport #114333.

#114333 is unrelated to the dhcp problem. It just triggers it in every case. 
 
The network setup must cope with changing timezones and utc/localtime during 
installation. 

so, why does the timezone matter at all?
read /proc/uptime and use that. I'm sure it cant become negative in the cases we
see here.

*** Bug 113606 has been marked as a duplicate of this bug. ***

I removed timestamp stuff completely. It was a bad idea anyway. Now i use status
files for the interfaces. My test up to now were succesful (as always). So
please give ~zoz/Export/sysconfig/* a try (external in ftp.suse.com/pub/people/zoz)

This should be fixed now (finally).

Just installed beta4. The bug is still there. 

Yes -see comment #22 - and it's fixed now for RC1.

sorry for the English: it WILL BE fixed in RC1, it can't be fixed in RC1, as 
RC1 is not on air yet. I am not sure it is smart to declare a bug as fixed 
when nobody from the betatesters has a distribution available to verify it's 
fixed. But this is just MHO. 

It's fixed *for* RC1 - and therefore will be fixed in RC1.

Our practice is to close bugs once we fixed and submitted them.

*** Bug 106040 has been marked as a duplicate of this bug. ***

*** Bug 115005 has been marked as a duplicate of this bug. ***

*** Bug 114948 has been marked as a duplicate of this bug. ***

I just installed RC1 twice and the bug is still there. Installed it on a
notebook and in vmware 4.5. Both installations show the same behaviour.
Network test during installation fails
YaST direct after installation gives the following status for the network device:

AMD PCnet - Fast 79C971
- Gerätename: eth-id-00:0c:29:78:55:5e
- IP-Adresse: , Subtezmaske 255.255.255.0
- Beim Booten automatisch gestartet

After editing only the machine name with YaSt network device window it changes
to the following:

AMD PCnet - Fast 79C971
- Gerätename: eth-id-00:0c:29:78:55:5e
- Über DHCP zugewiesene IP-Adresse
- Beim Booten automatisch gestartet

Created attachment 49328 [details]
y2logs RC1 on vmware

sorry, forgot to reopen the bug

I don't believe that this is the same bug.

What is the state of the network when network test is performed. Switch to
cosole 2 and send us the output of 
  ip a; ip r
  ps ax | grep dhcp
And tell us what you did configure.

If network settings change, when you anly changed hostname, this is a YaST problem.

It is unrelated. Bug 116092. 

*** Bug 114370 has been marked as a duplicate of this bug. ***