Bug 385498

Summary: update from 10.2: cycle in boot scripts
Product: [openSUSE] openSUSE 11.0 Reporter: Stephan Kulow <coolo>
Component: Update ProblemsAssignee: Dr. Werner Fink <werner>
Status: RESOLVED FIXED QA Contact: Jiri Srain <jsrain>
Severity: Normal    
Priority: P5 - None    
Version: Beta 2   
Target Milestone: ---   
Hardware: Other   
OS: Other   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description Stephan Kulow 2008-05-01 06:12:28 UTC 
dhcpd.rpm fails with the following message:

insserv: loop involving service boot.crypto at depth 3
insserv: loop involving service boot.klog at depth 2
insserv: loop involving service boot.localfs at depth 1
insserv: exiting now

I have no idea where the problem might come from, but dhcpcd's %postun (the one failing) does only insserv_cleanup (and I assume the 10.2 dhcpcd does nothing else)
Comment 1 Stephan Kulow 2008-05-01 06:16:50 UTC 
there is a loop between boot.klog and boot.crypto - that's what every script package update tells me now. I thought YAST_IS_RUNNING leaves out these errors?
Comment 2 Dr. Werner Fink 2008-05-05 09:16:47 UTC 
Looks like intermixed system (10.2 <-> 11.0).  Do you have really updated
*all* packages?
Comment 3 Stephan Kulow 2008-05-05 11:03:06 UTC 
well, these errors happen _during_ the update - the %post of dhcpd is the first one to error out
Comment 4 Dr. Werner Fink 2008-05-05 13:42:15 UTC 
Does this also happen with last change of aaa_base:

  Mon May  5 15:25:00 CEST 2008 - werner@suse.de
  - Replace `/bin/hostname -s' with `/bin/uname -n' (bnc#386621)
  - Also change reference boo.clock in sysconfig and add boot.clock
    as an alias within boot.setclock (bnc#386354)

and with the updated insserv package:

  Mon Apr 28 15:25:54 CEST 2008 - werner@suse.de
  - boot.clock was into two scripts for boot and shutdown
    Todo: make insserv knowing about Required-Stop to merge them
    again to one boot.clock.
Comment 5 Stephan Kulow 2008-05-05 14:22:39 UTC 
don't know.
Comment 6 Stephan Kulow 2008-05-05 15:02:53 UTC 
as we just found out: the old aaa_base is still in place, so it's unlikely it's fixing anything
Comment 7 Stephan Kulow 2008-05-05 15:27:04 UTC 
I put up forwerner and forwerner2.
Comment 8 Dr. Werner Fink 2008-05-05 16:53:00 UTC 
Found the problem in the3 behaviour of the new insserv. It does not ignore
error without using the option -f and as the rpm macro %insserv_cleanup does
not use this option even with YaST/zypper we run into this problem.

Now insserv uses getenv("YAST_IS_RUNNING") and checks for "instsys" to
enforce the option -f for that case.