Error /posix/wordexp-test.out
 

Hello,
I am building lfs for the first time and I got to chapter 6.11 (glibc)
I have a couple of errors at the make check command and I am not sure if this is real or not or id it's something that can be ignored
One of the errors is in /posix/wordevp-test.out and
another one for posix/tests This is where the make check stopped it ran for quite a while before it stopped.
I wasn't sure if this was a real error so I went ahead with make install but I got a couple of errors there also but I am not sure if the two errors are related.
After the make command was running for a while I got
"/dev/null" line 1 input line of unknown type
"/dev/null" line 2 line too long
make 2 /usr.share/zoneinfo/Africa/Algiers error 1
timezone/subdir_install error 2
Do I need the zoneinfo for Africa/Algiers if I am not planing on using it ?

Hello,
Here is some more information that may help someone tell me what is going on here.
It seems that after the make check something happened to make something "set" or corrupted so no matter what I do (short of startibg from scratch) will make it fail even before the make check now.

I deleted the glibc-build and the glibc source file and untarred it from
the sources directory and while trying to run the configure command I noticed
right at the begining for a split second before it scrolled up that there was an error "No such file or directory" however it did not stop there and just continued to the end. Even if I cd into the glibc directory it still says "No such file or directory"

While using the ls-l to figure out which files were made during that day
so I can delete them I noticed something else that is a bit strange to me
I am not sure if this is a problem I just want to know what/why this is happening.
For the glibc directory it's listed as user id 1003 and group id 100
Where is this id coming from ?
If I try the ls -l outside of chroot I get 1003 sshd
Did the make check added it ?
Who/what is this sshd ?
I untarred another file at random (grep) and was listed as root root
which was normal I think.
Then I tried another one (dejagnu) and showed 1000 100
So after logging out I looked at the passwd file in /etc
and I see one of the lines like this
"sshd:x:1000:100:sshd privsep:/var/empty:/bin/false"
Which I guess explains the 1000 and sshd although I don't know what that means and where it's coming from.
What about the 1003 ?
I don't see that listed anywhere in passwd.

Hi,

This is not something you have to worry about, it's caused by the way tar works.

If you create an archive the owner and group id are also stored (the number, not the name). When you untar this file on a different machine, it tries to match this uid and gid with a name (taken from /etc/passwd and /etc/group), if there is no match the number is printed instead.

Hope this clears things up a bit.

Hello,
Yes that does clear it up a bit.
Although I still can't figure out why the files in glibc are not recognized after the make check and even after deleting and untarring it again.

For some reason I don't remember seeing this line with sshd in the passwd
when I was going in and out of lfs environment
I only remember the root and 1001 which was the lfs uid

Are there hidden files that are modified during the make check ?
Do I have to erase everything and start over just to get glibc to work again ?

Hello,
I did some further checking and I think I have narrowed it down to the chroot
environment.
I just used the configure command by itself outside the chroot and of course
it works that way(by "works" I mean I don't get the "no such file or directory" error)
Then I entered the chroot with the chroot command only without setting up the other variables and it worked also
Then I got out and entered again this time with all the variables and now the configure doesn't work anymore just like before.

Can the make check command change something in the chroot environment ?

So now I have to somehow reset the chroot environment so that the configure
command works without deleting any imortant files if that's possible.

Hello,
I deleted everything except the /tools and /sources an rebuilt it from the begining of chapter 6 but it's not exacly the same as it was before I ran the make check because now it fails at the make command and the configure command is still not running right

Here is what I get after the configure command.
This is right at the begining so I have to hit ctrl-c in order to stop it from
scrolling by otherwise it keeps running till the end.

configure: loading cache /dev/null
/dev/null: line 1 : ../glibc-2.3.4-30040701/configure:: No such file or directory
Is there supposed to be something in /dev/null ?
I have nothing in there right now

Looking in config.log at the end I have
configure exit 0

This is gettin weird now.
I just typed make a couple of times and stopping it a little before the error
just to see the screen before the error messages and now I let it go and it's working.
This is going to take a while...

I will try it without the make check and see how far I get

Hello,
Well that didn't make any difference.
The make install still fails at Africa/algiers smae as above
I tried the tzselect command but it did not work
"/usr/bin/tzselect line 53 /usr/share/zoneinfo/iso3166.tab No such file or directory" which I assume is due to the make install failing however
I tried the tzselect command before the make install and it worked but it may
have been looking somewhere else for that missing file.

The localedata command worked
I went a little bit further to "re-adjusting the toolchain" but the sanity check did not go too well
at the cc dummy.c I got
ld-linux.so.2 needed by libc.so.6 not found try using(-rpath or -rpath-link)
I am not sure what that means or how it is related to the glibc errors or the environment so I guess I am stuck here for a while

Hello,
According to Wikipedia the description for /dev/null is

"In Unix-like operating systems, /dev/null or the null device is a special file that discards all data written to it, and provides no data to any process that reads from it (it returns EOF). In Unix programmer jargon, it may also be called the bit bucket or black hole.

The null device is typically used for disposing of unwanted output streams of a process, or as a convenient empty file for input streams. This is usually done by redirection"

So according to this description any errors that show up in /dev/null I should be able to ignore.
So the error that I had with configure
"/dev/null: line 1 : ../glibc-2.3.4-20040701/configure:: No such file or directory"
I should ignore since it "provides no data to any process that reads from it" and also because the config.log had "configure exit 0" at the end

Although it would have been nice just to see what caused the error .
I was just wondering why do we need this now and we did not need it during the
previous version of glibc instalation in the lfs environment

So that brings me back to my original post and beyond

Hi,

The info is getting a bit messy :) To recapture what you said (important parts only):

1) ./configure glibc...... => A ....configure:: No such file or directory briefly pops up, but process keeps running and ends without errors,
2) make => No problems,
3) make check fails (throws errors and stops early).

The rest is irrelevant if the above aren't correctly set up.

Questions:

1) Are there any other errors in the config.log (after ./configure runs its course),
2) Could you post the error(s) and the relevant lines around it (from the config.log),
3) Could you post the exact errors that make check throws? (not needed if the configure step fails premature).

BTW, This:
Is not a correct conclusion.

So according to this description any errors that show up in /dev/null I should be able to ignore
If done correctly you won't even know that there was an error. Output send to /dev/null will not be shown on screen or in a file. It's gone, forever (hence the term 'black hole'/'bit bucket'). So no text will 'show up' when you pipe something to /dev/null and if it does, its not /dev/null that is doing so.

If something like this "/dev/null: line 1 : ../glibc-2.3.4-20040701/configure:: No such file or directory" is shown, then something is wrong (unless stated otherwise, which is not the case). /dev/null is not the 'program' (it's a [buffered] character file, not a program) that created this error, something else did.

I don't know if you stopped (reboot) between chapter 6.0 and 6.9, if so: Did you re-create the needed environment (did you re-populate /dev, to name just one).

Hello,
The answer to question 1 is No.
There are no errors after ./ configure runs it's course except for that first
error that briefly pops up, but process keeps running and ends without errors

I don't have the exact error in front of me at the moment but at that time I looked on this forum and I found this error from poster Znif which is almost
exactly what I have without the other problems that he had and I have lfs 6.0 instead of 5.1 so I just pasted it here
"make[2]: *** [/sources/glibc-build/posix/wordexp-test.out] Error 1
make[2]: Leaving directory `/sources/glibc-2.3.3-lfs-5.1/posix'
make[1]: *** [posix/tests] Error 2
make[1]: Leaving directory `/sources/glibc-2.3.3-lfs-5.1' make: *** [check] Error 2"

I will rebuid it again this weekend to verify but I am sure it's acurate

"Output send to /dev/null will not be shown on screen or in a file. It's gone, forever (hence the term 'black hole'/'bit bucket')"
What about that first error that went by quicly during ./configure ?
Wasn't that in /dev/null for a moment ?
Actually I saw a few things in /dev/null if I stop the./configure with ctl-c while it's running. I just can't stop it fast enough right at the begining
because it's overwriten by other stuff while ./configure is running

Yes I did reboot but that was after chaper 6.9
I have a question while we are on the subject of rebooting and /dev
Do I have to re enter the mount command with devpts and tmpfs everytime I reboot or just one time ?

Hi,

These are only the last few lines, not enough to get a good idead about what went wrong. But you already stated that this is copy/pasted from elsewhere. Let's wait and see what you come up with over the weekend. Hopefully a more detailed account of what you did and the response you got.

The first error was not caused by /devnull (maybe a lack of having /dev/null). I can only re-state what I said before: All that is send to /dev/null will not be seen by you (not even briefly). The error seen comes from elsewhere (for us to find out what caused it).

How did you 'see things in /dev/null'? There's nothing there to see....

You need to re-do certain parts every time you reboot. The creation of these parts are vital for having a good base environment.

Between chap 6.9 (Linux-Libc-Headers) and 6.37 (bash) you need to set up 'a lot'. Take a look at the hint and adjust accordingly (it's not written for LFS 6.0 but LFS 6.1.1.3).

Hello,
I can certainly provide more information but not much beyond the last screen that I can see.
Is there a way to look at any previous previous errors (if any) that have already scrolled by ?

"The first error was not caused by /devnull (maybe a lack of having /dev/null"

That is quite the oposite because I tried it with and without the /dev/null
and if there is no /dev/null then it doesn't show that error on the screen because /dev/null doesn't exist.
I know it was not caused by /dev/null I just thought I may be able to capture
a little more information other than "No such file or directory "

"How did you 'see things in /dev/null'? There's nothing there to see...."

After I stop the ./configure with ctl-c
I cd into /dev and then I do an ls-l and looking at the null file if there is something ther it shows somthing other than 0 Sometimes 67 sometimes 37 bytes
Not a lot just something.
Then I do a cat null and shows whatever is there at the time I stopped it.
It's always something different depending on where I stop it.
If I let it run till the end then of course there will be nothing there

I looked at the hint but I wasn't sure how much of it applied to 6.0 that's why I was asking
In the 6.1 1-3 there are 5 other "mknod" commands and a "chown" command that
I don't have in my book so I left those out
I was asking about the 2 mount commands because at one point I typed mount
and I saw those 2 lines listed 4 times so I figured that everytime I reboot
and retype those commands I will have another 2 mount lines added so it didn't look right to me.
In either case I tried it with and without adding the mount commands after the first round and it didn't make any difference (At least not on the configure
error on which I was working on at the time)

Hi again,

<shift>-<page-up> or the log files.

You could also send all output to a file yourself: ./configure ....... 1>mylog 2>&1. All output (normal and error) is send to the mylog file.

You lost me here.

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).
So how can you try with and without /dev/null? Did you delete /dev/null itself? Did you edit one of the files from one of the packages??

Either way, you are not following the book here at all, which could (has??) mess things up.

What do you mean by There's nothing there?? /dev/null is created (chap 6.8.1) and should be there. The rest you say also sounds strange.

/dev/null is a special file with major/minor numbers 1 and 3. These numbers don't change, ever:
$ ls -l /dev/null
crwxrwxrwx 1 root root 1, 3 May 29 2004 /dev/null
It also doesn't show the amount of data 'in there'. You won't see 67, 37 or 0 bytes, just 1, 3 (major and minor number).

I came up with this (do check if I forgot something and change sdaX to reflect your setup):

from chap 6.9. Linux-Libc-Headers-2.6.11.2 to chap 6.37. Bash-3.0

Restart computer and boot from LiveCD

export LFS=/mnt/lfs
mkdir -pv $LFS
mount /dev/sda2 $LFS
swapon /dev/sda1

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

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

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

Hello,
Thanks for those 2 tips I will definitely try those out.

" 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)"
Well, I didn't know any better. It was part of the hints page along with some other mknod commands so I only entered the one that applied to 6.0
So everytime I rebooted I entered those 2 commands
So since I still had the errors I started messing around with it by entering all the other commands except the /dev/null.

Here is something interesting that may or may not provide a clue as to
what the problem may be.

If I enter all the commands up to and including the chroot and cd into /dev
I have the console and null files there Those are the only 2 files there
Checking the null with ls -l it shows the 1 and 3 like you said except
I don't have the x's it's crw-rw-rw-
Now if I enter the rest of the commands and check /dev again I no longer have the null or the console files there I just have the other files that i rentered (stdin,stdout etc...)
So perhaps that is the reason why "No such file.." because there is no /dev/null
So then after I run the ./configure command the null shows up in /dev
but this time when I type ls -l I get
-rw-r--r-- 1 root root 67 nov 16 23:00 null

About the mount commands
"mount -t devpts -o gid=4,mode=620 none /dev/pts
mount -t tmpfs none /dev/shm"
You are saying that this should be entered always after I reboot ?
Is it normal to have those 2 lines added to the 2 exact lines that are already there in the mount list after after each reboot ?

Hi,

You don't mention the hint you used (I'm not aware of this perticular hint), so I can only comment in general: The only hint I ever used to install 6.0 (and 6.11/6.2) was the restart hint. The other hints are not needed. This is a bit of a generalisation, but most of the time errors come from not doing what the book tells you to do, inexperience and/or typos.

This is what I meant by the "maybe a lack of having /dev/null" I mentioned in one of the previous answers I gave. This needs to be sorted out first before you continue (you are maybe forced to start over with chapter 6).

I already mentioned more then once that you need to do this. Without them you do not have a proper base environment. Not doing this will result in errors and probably a none working LFS version (If you ever get to the end without this base environment, that is.).

So to recapture: You always need to set up a proper base environment after a re-boot. Always!

Which mounts are already there immediately after a reboot? Please be a bit more elaborate.
Not one of the mounts/links mentioned in my previous post should be there after a reboot.

These:
mount -f -t tmpfs tmpfs $LFS/dev/shm
mount -f -t devpts -o gid=4,mode=620 devpts $LFS/dev/pts
Cannot be already there because $LFS needs to be set up first.

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.

BTW: As of today I'm not able to reach the official archive site that holds the 6.0 book (LFS 6.0 is rather old :) ). I think I said this already in one of the other threads I helped you with, but I'm going to try again: Try LFS 6.2. The bugs from 6.x are fixed, the way things are set up are easier (and more logical) and the documentations is still 'fresh' and available.

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.

Hello,
I see what you mean now.
The book is a little bit off
I have 1.3.3 as compile problem

I already rebuilt it after the last post
I made my own logfile based on your past sugestion 1> mylog 2>&1
Sorry I am not sure which buildlogs you ar refering to.
Are they created by make or make check or is this just mylog or whatever I create to capture the file as it's being built ?
I did not see any logfiles or buildlogs in /glibc-build except the config.log
BTW I forgot to answer the question about configure in my last post.
Yes the error with the "/dev/null" is still there right from the begining
but it continues past it and finishes with exit 0

I looked at that buildlog for 6.1.1 (chapter6 glibc 2.3.4) and it's pretty similar to mylog that was created with make -k check
I will try to copy it here and edit it for what my file looks like
That's actually one long line that wraps around

gcc wordexp-test.c -c -std=gnu99 -O2 -Wall -Winline -Wstrict-prototypes -Wwrite-strings -g -mpreferred-stack-boundary=2 -I../include -I. -I/sources/glibc-build/posix -I.. -I../libio -I../nptl -I/sources/glibc-build -I../sysdeps/i386/elf -I../nptl/sysdeps/unix/sysv/linux/i386/i686 -I../nptl/sysdeps/unix/sysv/linux/i386 -I../nptl/sysdeps/unix/sysv/linux -I../nptl/sysdeps/pthread -I../sysdeps/pthread -I../nptl/sysdeps/unix/sysv -I../nptl/sysdeps/unix -I../nptl/sysdeps/i386/i686 -I../nptl/sysdeps/i386 -I../sysdeps/unix/sysv/linux/i386 -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../sysdeps/unix/sysv/i386 -I../sysdeps/unix/sysv -I../sysdeps/unix/i386 -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/i386/i686/fpu -I../sysdeps/i386/i686 -I../sysdeps/i386/i486 -I../nptl/sysdeps/i386/i486 -I../sysdeps/i386/fpu -I../sysdeps/i386 -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -nostdinc -isystem
/tols/lib/gcc/i686-pc-linux-gnu/3.4.1/include -isystem /tools/glibc-kernheaders -D_LIBC_REENTRANT -D_LIBC_REENTRANT -include ../include/libc-symbols.h -DNOT_IN_libc=1
-o /sources/glibc-build/posix/wordexp-test.o -MD -MP -MF /sources/glibc-build/posix/wordexp-test.o.dt -MT /sources/glibc-build/posix/wordexp-test.o

Then the next long line

gcc -nostdlib -nostartfiles -o /sources/glibc-build/posix/wordexp-test -Wl,-dynamic-linker=/lib/ld-linux.so.2 -Wl,-z,combreloc -Wl,-z,relro /sources/glibc-build/csu/crt1.o /sources/glibc-build/csu/crti.o `gcc --print-file-name=crtbegin.o` /sources/glibc-build/posix/wordexp-test.o -Wl,-rpath-link=/sources/glibc-build:/sources/glibc-build/math:
/sources/glibc-build/elf:
/sources/glibc-build/dlfcn:/sources/glibc-build/nss:
/sources/glibc-build/nis:/sources/glibc-build/rt:
/sources/glibc-build/resolv:/sources/glibc-build/crypt:
/sources/glibc-build/nptl /sources/glibc-build/libc.so.6 /sources/glibc-build/libc_nonshared.a -lgcc -Wl,--as-needed -lgcc_s -Wl,--no-as-needed `gcc --print-file-name=crtend.o` /sources/glibc-build/csu/crtn.o

/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 another long line this is the only one that shows after running make check a second time after the first without rebuilding it

GCONV_PATH=/tools/build/glibc-build/iconvdata LC_ALL=C /sources/glibc-build/elf/ld-linux.so.2 --library-path /sources/glibc-build:/sources/glibc-build/math:
/sources/glibc-build/elf:/sources/glibc-build/dlfcn:
/sources/glibc-build/nss:/sources/glibc-build/nis:
/sources/glibc-build/rt:/sources/glibc-build/resolv:
/sources/glibc-build/crypt:/sources/glibc-build/nptl /sources/glibc-build/posix/wordexp-test > /sources/glibc-build/posix/wordexp-test.out
Then the make check stops after the error

Here are the other errors from runing make check with the -k flag

From the top
make[2]: *** [/sources/glibc-build/posix/wordxp-test.out] Error 1
make[2]: *** [/sources/glibc-build/posix/annexc.out Error 1 (ignored)
make[1]: *** [/posix/tests] Error 2
make[2]: *** [/sources/glibc-build/nptl/tst-mutex8.out Error 127
The same error (Error 127) is repeated for tst-cond7.out,tst-cond8.out,
tst-once3.out, tst-once4.out, tst-key3.out
These 2 have (Error 1) tst-basic3.out, tst-basic4.out
Then more Error 127's all in the /sources/glibc-build/nptl directory
about 43 files
Then just a few more after that
make[1]: *** [nptl/tests] Error 2
make[2]: *** [/sources/glibc-build/rt/tst-mqueue8x.out] Error 127
make[1]: *** [rt/tests] Error 2
make: *** [check] Error 2

Hi,

You need to post the actual output from your own build (the output of your make check to be exact). If there are any errors in the config.log, post these too.

It's impossible to determine what happened if you mix parts of a non-relevant (6.1.1) log and some of your own output.

You also mention running make check a second time, this could be of use later on, but for now I'm only interested in the output from a clean (first time) build.

BTW: Could you put code or quote tags around the posted output and put your comments below them (or make them bold), it makes the output a lot easier to read.

Hello,
That was the actual output from my code.
The only reason I used the 6.1.1 as a reference is to save on typping.

If that is not relevant I am not sure what else I can do that is different
than my output

That output was from a clean build.
I will make another clean build again to double check but I am pretty sure it's all there.

I will look in config.log to see if I can find any errors.

Hello,
I did a little experimenting and I seem to have stumbled upon a solution.
This may mean I have to deviate from the book at least just temporarily.

I know you said earlier

" 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)."

But I was thinking for some reason during configure on the first line
when it's looking for /dev/null it doesn't see it or it's not "reachable"
So I left everything out of "populating dev"
I exited and reentered chroot (I did not reboot) and went straight into
configure.
Right away I noticed that I no longer had the error about the /dev/null
So after doing " make" I ran "make -k check" to a logfile and after examining it I noticed I no longer have the wordexp-test.out error but I still had all the other ones.
Then I ran "make check" without loging it and it went through to the end without errors.
So I figured I may as well go ahead and do the "make install" and that also went all the way to the end without errors.
I also got a message on the last line
"Yout new glibc installation seems to be ok"

Now the question did I mess up anything by not populating dev ?

Would it be safe to continue normally from here ?

Hi,

This sounds very unconventional :)

Populating /dev is an important part and I doubt you can do without. But you can always try.

I don't think glibc is the problem, but rather something you did or did not do in the previous chapters. I was hoping to get a clue by examining the glibc logfiles. The /dev/null and other /dev related issues could be at the heart of all this.

Hello,
I am proceding cautiously.
I finished glibc and the readjusting the toolchain and the sanity check went well but now I have a problem at installing binutils 6.13
The expect -c "spawn ls" command is giving me the
"The system has no more ptys." error that is in the book
I hope this is not related to the glibc installation
I put back the commads for populating dev after I finished glibc so I don't think it's caused by that.
I will make a new post for this since this is no longer related to the original post