Your message dated Sun, 23 Dec 2018 14:59:15 +0000 with message-id <[email protected]> and subject line Re: Bug#691673: initscripts: please, allow having /run *not* being a RAM disk. has caused the Debian Bug report #691673, regarding initscripts: please, allow having /run *not* being a RAM disk. to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 691673: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691673 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: initscripts Version: 2.88dsf-32 Severity: wishlist Hi. For those people that want to shoot themselves on their own foot, please allow (even if undocumented) running with /run *not* being a ramdisk. This is especially important for memory-starved machines like embedded computers/NASes, where every single byte of RAM is important. Thanks in advance for the great job, Rogério Brito. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.5-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf-8, LC_CTYPE=pt_BR.utf-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages initscripts depends on: ii coreutils 8.13-3.3 ii debianutils 4.3.4 ii libc6 2.13-36 ii lsb-base 4.1+Debian7 ii mount 2.20.1-5.2 ii sysv-rc 2.88dsf-32 ii sysvinit-utils 2.88dsf-32 Versions of packages initscripts recommends: ii e2fsprogs 1.42.5-1 ii psmisc 22.20-1 initscripts suggests no packages. -- Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFCAAAA http://rb.doesntexist.org/blog : Projects : https://github.com/rbrito/ DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--- End Message ---
--- Begin Message ---Seems there is nothing more to discuss. Doing things on your own risk is always possible by editing init.d scripts. They are conffiles, changes are preserved on upgrades. [2012-10-28 12:27] Roger Leigh <[email protected]> > On Sun, Oct 28, 2012 at 12:18:25PM +0000, Roger Leigh wrote: > > On Sun, Oct 28, 2012 at 10:02:57AM -0200, Rogério Brito wrote: > > > For those people that want to shoot themselves on their own foot, please > > > allow (even if undocumented) running with /run *not* being a ramdisk. > > > > > > This is especially important for memory-starved machines like embedded > > > computers/NASes, where every single byte of RAM is important. > > > > We aleady do allow this. Just comment out the > > mount_run and mount_lock lines in /etc/init.d/mountkernfs.sh. > > We allow RAMLOCK to turn off /run/lock; we don't expose a > > RAMRUN to allow /run to be turned off--you do need to edit > > the script directly. > > > > The bootclean logic for cleaning /run still exists, so it > > will continue to work without it being a tmpfs. > > > > However... note that this would be done *entirely* at the > > user's risk. The reason for making /run a tmpfs unilaterally > > was mainly so that it could be relied upon to *be* a tmpfs, > > and so software can therefore assume that a tmpfs is present. > > This is primarily so that software services started in the > > initramfs can retain their state and open files from early > > boot through to the running system. Examples: udev, mdadm. > > While these also have codepaths to allow booting in the > > absence of an initramfs, it is possible that in the future > > these or other services will require a tmpfs. > > Related to this: if you use an initramfs, the initramfs will > mount the tmpfs; initscripts is not involved other than to > adjust the size limits. > > By the way, the size requirements for /run should be tiny. > On a desktop system with quite a lot of stuff running, it's > 600KiB. On a small system doing only a small number of > tasks, it should be just 10s of KiB--i.e. it should not > use much memory at all, and if you have a swap device it > will be swapped out if needed.
--- End Message ---
