Linux From ScratchThis Forum is for the discussion of LFS.
LFS is a project that provides you with the steps necessary to build your own custom Linux system.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Plus, last to my knowledge ALFS has not been updated for quite some time against the newer books documentation.
I always had a lot of trouble with jhalfs. I used to get "permission denied" errors somwhere along the build. But this time it actually worked, i.e. it ran through without error.
Jhalfs is supposed to work against the current development version. Given that the lfs 7.4 book seems to work, I would like to stick to this.
Quote:
You really should maintain your own build scripts for LFS and BLFS.
I have tried something like this. But it is an awful lot of work and I was not successful so far.
Now that my system works in a virtual box, I am actually quite confident that the system is ok.
As a summary I would say I had two problems:
An erroneous /etc/fstab file that led to the VFS: Unable to mount root fs" panic and an erroneously unchecked 64bit option in the kernel config that led to the "no init found" panic. This would explain what I experience on the virtual machine.
Now I get the first error again on a physical machine even though I adressed both problems.
That's confusing...
What I do currently is I have what is a drafted script based on a standard SlackBuild shell script.
I'll drop you a sample here of one of mine (this one is for glibc-2.18) so feel free to use it as needed to create other scripts.
Do note that there are a few sections that will need to be addressed such as the time zone selections and if you want to run the tests.
glibc.LFSBuild
Code:
#!/bin/sh
# LFS Build Script for glibc-2.18
# Copyright (c) 2013 ReaperX7 <james4591@hotmail.com>
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions are
# met:
#
# * Redistributions of source code must retain the above copyright
# notice, this list of conditions and the following disclaimer.
#
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
tar -xJf glibc-2.18.tar.xz
cd glibc-2.18
sed -i -e 's/static __m128i/inline &/' sysdeps/x86_64/multiarch/strstr.c
mkdir -v ../glibc-build
cd ../glibc-build
../glibc-2.18/configure \
--prefix=/usr \
--disable-profile \
--enable-kernel=2.6.32 \
--libexecdir=/usr/lib/glibc
# --libexecdir=/usr/lib/glibc
# This changes the location of some auxillary files from the default of
# /usr/libexec to /usr/lib/glibc.
make
# Uncomment these lines to enable checks of the build. Please note some
# tests are known to fail and may error and cancel the build script.
# make -k check 2>&1 | tee glibc-check-log
# grep Error glibc-check-log
touch /etc/ld.so.conf
make install
cp -v ../glibc-2.18/sunrpc/rpc/*.h /usr/include/rpc
cp -v ../glibc-2.18/sunrpc/rpcsvc/*.h /usr/include/rpcsvc
cp -v ../glibc-2.18/nis/rpcsvc/*.h /usr/include/rpcsvc
make localedata/install-locales
cat > /etc/nsswitch.conf << "EOF"
# Begin /etc/nsswitch.conf
passwd: files
group: files
shadow: files
hosts: files dns
networks: files
protocols: files
services: files
ethers: files
rpc: files
# End /etc/nsswitch.conf
EOF
tar -xf ../tzdata2013d.tar.gz
ZONEINFO=/usr/share/zoneinfo
mkdir -pv $ZONEINFO/{posix,right}
for tz in etcetera southamerica northamerica europe africa antarctica \
asia australasia backward pacificnew solar87 solar88 solar89 \
systemv; do
zic -L /dev/null -d $ZONEINFO -y "sh yearistype.sh" ${tz}
zic -L /dev/null -d $ZONEINFO/posix -y "sh yearistype.sh" ${tz}
zic -L leapseconds -d $ZONEINFO/right -y "sh yearistype.sh" ${tz}
done
cp -v zone.tab iso3166.tab $ZONEINFO
zic -d $ZONEINFO -p America/New_York
unset ZONEINFO
tzselect
# Edit this script section before execution to give the correct time
# zone data for your time zone such as America/Los_Angeles to the
# replace <xxx> placeholder.
cp -v --remove-destination /usr/share/zoneinfo/<xxx> \
/etc/localtime
cat > /etc/ld.so.conf << "EOF"
# Begin /etc/ld.so.conf
/usr/local/lib
/opt/lib
EOF
cat >> /etc/ld.so.conf << "EOF"
# Add an include directory
include /etc/ld.so.conf.d/*.conf
EOF
mkdir -pv /etc/ld.so.conf.d
cd ..
rm -rf glibc-2.18
rm -rf glibc-build
# End of LFS Build script for glibc-2.18
Right now I have no reason to believe jhalfs did not work correctly. In fact I think it worked just fine. Id does boot in my virtual machine.
So I'm afraid if I rebuild lfs 7.4 (by hand or from a self-written batch) I will have an identical system with the same problem. So before doing this I would like to find out where the problem is, first.
Given that the system works on one machine but not on the other I can only think of two possibilities:
1. the kernel lacks a driver that would be needed for the workstation (even when the kernel is configured/built on the workstation).
2. one of the packages does not work on the workstation because it was built on another (the virtual) machine (even though I did not use any kind of optimization).
For 1. I looked into the kernel menuconfig without finding anything (but there are many settings...)
For 2. all I could do is run jhalfs on the workstation rather than in the virtual machine.
If you are having kernel trouble try to download the Slackware Huge-Kernel config and try to import it's settings into an LFS build. Otherwise, try using lspci and other such tools to learn the ins and outs of your hardware and see which chipsets are being used and try to see which match up in the kernel configs.
Patrick's Huge kernel is literally a one-stop-shop-kill-everything-that-moves kernel.
If you are having kernel trouble try to download the Slackware Huge-Kernel config and try to import it's settings into an LFS build. Otherwise, try using lspci and other such tools to learn the ins and outs of your hardware and see which chipsets are being used and try to see which match up in the kernel configs.
Patrick's Huge kernel is literally a one-stop-shop-kill-everything-that-moves kernel.
Thanks for the hint. Not tried it out yet but it sounds like the way to go. I will keep this in mind.
I finally had the time to test the system on a different machine (Asus board, C2D) and it booted successfully. In all the tests I have conducted so far, the system performs flawlessly. Therefore I will not try to make it work on the workstation at the moment.
A remark about your build script example from above. Instead of e.g.
Code:
tar -xJf glibc-2.18.tar.xz
you could use
Code:
tar -xJf glibc*.tar.xz
which would make it much easier to reuse the script with future book versions (usually unchaged).
Or do you have a reason for keeping the version number there?
There were three problems leading to similar, though different kernel panic problems.
1. There were some errors in my /etc/fstab file
2. I changed to 32 bit in the kernel config without taking care of other settings. In retrospect, 64 bit (default) is just fine for my purpose. It turned out HPET is active by default and the option is invisible in the menuconfig.
3. The kernel seems to lack a driver for my workstation.
By adressing the first two issues I got a system that seems to work perfectly on most machines.
druuna and ReaperX7, thank you very much for your help!
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.