Bug 656520

Summary:	stricter insserv throws fatal error with /etc/init.d/network
Product:	[openSUSE] openSUSE 11.4	Reporter:	Bernhard Wiedemann <bwiedemann>
Component:	Basesystem	Assignee:	Dirk Mueller <dmueller>
Status:	RESOLVED FIXED	QA Contact:	E-mail List <qa-bugs>
Severity:	Normal
Priority:	P5 - None	CC:	dmueller, lnussel, mt, mvidner, suse-beta, werner
Version:	Factory
Target Milestone:	---
Hardware:	All
OS:	Other
Whiteboard:	maint:released:sle11-sp1:40497
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Bernhard Wiedemann 2010-11-30 10:25:13 UTC

this is related to bug 638508 comment 10

yesterday an insserv with stricter checks was committed
http://lists.suse.com/archive/opensuse-commit/2010-11/msg00938.html

while the commit log suggests added warnings, it actually throws FATAL errors for any "insserv xxx" on current Factory, because syslogds are configured to start in runlevel 2, requiring network (for remote-logging), but network is only configured to start in runlevel 3&5

SuSEfirewall, skeleton.compat and vboxadd also require network in runlevel 4, which is supposed to be user-defined.

one easy work-around is to edit /etc/init.d/network to have
# Default-Start:  2 3 4 5
and to insserv -d network

but this might not be what was intended.

Comment 1 Martin Vidner 2010-11-30 10:51:29 UTC

It can also be seen in http://openqa.opensuse.org/opensuse/video/openSUSE-NET-x86_64-Build0910-xfce.ogv at 01:25

Werner, Coolo said you have agreed to make it a non-fatal warning.

Comment 2 Dr. Werner Fink 2010-11-30 10:54:32 UTC

runlevel 4 is a nogo and will never happen ... all packages using
this runlevel are buggy.

The syslog script is fixed and already submitted
also the insserv messages have been made nonfatal
for now (which will be changed back to FATAL).

Comment 3 Ludwig Nussel 2010-11-30 12:34:09 UTC

should we create an rpmlint check that checks for runlevel 4 entries?

Comment 4 Ludwig Nussel 2010-11-30 12:38:28 UTC

/unpacked/head-i586/etc/init.d # grep -l "Default-Start.*4" *
boinc
cgconfig
cgred
chipcardd
collectl
dkimproxy
drbd
iprdump
iprinit
iprupdate
ipsec
irqbindall
logd
namcd
openct
openhpid
openwsmand
pcscd
pommed
powerman
ptpd
puppet
puppetmasterd
set_kthread_prio
sgdisk
sgraid
skeleton.compat
SuSEfirewall2_init
SuSEfirewall2_setup
vboxadd
vboxdrv

Comment 5 Dirk Mueller 2010-12-01 10:08:33 UTC

I agree that this should be a rpmlint warning first, possibly fatal, before breaking it for the user.

Comment 6 Bernhard Wiedemann 2010-12-08 05:39:44 UTC

What is the status of the rpmlint warning about runlevel 4?

Comment 7 Martin Vidner 2010-12-08 14:36:34 UTC

init-script-wrong-start-level in CheckInitScripts.py should probably be extented to mean not only boot-nonboot mismatch but also a forbidden runlevel like 4 or 9. Dirk, you are the maintainer, can you do that?

Comment 8 Christian Boltz 2011-01-07 14:05:09 UTC

I just upgraded from 11.3 to Factory (11.4 between M5 and M6) with zypper dup, and it looks like (nearly) none of the initscripts were fixed.

I have the following symlinks in runlevel 4:

rc4.d/S01SuSEfirewall2_init
rc4.d/S08vboxdrv
rc4.d/S14SuSEfirewall2_setup

The vboxdrv initscript was fixed:
    # Default-Start:  2 3 5
however the symlink in runlevel 4 still exists on my system after the upgrade.

The workaround to cleanup rc4.d is: 
    insserv -r vboxdrv ; insserv vboxdrv
This should probably be done in %post of each affected package (of course it should first be checked if the service is insserv'ed at all).

BTW: Ludwig, do you need a separate bugreport for SuSEfirewall? ;-)

Comment 9 Ludwig Nussel 2011-01-10 13:22:21 UTC

no, I just usually collect a few bugs before touching SuSEfirewall :) submitted now.

Comment 10 Ludwig Nussel 2011-04-29 13:31:41 UTC

rpmlint check is now deployed in factory

Comment 11 Swamp Workflow Management 2011-04-29 15:54:37 UTC

Update released for: SuSEfirewall2
Products:
SLE-DESKTOP 11-SP1 (i386, x86_64)
SLE-SERVER 11-SP1 (i386, ia64, ppc64, s390x, x86_64)
SLES4VMWARE 11-SP1 (i386, x86_64)