cvs commit: hints mtab.txt

timothy at linuxfromscratch.org timothy at linuxfromscratch.org
Tue Jul 30 12:23:22 PDT 2002


timothy     02/07/30 12:23:22

  Modified:    .        mtab.txt
  Log:
  Updates by author.
  
  Revision  Changes    Path
  1.2       +24 -11    hints/mtab.txt
  
  Index: mtab.txt
  ===================================================================
  RCS file: /home/cvsroot/hints/mtab.txt,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- mtab.txt	29 Jul 2002 23:59:23 -0000	1.1
  +++ mtab.txt	30 Jul 2002 19:23:22 -0000	1.2
  @@ -2,8 +2,13 @@
   LFS VERSION:	Any
   AUTHOR:		Oliver Brakmann <obrakmann at gmx.net>
   
  +LAST CHANGES:	2002-07-30: Added a note for those who don't want to
  +			    recompile glibc
  +		2002-07-30: rephrased some parts to prevent misunderstanding
  +		2002-07-29: fixed a couple of typos
  +
   SYNOPSIS:
  -	A default LFS install sets up mtab as a symlink to /proc/mounnts,
  +	A default LFS install sets up mtab as a symlink to /proc/mounts,
   	which breaks (u)mount's behaviour. This hints tells you how to
   	solve this problem elegantly.
   
  @@ -11,8 +16,10 @@
   	If /etc/mtab is a link to /proc/mounts, the following issues with
   the mount/umount programs show up:
   
  -	- the fstab user option doesn't work
  +	- the fstab 'user' option doesn't work
  +	  (you have to specify 'users' as a workaround)
   	- loop devices aren't freed properly when umounting
  +	  (you have to run 'losetup -d' manually)
   	- there was some talk about a wrong root device listed in /etc/mtab,
   	  though I never noticed that. Maybe someone would like to shed
   	  some light on this for me.
  @@ -20,13 +27,13 @@
   The reasons one might want to have /etc/mtab as a link to /proc/mounts are
   the following:
   
  -	- if, for some reason, the system should crash and you have to do
  -	  a hard reboot, /etc/mtab contains inconsistent data upon the
  +	- if, for some reason, the system crashes and you have to do
  +	  a hard reboot, /etc/mtab will not contain inconsistent data upon
   	  the next boot.
   	- you can mount your root partition read-only.
   
  -However, those two points can be dealt with without the need for the symlink.
  -
  +However, those two points can also be dealt with without the need for
  +the symlink.
   
   
   The goal is to have a read-only root partition and an mtab file that isn't
  @@ -60,9 +67,13 @@
   
   	Look up the installation instructions for glibc in the LFS Book.
   
  -	This patch makes freshly compiled programs look for the mtab file
  +	This patch makes newly compiled programs look for the mtab file
   	in /var/lib/misc/mtab.
   
  +	If you absolutely don't want to rebuild glibc, you can probably just
  +	patch /usr/include/paths.h instead of this step.
  +	This is, however, untested.
  +
   	4. now umount /var
   
   		$ umount /var
  @@ -84,11 +95,12 @@
   		$ ln -sf ../var/lib/misc/mtab /etc/mtab
   
   	   Be careful: from this point on, you lose all information about the
  -	   currently mounted partitions! If you have anything mounted that is
  -	   not mounted at boot-time (ie. by the /etc/rc.d/init.d/mountfs
  -	   script), umount it _before_ this step!
  +	   currently mounted partitions (that umount can work with, at least)!
  +	   If you have anything mounted that does not get mounted at boot-time
  +	   (ie. by the /etc/rc.d/init.d/mountfs script), umount it _before_
  +	   this step!
   
  -	7. at this point you can mount /var again
  +	7. at this point you have to mount /var again
   
   		$ mount -n /var
   
  @@ -171,6 +183,7 @@
   
   
   	Finally done! You can telinit back to your favourite run-level now.
  +
   
   OK, as a final note: keep in mind that I take no responsibility whatsoever for
   any damage done to your computer. Be careful doing this, you might badly screw
  
  
  
-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe hints' in the subject header of the message



More information about the hints mailing list