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.