Bug#623377: init: don't start in runlevel S *and* 2345

2012-03-08 Thread Michael Biebl
On 21.04.2011 06:07, Ben Hutchings wrote: On Tue, 2011-04-19 at 20:40 +0200, Michael Biebl wrote: [...] All filesystems listed in /etc/fstab should be mounted even in single- user mode. If any of those are mounted over NFS, rpc.statd and portmap or rpcbind must be started. Additional

Bug#623377: init: don't start in runlevel S *and* 2345

2011-11-25 Thread Goswin von Brederlow
Note: libtirpc.so.1 is now in /lib/$(DEB_HOST_MULTIARCH)/ so the demaons can start before /usr is mounted. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive:

Bug#623377: init: don't start in runlevel S *and* 2345

2011-11-25 Thread Luk Claes
On 11/25/2011 07:22 PM, Goswin von Brederlow wrote: Note: libtirpc.so.1 is now in /lib/$(DEB_HOST_MULTIARCH)/ so the demaons can start before /usr is mounted. Sure like now, though not everything is available at that time: kerberised access or NFSv4 idmapping for instance. So it still needs to

Bug#623377: init: don't start in runlevel S *and* 2345

2011-11-25 Thread Ben Hutchings
On Fri, 2011-11-25 at 19:35 +0100, Luk Claes wrote: On 11/25/2011 07:22 PM, Goswin von Brederlow wrote: Note: libtirpc.so.1 is now in /lib/$(DEB_HOST_MULTIARCH)/ so the demaons can start before /usr is mounted. Sure like now, though not everything is available at that time: kerberised

Bug#623377: init: don't start in runlevel S *and* 2345

2011-11-25 Thread Goswin von Brederlow
Ben Hutchings b...@decadent.org.uk writes: On Fri, 2011-11-25 at 19:35 +0100, Luk Claes wrote: On 11/25/2011 07:22 PM, Goswin von Brederlow wrote: Note: libtirpc.so.1 is now in /lib/$(DEB_HOST_MULTIARCH)/ so the demaons can start before /usr is mounted. Sure like now, though not

Bug#623377: init: don't start in runlevel S *and* 2345

2011-04-21 Thread Uwe Kleine-König
Hello Ben, I suppose we should split the init script, assuming that people stuck in the 90s continue to insist that separate /usr must be supported. Then maybe someone should start to make the installer more modern as it still supports a separate /usr in one of the automatic partitioning items.

Bug#623377: init: don't start in runlevel S *and* 2345

2011-04-21 Thread Michael Biebl
Am 21.04.2011 10:35, schrieb Uwe Kleine-König: Hello Ben, I suppose we should split the init script, assuming that people stuck in the 90s continue to insist that separate /usr must be supported. Then maybe someone should start to make the installer more modern as it still supports a

Bug#623377: init: don't start in runlevel S *and* 2345

2011-04-20 Thread Ben Hutchings
On Tue, 2011-04-19 at 20:40 +0200, Michael Biebl wrote: Package: nfs-common, portmap, rpcbind Severity: important Hi, the initscripts of nfs-common, pormap and rpcbind all have the following in their LSB header: # Default-Start: S 2 3 4 5 # Default-Stop: 0 1 6 As a

Bug#623377: init: don't start in runlevel S *and* 2345

2011-04-19 Thread Michael Biebl
Package: nfs-common, portmap, rpcbind Severity: important Hi, the initscripts of nfs-common, pormap and rpcbind all have the following in their LSB header: # Default-Start: S 2 3 4 5 # Default-Stop: 0 1 6 As a result, the init scripts are run *twice* when you boot your system. More

Bug#623377: init: don't start in runlevel S *and* 2345

2011-04-19 Thread Luk Claes
On 04/19/2011 08:40 PM, Michael Biebl wrote: Hi, Hi the initscripts of nfs-common, pormap and rpcbind all have the following in their LSB header: # Default-Start: S 2 3 4 5 # Default-Stop: 0 1 6 Indeed. As a result, the init scripts are run *twice* when you boot your system.

Bug#623377: init: don't start in runlevel S *and* 2345

2011-04-19 Thread Michael Biebl
Hi Luk Am 19.04.2011 22:08, schrieb Luk Claes: On 04/19/2011 08:40 PM, Michael Biebl wrote: nfs-common, portmap and rpcbind are the only packages using such a strange setup in Default-Start. I can't really tell, if those packages are supposed to be started during early boot (rcS) and