Bugzilla – Bug 384254
nscd: error in %post
Last modified: 2009-02-18 14:38:46 UTC
Just saw that when updating my workstation: * Installing: nscd-2.8-8 Installation of nscd-2.8-8 failed: (with --nodeps --force) Error: Subprocess failed. Error: RPM failed: insserv: Service boot.clock has to be enabled for service nscd insserv: exiting now! error: %post(nscd-2.8-8.x86_64) scriptlet failed, exit status 1
*** Bug 384257 has been marked as a duplicate of this bug. ***
Bah! Missed it by 3 bug reports :-)
insserv needs a fix really soon I'm afraid.
Already done: 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.
*** Bug 385156 has been marked as a duplicate of this bug. ***
*** Bug 385217 has been marked as a duplicate of this bug. ***
Does this work for anyone? I have the above in the insserv changelog, but I'm still constantly getting: # insserv nscd insserv: Service boot.setclock has to be enabled for service nscd insserv: exiting now! And boot.setclock does not seem to be run on boot either. After a fresh boot, the clock is always off by two hours until running "/etc/init.d/boot.setclock start" manually.
(of course it works after running "chkconfig boot.setclock on", but this does not seem to happen on update without manual intervention)
After a "clean" network install from factory yesterday "insserv nscd" returns nothing and "service nscd status" returns "running". Also the time is now correct after boot. #date Sat May 3 10:40:21 CEST 2008 # hwclock Sat 03 May 2008 10:40:26 AM CEST -0.687756 seconds
Indeed, and I cannot reproduce it a second time even on update. Closing again, will make a new report if this ever happens again.
*** Bug 386693 has been marked as a duplicate of this bug. ***
beta2 on PPC, using 'zypper dup' still fails: nscd-2.8-9 telepítése [kész] A(z) nscd-2.8-9 telepítése meghiúsult: (--nodeps --force használatával) Hiba: Subprocess failed. Error: RPM sikertelen: insserv: Service boot.setclock has to be enabled for service nscd insserv: exiting now! error: %post(nscd-2.8-9.ppc) scriptlet failed, exit status 1
Peter: Please show the result of `rpm -q --changelog aaa_base | head -n 10' ... it should be something like: * Wed Apr 23 2008 werner@suse.de - Force installing ncurses-utils to have tput and reset around * Mon Apr 21 2008 werner@suse.de - Apply last change also for insserv call * Fri Apr 18 2008 werner@suse.de - Split boot.clock into two scripts for boot and shutdown Todo: make insserv knowing about Required-Stop to merge them again to one boot.clock. the change from `Mon Apr 21 2008' should ensure that the service boot.setclock is enabled. Beside this zypper should set the environment variable YAST_IS_RUNNING to "yes" to force insserv to use the option `-f' of insserv.
factory:~ # rpm -q --changelog aaa_base | head -n 10 * sze ápr 23 2008 werner@suse.de - Force installing ncurses-utils to have tput and reset around * h ápr 21 2008 werner@suse.de - Apply last change also for insserv call * p ápr 18 2008 werner@suse.de - Split boot.clock into two scripts for boot and shutdown Todo: make insserv knowing about Required-Stop to merge them again to one boot.clock.
Doesn't seem to be working yet after all.
*** Bug 387120 has been marked as a duplicate of this bug. ***
If you see within the changelog of insserv the following: * Mon May 05 2008 werner@suse.de - Ignore temporary errors during update with YaST/zypper (bnc#385498) and the changelog of aaa_base: * Mon May 05 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) it should be fixed ... clearly after a full update, that is that all packages with failing %post scriptlets are (re)installed or updated to make the change within insserv work ;) Installing only insserv does not help as the missed service links within /etc/init.d/boot.d/ and /etc/init.d/rc*.d/ are done by the post install scripts of the related packages of the scripts.
I installed aaa_base and insserv manually and nscd still fails: jpr@gambit:~/Desktop> rpm -q --changelog aaa_base | head -n 15 * Tue May 06 2008 lrupp@suse.de - added help for 'chkconfig -A' option (bnc#371548) (aa_base-chkconfig-help.patch) - add some lsb-keywords to the init scripts (aa_base-lsb-keywords-patch) - recommend cron as this is not installed per default - disable "Obsoletes: tpctl" for now - added aaa_base-rpmlintrc to suppress some rpmlint warnings * Mon May 05 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 jpr@gambit:~/Desktop> rpm -q --changelog insserv | head * Mon May 05 2008 werner@suse.de - Ignore temporary errors during update with YaST/zypper (bnc#385498) * Mon Apr 28 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. * Wed Apr 09 2008 mkoenig@suse.de as per: Downloading package nscd-2.8-9.i586, 62.0 K (123.0 K unpacked) Downloading: nscd-2.8-9.i586.rpm [done] Installing: nscd-2.8-9 [done] Installation of nscd-2.8-9 failed: (with --nodeps --force) Error: Subprocess failed. Error: RPM failed: error: failed to stat /var/lib/gdm/.gvfs: Permission denied insserv: Service boot.setclock has to be enabled for service nscd insserv: exiting now! error: %post(nscd-2.8-9.i586) scriptlet failed, exit status 1
You have not used YaST nor zypper otherwise the *new* insserv would cry but *never* exit. Beside this after installing the *new* insserv and after this installing the *new* aaa_base the script /etc/init.d/boot.setclock should be linked into the directory /etc/init.d/boot.d/ ... IMHO something went wrong during the your update, IMHO a wrong dependcy order was used for updating.
*** Bug 385296 has been marked as a duplicate of this bug. ***
(In reply to comment #19 from Werner Fink) > You have not used YaST nor zypper otherwise the *new* insserv would cry > but *never* exit. Beside this after installing the *new* insserv and after > this installing the *new* aaa_base the script /etc/init.d/boot.setclock > should be linked into the directory /etc/init.d/boot.d/ ... I used zypper. jpr@gambit:~> sudo zypper install -f nscd Reading installed packages... The following package is going to be reinstalled: nscd The following package is going to be REMOVED: nscd Overall download size: 62.0 K. After the operation, 123.0 K will be freed. Continue? [Y/n/p/?]: y Downloading package nscd-2.8-9.i586, 62.0 K (123.0 K unpacked) Downloading: nscd-2.8-9.i586.rpm [done] Installing: nscd-2.8-9 [done] Installation of nscd-2.8-9 failed: (with --nodeps --force) Error: Subprocess failed. Error: RPM failed: error: failed to stat /var/lib/gdm/.gvfs: Permission denied insserv: Service boot.setclock has to be enabled for service nscd insserv: exiting now! error: %post(nscd-2.8-9.i586) scriptlet failed, exit status 1 Abort, retry, ignore? [A/r/i]:
jpr@gambit:~> ls -al /etc/init.d/boot.setclock -rwxr-xr-x 1 root root 3366 2008-05-05 14:42 /etc/init.d/boot.setclock
If insserv is really upto date *and* (lib)zypper sets the environment variable YAST_IS_RUNNING=instsys this error can not happen as the option -f of insserv will be automatically enabled. The question is: is the script /etc/init.d/boot.setclock enabled, which is simply a start link below /etc/init.d/boot.d/S*boot.setclock
zypper does not set YAST_IS_RUNNING=instsys - why should it, it's neither yast nor in instsys
Without YAST_IS_RUNNING=instsys even the rpm macros will not set the option -f of insserv. It is not possible to do an system update with zypper without this. To use zypper all missed boot and runlevel service links have to enabled with insserv in the correct dependcy order (or all scripts on one command line). This is not a bug of insserv nor of aaa_base this is how it works.
Question: which init/boot scripts had'nt been enabeld during the first update? I'd like to have login access to the system.
coolo: "zypper dup" is kind of like "yast2 upgrade" and the semantics for the update scripts rely on the environment variable. so if zypper dup should be a viable option for upgrading the distro the semantics for the scripts has to be preserved.
(In reply to comment #27 from Dr. Werner Fink) > Question: which init/boot scripts had'nt been enabeld during the first update? boot.setclock is not enabled jpr@gambit:/etc/init.d/boot.d> ls *clock* ls: cannot access *clock*: No such file or directory The aaa_base setup seems to rely on $YAST_IS_RUNNING to setup up everything correctly as well.
That is not fully correct as *all* setup scripts rely on the variable YAST_IS_RUNNING as this variable is used for the insserv and fillup rpm macros, just do `grep -rs YAST_IS_RUNNING /usr/lib/rpm/' ... this will e.g. enforce the usage of the option -f for insserv to ignore errors. This straightened the dependcy problem of(currently) not existing and therefore not enabled boot/init scripts during a full update. Otherwise all package must be installed in the order of the boot/init script dependcies ... nevertheless if on an update this order change you would also run into the same problem if an old but currently installed package violate a new dependcy found in a new package.
(In reply to comment #30 from Werner Fink) > That is not fully correct as *all* setup scripts rely on the variable > YAST_IS_RUNNING as this variable is used for the insserv and fillup > rpm macros, just do `grep -rs YAST_IS_RUNNING /usr/lib/rpm/' ... this > will e.g. enforce the usage of the option -f for insserv to ignore > errors. This straightened the dependcy problem of(currently) not existing > and therefore not enabled boot/init scripts during a full update. > > Otherwise all package must be installed in the order of the boot/init > script dependcies ... nevertheless if on an update this order change > you would also run into the same problem if an old but currently installed > package violate a new dependcy found in a new package. In this case, wouldn't a PreReq be the right way to go? Anyhow, poke me for access to my machine on IM or IRC
This is getting boring :-/ Everytime I do a zypper dup I get this error. And it keeps installing a new version of nscd instead of upgrading; mblxsrv01:/home/mboman # zypper dup Reading installed packages... The following packages are going to be upgraded: novell-nortelplugins java-1_6_0-sun gst-fluendo-mp3 helix-dbus-server flash-player RealPlayer The following packages are going to be reinstalled: terminfo nscd The following packages are going to be REMOVED: nscd nscd nscd terminfo Overall download size: 33.8 M. After the operation, 1.9 M will be freed. Continue? [YES/no]: no mblxsrv01:/home/mboman # rpm -q nscd nscd-2.8-6 nscd-2.8-8 nscd-2.8-9 nscd-2.8-11
*** Bug 389989 has been marked as a duplicate of this bug. ***
Michael? Jan? Do we run into trouble if we set YAST_IS_RUNNING to "instsys" for the `zypper dup' command? In other words does zypper execute the rpm setup scripts (%pre, %post, %preun, %postun, and any %trigger) as YasT does is on update case? Compare with the rpm macros found in /usr/lib/rpm/suse_macros, e.g. %restart_on_update(), %stop_on_removal(), %run_permissions(), %run_suseconfig(), %run_suseconfig_fonts(), %add_start_if_needed(), %insserv_force_if_yast(). If not the variable YAST_IS_RUNNING should be set to "instsys" if zypper is used in dup mode. Otherwise we badly need an other environment variable, like INSSERVOPTS with the value "force". On the other hand, does zypper and/or libzypper use own environment variables in case of `dup' which could be checked by insserv?
First, there is (AFAIK) no difference between zypper dist-upgrade/update -t package/install/verify when it comes to installing rpms. It just calls rpm to install or update the packages you see in summary. That's why nscd update fails also with zypper install (c#22). > Do we run into trouble if we set YAST_IS_RUNNING to "instsys" for the Yes: > `zypper dup' command? In other words does zypper execute the rpm setup > scripts (%pre, %post, %preun, %postun, and any %trigger) as YasT does is > on update case? Compare with the rpm macros found in No, zypper does not do any of this nor does it any other additional work yast does when this variable is used. This is most probably not easily doable (but may be wanted in the future - a FATE request?) OTOH package scripts should be able to function also without such variable, see below. > On the other hand, does zypper and/or libzypper use own environment > variables in case of `dup' which could be checked by insserv? No, zypper/libzypp just calls rpm, it does not set any env variables. You can think of this situation like running the update with plain rpm (look at zypper.log to see how exactly was rpm invoked for each package) on a running system. If it fails like said in this report (it should), it should be fixed to work with plain rpm. Then it will work with zypper, too.
(In reply to comment #32 from Magnus Boman) > This is getting boring :-/ Everytime I do a zypper dup I get this error. And > it keeps installing a new version of nscd instead of upgrading; > > mblxsrv01:/home/mboman # rpm -q nscd > nscd-2.8-6 > nscd-2.8-8 > nscd-2.8-9 > nscd-2.8-11 Now this is something interesting :O) We've been wondering how this happens for some time now. Can you please create a new report, assign to zypp-maintainers and attach zypper.log + solver test case? Thanx.
I wish I could, but I finally ended up getting rid of all nscd with rpm and then zypper worked fine... I see if I can find an older version of factory installed on any of my partitions so that I can supply this information
See Bug#390178
*** Bug 390178 has been marked as a duplicate of this bug. ***
I wonder why Rudi isn't in the CC of this bug. He's probably the only one that knows how our macros work/interact.
@ Ján om comment #35 : Even if `zypper dup' would install all packages in the order of the required boot/init script order this would not help if the order boot/init scripts of the current installed rpm packages will change during an update. This was *one* of the reasons *why* the variable YAST_IS_RUNNING enforce the option -f for insserv. We have to find a way to enable insserv to know when it should ignore dependcy error during (e.g. for `zypper dup' or `yast update'). It is a major feature for insserv to throw an error on a dependcy error for a single rpm package (only).
(In reply to comment #36 from Ján Kupec) > (In reply to comment #32 from Magnus Boman) > > This is getting boring :-/ Everytime I do a zypper dup I get this error. And > > it keeps installing a new version of nscd instead of upgrading; > > > > mblxsrv01:/home/mboman # rpm -q nscd > > nscd-2.8-6 > > nscd-2.8-8 > > nscd-2.8-9 > > nscd-2.8-11 > > Now this is something interesting :O) We've been wondering how this happens for > some time now. Can you please create a new report, assign to zypp-maintainers > and attach zypper.log + solver test case? Thanx. I have this on my machine now.
This mystery (for me) is solved in bug #390178. @Werner: what information do you need from me?
Ok, i cleaned up all the old versions. Still have the same error though: jpr@gambit:~> sudo zypper install -f nscd Reading installed packages... The following package is going to be reinstalled: nscd Overall download size: 62.0 K. No additional space will be used or freed after the operation. Continue? [YES/no]: Downloading package nscd-2.8-11.i586, 62.0 K (123.0 K unpacked) Installing: nscd-2.8-11 [error] Installation of nscd-2.8-11 failed: (with --nodeps --force) Error: Subprocess failed. Error: RPM failed: error: failed to stat /var/lib/gdm/.gvfs: Permission denied insserv: Service boot.setclock has to be enabled for service nscd insserv: exiting now! error: %post(nscd-2.8-11.i586) scriptlet failed, exit status 1 Abort, retry, ignore? [A/r/i]: a
Maybe an ignorant comment, but YAST_IS_RUNNING seems like the wrong path, because what if I've turned off the boot.setclock and then later decide to install nscd individually, won't that break too?
In other words insserv should not throw out any error if an error happens for a single rpm? If a user turns off a single script (e.g. boot.setclock) the the single installation of nscd should throw an error is insservs runs on an error. And yes your system is currently broken and can only be repaired by hand. For an update of a system with changing dependcies between boot/init scripts such errors should be ignored due to the fact that such an error is temporary upto the point where all packages are uptodate. Please note that insserv(8) does not know about simple rpm call nor YaST update nor zypper nor zyppers dup option. It has an simple option -f for ignoring if a required service is missed. Therefore this bug does not belong to me. If zypper has a way to inform all sub processes whats going on (update of a system or single installation of an rpm) then please inform me because then I've to adapt this within insserv.
Fine, fixed by hand - for other's reference: gambit:/home/jpr # YAST_IS_RUNNING=1 zypper install -f aaa_base Reading installed packages... The following package is going to be reinstalled: aaa_base Overall download size: 144.0 K. No additional space will be used or freed after the operation. Continue? [YES/no]: Downloading package aaa_base-11.0-65.i586, 144.0 K (314.0 K unpacked) Downloading: aaa_base-11.0-65.i586.rpm [done (636 B/s)] Installing: aaa_base-11.0-65 [done] gambit:/home/jpr # YAST_IS_RUNNING=1 zypper install -f nscd Reading installed packages... The following package is going to be reinstalled: nscd Overall download size: 62.0 K. No additional space will be used or freed after the operation. Continue? [YES/no]: Downloading package nscd-2.8-11.i586, 62.0 K (123.0 K unpacked) Downloading: nscd-2.8-11.i586.rpm [done (598 B/s)] Installing: nscd-2.8-11 [done]
Werner, 'rpm [-U][-i] nscd' must be possible (without knowing the context in which it is beeing run). We have to handle such situation in %post. YAST_IS_RUNNING was invented for other purposes anyway. Suggestion: why not use insserv -f always? AFAICS, if insserv fails with -f, the service won't get installed anytime later anyway. Or why not handle the failed insserv within the script and print a warning to stderr instead of failing?
Think twice: You can not modify the scripts of an already installed system. All %preun and %postun of the installed system depend on YAST_IS_RUNNING and exist already within the RPM database. Your suggestion will only work for a fresh installed system but *never* on an update ;) You suggestion would only work if we're able to detect within a sub process of the %preun and %postun scripts that rpm has started the scripts.
(In reply to comment #30 from Dr. Werner Fink) > That is not fully correct as *all* setup scripts rely on the variable > YAST_IS_RUNNING as this variable is used for the insserv and fillup > rpm macros, just do `grep -rs YAST_IS_RUNNING /usr/lib/rpm/' ... this > will e.g. enforce the usage of the option -f for insserv to ignore > errors. This straightened the dependcy problem of(currently) not existing > and therefore not enabled boot/init scripts during a full update. Something to fix in the future. > > Otherwise all package must be installed in the order of the boot/init > script dependencies ... nevertheless if on an update this order change > you would also run into the same problem if an old but currently installed > package violate a new dependency found in a new package. > I'd strongly recommend to add proper PreRequires so the correct install/update order can be computed with RPM rules. Moving this request to FATE now.
(In reply to comment #34 from Dr. Werner Fink) > > If not the variable YAST_IS_RUNNING should be set to "instsys" if > zypper is used in dup mode. Otherwise we badly need an other > environment variable, like INSSERVOPTS with the value "force". Werner, how is this supposed to work when just RPM is used from the command line to install/update a package ?
(In reply to comment #41 from Dr. Werner Fink) > Even if `zypper dup' would install all packages in the order of the > required boot/init script order this would not help if the order > boot/init scripts of the current installed rpm packages will change > during an update. This sounds as if the current insserv dependency resolution cannot work with RPM. > This was *one* of the reasons *why* the variable > YAST_IS_RUNNING enforce the option -f for insserv. This environment is not available when just using RPM on the command line. > > We have to find a way to enable insserv to know when it should ignore > dependency error during (e.g. for `zypper dup' or `yast update'). What about "rpm -i" and "rpm -U" ? > It is a major feature for insserv to throw an error on a dependency error > for a single rpm package (only). IMHO, running insserv from within rpm (pre/post scripts) should only warn but not fail. Running insserv from the command line should error out in case of unfulfilled innserv dependency.
Created attachment 215606 [details] C function for determining if rpm scriptlet is used I've submitted an insserv version with the new C function underrpm() which determines if insserv is executed from a parent with the command line /bin/sh /var/tmp/rpm-tmp.<XXXXXX> <NUMBER> (<XXXXXX> random value, <NUMBER>={0,1,2}) which is the normal command line used by rpm for %pre, %post, %preun, and %postun scriptlets. The question remains if i should use the librpm for comparsion as /bin/sh is defined with %_buildshell and /var/tmp with %_tmppath in the rpm rc files. Currently I use hard coded path but can simply switch over to librpm (see attachment). But even if the current rpm package overwrites %_buildshell and %_tmppath in its build spec the global rc files do not fit this.
*** Bug 391326 has been marked as a duplicate of this bug. ***
*** Bug 391840 has been marked as a duplicate of this bug. ***
ping :-)
raising priority and severity
*** Bug 383552 has been marked as a duplicate of this bug. ***
Read comment #53 .. the workaround in insserv is added and submitted. Nevertheless insserv is not able to control the correct installation order which is used by YaST and/or zypper. In other words and IMHO the dependency list of rpm should be extend by the list found in the installed boot/init scripts at the lines Required-Start and Required-Stop, compare with comment #19, comment #26, and comment #50. This could be done by using some lines of shell code used in e.g. /usr/lib/rpm/find-requires for the PreReq tag. See next attachment.
Created attachment 216406 [details] /usr/lib/rpm/find-prerequires.init A module for detecting boot/init PreRequires for boot scripts. Usage in e.g. /usr/lib/rpm/find-requires [ -x ${0%/*}/find-requires.ksyms ] && printf "%s\n" "${filelist[@]}" | ${0%/*}/find-prerequires.init the question is do we have a global find-prerequires around?
Rudi? How the attachment #216406 [details] can be added to the build system to be able to perform an extension of the PreReq tag of the file RPM package?
This will only create a dependency cycle between udev and aaa_base, so what's the point? If this is only about insserv and aaa_base, then fix these two packages and leave the rest alone.
Created attachment 216502 [details] rpm --verbose -Uvh aaa_base The bug is reproducible with a chroot: rpm -r $PWD -e aaa_base --nodeps rpm -r $PWD -ivh <10.3's aaa_base> rpm -r $PWD -Uvh <11.0's aaa_base>
From the log of aaa_base just submitted: Mon May 19 17:52:34 CEST 2008 - Move udev from the Required to the PreRequired list (bnc#384254) - Rename boot.setclock to boot.clock but preserve boot.getclock this avoid to get temporary boot.clock provided twice during update (bnc#384254) just tested with command lines from comment #64 and it works flawless together with the new insserv including change from attachment #215606 [details]
*** Bug 393475 has been marked as a duplicate of this bug. ***
*** Bug 390347 has been marked as a duplicate of this bug. ***
*** Bug 389701 has been marked as a duplicate of this bug. ***
*** Bug 386591 has been marked as a duplicate of this bug. ***
*** Bug 393799 has been marked as a duplicate of this bug. ***
is "NEED" still valid on this bug ?
Not sure what having the incorrect time has got to do with this issue, especially since this is going on for a while and the time issue is very recent. Anyway looking at my panel time now suggests it's 15:31 while my wall clock ( DCF77 driven ) says its 09:31
After rebooting once more it's now 20:21 tray vs 10:21 wall, also hwclock seems to get set to different values on each reboot. Currently at hwclock Mon 26 May 2008 06:19:56 PM CEST -1.013908 seconds while ntpdate ptbtime1.ptb.de 26 May 10:22:48 ntpdate[5075]: step time server 192.53.103.108 offset -35995.484631 sec I still think Bug 393799 is a different issue
If /etc/init.d/boot.clock or /etc/init.d/boot.setclock is missed then the bug is driver by the same behaviour of insserv: by default it does not igmore errors anymore. The current insserv from factory tries to determine if the script used for execution (the parent) is executed by rpm it ignores know errors (hopefully temorary errors). Next is that aaa_base from factory now uses /etc/init.d/boot.clock again, no /etc/init.d/boot.setclock, but /etc/init.d/boot.getclock. This should avoid that during an update there exists temporary two scripts providing both boot.clock in the LSB header. Nevertheless if the error once happened it can only be repaired with a) updating both insserv and aaa_base from factory *and* b) executing the command line insserv boot.clock by hand. This because the rpm post install script assumes that if the start link for boot.clock is missed the user had removed this link and therefore no new link is required.
*** Bug 394497 has been marked as a duplicate of this bug. ***
remove needinfo, please re-set if I'm missing something
Well, what can I say, I followed Werner's advice from Comment #74 and set hwclock and date properly once again, rebooted twice, each time correct time in tray as well as hwclock. Thanks for pointing that out!
(In reply to comment #73 from Casual J. Programmer) > I still think Bug 393799 is a different issue I think so, too. just reopened that bug.
(In reply to comment #74 from Dr. Werner Fink) > If /etc/init.d/boot.clock or /etc/init.d/boot.setclock is missed then the > bug is driver by the same behaviour of insserv: by default it does not > igmore errors anymore. The current insserv from factory tries to determine > if the script used for execution (the parent) is executed by rpm it ignores > know errors (hopefully temorary errors). Next is that aaa_base from factory > now uses /etc/init.d/boot.clock again, no /etc/init.d/boot.setclock, but > /etc/init.d/boot.getclock. This should avoid that during an update there > exists temporary two scripts providing both boot.clock in the LSB header. > Nevertheless if the error once happened it can only be repaired with > a) updating both insserv and aaa_base from factory *and* > b) executing the command line > > insserv boot.clock > > by hand. This because the rpm post install script assumes that if the > start link for boot.clock is missed the user had removed this link and > therefore no new link is required. These instructions were not enough for me to stop zypper from failing to install nscd: I had to uninstall nscd (all installed versions) and then re-install. That worked, though. Michael
To be noted that there are several ncsd get installed is an subsequent error caused by the changed behaviour of insserv. IMHO this will be fixed in the case that an update would be done on a system which was *never* affected by the insserv problem e.g. several ncsd packages installed and/or not enabled boot.clock/boot.setclock scripts also caused by insserv.
Yeah. That is right: uninstalling nscd and then installing did the trick. :-)
BTW: Can it be that a sles10 platform is also affected? Just had a report that sounded exactly the same.
The only difference between insserv from 10.3/SLES10 (including SLES10-SP2) to 11.0 is that a loop detection cause an error. Broken LSB header and and missiong dependcies had caused always an error.
*** Bug 395805 has been marked as a duplicate of this bug. ***
This bug is fixed with the final GM. Nevertheless *all* errors happen by this bug had to be fixed manually by enabling the missed services with insserv on the comand line, e.g. boot.clock.
*** Bug 388194 has been marked as a duplicate of this bug. ***
*** Bug 473332 has been marked as a duplicate of this bug. ***