Debian Bug report logs - #674517
initscripts: RAMTMP is turned on during upgrades

version graph

Package: initscripts; Maintainer for initscripts is Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>; Source for initscripts is src:sysvinit.

Reported by: Cyril Brulebois <kibi@debian.org>

Date: Fri, 25 May 2012 07:48:01 UTC

Severity: grave

Found in version sysvinit/2.88dsf-22.1

Fixed in version sysvinit/2.88dsf-26

Done: Roger Leigh <rleigh@debian.org>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, kibi@debian.org, Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>:
Bug#674517; Package initscripts. (Fri, 25 May 2012 07:48:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Cyril Brulebois <kibi@debian.org>:
New Bug report received and forwarded. Copy sent to kibi@debian.org, Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>. (Fri, 25 May 2012 07:48:05 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Cyril Brulebois <kibi@debian.org>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: initscripts: RAMTMP is turned on during upgrades
Date: Fri, 25 May 2012 09:44:50 +0200
[Message part 1 (text/plain, inline)]
Package: initscripts
Version: 2.88dsf-22.1
Severity: grave
Justification: fucks up systems during upgrade

Hi,

from previous “RAMTMP isn't so bad” IRC sessions, it appears it's
supposed to be on for new installations, and not turned on during
upgrades.

Except it is.

Reproducibility:
 - install a squeeze VM
 - sed -i s/squeeze/testing/ /etc/apt/sources.list
 - apt-get update && apt-get install initscripts

→ RAMTMP=yes is set.

For your convenience, before/after /etc/default/rcS are attached.

Please stop this craziness.

Mraw,
KiBi.
[rcS.squeeze (text/plain, attachment)]
[rcS (text/plain, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>:
Bug#674517; Package initscripts. (Fri, 25 May 2012 11:00:18 GMT) Full text and rfc822 format available.

Acknowledgement sent to Roger Leigh <rleigh@codelibre.net>:
Extra info received and forwarded to list. Copy sent to Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>. (Fri, 25 May 2012 11:00:20 GMT) Full text and rfc822 format available.

Message #10 received at 674517@bugs.debian.org (full text, mbox):

From: Roger Leigh <rleigh@codelibre.net>
To: Cyril Brulebois <kibi@debian.org>, 674517@bugs.debian.org
Subject: Re: Bug#674517: initscripts: RAMTMP is turned on during upgrades
Date: Fri, 25 May 2012 11:56:32 +0100
On Fri, May 25, 2012 at 09:44:50AM +0200, Cyril Brulebois wrote:
> from previous “RAMTMP isn't so bad” IRC sessions, it appears it's
> supposed to be on for new installations, and not turned on during
> upgrades.

We previously didn't enable this for upgrades primarily because it
wasn't possible to.  It wasn't possible to upgrade /etc/default/rcS.
Also, quite a few people complained about the semantics of RAM* in
rcS changing since it used to refer to /var/* rather than the new
locations (mainly from RAMRUN and RAMLOCK).  To address these concerns,
all the RAM* settings were moved to /etc/default/tmpfs, putting all
the tmpfs-related settings in a single place.  However, this does
result in tmpfs being enabled on upgrade.

Whether the default is set to enabled or disabled, we now have a single
place to configure it, which will take effect for upgrades or new
installs.  Having a consistent default for both upgrades and new
installs is, I think, generally desirable, irrespective of what that
default ends up being.

What problems did you experience as a result of the change?


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux    http://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-    GPG Public Key      F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800




Information forwarded to debian-bugs-dist@lists.debian.org, Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>:
Bug#674517; Package initscripts. (Fri, 25 May 2012 12:36:38 GMT) Full text and rfc822 format available.

Acknowledgement sent to Cyril Brulebois <kibi@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>. (Fri, 25 May 2012 12:37:06 GMT) Full text and rfc822 format available.

Message #15 received at 674517@bugs.debian.org (full text, mbox):

From: Cyril Brulebois <kibi@debian.org>
To: Roger Leigh <rleigh@codelibre.net>
Cc: 674517@bugs.debian.org
Subject: Re: Bug#674517: initscripts: RAMTMP is turned on during upgrades
Date: Fri, 25 May 2012 14:12:32 +0200
[Message part 1 (text/plain, inline)]
Roger Leigh <rleigh@codelibre.net> (25/05/2012):
> We previously didn't enable this for upgrades primarily because it
> wasn't possible to.  It wasn't possible to upgrade /etc/default/rcS.
> Also, quite a few people complained about the semantics of RAM* in
> rcS changing since it used to refer to /var/* rather than the new
> locations (mainly from RAMRUN and RAMLOCK).  To address these concerns,
> all the RAM* settings were moved to /etc/default/tmpfs, putting all
> the tmpfs-related settings in a single place.  However, this does
> result in tmpfs being enabled on upgrade.
> 
> Whether the default is set to enabled or disabled, we now have a single
> place to configure it, which will take effect for upgrades or new
> installs.  Having a consistent default for both upgrades and new
> installs is, I think, generally desirable, irrespective of what that
> default ends up being.

Changing the default on upgrades in *not* acceptable.

> What problems did you experience as a result of the change?

ENOSPC while I have 100's of GB free on that fucking disk I've always
been using. Breaking random apt-get source, breaking random chroot
creation, breaking more or less anything I'm used to use /tmp for.
(Why? Because I don't have to worry about the space there, and on
getting stuff cleaned at some point.)

Mraw,
KiBi.
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>:
Bug#674517; Package initscripts. (Fri, 25 May 2012 14:00:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Roger Leigh <rleigh@codelibre.net>:
Extra info received and forwarded to list. Copy sent to Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>. (Fri, 25 May 2012 14:00:08 GMT) Full text and rfc822 format available.

Message #20 received at 674517@bugs.debian.org (full text, mbox):

From: Roger Leigh <rleigh@codelibre.net>
To: Cyril Brulebois <kibi@debian.org>
Cc: 674517@bugs.debian.org
Subject: Re: Bug#674517: initscripts: RAMTMP is turned on during upgrades
Date: Fri, 25 May 2012 14:57:27 +0100
On Fri, May 25, 2012 at 02:12:32PM +0200, Cyril Brulebois wrote:
> Roger Leigh <rleigh@codelibre.net> (25/05/2012):
> > We previously didn't enable this for upgrades primarily because it
> > wasn't possible to.  It wasn't possible to upgrade /etc/default/rcS.
> > Also, quite a few people complained about the semantics of RAM* in
> > rcS changing since it used to refer to /var/* rather than the new
> > locations (mainly from RAMRUN and RAMLOCK).  To address these concerns,
> > all the RAM* settings were moved to /etc/default/tmpfs, putting all
> > the tmpfs-related settings in a single place.  However, this does
> > result in tmpfs being enabled on upgrade.
> > 
> > Whether the default is set to enabled or disabled, we now have a single
> > place to configure it, which will take effect for upgrades or new
> > installs.  Having a consistent default for both upgrades and new
> > installs is, I think, generally desirable, irrespective of what that
> > default ends up being.
> 
> Changing the default on upgrades in *not* acceptable.

We should probably only have done that for RAMLOCK.  It's definitely
possible to continue to look in rcS for RAMSHM and RAMTMP.  I'll
look at it on Monday.

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux    http://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-    GPG Public Key      F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800




Information forwarded to debian-bugs-dist@lists.debian.org, Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>:
Bug#674517; Package initscripts. (Sun, 27 May 2012 15:39:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Thomas Goirand <zigo@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>. (Sun, 27 May 2012 15:39:03 GMT) Full text and rfc822 format available.

Message #25 received at 674517@bugs.debian.org (full text, mbox):

From: Thomas Goirand <zigo@debian.org>
To: 674517@bugs.debian.org
Subject: Please also make this configurable!
Date: Sun, 27 May 2012 23:36:14 +0800
Hi,

When reading /etc/init.d/mountkernfs.sh, I can't see any ways to have it
*not* to mount /tmp as tmpfs. Even if that's for a new system, I'd like
to be able to *not* use tmpfs, *even* if I have no /tmp entry in my
/etc/fstab.

Please don't screw all my virtual machines. I never asked for this, and
you have no rights to impose it to me (or to anyone). In many of my VMs,
that will just make them crash, or require twice the mount of RAM, which
customers will *not* pay for.

Thomas




Information forwarded to debian-bugs-dist@lists.debian.org, Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>:
Bug#674517; Package initscripts. (Sun, 27 May 2012 17:15:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Roger Leigh <rleigh@codelibre.net>:
Extra info received and forwarded to list. Copy sent to Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>. (Sun, 27 May 2012 17:15:03 GMT) Full text and rfc822 format available.

Message #30 received at 674517@bugs.debian.org (full text, mbox):

From: Roger Leigh <rleigh@codelibre.net>
To: Thomas Goirand <zigo@debian.org>, 674517@bugs.debian.org
Subject: Re: Bug#674517: Please also make this configurable!
Date: Sun, 27 May 2012 18:12:08 +0100
On Sun, May 27, 2012 at 11:36:14PM +0800, Thomas Goirand wrote:
> When reading /etc/init.d/mountkernfs.sh, I can't see any ways to have it
> *not* to mount /tmp as tmpfs. Even if that's for a new system, I'd like
> to be able to *not* use tmpfs, *even* if I have no /tmp entry in my
> /etc/fstab.

This is already configurable.  See RAMTMP in /etc/default/rcS (old) or
/etc/default/tmpfs (new).  Also, please look at the version of
initscripts in experimental.

Also, note that mountkernfs (in experimental, at least), does not
mount /tmp.  See mountall.sh and /lib/init/tmpfs.sh and
/lib/init/mount-functions.sh.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux    http://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-    GPG Public Key      F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800




Information forwarded to debian-bugs-dist@lists.debian.org, Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>:
Bug#674517; Package initscripts. (Sun, 27 May 2012 17:42:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Thomas Goirand <thomas@goirand.fr>:
Extra info received and forwarded to list. Copy sent to Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>. (Sun, 27 May 2012 17:42:03 GMT) Full text and rfc822 format available.

Message #35 received at 674517@bugs.debian.org (full text, mbox):

From: Thomas Goirand <thomas@goirand.fr>
To: 674517@bugs.debian.org
Subject: Re: Bug#674517: Please also make this configurable!
Date: Mon, 28 May 2012 01:39:46 +0800
----- Original message -----
> This is already configurable.   See RAMTMP in /etc/default/rcS (old) or
> /etc/default/tmpfs (new).   Also, please look at the version of
> initscripts in experimental.

I did have a look at /etc/default/tmpfs in SID but
didn't spot the option. Also, /etc/default/rcS is
not referenced at all in the init script. So where
is it???

Thomas





Information forwarded to debian-bugs-dist@lists.debian.org, Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>:
Bug#674517; Package initscripts. (Sun, 27 May 2012 18:00:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Roger Leigh <rleigh@codelibre.net>:
Extra info received and forwarded to list. Copy sent to Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>. (Sun, 27 May 2012 18:00:03 GMT) Full text and rfc822 format available.

Message #40 received at 674517@bugs.debian.org (full text, mbox):

From: Roger Leigh <rleigh@codelibre.net>
To: Thomas Goirand <thomas@goirand.fr>, 674517@bugs.debian.org
Subject: Re: Bug#674517: Please also make this configurable!
Date: Sun, 27 May 2012 18:57:18 +0100
On Mon, May 28, 2012 at 01:39:46AM +0800, Thomas Goirand wrote:
> 
> ----- Original message -----
> > This is already configurable.   See RAMTMP in /etc/default/rcS (old) or
> > /etc/default/tmpfs (new).   Also, please look at the version of
> > initscripts in experimental.
> 
> I did have a look at /etc/default/tmpfs in SID but
> didn't spot the option. Also, /etc/default/rcS is
> not referenced at all in the init script. So where
> is it???

/lib/init/vars.sh

This is also where we'll remove the 'unset RAMTMP' to fix this
specific bug, BTW.

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux    http://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-    GPG Public Key      F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800




Information forwarded to debian-bugs-dist@lists.debian.org, Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>:
Bug#674517; Package initscripts. (Mon, 28 May 2012 19:30:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Thomas Goirand <zigo@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>. (Mon, 28 May 2012 19:30:04 GMT) Full text and rfc822 format available.

Message #45 received at 674517@bugs.debian.org (full text, mbox):

From: Thomas Goirand <zigo@debian.org>
To: 674517@bugs.debian.org
Subject: Don't hide the variable
Date: Tue, 29 May 2012 03:27:39 +0800
Hi,

I'm a DD, I read the init script, and didn't find the variable, which I
really didn't expect to see there. Do you think it would be possible to
have the RAMTMP switch where it's more obvious? I mean, in
/etc/default/tmpfs? (Do I understand well that this is your plan?)

Oh, and while I'm at it, having just "RAMTMP" as a variable name isn't
really self-explanatory, especially with only cryptic comments above it.
How about:

# Set this to yes if you want to mount, at boot time, a tmpfs ramdisk
# in your /tmp.
# Note that by default in Debian, it will use a maximum of 20%
# of your available memory, and potentially make your computer use
# the swap space if large files are written to it and memory usage
# is high. Make sure you have enough swap space and physical RAM
# if you enable this option.
USE_TMPFS_RAMDISK_FOR_TMP=no

That's be much much better, IMO.

And also, the following in /etc/default/tmpfs isn't documented enough IMO:
# TMP_SIZE: maximum size of /tmp
#
# No default size.
TMP_SIZE=

What does "No default size" mean, and what does it do? Gives no limit so
that /tmp can grow as much as needed? Or use TMPFS_SIZE=20%? I believe
the later, given the recent discussions in -devel, but this deserves a
bit more comments.

Cheers,

Thomas

P.S: Sorry if I didn't have a look to the scripts in experimental and if
the fixes are there already! :)




Information forwarded to debian-bugs-dist@lists.debian.org, Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>:
Bug#674517; Package initscripts. (Mon, 28 May 2012 19:45:09 GMT) Full text and rfc822 format available.

Acknowledgement sent to Roger Leigh <rleigh@codelibre.net>:
Extra info received and forwarded to list. Copy sent to Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>. (Mon, 28 May 2012 19:45:09 GMT) Full text and rfc822 format available.

Message #50 received at 674517@bugs.debian.org (full text, mbox):

From: Roger Leigh <rleigh@codelibre.net>
To: Thomas Goirand <zigo@debian.org>, 674517@bugs.debian.org
Subject: Re: Bug#674517: Don't hide the variable
Date: Mon, 28 May 2012 20:42:03 +0100
On Tue, May 29, 2012 at 03:27:39AM +0800, Thomas Goirand wrote:
> Hi,
> 
> I'm a DD, I read the init script, and didn't find the variable, which I
> really didn't expect to see there. Do you think it would be possible to
> have the RAMTMP switch where it's more obvious? I mean, in
> /etc/default/tmpfs? (Do I understand well that this is your plan?)
> P.S: Sorry if I didn't have a look to the scripts in experimental and if
> the fixes are there already! :)

This is all fixed in experimental for a good while.  Please do take a
look.  There's even a tmpfs(5) manpage which explains everything.


Thanks,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux    http://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-    GPG Public Key      F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800




Information forwarded to debian-bugs-dist@lists.debian.org, Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>:
Bug#674517; Package initscripts. (Mon, 28 May 2012 21:09:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Roger Leigh <rleigh@codelibre.net>:
Extra info received and forwarded to list. Copy sent to Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>. (Mon, 28 May 2012 21:09:07 GMT) Full text and rfc822 format available.

Message #55 received at 674517@bugs.debian.org (full text, mbox):

From: Roger Leigh <rleigh@codelibre.net>
To: Cyril Brulebois <kibi@debian.org>
Cc: 674517@bugs.debian.org
Subject: Re: Bug#674517: initscripts: RAMTMP is turned on during upgrades
Date: Mon, 28 May 2012 22:07:35 +0100
On Fri, May 25, 2012 at 02:57:27PM +0100, Roger Leigh wrote:
> On Fri, May 25, 2012 at 02:12:32PM +0200, Cyril Brulebois wrote:
> > Roger Leigh <rleigh@codelibre.net> (25/05/2012):
> > > We previously didn't enable this for upgrades primarily because it
> > > wasn't possible to.  It wasn't possible to upgrade /etc/default/rcS.
> > > Also, quite a few people complained about the semantics of RAM* in
> > > rcS changing since it used to refer to /var/* rather than the new
> > > locations (mainly from RAMRUN and RAMLOCK).  To address these concerns,
> > > all the RAM* settings were moved to /etc/default/tmpfs, putting all
> > > the tmpfs-related settings in a single place.  However, this does
> > > result in tmpfs being enabled on upgrade.
> > > 
> > > Whether the default is set to enabled or disabled, we now have a single
> > > place to configure it, which will take effect for upgrades or new
> > > installs.  Having a consistent default for both upgrades and new
> > > installs is, I think, generally desirable, irrespective of what that
> > > default ends up being.
> > 
> > Changing the default on upgrades in *not* acceptable.
> 
> We should probably only have done that for RAMLOCK.  It's definitely
> possible to continue to look in rcS for RAMSHM and RAMTMP.  I'll
> look at it on Monday.

To keep you up to date, this is what I've done so far.  It's in
sysvinit.git.

  - We no longer comment out RAMSHM or RAMTMP in /etc/default/rcS,
    and these settings are used if present (the settings in tmpfs
    take priority, but these are unset and disabled by default).

This takes care of upgrades, so the existing RAMTMP setting will
be preserved and will continue to be used.  We could also reverse
the commenting of RAMTMP entries in rcS from recent upgrades with
a little more work.  If you feel that this should be undone, I'll
do this as well.

New installs: defaults to default set in initscripts; this is
unchanged.

Upgrades from squeeze: these have never had a RAMTMP setting, so
it will still get enabled by default.  The above only helps
testing/unstable users.  We do need to prevent it being enabled
in this scenario as well.  Thoughts?
- We could, if we are upgrading from the squeeze version, add
  RAMTMP=no to rcS in the preinst.  Ugly, but would match the
  testing/unstable upgrade behaviour.  Alternatively, we could
  edit /etc/default/tmpfs (but it's a conffile).


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux    http://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-    GPG Public Key      F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800




Reply sent to Roger Leigh <rleigh@debian.org>:
You have taken responsibility. (Wed, 06 Jun 2012 22:51:25 GMT) Full text and rfc822 format available.

Notification sent to Cyril Brulebois <kibi@debian.org>:
Bug acknowledged by developer. (Wed, 06 Jun 2012 22:51:25 GMT) Full text and rfc822 format available.

Message #60 received at 674517-close@bugs.debian.org (full text, mbox):

From: Roger Leigh <rleigh@debian.org>
To: 674517-close@bugs.debian.org
Subject: Bug#674517: fixed in sysvinit 2.88dsf-26
Date: Wed, 06 Jun 2012 22:48:30 +0000
Source: sysvinit
Source-Version: 2.88dsf-26

We believe that the bug you reported is fixed in the latest version of
sysvinit, which is due to be installed in the Debian FTP archive:

bootlogd_2.88dsf-26_amd64.deb
  to main/s/sysvinit/bootlogd_2.88dsf-26_amd64.deb
initscripts_2.88dsf-26_amd64.deb
  to main/s/sysvinit/initscripts_2.88dsf-26_amd64.deb
sysv-rc_2.88dsf-26_all.deb
  to main/s/sysvinit/sysv-rc_2.88dsf-26_all.deb
sysvinit-utils_2.88dsf-26_amd64.deb
  to main/s/sysvinit/sysvinit-utils_2.88dsf-26_amd64.deb
sysvinit_2.88dsf-26.debian.tar.gz
  to main/s/sysvinit/sysvinit_2.88dsf-26.debian.tar.gz
sysvinit_2.88dsf-26.dsc
  to main/s/sysvinit/sysvinit_2.88dsf-26.dsc
sysvinit_2.88dsf-26_amd64.deb
  to main/s/sysvinit/sysvinit_2.88dsf-26_amd64.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 674517@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Roger Leigh <rleigh@debian.org> (supplier of updated sysvinit package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Format: 1.8
Date: Mon, 28 May 2012 17:58:38 +0100
Source: sysvinit
Binary: sysvinit sysvinit-utils sysv-rc initscripts bootlogd
Architecture: source amd64 all
Version: 2.88dsf-26
Distribution: unstable
Urgency: low
Maintainer: Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>
Changed-By: Roger Leigh <rleigh@debian.org>
Description: 
 bootlogd   - daemon to log boot messages
 initscripts - scripts for initializing and shutting down the system
 sysv-rc    - System-V-like runlevel change mechanism
 sysvinit   - System-V-like init utilities
 sysvinit-utils - System-V-like utilities
Closes: 386368 630615 665635 666698 674208 674460 674517
Changes: 
 sysvinit (2.88dsf-26) unstable; urgency=low
 .
   [ Roger Leigh ]
   * initscripts:
     - /run/shm is mounted noexec.  Closes: #386368.
     - The RAMSHM and RAMTMP settings in /etc/default/rcS are used if
       present, though the replacement settings in /etc/default/tmpfs
       will override these, if enabled.
     - Revert RAMTMP setting to be disabled by default.
       Closes: #630615, #665635, #666698, #674517.
     - Don't prompt the user on upgrade if rcS was not modified by
       the admin.  Closes: #674460.
   * sysvinit-utils:
     - Fix typo in fstab-decode(8).  Thanks to Bjarni Ingi Gislason.
       Closes: #674208.
Checksums-Sha1: 
 3c82521046fe0bc28aa23f0d4a34271bad6f9a53 2342 sysvinit_2.88dsf-26.dsc
 2652be7e905b67b5a6e8da86a794b98a1a1f0738 201474 sysvinit_2.88dsf-26.debian.tar.gz
 d29edc85b963aaefc4a6171cbfb084ee7ab34723 130062 sysvinit_2.88dsf-26_amd64.deb
 61670601d0b467d078578a4b944077767e6f3c18 96020 sysvinit-utils_2.88dsf-26_amd64.deb
 81de4371959b1339c1aead437d34d3bcea182567 74976 sysv-rc_2.88dsf-26_all.deb
 3932b1b997387d7c28a283125ea19c2cca629b31 87720 initscripts_2.88dsf-26_amd64.deb
 be47b5a4e7b12b52e34fb1df9fbc62e2f6822e39 52116 bootlogd_2.88dsf-26_amd64.deb
Checksums-Sha256: 
 ee6385d301943c4aeb35b037a46ab8c9792707deadcdd32c4274e80389409d87 2342 sysvinit_2.88dsf-26.dsc
 86cc67267ad0d76143aabd10084e93d95c6d4ee4de5fc3d49f073695ca0b9d87 201474 sysvinit_2.88dsf-26.debian.tar.gz
 13863704c20c519c768e74501d7410122b4bdd8197822710a381a4f8caebd0e6 130062 sysvinit_2.88dsf-26_amd64.deb
 1ca84a97924e87200cbe4a99dc5a655ea14ff732a1722b516f47bb5873833b0b 96020 sysvinit-utils_2.88dsf-26_amd64.deb
 7034a86747cc2eefa0a4ea6879371f5f5219a58584489bbc555f6907bae362a6 74976 sysv-rc_2.88dsf-26_all.deb
 ea9ca8dab36bd61a1d61049c291e87ad9696d2426e60d03afeab209abde4ce5a 87720 initscripts_2.88dsf-26_amd64.deb
 2300e379d3ee055625a78ddd5e574ae713b86a577689addf0181dccf0bf4a71f 52116 bootlogd_2.88dsf-26_amd64.deb
Files: 
 60ec6cbc959ca118e00cffbaef5861e3 2342 admin required sysvinit_2.88dsf-26.dsc
 1cf2ebc37120e3d4e7d50fb80588355d 201474 admin required sysvinit_2.88dsf-26.debian.tar.gz
 bea6e21164dc526215269394552362ae 130062 admin required sysvinit_2.88dsf-26_amd64.deb
 3312dc77c0cadff02c69c1ce5c3c41fa 96020 admin required sysvinit-utils_2.88dsf-26_amd64.deb
 b4108cfe9f64c5021171bd56d1122db2 74976 admin required sysv-rc_2.88dsf-26_all.deb
 e284939ba57576e674d64c61507ac030 87720 admin required initscripts_2.88dsf-26_amd64.deb
 e4a725feb457c9d603df328007f1a56e 52116 admin optional bootlogd_2.88dsf-26_amd64.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCgAGBQJPz9lVAAoJEOJSSsUKn1xZcTkQAItYpP6zhOhgHP9EERqjG2M0
uJ2wOJGyGz23tPaYah4jOt1On9ih30EXyoz/1Vk5e56UrBe1V14guw4Qg4nimf1u
SfknjG4xzGf41kus4EpR8OzZXY9GQMtTGBDJsG75UaLZUXEw14bszaRlIZ/Acf6y
x2Q2Sszg0HW5B5Hr32kywo2zlC494XD77y356IWG9VWAxccUY7F+kgKOcQT8wOwL
62TP6ItzH+2d1CpjlFW1RXNXBGyo2U5t8f/rdoSuWVgT0ANHKGoFhyDJ2w/vK656
vNW/JM9HWC+f6lr6HsY4th1B7ZMpImB13WVGIzFsrB+TcFADJ48ikTgOA2jnBlRo
91AYH3sxuBw+iqJMzZsHuZ3cL2Ua4Dwd+/o8o8JYHWpLuY0X5elXIeyZR88KseZx
MYoyixJy1AgiWvre4gut4U5pHq+MUkV/9z3RywDL8S6IfvSnWhhNibeAqcv1ThDB
Ey3YxyY5X3a75hhNtufW4avFWyr4Q+7EGQVQgD08QI0cYIDQN2gZwTUvH9RhXq6T
03h+PT008cwu9GY+2BIxpPWhKgz2jD3h0ke+bP9zXa8BRYDdWNfMHlk30PoUkpoX
X+QNPl4gNbEINrniSL8WkE5Z4pL3qs+UKVn3oIx6FEC9LKi/ut932fgQtZXzfL+M
kk9A39T0ujTHw2mUoXD/
=gNVP
-----END PGP SIGNATURE-----





Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Sat, 01 Sep 2012 07:26:40 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Wed Apr 23 08:16:50 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.