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,
>This is a very good point. I have always ran with devpts mounted so do not
>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
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