Re-entering with chroot question

Jon jongrosshart at sbcglobal.net
Fri Jan 7 06:50:30 PST 2005


I would like a little clarification on this process. I'm trying to pin 
down the exact commands and the order in which you should execute them 
to start building again after a reboot. I am in Chapter 6 currently. 
This is what I came up with:

mount /dev/hda3 /mnt/lfs
mount -t proc proc /mnt/lfs/proc
mount -t sysfs sysfs /mnt/lfs/sys
mount -f -t ramfs ramfs /mnt/lfs/dev
mount -f -t tmpfs tmpfs /mnt/lfs/dev/shm
mount -f -t devpts -o gid=4,mode=620 devpts $LFS/dev/pts
chroot /mnt/lfs /tools/bin/env -i \
HOME=/root TERM="$TERM" PS1='[\u@\h \w] ' \
PATH=/bin:/usr/bin:/sbin:/usr/sbin:/tools/bin \
/tools/bin/bash --login +h
mount -n -t ramfs none /dev
/tools/sbin/udevstart
ln -s /proc/self/fd /dev/fd
ln -s /proc/self/fd/0 /dev/stdin
ln -s /proc/self/fd/1 /dev/stdout
ln -s /proc/self/fd/2 /dev/stderr
ln -s /proc/kcore /dev/core
mkdir /dev/pts
mkdir /dev/shm
mount -t devpts -o gid=4,mode=620 none /dev/pts
mount -t tmpfs none /dev/shm

However, when I issue the mount command, I get this:

none on /dev/pts type devpts (rw,gid=4,mode=620)
none on /dev/shm type tmpfs (rw)
none on /dev/pts type devpts (rw,gid=4,mode=620)
none on /dev/shm type tmpfs (rw)
none on /dev/pts type devpts (rw,gid=4,mode=620)
none on /dev/shm type tmpfs (rw)
none on /dev/pts type devpts (rw,gid=4,mode=620)
none on /dev/shm type tmpfs (rw)
none on /dev/pts type devpts (rw,gid=4,mode=620)
none on /dev/shm type tmpfs (rw)
none on /dev/pts type devpts (rw,gid=4,mode=620)
none on /dev/shm type tmpfs (rw)
none on /dev/pts type devpts (rw,gid=4,mode=620)
none on /dev/shm type tmpfs (rw)

This makes no sense to me. I uderstand that proc and sysfs wouldn't be 
listed because we mounted those before chrooting but why are shm and pts 
listed repeatedly? twice would be understandable by looking at the above 
commands, but that many times? I should also be seeing ramfs shouldn't 
I? I've halted with building packages until I can get this squared away. 
Thanks everyone for your anticipated help.

Jon



More information about the lfs-support mailing list