MAKEDEV & devpts filesystem

Bill Maltby - LFS Related lfsbill at wlmcs.com
Wed May 7 21:19:45 PDT 2003


On Thu, 8 May 2003, Greg Schafer wrote:

>On Wed, May 07, 2003 at 09:18:19PM -0500, Larry Lawrence wrote:
>> Chapter 6 MAKEDEV seems to emphasis generic over genric-nopty.  Granted,
>><snip>

>This is a very good point. I have always ran with devpts mounted so do not
><snip>

>Changing the subject slightly, I still find the whole concept of mounting
>from within the chroot env a broken idea. I know Richard L. has expressed
>this same concern in the past and I agree with him. The mtab on the host
>can get out of sync. From memory, we started doing this when the
>keep_separate hint was first implemented as it was somehow deemed "cleaner"
>to use the new mount binary. I dispute this notion unless someone can show a
>technical argument as to why it is better.

Your point is on target. A mount from within change root would affect only
things accessible from within the chroot env. Host /etc/mtab would *not*
be updated (if it was not a symlink to /proc/mounts). That alone is enough
to strongly suggest that mounting within chroot is a broken
procedure. There are other scenarios wherein I could imagine problems but
I do not know of any concrete examples. Maybe folks have been lucky or ...

>Anyhow, my preference would be to mount the proc and devpts file systems
>from outside the chroot. This means some directories will have to be created
>from the outside but again I ask the question, what value is there by
>creating the dir structure from inside the chroot, apart from the warm &
>fuzzy feeling factor? I mean, a dir on a filesystem is a dir on a
>filesystem, right? The kernel still does all the syscalls and stuff that
>make it happen so the actual binary making the dirs is somewhat irrelevant,
>right? But maybe some special attributes or other stuff I don't understand
>are catered for by using the newer mkdir binary. Dunno.

And now that LFS uses a real mtab, a mount in chroot results in two mtabs,
each with different contents (at least temporarily). Not a good thing. It
can easily lead to confusion if one is working multiple VTs and that 2:00
AM coffee hasn't kicked in yet and you can't figure why you don't see what
you expect when you are in the *other* VT.

The kernel doesn't care. An i-node redirect is done regardless and he
doesn't care about the user confusion.

Just as chroot is entered for "security" against inadvertant damage,
mounts s/b done *outside* chroot for protection against confusion. Plus,
it seems "cleaner", IMO, to have the platform "fully ready" before
entering chroot.

>Greg

-- 
Bill Maltby
lfsbill at wlmcs.com

-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message



More information about the lfs-dev mailing list