Hello,
The hint I used was the only one I know is the 6.1.1-3
This is what it shows for populating dev for sections 6.9 to 6.37
6. Populating /dev
mount -nvt tmpfs none /dev
mknod -m 622 /dev/console c 5 1
mknod -m 666 /dev/null c 1 3
mknod -m 666 /dev/zero c 1 5
mknod -m 666 /dev/ptmx c 5 2
mknod -m 666 /dev/tty c 5 0
mknod -m 444 /dev/random c 1 8
mknod -m 444 /dev/urandom c 1 9
chown -v root:tty /dev/{console,ptmx,tty}
ln -sv /proc/self/fd /dev/fd
ln -sv /proc/self/fd/0 /dev/stdin
ln -sv /proc/self/fd/1 /dev/stdout
ln -sv /proc/self/fd/2 /dev/stderr
ln -sv /proc/kcore /dev/core
mkdir -v /dev/pts
mkdir -v /dev/shm
mount -vt devpts -o gid=4,mode=620 none /dev/pts
mount -vt tmpfs none /dev/shm

And this is what I have in the book for 6.0
mknod -m 622 /dev/console c 5 1
mknod -m 666 /dev/null c 1 3
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
If you say that the 2 mknod commands are only needed once in 6.0 and is used always in 6.1.1-3 I can try it that way and see what happens.

The other part I was refering to is the
mount -t devpts -o gid=4,mode=620 none /dev/pts
mount -t tmpfs none /dev/shm

You said something interesting which may or may not be my problem
"Cannot be already there because you haven't entered the chrooted environment yet/and they also need to be set up first."
Well in the 6.0 version and also in the 6.1.1-3 hints those commads come after entering chroot.
Are you saying that all or some of those commands should be made before entering chroot ?
Now that I think may make a big difference.

I can say for a fact that you have helped me a lot in understanding on how lfs works. So I do appreciate all the help you have given me so far
So as long as you or anyone else that can help me with 6.0 I will keep trying to move ahead.
I know you told me to upgrade but I also have my reason (dialup)

Hi,
Do not focus on or use 6.1.1.X instructions (or 6.2 for that matter).
These versions of LFS are (very) different from 6.0. One of those differences is starting/not starting /tools/sbin/udevstart. Which explains the difference in the amount of mknod commands between 6.0 and 6.1.1.

Here's the list I gave earlier with some comments about the place things are originally done in the book:

## Stop and resume for LFS 6.0 (from 6.9 up to 6.37) ##

# originally done in chapters up to and including 5:
export LFS=/mnt/lfs
mkdir -pv $LFS
mount /dev/sda2 $LFS
swapon /dev/sda1

# originaly done in chapter 6.2:
mount -t proc proc $LFS/proc
mount -t sysfs sysfs $LFS/sys

mount -f -t ramfs ramfs $LFS/dev
mount -f -t tmpfs tmpfs $LFS/dev/shm
mount -f -t devpts -o gid=4,mode=620 devpts $LFS/dev/pts

# originally done in chapter 6.3
chroot "$LFS" /tools/bin/env -i \
HOME=/root TERM="$TERM" PS1='\u:\w\$ ' \
PATH=/bin:/usr/bin:/sbin:/usr/sbin:/tools/bin \
/tools/bin/bash --login +h

# originally done in chapter 6.8.2:
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

cd /sources

Sorry, but did you actually read the hint and my advice?
It clearly states what to do after a reboot, this includes: rebooting from the liveCD, setting up LFS, mounting, entering the chrooted env (almost a halfway point!), mount, start udev and link some other stuff.
This surely indicates that you also need to do stuff BEFORE you enter the chrooted environment.

Hope this gets you going again.

Hello,
The list that you have is exactly what I was using.
It's only after having the errors I started deviating from it since I wasn't sure if those are the exact steps.

In your earlier statement you said

"I just re-checked the LFS 6.0 book (chap 6.01 up to 6.11) and you never have to use /dev/null (besides creating it in chap 6.8.1)."

Maybe that was a missunderstanding and I thought that I only have to enter the mknod -m 666 /dev/null c 1 3 command once and not everytime I reboot

You also said

These:
mount -t devpts -o gid=4,mode=620 none /dev/pts
mount -t tmpfs none /dev/shm
Cannot be already there because you haven't entered the chrooted environment yet/and they also need to be set up first.

I guess there was a missunderstanding here also.
I should have been more specific
Following that list after I enter all those commands and I am inside chroot I type mount and I get
none on /dev/pts type devpts (rw,gid=4,mode=620)
none on /dev/shm type tmpfs (rw)
So after I reboot and enter those commands again and type mount I get
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)
So each time I reboot I get those 2 lines added to the mount list and the list keeps growing with each reboot
Sorry about not being more specific

Hi,
Ok, clear.

Although the deviations you later tried could have FUBAR'ed the base you set up in chapter 5........... But this I'm not sure about, not knowing what it is you tried.

I'm not entirely sure if the 2 mknod steps (mknod -m 600 /dev/console c 5 1 and mknod -m 666 /dev/null c 1 3) need to be done. Logic says you don't (you have done it already, so they must be there after the reboot). Re-doing this won't have any negative implications. I do expect an error message if they already excist (something like: mknod: `/dev/null': File exists).
If that error did not show up, keep mknod-ing every time you reboot

The above (the extra 2 entries after every [re]boot) looks wrong and sounds very, very strange.

If you mount a device and reboot the machine (without unmounting yourself) the shutdown process should (try to) unmount everything. This is a normal shutdown procedure and seen in all distro flavors.

I do believe that you always start with an umounted situation. I've had my box hang after not manually unmounting a device and the systems 'auto' unmount failed to do its job. But the device in question was not mounted anymore after I had to do a hard power-off and boot (Just in case: Do _not_ switch the power of your box off unless you absolutely have no other choice!!. You could end up with a corrupted disk).

Do you see this behavior also after a powerdown?
If so: How do you initiate a reboot?

I'm wondering: Do you still have a base you can use/trust, or has it changed too much after trying this and that (this isn't the first problem you encountered). You could consider starting from scratch (no pun intended). With the knowledge you have gathered over the last couple weeks, things will make a lot more sense and re-doing things won't take as long (up to and including chapter 5 can be done in one evening).

Hope this helps.

Hello,
Yes I believe it has been FUBAR'ed

I have been having an error in configure something about
"unable to compute size of double"
I thought it was because I went too far after the error but I guess it's also possible that it happened because I tried too many things.
I rebuilt it from chapter 6 but the error is still there so it looks like I have to start from scratch
I very rarely use the power switch to turn it off I may have done it at the begining a few times when I first started with lfs but definitely not since
I am getting further into th build

Usually when I want to shut it down I type exit to get out of chroot or when I am in lfs and then type halt.
Otherwise I type reboot after exit.

Do you think maybe I should unmount it first before shutting down ?

Hello,
I just made a quick check after entering the 2 mknod commands it does say
"File exists"
However after a litle more chcking I found that after entering the next command "mount -n -t ramfs none /dev"
both the null and console files are gone from the /dev directory
Is that normal ?
Should the console and null files be created after that command perhaps ?


The mount is still the same
I tried it with reboot and halt and it's still adding 2 of those mount lines
each time I use the mount commands.

I looked at it in more detail and the 2 mount commands behave a little bit different
After I type the first mount command
mount -t devpts -o gid=4,mode=620 none /dev/pts
I get "can't open /etc/fstab: No such file or directory" which is normal according to the book but if I type it again right after it it says none already mounted or /dev/pts busy
I found that there is an "mtab" file created in /etc when I type the first mount command so when I just type mount it lists the content of mtab.
So this is the file that I see when type mount
So since I will be rebuilding it from scratch anyway I decided to mess around
with it and I deleted the mtab file in /etc
So after doing that and typing mount again I get a completely different list
Aparently it is looking at the mtab file that is outside of chroot that lists
all the devices mounted not just the "devpts" that I just entered

So then I entered the other mount command
mount -t tmpfs none /dev/shm and again I got
"can't open /etc/fstab: No such file or directory" which is ok since I deleted the mtab file but when I typed it again like I did the first one I did not get
anything and after typing mount I see it listed twice.
I deleted mtab again and I typed mount again and I saw it listed twice along with the other devices.
One thing I was able to verify was that the devpts and tmpfs that are in the mtab that is outside of chroot do get unmounted because they are not there after reboot.
Only the mtab that is inside chroot does not unmount so I am not sure f this is still a problem as long as the one outside gets unmounted
One thing that still doesn't look right to me is why it doesn't say already mouted for tmpfs like it does for devpts or any other mounted device

Hi,

That doesn't sound to good. Another reason to start from scratch again. But that you already stated yourself.

Ok, this means that the 2 mknod statements are not needed. I'll remove them from the previous posts so that others won't run in to this when they use it.

I'm not sure why this is correct, but I think it is.

The ramfs mount is done on top of the previous mounts (console/null), this would mean that ramfs is mounted on top of the previous /dev and the /dev/null and /dev/console entries are still there, but not visible/reachable. The udevstart command (command after mounting ramfs) should create the needed device nodes (on demand).

Besides the explanation the book gives, I cannot give you a good reason why they set this up this way for 6.0 (the LFS team changed this from 6.1 on, specific/needed device nodes are mounted and udevstart is not used).

I don't think you need to worry about this atm.

I can only rever to previous answers for this problem. I still haven't got a clue why 2 entries are added after each reboot. There must be a lot of them by now

This looks like correct behaviour.
You do not have a fstab file yet (as stated in the book), if you try to redo those commands you find out that they are already mounted (the first time worked already).

I don't know if you have any idea how mount works, so here it is in a nutshell:
After a mount command, the system will first try to get the needed information from the /etc/fstab file, if the info isn't there the system will try to mount the device with the option it got from the command line.
This also means that it will complain if it cannot find /etc/fstab, but will still do its job.

The file /etc/mtab is a normal file that is updated by the mount program whenever file systems are mounted or unmounted. You should not mess with this file on a normal running system, it is ok to mess with it if you know that you are going to rebuild the system

BTW: /proc/mounts is a better way to find out what is mounted. This also shows memory, tty (among others) related entries.

I do believe you decided to start over again: I don't know if this is at all possible but try not to reboot. There is a 'safe' reboot point, after finishing chapter 5, before starting chapter 6. The whole process can be done in one (very long) day, but I guess that's it bit much and you will not learn to much.
You could decide to split it up in 2 bits: Up to and including chapter 5 and from chapter 6 to end. The last part will take you about 2 days (if you have the time). You could decide to leave your computer on, but I guess that's only feasible over the weekend.

Anyway, hope things go a lot smoother this time.

Hello,
Thanks for the explanation about how /dev/null and the ramfs works.

" You do not have a fstab file yet (as stated in the book), if you try to redo those commands you find out that they are already mounted"
Well that is true for the devpts mount but not the tmpfs mount
The tmpfs does not say it's already mounted if I try to mount it again.

About the /etc/fstab.
Is that related somehow to mtab ?
I know you said that "/etc/mtab is a normal file that is updated by the mount program whenever file systems are mounted or unmounted " but does that affect the /etc/fstab not being there because once the /etc/mtab is created I no longer get the warning message about the /etc/fstab.
It's only if I delete mtab I get the warning once and any mounts after that I
don't get that warning


About the reboot.
I tried it both ways. The first time I stopped after finishing chapter 5 and
started chapter 6 and continued till the error.
The second time I stopped a little before finishing chapter 5. Then restarted where I left off in chapter 5 and transitioned over to chapter 6 without rebooting and continued till the error
It did not make any difference on the error
It's going to be a long day either way.

Hi,

You're welcome

Not really. Mount and umount 'maintain' /etc/mtab. /etc/fstab is 'just' a tool to make mounting easier.

The mount/umount process tries to be smart. If the mtab file is created it means that the warning about the missing fstab file is already shown, then there's no reason to show it again.

Hello,
Thanks for the explanation of mtab, fstab
I still don't know why the tmpfs does not give an error sayin that it's already mounted.
I played around with it before starting the rebuild
I typed the mount command 4 times then I typed the umount only 2 times and it was removed.
It seems that every umount removes 2 mounts (at least on this tmpfs)
If I mount it once and type umount it removes it but it also gives an error saying that it's already unmounted
Seems very strange

I started my rebuild and I am about seven and a half hours into it now.
I am at the gcc second pass at the make -k check
That's along test. I will probably stop somewhere after installing
binutils then continue from there till chapter 6

Hello,
I staarted from where I left off and I noticed some errors at chaper 5.24 gettext during make check
I believe it was there on the preious run but I am not sure how important these errors are since the book says that "Gettext test suite is known to experience failures under certain host conditions, "
So I wasn't sure if this was one of those failures or something unexpected so I continued on the first build but now that it's failing at chaper 6 I am thinking that maybe these errors are somehow related
I just wanted to write these down here in case someone knows if these are real errors.
1 of 219 tests failed
(22 tests were not run)
make[3] *** [check-TESTS] Error 1
make[3]Leaving directory ...
make[2 ***[check]-am] Error 2
make[2]Leaving directory ...
make[1]***[check-recursive] Error 1
make[1]Leaving directory ...
make *** [check-recursive] Error 1

I saved the output to a file and looking through it and the first fail line is
format-c-5 and the message before that is "Couldn't set locale"
There are a few more "Couldn't set locale" messages but it doesn't say fail after those it just say SKIP

Hello,
Well I made it back to chapter 6 but I still have the original error.
I will try to put the output here but it's a bit hard to know exactly where
to start from so I will do my best to capture the relevant informatin
I believe the test starts with
gcc wordexp-test.c then there are about 17 lines and then it ends with
-MT /sources/glibc-build/posix/wordexp-test.o
Then the next line starts with
gcc -nostdlib -nostartfiles -o /sources/glibc-build/posix/wordexp-test
then about 9 lines down there is this line
/sources/glibc-build/posix/wordexp-test.o (.text+0x402): In function 'main'
/sources/glibc-2.3.4-20040701/posix/wordexp-test.c:249: warning: the use of 'tmpnam'is dangerous better use 'mkstemp'then there are another 4 lines and then it ends with
/sources/glibc-build/posix/wordexp-test
> /sources/glibc-build/posix/wordexp-test.out and then after that I have the errors

make[2]: *** [/sources/glibc-build/posix/wordexp-test.out] Error 1
make[2]: Leaving directory `/sources/glibc-2.3.4-20040701/posix'
make[1]: *** [posix/tests] Error 2
make[1]: Leaving directory `/sources/glibc-2.3.4-20040701'
make: *** [check] Error 2"

Hi again,

The error part you post won't tell us too much. Could you post the make errors, including say 25 lines before it? Also take a look at chapter 1.4.3 (Help), it shows what is relevant and what is not (kinda).

Did the configure step go smoothly?

About gettext make test failing: Normally you don't need the test suites in chapter 5 (unless stated otherwise that is). Gettext is one of those that need extra work if you want to test the compile/make step. I think you don't need to worry about this test failing.

Hello,
"Could you post the make errors"
Ammm, not sure what you are asking me.
There are no make errors.
The errors I posted are from 'make check'
I am not aware of any other errors before that.
I ran make check again without rebuilding it and I got a different error something about timezone, then I thought about runnning make check with the -k option but that also failed because of too many errors so I ran make check again and now I am back to the original error although it seems a little bit
shorter from where the test for this particular program starts and finishes
It was roughly about 22 lines and now there is only about 5 lines.
I am not sure if the lines before the error will tell you much but here is a
sample.
GCONV_PATH=/sources/glibc-build/iconvdata LC_ALL=C /sources/glibc-build/elf/ld-linux.so.2 --library-path /sources/glibc-build:/sources/glibc-build/math and it goes on like that with different files in the glibc-build directory I will just list the files
to save on typing so after /sources/glibc-build/math I have elf, dlfco, nss, nis, rt, resolv, crypt, nptl, /posix/wordexp-test than the last line before the errors
> /sources/glibc-build/posix/wordexp-test.out and then after that I have the errors which I have already posted

I don' have chapter 1.4.3 (Help) in 6.0 but I have chapter 1.3 but that's just talking about general help not specifically to any relevant errors to glibc.
However now that I look at it in the book at the list of common issues at the glibc chapter 6.11.1 I see the one of the issues is with gettext although it doesn't say how this issue manifest itself it doesn't give specific errors or what to do about it. it just says
"The gettext test sometimes fails due to host system issues. The exact reasons are not yet clear"
So you don't think that gettext errors and the wordexp-test errors are somehow related ?

Hi,
Make check is what I meant.

Could you post the error(s) and +/-25 lines before the error (from the logfile)? Please start again with glibc (remove both dirs, unpack glibc and start again) to create a 'clean' logfile.

No 1.4.3??? Aren't you installing LFS 6.0. I mentioned before that this site was down, it appears to be up again.
Please check if your doc is the same. If we are not using the same version/document, things could go wrong.

I just checked (Current LFS build logs), but the buildlogs for 6.0 are no longer available. It's a good source to check which errors are 'to be ignored' and which you should check out......

This could make the error hunting a bit easier:

make -k check 2>&1 | tee glibc-check-log
grep Error glibc-check-log

This shows the output on screen, but also directs it to a logfile (glibc-check-log). The grep statement shows all the Error('s) present in this logfile. It's also wise to check this logfile from top to bottom. The -k flag for make check prevents it from stopping on fatal errors. The logfile created by make check itself should also still be available.

BTW: This ....warning: the use of 'tmpnam'is dangerous..... can be ignored.