Re: 7r5beta bug report (/etc/mtab)

From: Clive Wright (clive_wright@telinco.co.uk)
Date: Tue Dec 28 1999 - 03:42:30 CET


Michele Andreoli wrote:
>
> On Mon, Dec 27, 1999 at 01:11:17AM +0000, Dave Houghton nicely wrote:
> >
> > >
> > >How you discovered the bug?!
> >
> > in /etc/rc.4 after you set the PATH but immediately before you mount the "real" root file system add the following line:-
> >
> > rm -f /etc/mtab 2>/dev/null
>
> The different behaviour is due to two concurrent ... autoexec.bat in
> mulinux: /linuxrc and /etc/rc.4. Both mount root.
>
> --- /linuxrc
> ... snip ..
> > /etc/mtab
> mount -o remount,rw / 2>/dev/null
> .. snip ..
>
> --- /etc/rc.4
>
> .. snip ..
> mount -o remount,rw / 2>/dev/null
> [ -z "$root_device" ] && mount -f /
> .. snip ..
>
> In /etc/mtab ther is the list of mounted partition. RAM muLinux
> execute in turn the two script. The istruction "mount -f /" means:
> put only a relative entry in /etc/mtab. Maybe, this is the bad line:
> the test do not works reliably.
>
> To put a new "> /etc/mtab" in rc.4 is not a good idea, because
> in one case /linuxrc mount a loop filesystem (LOOP muLinux), and
> this action will destroy the mounted list.
>
> On the other hand, to test this kind of script is difficult, because
> simply the sustem hang!
>
I thought Dave's answer appeared sensible and was going to edit rc.4 but
after reading above I'm not sure what to do. I assume "/" the root
partition is the
last file system to be unmounted so could there be a suitable place in
rc.6 script to "rm -f /etc/mtab", after all the other fs have been
dismounted but while /etc is still accessible?
> >
> > That's it, don't know why we didn't spot that one before !
> > While we are talking about growing junk, after you remove /etc/mtab in rc.4 how about doing a file search of /tmp for files more than say three days old and remove them because on a cloned system /tmp rapidly becomes full of rubbish.. old chimera pages, temp modules,and loads of other odd bits+pc's. Nice thought but find=mufind=sed/tr script so we would have to add creation date parsing to find...Oh well :^(
>
On a cloned system why not move modules/ to /lib/
and leave /tmp/ on a ram disk. Booting may be slower but when up and
running less disk accesses should result in a faster system and temp
files vanish without trace automatically on shutdown.
If that is not acceptable then at least ammend the script that runs RNA
to stop the following happening:
#ls tmp |grep rna

rna1000
rna1031
rna1072
rna1137
rna1262
rna1281
rna1393
rna1417
rna1453
rna1549
rna2089
rna2231
rna2323
rna2592
rna2624
rna2885
rna6551
rna990

All folders so would not be removed with rm *

I will not hold my breath but it looks as if this /tmp/ thread could
become interesting.

Clive

---------------------------------------------------------------------
To unsubscribe, e-mail: mulinux-unsubscribe@sunsite.auc.dk
For additional commands, e-mail: mulinux-help@sunsite.auc.dk



This archive was generated by hypermail 2.1.6 : Sat Feb 08 2003 - 15:27:13 CET