Bug#422257: initscripts: RAMRUN=yes is unusable with some packages

Package: initscripts
Version: 2.86.ds1-38
Severity: normal

Hi,

some packages create subdirectories in /var/run , then expect them to
remain after next reboot. bootclean script does not remove these
directories from real FS. But with RAMRUN, we get an empty directory
without any structure in it. Startup scripts of some packages could
dislike this situation. My testcase :

1. set RAMRUN=yes in /etc/default/tmpfs
2. Reboot the system
3. install courier-imap
4. Reboot the system
5. See courier-imap not starting, unable to create its .pid-file 
	in /var/run/courier/ .

To fix the problem, we have either recreate necessary directories in
/var/run on each startup, or turn off RAMRUN at all before installing
and using such packages. I think this should be either fixed by whoever,
or documented as undesirable side-effect of using RAMRUN.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable')
Architecture: i386 (i686)

Bug#422257: Bug#422257: initscripts: RAMRUN=yes is unusable with some packages

[Wladimir Mutel]
> some packages create subdirectories in /var/run , then expect them
> to remain after next reboot.

These packages are broken, as having /var/run/ as a tmpfs has been a
supported configuration for a long time.  The RAMRUN option was
introduced to make it easier to enable, as well as making it easier to
set up stateless machines, but did not introduce the support for this
feature.

> To fix the problem, we have either recreate necessary directories in
> /var/run on each startup,

Fix the package to create the stuff it need under /var/run/ (and
/var/lock, if needed).

> I think this should be either fixed by whoever, or documented as
> undesirable side-effect of using RAMRUN.

I agree that it should be documented.

Friendly,
--

-- 
Petter Reinholdtsen

Bug#422546: initscripts: /etc/network/if-up.d/mountnfs doesn't mount OCFS2 volumes

Package: initscripts
Version: 2.86.ds1-38
Severity: normal
Tags: patch

OCFS2 requires /etc/init.d/o2cb (from ocfs2-tools package) to be started
first. But current version /etc/network/if-up.d/mountnfs just tries to
mount ocfs2 just like any normal filesystem. More details sent to
debian-devel mailing list yesterday:
http://lists.debian.org/debian-devel/2007/05/msg00132.html

I've added few lines to my /etc/network/if-up.d/mountnfs and it works
for me.

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-xen-686
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to pl_PL.UTF-8)

Versions of packages initscripts depends on:
ii  debianut 2.17                            Miscellaneous utilities specific t
ii  e2fsprog 1.39+1.40-WIP-2006.11.14+dfsg-2 ext2 file system utilities and lib
ii  libc6    2.3.6.ds1-13                    GNU C Library: Shared libraries
ii  lsb-base 3.1-23.1                        Linux Standard Base 3.1 init scrip
ii  mount    2.12r-19                        Tools for mounting and manipulatin
ii  sysvinit 2.86.ds1-38                     System-V-like utilities

Bug#422940: initscripts: usbfs not mounted anymore during system bootup

Package: initscripts
Version: 2.86.ds1-38
Severity: minor

No idea what happens when, I just see after bootup usbfs is not mounted,
/proc/bus/usb is empty, usbview and such software does not show anything. As
this mounting should be done by mountkernfs I report this bug against
initscripts. Please correct me if I am wrong. for a quickfix I edited
/etc/rc.local and start the following:

if [ -e /proc/bus/usb/devices ]
        then echo "usbfs wird wieder automatisch gemountet!"|mail -s "Es is wieder da!!" mschmitt
        else mount -t usbfs none /proc/bus/usb/
fi

this helps for sure... but I'd like to fix this issue rather than workaround
it. As I don't see any special configurations on my system related to that
thing, I believe this may / is a bug and not a missconfiguration and should be
reported. Sorry in advance if I missed something.

As a side note, without this quickfix /proc/mounts and /etc/mtab do show no
usbfs mounted.

greetings
Michael

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')

Bug#403863: Bug has not been reassigned

Please note:

   This bug has not yet been reassigned to chkrootkit due to the email address 
that was used to reassign the bug.  That needs to go to the email address 
control <at> bugs.debian.org.  This is explained in:

   http://www.debian.org/Bugs/server-control

   -- Chris

--

-- 

Chris Knadle
Chris.Knadle <at> coredump.us

Bug#423095: sysvinit: Allow bootsplash packages to hook into fsck events

Package: sysvinit
Version: 2.86.ds1-38
Severity: wishlist
Tags: patch

Hi,

the attached patch changes the sysvinit init.d script(s) to allow splash 
scripts to hook into the fsck stage so that special action can be taken 
(in the case of usplash, this would be to set a high timeout and to let 
the progressbar reflect that an unknown amount of time will be spent 
fscking, splashy would probably want something similar).

--

-- 
David Härdeman

Package: sysvinit
Version: 2.86.ds1-38
Severity: wishlist
Tags: patch

Hi,

the attached patch changes the sysvinit init.d script(s) to allow splash 
scripts to hook into the fsck stage so that special action can be taken 
(in the case of usplash, this would be to set a high timeout and to let 
the progressbar reflect that an unknown amount of time will be spent 

Bug#361717: invoke-rc.d always restarts services in a chroot, runlevel unknown

This bug might be another symptom of Debian Bug # 397900

This bug might be another symptom of Debian Bug # 397900

Bug#403863: Bug #403836 merged with #406493

This post is just for explanation.

Last post was incorrect, as the log in the bug thread shows that the bug was 
reassigned -- my error.
I got confused because I didn't see #403863 anywhere in the list of bugs for 
chkrootkit, and that's because it was merged with #406493.

Appologies for the confusion -- I'm still learning the BTS.

  -- Chris

--

-- 

Chris Knadle
Chris.Knadle <at> coredump.us

Bug#423095: Bug#423095: sysvinit: Allow bootsplash packages to hook into fsck events

[David Härdeman]
> the attached patch changes the sysvinit init.d script(s) to allow splash 
> scripts to hook into the fsck stage so that special action can be taken 
> (in the case of usplash, this would be to set a high timeout and to let 
> the progressbar reflect that an unknown amount of time will be spent 
> fscking, splashy would probably want something similar).

This seem like a good idea to me, and I suspect we should move all the
current usplash hooks into the /lib/init/splash-functions-base file if
we go this way, to make it easier for splasy and others to hook into
the boot system.

Anyone got a complete patch replacing the code in /etc/init.d/rc using
'type usplash_write' to decide what to do?  I suspect at least some
splash_progress is needed. :)

Friendly,
--

-- 
Petter Reinholdtsen

Bug#423095: sysvinit: replacing the code in /etc/init.d/rc to use splash

Petter Reinholdtsen wrote:
> Anyone got a complete patch replacing the code in /etc/init.d/rc using
> 'type usplash_write' to decide what to do?  I suspect at least some
> splash_progress is needed. :)

Attached.

(you need to manually add a splash_progress NOP function to 
/lib/init/splash-functions-base)

-- 
David Härdeman

Petter Reinholdtsen wrote:
> Anyone got a complete patch replacing the code in /etc/init.d/rc using
> 'type usplash_write' to decide what to do?  I suspect at least some
> splash_progress is needed. :)

Attached.

(you need to manually add a splash_progress NOP function to 
/lib/init/splash-functions-base)

--

-- 
David Härdeman