[SOLVED] LFS 7.9, chap.6.7 fails on make mrproper

perseus12 · 08-22-2016, 07:54 AM

Hi all, I've already completed a build of LFS 7.9 upto chap 6.73. Did it by cutting pasting commands into a console. Now I've started to automate by putting commands into shell scripts. Section 5 works and section 6 works up to ch 6.7. the scripts are simple at this point containing just the commands shown in LFS book.
Ch 6.7 fails as follows:
"...
make -f ./scripts/Makefile.clean obj=Documentation/DocBook
make -f ./scripts/Makefile.clean obj=scripts
make -f ./scripts/Makefile.clean obj=scripts/basic
make -f ./scripts/Makefile.clean obj=scripts/dtc
make -f ./scripts/Makefile.clean obj=scripts/gdb
make -f ./scripts/Makefile.clean obj=scripts/gdb/linux
make -f ./scripts/Makefile.clean obj=scripts/genksyms
make -f ./scripts/Makefile.clean obj=scripts/kconfig
make -f ./scripts/Makefile.clean obj=scripts/mod
make -f ./scripts/Makefile.clean obj=scripts/package
make -f ./scripts/Makefile.clean obj=scripts/selinux
make -f ./scripts/Makefile.clean obj=scripts/selinux/genheaders
make -f ./scripts/Makefile.clean obj=scripts/selinux/mdp
rm -rf
rm -f
CHK include/generated/uapi/linux/version.h
UPD include/generated/uapi/linux/version.h
HOSTCC scripts/basic/fixdep
/bin/sh: line 1: 21739 Segmentation fault scripts/basic/fixdep scripts/basic/.fixdep.d scripts/basic/fixdep 'gcc -Wp,-MD,scripts/basic/.fixdep.d -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 -fomit-frame-pointer -std=gnu89 -o scripts/basic/fixdep scripts/basic/fixdep.c ' > scripts/basic/.fixdep.tmp
make[1]: *** [scripts/basic/fixdep] Error 139
scripts/Makefile.host:91: recipe for target 'scripts/basic/fixdep' failed
make: *** [scripts_basic] Error 2
Makefile:439: recipe for target 'scripts_basic' failed"

It is the "make mrproper" command that fails.
I used make V=1 mrproper to generate the output.

If instead of running the script I enter the command into the same console it works as follows:

bash-4.3# make mrproper
CLEAN scripts/basic
CLEAN include/generated
bash-4.3#

Have tried #!/tools/bin/bash and #!/bin/bash as script header, both fail.

Also observed that the script can echo text but cannot read input.
So "echo foobar" works but "read -p foobar" does not. running script with set -ex shows that it does not fail on the read -p, its just ignored.

Running 'expect -c "spawn ls"' at the top of the script produces correct output.

I've searched for this problem and found similar errors but for those that had solutions they do not work. the most promising was to create these outside of a script:
mknod -m 600 $LFS/dev/console c 5 1
mknod -m 666 $LFS/dev/null c 1 3

Did it but did not work.
Hope someone can help.

Keith Hedger · 08-22-2016, 10:39 AM

Post your actual script that is failing and PLEASE use code tags
http://www.linuxquestions.org/questi....php?do=bbcode

spiky0011 · 08-22-2016, 11:33 AM

Is

Code:

mount -v --bind /dev $LFS/dev

mounted ok? or any of the other "Virtual Kernel File Systems"
Can you do this part manuely along with the chroot.

perseus12 · 08-22-2016, 12:49 PM

spiky0011:
will try

Code:

mount -v --bind /dev $LFS/dev, etc...

when I get home later today.

The output of version-check:

Code:

bash, version 4.2.53(2)-release
/bin/sh -> /bin/bash
Binutils: (Linux/GNU Binutils) 2.23.52.0.1.20130226
bison (GNU Bison) 2.7
yacc is bison (GNU Bison) 2.7
bzip2,  Version 1.0.6, 6-Sept-2010.
Coreutils:  8.21
diff (GNU diffutils) 3.3
find (GNU findutils) 4.4.2
GNU Awk 4.1.0, API: 1.0 (GNU MPFR 3.1.2, GNU MP 5.1.3)
/usr/bin/awk -> /bin/gawk-4.1.0
gcc (GCC) 4.8.2
g++ (GCC) 4.8.2
(GNU libc) 2.17
grep (GNU grep) 2.14
gzip 1.6
Linux version 3.10.17 (root@hive64) (gcc version 4.8.2 (GCC) ) #2 SMP Wed Oct 23 16:34:38 CDT 2013
m4 (GNU M4) 1.4.17
GNU Make 3.82
GNU patch 2.7.4
Perl version='5.18.1';
sed (GNU sed) 4.2.2
tar (GNU tar) 1.26
makeinfo (GNU texinfo) 4.13
xz (XZ Utils) 5.0.5
g++ compilation OK
libgmp.la: found
libmpfr.la: found
libmpc.la: found

Keith:
the script is shown below:

Code:

#!/bin/bash

PKG='linux-4.4.2'

cd /build
rm -rf ./$PKG
tar xf /source/$PKG.tar.xz || exit 1
cd ./$PKG

make V=1 mrproper || exit 1

make INSTALL_HDR_PATH=dest headers_install || exit 1
find dest/include \( -name .install -o -name ..install.cmd \) -delete
cp -rv dest/include/* /usr/include

Keith Hedger · 08-22-2016, 02:23 PM

Well just ran your script ( on version 4.2 ) and no problems at all both in a chroot environment and not and with/without dev etc mounted in the chroot, so I must assume you have a badly mounted LFS partition or a corrupt kernel archive ( unlikely but check the md5sum ) or something went weirdly wrong earlier and you have some cross contamination from the host system, what happens if you run your script in the host system? does it fail there?

perseus12 · 08-22-2016, 03:55 PM

Keith, i'm not home yet so cant check this but how can I test for a badly mounted LFS partition? also if I remember correctly these are the things to note:
I can complete all chap 5.04 through to 6.73 if I cut / paste into a console. Using the same user setup and source I can run chaps 5.04 to 5.34 in a script, then if I manually run chap 6 commands then success. If I run the same chap 6 commands as scripts like I sent you then
chap 6.07 fails. I have tried to run the script I sent you in an xterm, rxvt and then out of X in a console with same failure. I have checked from within chroot the following:

Code:

mkdir -pv $LFS/{dev,proc,sys,run}

mknod -m 600 $LFS/dev/console c 5 1
mknod -m 666 $LFS/dev/null c 1 3

mount -v --bind /dev $LFS/dev

mount -vt devpts devpts $LFS/dev/pts -o gid=5,mode=620
mount -vt proc proc $LFS/proc
mount -vt sysfs sysfs $LFS/sys
mount -vt tmpfs tmpfs $LFS/run

if [ -h $LFS/dev/shm ]; then
  mkdir -pv $LFS/$(readlink $LFS/dev/shm)
fi

What I'll double check later is what happens if I enter the above code manually then run the scripts.

What I was hoping would be meaningful is the fact that it seems stdout and stderr work ok but not stdin in the script I sent you. Maybe a red herring?
will let you guys know as soon as I've made progress

Keith Hedger · 08-23-2016, 04:44 AM

stdin is not used in the script you posted, as you don't do any reads.

Keith Hedger · 08-23-2016, 04:48 AM

Quote:

Originally Posted by perseus12

... I have checked from within chroot the following:

Code:

mkdir -pv $LFS/{dev,proc,sys,run}

mknod -m 600 $LFS/dev/console c 5 1
mknod -m 666 $LFS/dev/null c 1 3

mount -v --bind /dev $LFS/dev

mount -vt devpts devpts $LFS/dev/pts -o gid=5,mode=620
mount -vt proc proc $LFS/proc
mount -vt sysfs sysfs $LFS/sys
mount -vt tmpfs tmpfs $LFS/run

if [ -h $LFS/dev/shm ]; then
  mkdir -pv $LFS/$(readlink $LFS/dev/shm)
fi

...

These commands need to be run before you enter the chroot not after.

perseus12 · 08-23-2016, 06:38 AM

Keith, two points:
1. yes I did run those commands before entering chroot otherwise even manual running of scripts would not work. sorry if gave you wrong understanding, I meant I checked those from within chroot.
2. the script I sent you is exactly the one that I first ran and got error. I then added read -p lines to be able to pause it and check what was going on and that is when I realized stdin was being ignored.

Furthermore I repeated some tests last night and can definitely say that after completing chap 6 manually up to part 6, then running part 7 'linux headers' manually I get no failures. If I run the same commands in a script I get the segmentation fault at make mrproper, which may mean that the bash build (in 5.16) went wrong but I did not see any errors.

Keith Hedger · 08-23-2016, 08:07 AM

Try running ( from the chroot )

Code:

ldd $(which bash)

If you get an output that includes 'tools' or anything from the host then bash went wrong.

perseus12 · 08-23-2016, 07:18 PM

At the point of entering chroot there is no 'which' so cant do what you ask but the
result of ldd /bin/bash (which points to /tools/bin/bash) is:

Code:

ldd /bin/bash 
  linux-vdso.so.1 (0x00007fff10bff000)
  libdl.so.2 => /lib64/libdl.so.2 (0x00007f21470e1000)
  libc.so.6 => /lib64/libc.so.6 (0x00007f2146d17000)
  /tools/lib64/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f2147312000)

If you have a copy of $LFS/tools archived just after end of chap5 could you see what ldd /bin/bash produces for you?
thanks

Keith Hedger · 08-24-2016, 05:49 AM

You are of course correct there is no 'which' at that stage! Sorry, just goes to prove that no matter how many times you build LFS you can still make stupid mistakes!

Your ldd output looks fine so I can't understand why your script is failing, something went subtly wrong during the tools build phase I'm guessing, don't know what else to suggest

spiky0011 · 08-24-2016, 06:47 AM

What happens if you chroot in manualy and complete all of Ch6 to 6.6 manualy, Then run script from Ch6.7

perseus12 · 08-24-2016, 07:39 AM

spiky0011: the way you suggest fails as well. But I may have found a solution.

I completed all of chap 5 via automated scripts; completed chap 6 up to & including part 6.6 manually, then continued with 6.7, etc manually. By doing cut/paste the steps are known to work. Then during part 6.17. GCC-5.3.0 build, I entered another chroot via an xterm and ran a test script:

Code:

!/bin/bash

PKG='linux-4.4.2'

cd /build
rm -rf ./$PKG
tar xf /source/$PKG.tar.xz || exit 1
cd ./$PKG

make V=1 mrproper || exit 1
make V=1 INSTALL_HDR_PATH=dest headers_install || exit 1

and the script worked just fine.

I need to repeat this later to verify that nothing installed during 6.7 to 6.16 influenced things. Note that 6.17 was still running tests so had not installed anything at that point.
So one of two things could be true:
1. something done between 6.7 - 6.16 provided a fix
2. something in the initial chroot environment is screwed

Remember that in chap 6 we do'chroot' and then an 'exec /tools/bin/bash --login +h' before we start make mrproper whereas entering another chroot environment we simply do chroot, the files /etc/passwd and /etc/group exist already so we don't have to do another login.
I'm speculating, not saying this is the solution; and it is probable that something is wrong in my chap 5 tools. However if I have found the solution it may point to the problem, kind of reverse engineering ;-)
hopefully I can provide a definite answer soon.

perseus12 · 08-26-2016, 07:02 AM

I've figured out the cause of the problem. I had archived the tools from two separate runs of chap 5. #2 I had used to compare to Slackware binaries, but I had deleted all locales, manpages & docs from it to save space. Stupidly this is the one I had restored later.

I've restored the pristine archive and verified that that results in everything working just fine. The automated scripts work as expected. After some quick tests I think that the problem wasn't 'bash' but 'make' was failing on some line of the kernel makefile.
As well, the reading of stdin is solved as well. Haven't looked deeper into this but with
'LC_ALL=POSIX' defined but no locales, (even /usr/share/i18n was empty) it caused my problem.
So I'm marking this thread as solved. Thanks to all for the help.