NetBSD Problem Report #36508

From martin@duskware.de  Mon Jun 18 21:58:24 2007
Return-Path: <martin@duskware.de>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by narn.NetBSD.org (Postfix) with ESMTP id 5EE6163B908
	for <gnats-bugs@gnats.netbsd.org>; Mon, 18 Jun 2007 21:58:24 +0000 (UTC)
Message-Id: <20070618212552.3557963B908@narn.NetBSD.org>
Date: Mon, 18 Jun 2007 21:25:52 +0000 (UTC)
From: adam.hoka@gmail.com
Reply-To: adam.hoka@gmail.com
To: netbsd-bugs-owner@NetBSD.org
Subject: Init scripts to enable mounting from read only filesystems
X-Send-Pr-Version: www-1.0

>Number:         36508
>Category:       misc
>Synopsis:       Init scripts to enable mounting from read only filesystems
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    misc-bug-people
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Mon Jun 18 22:00:01 +0000 2007
>Last-Modified:  Tue Jul 03 12:50:01 +0000 2007
>Originator:     Adam Hoka
>Release:        NetBSD-4
>Organization:
>Environment:
>Description:
These init scripts are ported from FreeBSD and they make an automatic check wheter the /var and /tmp filesystems are writable at the pont they should be. If they are not, the script mounts a writeable ramdisk device to the read-only directory. The script also populates the /var ramdisk using the mtree tool.

The ramdisks can use both mfs and tmpfs. The tmpfs is the default setting, but it can be overridden in rc.conf, as the size of the ramdisk drives.
The whole scripts also can be disabled or forced in rc.conf.

This let the system to function with only a few limits without a writable filesystem out of the box.
>How-To-Repeat:
Try to boot the system from from a read-only device, without setting ramdisks for /var and/or /tmp in fstab, nor through any other script.
The system won`t be able to work properly.
>Fix:
--- /etc/defaults/rc.conf	2006-10-07 18:50:34.000000000 +0200
+++ /etc/defaults/rc.conf	2007-06-18 21:20:00.000000000 +0200
@@ -321,3 +321,15 @@
 veriexec=NO
 veriexec_strict=0
 veriexec_verbose=0
+
+# Settings for automatic ramdisk mount, by default the system will mount
+# a tmpfs ramdisk for /var and /tmp if they are on non-writable area.
+#
+tmpmfs="AUTO"		# Set to YES to always create an mfs /tmp, NO to never
+tmpmfs_type="tmpfs"	# You can set it to mfs or tmpfs
+tmpsize="20m"		# Size of mfs /tmp if created
+tmpmfs_flags=""	# Extra mdmfs options for the mfs /tmp
+varmfs="AUTO"		# Set to YES to always create an mfs /var, NO to never
+varmfs_type="tmpfs"	# You can set it to mfs or tmpfs
+varsize="32m"		# Size of mfs /var if created
+varmfs_flags=""	# Extra mount options for the mfs /var


--- /dev/null	2007-06-18 20:03:03.000000000 +0200
+++ /etc/rc.d/tmp	2007-06-18 21:20:01.000000000 +0200
@@ -0,0 +1,84 @@
+#!/bin/sh
+#
+# Copyright (c) 1999  Matt Dillon
+# Copyright (c) 2007  Adam Hoka
+# All rights reserved.
+#
+# Redistribution and use in source and binary forms, with or without
+# modification, are permitted provided that the following conditions
+# are met:
+# 1. Redistributions of source code must retain the above copyright
+#    notice, this list of conditions and the following disclaimer.
+# 2. Redistributions in binary form must reproduce the above copyright
+#    notice, this list of conditions and the following disclaimer in the
+#    documentation and/or other materials provided with the distribution.
+#
+# THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+# ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+# SUCH DAMAGE.
+#
+# $FreeBSD: /repoman/r/ncvs/src/etc/rc.d/tmp,v 1.38 2007/05/24 05:54:37 rse Exp $
+#
+
+# PROVIDE: tmp
+# REQUIRE: mountcritremote
+# BEFORE: SERVERS
+
+. /etc/rc.subr
+
+name="tmp"
+
+load_rc_config $name
+
+# If we do not have a writable /tmp, create a memory
+# filesystem for /tmp.  If /tmp is a symlink (e.g. to /var/tmp,
+# then it should already be writable).
+# We invoke the whole script before SERVER, because they may need to
+# write to /tmp.
+
+mount_tmp_ramdisk()
+{               
+case "${tmpmfs_type}" in
+tmpfs)          
+        mount_tmpfs -s ${tmpsize} ${tmpmfs_flags} tmpfs /tmp
+	;;      
+mfs)                    
+	mount_mfs -s ${tmpsize} ${tmpmfs_flags} swap /tmp
+	;;              
+*)              
+	echo "Warning: tmpmfs_type is not properly set, falling back to tmpfs"
+        mount_tmpfs -s ${tmpsize} ${tmpmfs_flags} tmpfs /tmp
+	;;
+esac
+} 
+
+case "${tmpmfs}" in
+[Yy][Ee][Ss])
+	mount_tmp_ramdisk
+	chmod 01777 /tmp
+	;;
+[Nn][Oo])
+	;;
+*)
+	if /bin/mkdir -p /tmp/.diskless 2> /dev/null; then
+		rmdir /tmp/.diskless
+	else
+		if [ -h /tmp ]; then
+			echo "*** /tmp is a symlink to a non-writable area!"
+			echo "dropping into shell, ^D to continue anyway."
+			/bin/sh
+		else
+			mount_tmp_ramdisk
+			chmod 01777 /tmp
+		fi
+	fi
+	;;
+esac


--- /dev/null	2007-06-18 20:03:03.000000000 +0200
+++ /etc/rc.d/var	2007-06-18 21:20:01.000000000 +0200
@@ -0,0 +1,133 @@
+#!/bin/sh
+#
+# Copyright (c) 1999  Matt Dillon
+# Copyright (c) 2007  Adam Hoka
+# All rights reserved.
+#
+# Redistribution and use in source and binary forms, with or without
+# modification, are permitted provided that the following conditions
+# are met:
+# 1. Redistributions of source code must retain the above copyright
+#    notice, this list of conditions and the following disclaimer.
+# 2. Redistributions in binary form must reproduce the above copyright
+#    notice, this list of conditions and the following disclaimer in the
+#    documentation and/or other materials provided with the distribution.
+#
+# THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+# ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+# SUCH DAMAGE.
+#
+# $FreeBSD: /repoman/r/ncvs/src/etc/rc.d/var,v 1.43 2007/05/24 05:54:37 rse Exp $
+#
+
+# PROVIDE: var
+# REQUIRE: mountcritlocal
+# BEFORE: dhclient
+
+$_rc_subr_loaded . /etc/rc.subr
+
+name="var"
+load_rc_config $name
+
+populate_var()
+{
+	(mkdir -p /var/mtree_root && mtree -deU -f /etc/mtree/NetBSD.dist -p /var/mtree_root > /dev/null && mv /var/mtree_root/var/* /var && rm -rf /var/mtree_root)
+}
+
+# I made it possible to choose from using tmpfs or the legacy mfs. 
+#
+mount_var_ramdisk()
+{
+case "${varmfs_type}" in
+tmpfs)
+	mount_tmpfs -s ${varsize} ${varmfs_flags} tmpfs /var
+	;;
+mfs)
+	mount_mfs -s ${varsize} ${varmfs_flags} swap /var
+	;;
+*)
+	echo "Warning: varmfs_type is not properly set, falling back to tmpfs"
+        mount_tmpfs -s ${varsize} ${varmfs_flags} tmpfs /var
+	;;
+esac
+}
+
+# If we do not have a writable /var, create a memory filesystem for /var
+# unless told otherwise by rc.conf.  We don't have /usr yet so use mkdir
+# instead of touch to test.  We want mount to record its mounts so we
+# have to make sure /var/db exists before doing the mount -a.
+# It`s invoked before dhclient because it needs to write a leases file.
+#
+case "${varmfs}" in
+[Yy][Ee][Ss])
+	mount_var_ramdisk
+	;;
+[Nn][Oo])
+	;;
+*)
+	if /bin/mkdir -p /var/.diskless 2> /dev/null; then
+		rmdir /var/.diskless
+	else
+		mount_var_ramdisk
+	fi
+esac
+
+
+# If we have an empty looking /var, populate it, but only if we have
+# /usr available.  Hopefully, we'll eventually find a workaround, but
+# in realistic diskless setups, we're probably ok.
+#
+case "${populate_var}" in
+[Yy][Ee][Ss])
+	populate_var
+	;;
+[Nn][Oo])
+	exit 0
+	;;
+*)
+	if [ -d /var/run -a -d /var/db ] ; then
+		true
+	elif [ -x /usr/sbin/mtree ] ; then
+		populate_var
+	else
+		# We need mtree to populate /var so try mounting /usr.
+		# If this does not work, we can not boot so it is OK to
+		# try to mount out of order.
+		#
+		mount /usr
+		if [ ! -x /usr/sbin/mtree ] ; then
+			exit 1
+		else
+			populate_var
+		fi
+	fi
+	;;
+esac
+
+# Make sure we have /var/log/lastlog,  /var/log/wtmp
+# /var/log/lastlogx and /var/log/wtmpx files
+#
+if [ ! -f /var/log/lastlog ]; then
+	cp /dev/null /var/log/lastlog
+	chmod 644 /var/log/lastlog
+fi
+if [ ! -f /var/log/wtmp ]; then
+	cp /dev/null /var/log/wtmp
+	chmod 644 /var/log/wtmp
+fi
+if [ ! -f /var/log/lastlogx ]; then
+	cp /dev/null /var/log/lastlogx
+	chmod 644 /var/log/lastlogx
+fi
+if [ ! -f /var/log/wtmpx ]; then
+	cp /dev/null /var/log/wtmpx
+	chmod 644 /var/log/wtmpx
+fi

>Audit-Trail:
From: "Johnny C. Lam" <jlam@pkgsrc.org>
To: gnats-bugs@NetBSD.org
Cc: netbsd-bugs@netbsd.org
Subject: Re: misc/36508: Init scripts to enable mounting from read only filesystems
Date: Thu, 28 Jun 2007 22:20:46 +0000

 I don't think these scripts will be good in the general case.

 Take the case of /var.  It is almost certainly a critical file system
 to mount, and so must really be done either within mountcritlocal or
 as a script that REQUIRES root and is BEFORE mountcritlocal.

 I don't think the suggestion to populate /var "only sometimes" makes
 sense.  I understand the difficulty where /var needs to be mounted
 extremely early and one can't rely on the presence of utilities stored
 on /usr, e.g. mtree, chown, chgrp, etc., to help with populating /var.

 Why not create a "mountvar" script that REQUIRES root and is BEFORE
 mountcritlocal that has an additional action "create" that creates
 a .tar file on the root filesystem?  Then the "start" action could
 mount the tmpfs filesystem onto /var and then just extract the .tar
 file directly into /var using /bin/pax.  This avoids any problems
 with not having /usr mounted at boot time.

 The "mounttmp" script should probably grow the option to just symlink
 /tmp to /var/tmp and avoid needing two separate tmpfs mounts for both
 n /var and /tmp.  the cases where one might want to deal with read-only
 root, e.g. for an embedded device, symlinking /tmp to /var/tmp is
 fairly common.  I would guess the "mounttmp" script would REQUIRE
 mountvar and is BEFORE mountcritlocal.

 I do think that these "mountvar" and "mounttmp" scripts should be just
 incorporated directly into the mountcritlocal script.

 	Cheers,

 	-- Johnny Lam <jlam@pkgsrc.org>

From: Adam Hoka <adam.hoka@gmail.com>
To: gnats-bugs@NetBSD.org
Cc: <jlam@pkgsrc.org>
Subject: Re: misc/36508: Init scripts to enable mounting from read only
 filesystems
Date: Tue, 3 Jul 2007 14:46:33 +0200

 On Thu, 28 Jun 2007 22:25:02 +0000 (UTC)
 "Johnny C. Lam" <jlam@pkgsrc.org> wrote:

 > The following reply was made to PR misc/36508; it has been noted by GNATS.
 > 
 > From: "Johnny C. Lam" <jlam@pkgsrc.org>
 > To: gnats-bugs@NetBSD.org
 > Cc: netbsd-bugs@netbsd.org
 > Subject: Re: misc/36508: Init scripts to enable mounting from read only filesystems
 > Date: Thu, 28 Jun 2007 22:20:46 +0000
 > 
 >  I don't think these scripts will be good in the general case.

 Let`s assume you have some hardware problems (or some other reason, you cant prepare for), and you can only mount your drive as read only.
 You will have suddenly an unusably system. (if its starting at all) And you have to find a solution manualy, which is a waste of time. :)
 These scripts check if /var and /tmp should be already writable, and they are not they provide a temporaly space for logs and lease files for example.

 >  Take the case of /var.  It is almost certainly a critical file system
 >  to mount, and so must really be done either within mountcritlocal or
 >  as a script that REQUIRES root and is BEFORE mountcritlocal.

 The script dont know if there will be usable filesystem after mouncritlocal (which would be in normal case)

 >  I don't think the suggestion to populate /var "only sometimes" makes
 >  sense.  I understand the difficulty where /var needs to be mounted
 >  extremely early and one can't rely on the presence of utilities stored
 >  on /usr, e.g. mtree, chown, chgrp, etc., to help with populating /var.
 >  
 >  Why not create a "mountvar" script that REQUIRES root and is BEFORE
 >  mountcritlocal that has an additional action "create" that creates
 >  a .tar file on the root filesystem?  Then the "start" action could
 >  mount the tmpfs filesystem onto /var and then just extract the .tar
 >  file directly into /var using /bin/pax.  This avoids any problems
 >  with not having /usr mounted at boot time.
 >  
 >  The "mounttmp" script should probably grow the option to just symlink
 >  /tmp to /var/tmp and avoid needing two separate tmpfs mounts for both
 >  n /var and /tmp.  the cases where one might want to deal with read-only
 >  root, e.g. for an embedded device, symlinking /tmp to /var/tmp is
 >  fairly common.  I would guess the "mounttmp" script would REQUIRE
 >  mountvar and is BEFORE mountcritlocal.

 If someone wants to really use it in embedded environment, he wont use the defaults but a costumised environment for the task.
 This is why its embedded use. :)
 It`s some kind of a fault tolerancy/sanitiy check, not a complete solution. So please think about it that way.

 >  I do think that these "mountvar" and "mounttmp" scripts should be just
 >  incorporated directly into the mountcritlocal script.

 I just put them as separate scripts because the original implementation did it this way
 They could be part of the mountrcrit scripts. But I think they are good that way.

 thanks for the comment

 -- 
 Adam

Home	PR Database Search