[SOLVED] LFS 7.3 Sec 6.7 fixdep: permission denied error

Godsgood33 · 04-12-2013, 06:23 PM

I've been working through the LFS 7.3 book and I've hit a snag. I've gotten all the way through chapter 5 without a hitch and I get to 6.7 where I'm installing the kernel API headers and when running the "make headers_check" I get the following problem...

Code:

root:/sources/linux-3.8.1# make mrproper
root:/sources/linux-3.8.1# make headers_check
  CHK     include/generated/uapi/linux/version.h
  UPD     include/generated/uapi/linux/version.h
  HOSTCC  scripts/basic/fixdep
/bin/sh: scripts/basic/fixdep: Permission denied
make[1]: *** [scripts/basic/fixdep] Error 1
make: *** [scripts_basic] Error 2

I've looked at that fixdep file and it's set to 660. I tried changing it to 770, but then when I ran the command again it was reset back to 660 and still gave me the permission denied error.

If I run the make with a verbose flag "V=2" I get this...

Code:

 HOSTCC  scripts/basic/fixdep - due to missing .cmd file

I asked on the LFS forum, but nobody has responded. I've run through the book three times now to this point, copy/pasting the code exactly as it is in the book. Any suggestions would be appreciated! TIA

spiky0011 · 04-13-2013, 04:43 AM

Hi

This section is run in chroot. When enteting
chroot did you make sure lfs is in roots path
login as root run echo §LFS

Godsgood33 · 04-13-2013, 11:47 AM

Quote:

Originally Posted by spiky0011

Hi

This section is run in chroot. When enteting
chroot did you make sure lfs is in roots path
login as root run echo §LFS

That is not necessary to have the LFS variable...6.4 says
From this point on, there is no need to use the LFS variable anymore, because all work will be restricted to the LFS file system. This is because the Bash shell is told that $LFS is now the root (/) directory.

druuna · 04-13-2013, 01:23 PM

Quote:

Originally Posted by Godsgood33

That is not necessary to have the LFS variable...

The chroot command itself needs/uses the LFS variable, so it must be set in root's environment (or use the representing full path instead of the LFS variable).

Quote:

6.4 says
From this point on, there is no need to use the LFS variable anymore, because all work will be restricted to the LFS file system. This is because the Bash shell is told that $LFS is now the root (/) directory.

This is true after executing the chroot command (I.e.: Inside the chrooted environment).

Godsgood33 · 04-13-2013, 01:35 PM

Quote:

Originally Posted by druuna

The chroot command itself needs/uses the LFS variable, so it must be set in root's environment (or use the representing full path instead of the LFS variable).

This is true after executing the chroot command (I.e.: Inside the chrooted environment).

As I stated in the initial post, I copied all the commands exactly as they are in the book. LFS variable has been present all the way through.

druuna · 04-13-2013, 01:52 PM

Quote:

Originally Posted by Godsgood33

As I stated in the initial post, I copied all the commands exactly as they are in the book.

Errors and/or typo's are easy to make and the fast majority of errors encountered are made by the builder. Besides that, your previous post (#3) is wrong, you do need the LFS variable.

If all the commands are copied correctly, then the only thing I can think of that might have been "overlooked": Did you remove the linux source directory after finishing chapter 5.6?

Godsgood33 · 04-13-2013, 02:31 PM

Quote:

Originally Posted by druuna

Errors and/or typo's are easy to make and the fast majority of errors encountered are made by the builder.

Yes, I agree a majority of mistakes occur between the chair and keyboard. Just like "fast majority"...pretty sure you meant "vast majority" ;-)

Quote:

Besides that, your previous post (#3) is wrong, you do need the LFS variable.

If I am wrong then so is the book...I quoted directly from it. So you'll need to take that up with the authors. If you mean I need the variable in the chroot command, then you are correct, but I clarified in comment #5 that I ran all through the script multiple times and get the same result. I have check the LFS variable multiple times to make sure that it is there and in at least on instance check just before running the chroot command and it was as it should be (/mnt/lfs).

Quote:

If all the commands are copied correctly, then the only thing I can think of that might have been "overlooked": Did you remove the linux source directory after finishing chapter 5.6?

Yes, I did remove the Linux source directory just like the instructions indicate on page 34. The instructions in 5.6 do not say to leave it, so I removed it.

Something I did forget to mention because it didn't seem like it would be a problem. In section 5.7 when setting up Glibc, the error that the book mentions about msgfmt incompatibility...I didn't get that message, but I did get the same message about autoconf. The INSTALL file says it needs 2.53 or higher...I have 2.69. So because of that I didn't think it would be a problem...could that be part of it?

Godsgood33 · 04-13-2013, 02:55 PM

Quote:

Originally Posted by spiky0011

Hi

This section is run in chroot. When enteting
chroot did you make sure lfs is in roots path
login as root run echo §LFS

Sorry, Spiky...I didn't see you mention version-check until just now...here it is.

Code:

bash, version 4.2.37(1)-release
/bin/sh -> /bin/bash
Binutils: (GNU Binutils for Ubuntu) 2.22.90.20120924
bison (GNU Bison) 2.5
/usr/bin/yacc -> /usr/bin/bison.yacc
bzip2,  Version 1.0.6, 6-Sept-2010.
Coreutils:  8.13
diff (GNU diffutils) 3.2
find (GNU findutils) 4.4.2
GNU Awk 4.0.1
/usr/bin/awk -> /usr/bin/gawk
gcc (Ubuntu/Linaro 4.7.2-2ubuntu1) 4.7.2
(Ubuntu EGLIBC 2.15-0ubuntu20) 2.15
grep (GNU grep) 2.12
gzip 1.5
Linux version 3.5.0-27-generic (buildd@lamiak) (gcc version 4.7.2 (Ubuntu/Linaro 4.7.2-2ubuntu1) ) #46-Ubuntu SMP Mon Mar 25 19:58:17 UTC 2013
m4 (GNU M4) 1.4.16
GNU Make 3.81
patch 2.6.1
Perl version='5.14.2';
GNU sed version 4.2.1
tar (GNU tar) 1.26
Texinfo: makeinfo (GNU texinfo) 4.13
xz (XZ Utils) 5.1.0alpha
gcc compilation failed

I don't know why it said gcc compilation failed. The file it creates "dummy" is not executable, so that might be why. If I created the file manually like this...

Code:

echo 'main(){puts("test\n");}' > dummy.c

And then compiled with

Code:

gcc -o dummy dummy.c

, then I had to change the file so it was executable and if I ran it it output "test" as expected. So it seems that the compiling is working just fine...I don't know why the version-check script is saying it failed. I'm not that familiar with bash scripting so I don't know what -x means. If it means is it executable, the gcc does not make it executable when it creates the binary....

Think I may have just figured something out...I'll get back in just a second...

Godsgood33 · 04-13-2013, 04:34 PM

I think I figured out what the problem was...my root user has the umask 117...so that making it so that when the file was created it would not have execute permissions. This obviously make the code from executing the fixdep script. I had changed the umask on my personal user back to 022 a while back because of a similar issue, but forgot to change the root user back.