headers
Karl Schmidt | 4 Apr 2007 03:32
Favicon

Bug#417657: sysvinit: reboot causes unclean shutdown of md raid1

Package: sysvinit
Version: 2.86.ds1-38
Severity: important

-- System Information:
Debian Release: 4.0
  APT prefers testing
    APT policy: (500, 'testing'), (500, 'stable')
    Architecture: amd64 (x86_64)
    Shell:  /bin/sh linked to /bin/bash
    Kernel: Linux 2.6.18-4-amd64
    Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

    Versions of packages sysvinit depends on:
    ii  initscripts                 2.86.ds1-38  Scripts for initializing and shutt
    ii  libc6                       2.3.6.ds1-13 GNU C Library: Shared libraries
    ii  libselinux1                 1.32-3       SELinux shared libraries
    ii  libsepol1                   1.14-2       Security Enhanced Linux policy lib
    ii  sysv-rc                     2.86.ds1-38  System-V-like runlevel change mech
    ii  sysvinit-utils              2.86.ds1-38  System-V-like utilities

    sysvinit recommends no packages.

    -- no debconf information
    mdadm 2.5.6-9

    Durning shutdown the raid drives are still busy and don't get shutdown correctly. This
    happens intermitently (but more than every other time) and requires a rebuild of the
    raid on start up. There is a potential for data loss here.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Petter Reinholdtsen | 8 Apr 2007 10:39

Bug#417657: Bug#417657: sysvinit: reboot causes unclean shutdown of md raid1

[Karl Schmidt]
> Durning shutdown the raid drives are still busy and don't get
> shutdown correctly. This happens intermitently (but more than every
> other time) and requires a rebuild of the raid on start up. There is
> a potential for data loss here.

Sounds bad.  Isn't this a kernel issue?  I would expect it to be
responsible to shut down the raid, as the shutdown scripts can't as
long as the root file system is mounted, even if it is mounted
read-only.

Friendly,
--

-- 
Petter Reinholdtsen
Permalink | Reply | 0 comments |
headers
Bas Zoetekouw | 9 Apr 2007 20:53
Picon
Favicon

Bug#418445: initscripts: please mount debugfs on boot

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

Please mount debugfs (/sys/kernel/debug) on boot if it is available in
the kernel.  It is required for blktrace, which I'm uploading to
unstable soon (currently in experimental).  It would be great if we
could make blktrace work out of the box in a default debian system.

Thanks,
Bas.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: i386 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.20.4
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)

Versions of packages initscripts depends on:
ii  debianut 2.18                            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

Versions of packages initscripts recommends:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Karl Schmidt | 8 Apr 2007 23:17
Favicon

Bug#417657: Bug#417657: sysvinit: reboot causes unclean shutdown of md raid1

Petter Reinholdtsen wrote:

> Sounds bad.  Isn't this a kernel issue?  I would expect it to be
> responsible to shut down the raid, as the shutdown scripts can't as
> long as the root file system is mounted, even if it is mounted
> read-only.

Could well be - /sbin/shutdown is a command not a script - and I haven't looked at the 
source code. It could be the way the kernel call is made or the kernel itself. I would hope 
the maintainers would forward the bug if appropriate.

----------------------------------------------------------------
Karl Schmidt                         EMail Karl <at> xtronics.com
Transtronics, Inc.                     WEB http://xtronics.com
3209 West 9th Street                    Ph (785) 841-3089
Lawrence, KS 66049                     FAX (785) 841-0434

I wonder why I wonder why; I wonder why I wonder.

----------------------------------------------------------------
Permalink | Reply | 0 comments |
headers
Joerg Platte | 11 Apr 2007 19:57

invoke-rc.d in chroots

Hello,

I hope this has not been discussed before. I installed Debian in a chroot and 
copy this image to several boxes using rsync. Package upgrades are started 
within the chroot environment. 

However, many packages are calling invoke-rc.d during package upgrade 
resulting in error messages, if the daemon cannot be started properly (for 
example, because the same daemon is already running outside the chroot). Is 
it possible to prevent any invoke-rc.d action when the script is called in a 
chroot? Currently, I'm using dpkg-divert to use my own version of 
start-stop-daemon which simply does nothing in the chroot, but not all 
programs are starting daemons using start-stop-daemon.

I could "dpkg-divert" invoke-rc.d as well, but maybe there is less intrusive 
solution.

regards,
Jörg

PS: Please CC me, I'm not subscribed.
Permalink | Reply | 2 comments |
headers
Petter Reinholdtsen | 12 Apr 2007 08:52

Re: invoke-rc.d in chroots

[Joerg Platte]
> Currently, I'm using dpkg-divert to use my own version of
> start-stop-daemon which simply does nothing in the chroot, but not
> all programs are starting daemons using start-stop-daemon.

This is the method used by debian-installer, and I believe all
packages not using start-stop-daemon can be considered broken because
of this.  So I recommend getting the packages fixed, and continue
using start-stop-daemon.  Eventually, every package will use
policy-rc.d, and you can provide your own policy to avoid starting the
daemons.  This is a bit further ahead, though.

> I could "dpkg-divert" invoke-rc.d as well, but maybe there is less intrusive 
> solution.

Not that I am aware of.

Friendly,
--

-- 
Petter Reinholdtsen
Permalink | Reply | 0 comments |
headers
Henrique de Moraes Holschuh | 12 Apr 2007 18:57
Picon
Favicon

Re: invoke-rc.d in chroots

On Wed, 11 Apr 2007, Joerg Platte wrote:
> I hope this has not been discussed before. I installed Debian in a chroot and 
> copy this image to several boxes using rsync. Package upgrades are started 
> within the chroot environment. 

These packages should have bugs filled asking them to switch to invoke-rc.d.

Meanwhile, you need to divert start-stop-daemon (which is what pbuilder and
others do, besides providing restrictive policy-rc.d).

> However, many packages are calling invoke-rc.d during package upgrade 
> resulting in error messages, if the daemon cannot be started properly (for 
> example, because the same daemon is already running outside the chroot). Is 
> it possible to prevent any invoke-rc.d action when the script is called in a 
> chroot? Currently, I'm using dpkg-divert to use my own version of 

Yes, it is.  All incarnations of invoke-rc.d *are* to use policy-rc.d when
they decide to actually do something.  And you can have a policy-rc.d that
does an exit 101, which will forbid any starts, stops, etc.

> I could "dpkg-divert" invoke-rc.d as well, but maybe there is less intrusive 
> solution.

You don't need to. invoke-rc.d does the right thing, if policy-rc.d exists
and exits with status 101. If it doesn't, file a bug, severity important or
higher.  It really is supposed to.

--

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
(Continue reading)

Permalink | Reply | 0 comments |
headers
Julien BLACHE | 14 Apr 2007 11:57
Picon
Favicon

Bug#419195: initscripts: if-up.d/mountnfs should only run after all interfaces have been brought up at boot; hangs boot

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

Hi,

I have a machine here with 2 network interfaces which mounts an NFS FS
from another machine it can only reach via its second network interface.

At boot, if-up.d/mountnfs is run after eth0 has been brought up and the boot
process hangs as it cannot mount the FS until eth1 is up.

The line in fstab looks like:
10.0.1.3:/export/foobar /mnt/foobar nfs rw,hard,intr 0 0

This is really annoying as it requires manual intervention for the machine to
boot.

JB.

-- 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
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages initscripts depends on:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Petter Reinholdtsen | 15 Apr 2007 10:54

Bug#419195: Bug#419195: initscripts: if-up.d/mountnfs should only run after all interfaces have been brought up at boot; hangs boot

[Julien BLACHE]
> At boot, if-up.d/mountnfs is run after eth0 has been brought up and the boot
> process hangs as it cannot mount the FS until eth1 is up.

I believe a workaround is to change the order of the interfaces in
/etc/network/interfaces, to list the interfaces needed to NFS mount
first.

I agree that it is not optimal at the moment, but mounting NFS
directories after ifup solve other problems without known workarounds.

> The line in fstab looks like:
> 10.0.1.3:/export/foobar /mnt/foobar nfs rw,hard,intr 0 0

You can also avoid the problem by adding 'bg' to the option list,
ending up with an entry like this:

   10.0.1.3:/export/foobar /mnt/foobar nfs rw,hard,intr,bg 0 0

Friendly,
--

-- 
Petter Reinholdtsen
Permalink | Reply | 0 comments |
headers
Julien BLACHE | 15 Apr 2007 17:14
Picon
Favicon

Bug#419195: Bug#419195: initscripts: if-up.d/mountnfs should only run after all interfaces have been brought up at boot; hangs boot

Petter Reinholdtsen <pere <at> hungry.com> wrote:

Hi,

> I agree that it is not optimal at the moment, but mounting NFS
> directories after ifup solve other problems without known workarounds.

The problem is that it's not run *after* ifup, it's run after an
interface has been brought up, which is quite different when you're
calling ifup -a as the initscript does.

Maybe ifupdown should be fixed to run the if-up.d scripts only after
it's brought up all the interfaces.

>> The line in fstab looks like:
>> 10.0.1.3:/export/foobar /mnt/foobar nfs rw,hard,intr 0 0
>
> You can also avoid the problem by adding 'bg' to the option list,
> ending up with an entry like this:
>
>    10.0.1.3:/export/foobar /mnt/foobar nfs rw,hard,intr,bg 0 0

I'll try that next time I'll reboot this machine, but I really do not
like that situation at all.

Moreover, there's exactly 0 lines about this in initscripts'
README.Debian, and this appears to be a somewhat known problem...

JB.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane