Hello,
I am trying to make lfs for the first time and I seem to be stuck at chapter 6
I have an error while trying tu run glibc that seems to point to the fact that it can't find gcc in /tool/bin or it doesn't work

I think in order to fix the problem I need to understand
who owns the /tools directory.
There is a note in chapter6.1 that says that" The reamainder of this book is to be performed while logged in as user root and no longer as user lfs"

What is a little confusing to me is that when I boot from the live cd I am already user root or at least I have to type root to get in
Is the default user root the same as user root that is mentioned in the book ? It seems to change to a different root after the chroot commands

I typed all the commands from the book and I got to glibc
with no problems. After the problem I shut it down and started again later.

One of the things I need to know is which commands are needed after restart to be able to continue or to start
from the begining of chapter 6 ?
It seems that some things have changed since I ran it the first time. I no longer get the "I have no name" because
the /etc/passwd was created

The main concern I have is with changing ownership (6.4)
The book says "Alternatively, assign the contents of the /tools directory to user root by running the following command chown -R 0:0 /tools
Is this really needed if I am the only user ?


It seems that I locked myself out
If I type just the first line "chroot "$LFS" /tools/bin/env -i"
I get "cannot change root directory to : No such file or directory"
If I type "chown -R 0:0 /tools"
I get " cannot access '/tools': No such file or directory"

It's like I don't have access to the /tools directory

Can I just delete the passwd file in /etc?

Haven't done LFS but wanted to answer some things that may be confusing you.

root USER (user with UID 0) is the "super user" for Linux and UNIX systems.

root DIRECTORY is the "/" which is the top level directory for Linux and UNIX systems.

root HOME directory is the directory root is in when you first login which may be "/" but is often "/root". Despite this you will still have "/" as the root directory.

chroot is a command that makes another directory APPEAR to be the root DIRECTORY (e.g. once you have chrooted even if you're really in the directory "/tools" when you type pwd it will say you are in "/". The idea of chroot is to limit the access to the real directory and the subdirectories it contains.

So say you have the following directories:
/
/usr
/usr/lib
/bin
/root
/tools
/tools/bin
/tools/usr
/tools/mydir

AND your passwd file contains the following for the root user:
root:x:0:0:root:/root:/bin/bash
Passwd entry shows:
root is user name
passwd is stored somewhere else (shadow, PAM or other)
root UID is 0
root default group is group 0 (which is the root group)
home directory for root is /root
default shell for root is /bin/bash

If you login and do pwd it will show "/root".

If you do cd / then do "ls -l" it will show all the directories above. (You could see real /, /usr, /usr/lib, /tools ...)

However if you were chrooted to the directory /tools and typed "pwd" it would show you "/" even though you are really in "/tools". If you then did "ls -l" while chrooted it would show only the directories:
/
/bin
/usr
/mydir

Note that there is not really a mydir in the real root directory so the fact you see it as a subdirectory of / would confirm you were chrooted to /tools. The /bin and /usr you see are not the ones you saw when you weren't chrooted but are rather actually /tools/bin and /tools/usr - you just don''t see "/tools" at all because "/tools" APPEARS to be "/".

The point of the above is so that you could have someone (or some process) chrooted to a certain directory. If that user or process gets hacked then the person can get nowhere outside the chrooted directory (/tools in the example). So if they did "rm -rf /" to try to erase all the files and directories they would in fact only be able to erase all the files under /tools which means you could recover /tools from your backup without having to reload the system from scratch.

chown 0:0 filename is the same as chown root:root filename which means set the owner and the group to root.

Hello,
Thanks for the information

When I first boot up and login I have to type root to login so the first prompt is "lfs6cd:root~ #" and when I type pwd I get /root so that's the home directory so far it's ok
Then I have to sidetrack a little to get to the /tools directory
I have to mount the lfs with mount /dev/hda7 /mnt/lfs
So the real location of /tools is in /mnt/lfs/tools

The problem is that I can't even chroot anymore because of the error
"cannot change root directory to : No such file or directory"
so I can't try the pwd while I am chrooted

I would like to undo what I did so far (the chroot and the chown) but I don't want to erase or make what I did up to this point unusable.
I am not even sure if that is the problem but I want to give it a try.

Every command that is in the /tools directory is not working anymore.

Is there a way to undo the chroot command ?

Hi,

The note is there to remind you that the rest is done as user root. The LFS team did this because most of chapter 5 is done as user lfs.

I don't know how you try to enter the chrooted environment, but if you only try this part "chroot "$LFS" /tools/bin/env -i" (as stated in your first post) it will not work. You need to enter the complete command to make sure that environment settings are correct and the correct bash shell is started for the chrooted environment. I.e (as stated in the book):
Also: You cannot undo the chroot command. You can enter or exit a chrooted environment, but this command alone does not set anything permenantly that you can/need to remove.

See man chroot for details on chrooted environments.

Setting up the correct environment before you (re)start is very important. There is a lfs hint that explains what needs to be done, but it is based on an early 6.X LFS version so things may differ a bit.

If I remember correctly you are installing LFS 6.0, based on that the following needs to be done (for chap 6.2->6.8):
PS: replace /dev/sda1 and /dev/sda2 with what is appropriate for your setup.

PPSS: The above steps are for restarting between 6.2 and 6.8 (including). If you restart at a later point see the hints file for appropriate steps (and check them against the LFS version you are installing).

Hope this gets you going again.

Hello,
Thanks for the restart steps.
I see that the problem was that I missed the mkdir -pv $LFS
So when I ran the chroot "$LFS" /tools/bin/env -i the error was because
there was no $LFS directory not the /tools/bin directory.

So now I still have the original problem running glibc that I have on another post in which it can't seam to find gcc
Maybe I should rephrase the post in order to get more replies

If I am inside chroot and I run gcc -v should I get a similar display that
I get outside ?
Right now when I am inside chroot I get
bash: /tools/bin/gcc: No such file or directory

TO reply to jlitner

"If you're really in the directory "/tools" when you type pwd it will say you are in "/" "
Now that I can get in I can try the pwd and it's not like you said
If I am in /tools and I type pwd I get /tools and when I am in / and I type pwd I get /
Is that a problem ?

My response was based on the idea that /tools was the chroot directory. It appears from what you wrote it is not.

The /tools/bin/gcc it is looking for is relative to the actual chroot directory if you are chrooted.

So if the chrooted directory were /mnt/test/something/longpath then there would need to exist:
/mnt/test/something/longpath/tools/bin/gcc.

When NOT chrooted you would see the latter path.
When you ARE chrooted you'd see it as just /tools/bin/gcc because "/mnt/test/something/longpath" is now seen as simply "/".

Basically when you make a directory you intend to use for chroot you have to copy into it the things that you would need if it root. It sounds as if you haven't copied in your reall gcc file into CHROOTDIR/tools/bin/gcc from wherever it exists outside.

e.g. In reality ls and bash are in /bin. If you want to use them inside the CHROOTDIR you'd need to copy them there so using my above you'd need to do:
mkdir /mnt/test/something/longpath/bin
cp -p /bin/ls /mnt/test/something/longpath/bin
cp -p /bin/bash /mnt/test/something/longpath/bin
You'd of course do that BEFORE doing the chroot.
After the chroot you'd see the files simply as /bin/bash and /bin/ls. However you wouldn't see anything else in /bin that you hadn't copied into it. Without being chrooted you'd see dozens of files in /bin normally.

Hello,
So in my case the chroot directory would be /mnt/lfs because I don't see that
once I am inside chroot. I only see what is after that which is /tools/bin/gcc

You could be right but I don't see why I would need to copy gcc if it's already there. The file (gcc) exists outside of chroot in /mnt/lfs/tools/bin/gcc and I also see it inside chroot at /tools/bin/gcc.
The only difference is that it works outside but not inside chroot.

Hi,

If you enter the chrooted environment the only commands (and libraries etc) that can be used are those inside that environment. That is what LFS chapter 5 is for: Create an (temporary) environment that is needed to do all the stuff in chapter 6. Nothing is (can be) used outside the chrooted environment once you enter it.

To quote the LFS book:
If commands work outside the chrooted environment (/ie: /mnt/lfs/bin/gcc) and it does not when you entered the chrooted environment (ie: /bin/gcc) something went wrong during chapter 5 or you entered the chrooted environment the wrong way. I've seen you using chroot "$LFS" /tools/bin/env -i in the previous post, I hope that's not the command you use, it's a bit longer then that, as I stated in post #4.

Hello,
Actually I did not do what I said when I said that it was working outside.
That was the /usr/bin/gcc that was working.
In order to check it I have to login as lfs user

So if I login as lfs user and run the sanity check and it's working does that
mean that chapter 5 was done correctly ?


I know that chroot line was short but that was because I was getting that error and entering the full line did not make any difference but I do enter it correctly now that it's working.
I may have hit the enter key by mistake one time when I meant to enter the
the "\" key which is right above the enter key but I retyped the entire line after that.

Hello,
I loged in as lfs user and was able to do the sanity check in chapter 5 so as far as I know chapter 5 was done correctly and gcc works as it should.

So I think it has something to do with the chroot environment I just don't know what it is.

Is there a way to reset the chroot environment ?
Does it automatically make a new environment everytime I go inside the chroot ?

Do this:

Do your chroot
Type "cd /" and hit return
Type "pwd" and hit return
Type "ls -ld /tools" and hit return
Type "ls -ld /tools/bin" and hit return
Type "ls -ld /tools/bin/gcc" and hit return.
Type "file /tools/bin/gcc" and hit return.

Cut and paste everything you typed and what you saw (without password of course) here. Either you're not understanding what we're telling you about chroot or we're not properly understanding your chroot environment. Doing the above will help make sure we're understanding your environment.

Hello,
I can't cut and paste because I am using it on a laptop but I can type what I get
For pwd I get /
for ls -ld /toola I get drwxr-xr-x 14 root root 4896 oct 15 18:13 /tools
for ls -ld /tools/bin I get drwxr-xr-x 3 root root 4896 oct 21 18:32 /tools/bin
for ls -ld /tool/bin/gcc I get -rwxr-xr-x 3 root root 85252 oct 8 18:14 /tools/bin/gcc
for file /tools/bin/gcc I get bash: file: command not found
I verified and there is no find command in /tools/bin if that's where is supposed to be located


I checked it outside the chroot if that helps
so for find /mnt/lfs/tools/bin/gcc I get /mnt/lfs/tools/bin/gcc ELF 32-bit executable, Intel 80386, version 1 (sysv), for GNU/linux 2.6.0 dynamically linked (uses shared libs), stripped

Hi,

I've re-read this whole thread and noticed that some extra (important??) information isn't provided. So here are a few questions:

What is the actual error you are getting and which command did you use (I assume the configure step).

Did you truly solve all your previous problems? Especially this part (original text can be found here):

So instead of copying it to /mnt/lfs/tools it made another directory /tools within tools and copied the files there.
So the only thing I did differently was to put /mnt/lfs in front of those /tools copy commands to make sure there is only one tools directory
Everything else I made the same.
So I am not sure if that was the problem but it's working now

Looks to me that you ended up with something like this: /mnt/lfs/tools/tools/. Which could have work at the time, but is definitely incorrect and could be the cause of your current problems.

Also, what does env show you (from within the chrooted environment).

I understand that you cannot copy/paste and need to retype all output, so I'll leave it at this (for the moment).

Hello,
I'll start with the last question first
For env I get
TERM=linux
PATH=/bin:/usr/bin:/sbin:/usr/sbin:/tools/bin
PWD=/
PS1=\u:\w\$
SHLVL=1
HOME=/root
-=/tools/bin/env
That last line looks a bit strange to me
Is that correct ?

As to the other questions
Yes that error was at the configure step of glibc
These lines are from the config.log that was generated
I'll start a little before the error to see the sequence in case that is important
configure:2182 checking for BSD compatible install
configure:2237 result: /tools/bin/install -c
configure:2252 checking weather ln -s works
configure:2256 result: yes
configure:2310 checking for gcc
configure:2326 found /tools/bin/gcc
configure:2336 result: gcc
configure:2580 checking for C compiler version
configure:2583 gcc --version </dev/null>&5
../glibc-2.3.4-20040701/configure: line 2584 /tools/bin/gcc Mo such file or directory
configure:2586 $7 = 127
configure:2588 gcc -v </dev/null>&5
../glibc-2.3.4-20040701/configure: line 2589 /tools/bin/gcc Mo such file or directory
configure:2591 $7 = 127
configure:2593 gcc -V </dev/null>&5
../glibc-2.3.4-20040701/configure: line 2594 /tools/bin/gcc Mo such file or directory
configure:2596 $7 = 127
configure:2600 checking for suffix of object files
configure:2621 gcc -c conftest.c>&5
../glibc-2.3.4-20040701/configure: line 2622 /tools/bin/gcc Mo such file or directory
configure:2624 $7 = 127
configure: failed program was:
| /* confdefs.h. */
Skipping a few lines...(p
configure:2638: error cannot compute suffix of object files: cannot compile
See 'config.log' for more details

I am not sure if adding /mnt/lfs in front of /tools/glibc-kernheaders was
the right way to fix it but I made sure there was only one /tools directory
after that build. That was the only place I used it

Hi,

This looks correct. The last line shows the last command entered (including full path), so that's also correct.

Looks like gcc is found, but not workling proparly.

I still think that the problem lies with the install of gcc in chapter 5.

I see from your previous posts that you have had problems from day one. If I where you I would download the latest version (liveCD 6.2-3). All (most?) errors from 6.0 to 6.2.2 in the 6.2.3 version have been fixed and some other important changes have been made.

If you ever get the 6.0 version you are working on to boot, you must ask yourself if it is stable and usable especially after all the problems and personal tweaks (to get it working). Starting with a clean sheet looks like the best options to me.

This is probably not the answer you where looking for, but the best (most honest) I can come up with.