From: Dave Houghton (davehoughton@mulinux.free-online.co.uk)
Date: Tue Dec 28 1999 - 04:54:07 CET
On 27 Dec 1999, Michele Andreoli <m.andreoli@tin.it> 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 ..
100% true
>
>In /etc/mtab ther is the list of mounted partition. RAM muLinux
>execute in turn the two script. The istruction "mount -f /" means:
also true
>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.
It's true that loop, umsdos and ext2 root filesystems are mounted by linuxrc via initrd. After linuxrc has been run through, the /proc filesystem is unmounted leaving the root filesystem still mounted, that is also true.
/etc/rc.4 is then run as the default run level from /etc/inittab. In rc.4 the root filesystem is remounted as rw. The key to this is REMOUNTED ( not shouting just emphasising the point :) ). The mount command using the remount option does not actually unmount and then mount again the filesystem, and so does not read /etc/mtab. It simply rewrites /etc/mtab with the correct information. Thus /etc/mtab doesn't need to even exist in order to carry out a REMOUNT, which is why I said to
rm -f /etc/mtab 2> /dev/null
in rc.4 immediately before remounting the root filesystem.
Its a dirty trick but it works. Check out Slackware and no doubt others which use scripts from the same source as muLinux.
>On the other hand, to test this kind of script is difficult, because
>simply the sustem hang!
Very true, but I have spent the evening cloning to and from every possible combination of filesystem using the above hack and it works with ALL permutations.
Combinations or permutations ?? now there's a interesting discussion point..
>
>>
>> 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 :^(
>
>Some cleanup is performed in /etc/rc.4, but only in /var/run/* and
>/var/lock/*. I can add a "rm /tmp/*", but not a "rm -r /tmp/*".
rm /tmp/* is fine as there is not much worth keeping in /tmp and it is only supposed to be for temporary files anyway.
>
>I wan't remove the module cache /tmp/modules, because Setup search
>for modules first in the cache, then try to unpack various archive.tgz.
>Removing /tmp/modules works, but this make to boot more slow.
Yes we need the cache agreed, but is there any reason why you have symlinked /lib/modules/2.0.36 to /tmp/modules/prefered rather than have the modules directly in /lib/modules/2.0.36 as is the normal case with Linux ??
------
Dave g0mxw
muLinux U.K. mirror
Happy House for the perpetually fractured
---------------------------------------------------------------------
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:12 CET