The FAQ tries to answer questions before they're asked. This saves the trouble of asking them, and sometimes, the trouble of encountering a problem.
This does reduce traffic and improve the signal to noise ratio but that is merely a useful side effect.
Since the FAQ isn't the natural place to look for information, items should be added to it only if they can't be added to the appropriate documentation, although sometimes it will be necessary to add a pointer to the information in the documentation.
LFS stands for Linux From Scratch which is a project that documents how to install a Linux system by downloading, building, and installing the packages yourself.
For why you might want to do this, how to do it, and other useful stuff, see the website at http://www.linuxfromscratch.org/.
The full answer is at http://www.linuxfromscratch.org/mailinglists/info.shtml, but here is a summary:
Send support questions to only lfs-support and blfs-support. Questions like "How do I..." and "I'm getting this error..." or anything else requesting help go to the support lists and no where else.
If you are not having trouble following the LFS Book itself, do not email lfs-support.
Unless you are suggesting an improvement to the LFS Book itself, do not email lfs-dev.
Only suggestions concerning the BLFS Book are acceptable on blfs-dev.
Things are a little different with blfs-support. Everything that doesn't fit one of the preceding lists fits there except for the price of beer and GNU versus BSD flamewars.
The price of beer, GNU versus BSD, and Microsoft versus Linux flamewars are restricted to lfs-chat. These days, hardware discussion should go there as well.
When this FAQ fails to help, there are several places to go.
If you're having a problem with something in the book, it never hurts to go back over the book. It's surprising how easy it is to overlook little things.
If nothing else, reading the appropriate man and info pages will yield useful information on some subject, if not what you were looking for, and insure that you know enough not to embarrass yourself if you have to ask someone.
http://www.tldp.org/ has the HOW-TOs and a great deal of other documentation. You might find something there.
The linuxfromscratch.org site search includes the mailing lists. Many questions have been discussed there at least once. It's at http://search.linuxfromscratch.org/.
For support type help, IRC is often best. It's faster, and doesn't clog the mailinglists. Information on the LFS IRC channel is at http://www.linuxfromscratch.org/misc/irc.shtml.
As a last resort, there are the mailing lists. People will get frustrated with you if you use the wrong one or cross post. Mailing list information is at http://www.linuxfromscratch.org/mailinglists/info.shtml. and tells which list to use.
Suggestions are more than welcome. The FAQ maintainer can be reached either via direct email or on the apropriate mailing list.
Useful suggestions include the addition of questions that are actually frequently asked -- with well researched answers -- and the removal of questions that are obsolete.
Serious, regular contributors are also welcome. If you're interested in doing this, you'll need to check the FAQ out of LFS CVS just like you would the book, and modify the DocBook XML source. Those modifications would normally be submitted as patches generated with "diff -Naur", but for simple additions which mostly involve the addition of a single file, it may be simpler just to send the new file.
Everything intended to go in the FAQ without substantial editing must be well thought out, checked, and researched; and written in a style consistent with the existing content.
Unix systems normally run sulogin if the normal bootup fsck run errors out so that root can log in and fix it. Because sulogin will accept any password if /etc/passwd is corrupt, the LFS developers decided this was a security risk. Therefore, the LFS bootscripts shut the machine down if fsck errors, and it must be booted with the "init=/bin/bash" kernel parameter to get a root shell. Whether this is wise is beyond the scope of the FAQ, but if it doesn't work for you you'll want to change that boot script before it's too late.
If you'd like to report a new release of a package, here's how:
Check the freshmeat page for the project to see if it has been updated. If it hasn't, report the new release there and the automated freshmeat announcements will report it to the LFS lists.
If freshmeat has been updated, check the list archives to see if freshmeat (or someone else) has reported it to lfs-book (or blfs-book for packages in BLFS).
If no one has reported it to the lists, check LFS bugzilla (or BLFS bugzilla) to see if it's there.
If it's not in bugzilla, report it to lfs-book (or blfs-book for packages in BLFS). And if you like, test the new release and report any problems or changes in compilation instructions, too.
Try "ls -i /bin/foo /bin/bar". Are the inode numbers the same? If so, they're not copies, they're hardlinked.
LFS is a very basic system, in massive contrast to traditional distributions. The reason is this: LFS is not intended to create your system as you want it. It's intended to be just enough to allow you to build your system as you want it. It's not an end, it's a beginning. When you're done with LFS, you've just started building your system.
This can be a problem if you're new to Unix systems and want a typical desktop install with X and a web browser but have no idea what packages you need. For this reason, there is Beyond Linux From Scratch, or BLFS. It's at http://beyond.linuxfromscratch.org/.
It is in LFS CVS, and you will need to use the instructions there for all packages since some of them need patches to work with gcc 3.1.
You should know that gcc 2.x and 3.x don't mix. Among other things, this means that you may have problems if you must use precompiled binaries as is often the case with closed source software. (The most recent version of Netscape 4 is reported to be fine.)
GRUB will very likely replace LILO in the book when the GRUB maintainers made a release they call stable. If you'd like to see that happen, you could bug the GRUB maintainers, since current releases seem perfectly stable.
If your current setup uses GRUB or you'd like to use it anyway, you should have no trouble following the GRUB documentation and the LFS "GRUB-Howto" Hint at http://hints.linuxfromscratch.org/hints/grub-howto.txt. If you do this, you can omit bin86, since it is only used by LILO.
For now, the book is staying with LILO 22.2 because versions of LILO after 22.2 require nasm. While there should be no problem installing nasm, the book and many users are reluctant to install an extra package just for LILO. Many users are switching to GRUB. (The book would probably switch to GRUB if the GRUB maintainers made a release they called stable. You could bug the GRUB maintainers if you'd like to see this happen.)
Users who switch to GRUB can omit bin86, since it is only used by LILO.
Marc Heerdink may have said it best in a post to lfs-dev:
The problem is that the FAQ is a dynamic document. The FAQ for a book release is released only after the book version itself, because the FAQ is updated to reflect the Qs asked about the current version of the book. A link is better, since you'll always have the most up-to-date answers handy.
This is fairly well discussed in the thread starting at http://archive.linuxfromscratch.org/mail-archives/lfs-dev/2002/02/0012.html.
The book includes ed because patch uses it to process ed scripts. However, these are rare today; everyone uses diff format patches.
But ed does have other uses:
For all who've learned to use it, ed is a very useful emergency editor. The MS Windows standard telnet client can deal with ed but has trouble with fullscreen editors (like vim). And a full featured vim requires not only ncurses, but X11 as well! Any trouble with those libraries will leave the system without an editor if ed isn't present.
Though it's not a reason to have ed in the book, some people actually like ed.
Understanding ed helps with understanding vi(m) and Unix history in general.
Package management - beyond that provided by tarballs and makefiles - is beyond the scope of the book. If nothing else does, the number of different "solutions" should hint at some of the reasons.
Here are a few of the options:
No package management is really necessary. Unless it is desirable to monitor package file placement minutely, any package large enough to warrent removal for disk space reasons can be installed in /opt as detailed by the FHS, and new releases can be installed over the old, although major upgrades and libraries are generally best upgraded by rebuilding the system from the bottom up.
RPM, the Redhat Package Manager, is used by a number of distributions. It is available from http://www.rpm.org/, and there is an RPM Hint to help with installation at http://hints.linuxfromscratch.org/hints/rpm.txt.
There are several implementations of symlink style package management:
Epkg is available from http://encap.cso.uiuc.edu/epkg/.
Graft is available from http://www.gormand.com.au/peters/tools/.
GNU Stow is available from http://www.gnu.org/software/stow/.
Depot is available from http://asg.web.cmu.edu/depot/.
And several more are listed in the Graft documentation at http://www.gormand.com.au/peters/tools/graft/graft.html#research.
Originally based on a script written by LFS' own Gerard Beekmans, install-log records a list of files installed by a package as the package is installed. It is available from http://install-log.sourceforge.net/.
Gerard has since made additions to his script. It is available from ftp://ftp.linuxfromscratch.org/misc/pkginst and ftp://ftp.linuxfromscratch.org/misc/pkgdel.
CheckInstall attempts log system calls made by "make install". It is available from http://asic-linux.com.mx/~izto/checkinstall/.
More information about these systems and information about other interesting systems is at http://hints.linuxfromscratch.org/hints.shtml#package.
Mostly, it's not hard, but some packages can lead quite a chase. Here are some steps:
http://freshmeat.net/: Searching for
foo |
http://www.google.com/: Use a search string like
+foo +index |
+foo +index -RPM -debian |
Google may well turn up a link to something under http://www.ibiblio.org/pub/. (If you want to look specifically on ibiblio.org use
foo site:ibiblio.org |
A foo.lsm (Linux Software Map) file which may list a primary site where more recent versions may be found.
In addition to the kernel documentation at /usr/src/linux/Documentation or wherever you unpacked your kernel source and the help in kernel config tool (make menuconfig), see the Module-HOWTO at http://www.tldp.org/HOWTO/Module-HOWTO/, and the Kernel-HOWTO at http://www.tldp.org/HOWTO/Kernel-HOWTO.html.
Any recent distribution should be fine. If you have problems, try installing and/or updating the development packages. (Look for ones starting in "gcc", "glibc", or "libstdc++" or ending in "-dev".)
There are instructions in the NFS Hint at http://hints.linuxfromscratch.org/hints/nfs.txt.
I have a version of tcp_wrappers and portmap up that have both been patched with the debian patches, adapted Makefiles for LFS plus all compile warnings/problems were fixed. Additionally, an lfs-install.sh is included in both tarballs that provides a really quick and dirty way to install them. They can be found at http://www.linuxfromscratch.org/~gimli/. You may want to add a note about these packages for people who want to do it the easy way :)
In Mandrake/RPMS2/libncurses5-devel-5.2-16mdk.1586.rpm on Disk 2. Version numbers might be a little different for you. (If you're missing libcurses.a (no "n"), reread the book's instructions for bash more carefully.)
See the Boot-CD Hint and http://hints.linuxfromscratch.org/hints/bootcd.txt.
Gerard describes the process of making a 5MB LFS install in an email archived at http://archive.linuxfromscratch.org/mail-archives/lfs-support/2001/10/0072.html, and there are links to many resources in a post by Cor Lem archived at http://archive.linuxfromscratch.org/mail-archives/lfs-support/2002/06/0225.html and a reply to it.
It's often useful to compile LFS for one machine on another machine. Say using that fast 1Ghz Athlon to build an install for an old 486. While this is technically not cross compiling, binaries compiled for the Athlon cannot be run on the 486 because binaries compiled for the newer processor use features the older processor doesn't have. To make the newer system compile for the older, follow the hint at http://hints.linuxfromscratch.org/hints/crosscompiling-x86.txt.
There's a few things that don't require much knowledge of C that you can do to get old sources to compile on a recent system.
If you're using GCC 3, try adding the -std=gnu89 switch to the compile options. (For instance, in CFLAGS or CC. The exact method is a bit beyond the scope of this FAQ.)
No. You should delete the source after installing. The source is only useful for reinstalling without recompiling. To recompile, always delete the old source and start fresh because "make clean" and friends are not always trustworthy. Deleting compiled source trees also frees considerable disk space.
Here's an example:
tar xvjf foo-0.0.tar.bz2 cd foo-0.0 ./configure --prefix=/usr make make install cd .. rm -rf foo-0.0 |
It has to do with the characters used to end lines.
There are two that may be used:
Line Feed: (LF) Octal:012 Decimal:10 Hex:0A C Style Escape:'\n' Moves down one line.
Carriage Return: (CR) Octal:015 Decimal:13 Hex:0D C Style Excape:'\r' Move to the left margin.
Unix, DOS, and MacOS each use a different combination to end lines in text files:
Unix: LF only. This is why when a Unix format text file is sent to a printer raw, it prints out
like
stairs
steps.
|
DOS: CRLF both. Which is why if you do "cat -v" on a DOS file you'll see a "^M" (control m is carriage return) at the end of each line. And that is why scripts don't work when written with Microsoft Notepad. The kernel looks for "/bin/sh^M" which doesn't exist. There's a "/bin/sh", but nothing with a "^M" appended.
MacOs: CR only. Printers probably print every line atop the first, and Unix tools think the whole file is one line with "^M" all through it.
To change DOS to Unix, use
cp <filename> <filename>.dos && cat <filename>.dos | tr -d '\r' > <filename> |
Use the useradd program. It was installed with the shadow package and has many useful options. See the useradd man page for more information.
In short, we copy the kernel headers instead of linking them because the kernel headers should match the currently running libc, not the currently running kernel.
For the long answer see these:
A post by Linus himself: http://www.uwsg.iu.edu/hypermail/linux/kernel/0007.3/0587.html.
Kernel Traffic #80, 4. Symlinks In The Kernel; Kernel/Library/etc Interface Dispute: http://kt.zork.net/kernel-traffic/kt20000814_80.txt (This covers the thread in which the above post occurred.)
Short answer: no.
Long answer: probably, but only to someone working on the package you're trying to compile. Mostly, everything will be fine unless make quits with an error.
Here's an example:
sk ~/tmp $ cat > Makefile
main:
gcc main.c
sk ~/tmp $ cat > main.c
void main() { exit(0); }
sk ~/tmp $ make
gcc main.c
main.c: In function `main':
main.c:1: warning: return type of `main' is not `int'
sk ~/tmp $ ######## that worked ########
sk ~/tmp $
sk ~/tmp $ cat > main.c
int main() { exxit(0) }
sk ~/tmp $ make
gcc main.c
main.c: In function `main':
main.c:1: parse error before `}'
make: *** [main] Error 1
sk ~/tmp $ ######## that failed ########
sk ~/tmp $
|
Examples of this error are:
/usr/bin/env: /static/bin/bash: No such file or directory gcc: No such file or directory |
They usually occur when trying to enter (or shortly after entering) chroot in Chapter 6, and are caused by trying to run a dynamically linked binary at that point. You can check by running file on the binary. For example:
file $LFS/static/bin/bash |
The solution is to go back to Chapter 5 and recompile the affected package. And this time, take extra care with the instructions for compiling it statically.
You're most likely getting this while building bash in Chapter 5 of the LFS Book. The problem is most likely your mount options. You probably have a line in /etc/fstab like:
/dev/hda10 /mnt/lfs ext2 user 1 2 |
So change the line in /etc/fstab like this:
user Allow an ordinary user to mount the file system. This option implies the options noexec, nosuid, and nodev (unless overridden by subsequent options, as in the option line user,exec,dev,suid).
/dev/hda10 /mnt/lfs ext2 defaults 1 2 |
Typical symptoms look like this:
sk ~/tmp-0.0 $ ./configure creating cache ./config.cache checking host system type... configure: error: can not guess host type; you must specify one sk ~/tmp-0.0 $ |
The problem is usually that the script can't run the compiler. Usually it's just a missing /usr/bin/cc symlink. You can fix it like this:
cd /usr/bin ln -s gcc cc |
If that doesn't do it, check the file config.log created by configure. Errors go there and may indicate the problem.
If you're getting an error from configure like:
checking whether we are using GNU C... no configure: error: GNU libc must be compiled using GNU CC |
To test if egrep is working before reinstalling the grep package in Chapter 6, run the following command from outside chroot:
file $LFS/bin/egrep |
To test if egrep is working after reinstalling the grep package in Chapter 6, run the following command from inside chroot:
egrep root /etc/passwd |
Does /dev/null look like this:
$ ls -l /dev/null crw-rw-rw- 1 root root 1, 3 Aug 3 2000 /dev/null |
If it does look right, the problem is probably your mount options. See the answer to "./configure: bad interpreter: Permission denied", above.
GTK+ 2.x and 1.2.x aren't compatible. The package you're installing may need GTK+ (and GLIB) 1.2.x. You can install GTK+ (and GLIB) 1.2.x next to 2.x.
Typical symptoms look like this:
$ echo -en 'x11:\n\tgcc x11.c\n' > Makefile
$ echo -en '#include <X11/Xlib.h>\nmain() { }\n' > x11.c
$ make
gcc x11.c
x11.c:1: X11/Xlib.h: No such file or directory
make: *** [x11] Error 1
$ rm Makefile x11.c
$
|
Creating a couple symlinks will fix it. Here are the commands:
cd /usr ln -s X11R6 X11 cd include ln -s ../X11/include/X11 X11 |
If compiling GCC in Chapter 5 errors out with
Error: Unknown pseudo-op: `.hidden' |
It should be mentioned that glibc (and gcc and binutils) are good places to not optimize. The performance versus stability trade off is unusually poor for these packages. But. . . .
If you've specified a CFLAGS value like "-march=i686 -mcpu=686" and you're getting an error like this:
spinlock.c: In function `__pthread_lock': spinlock.c:107: inconsistent operand constraints in an `asm' make[2]: *** [/usr/src/glibc-build/linuxthreads/spinlock.o] Error 1 make[2]: Leaving directory `/usr/src/glibc-2.2.4/linuxthreads' make[1]: *** [linuxthreads/others] Error 2 make[1]: Leaving directory `/usr/src/glibc-2.2.4' make: *** [all] Error 2 |
# Default flags to pass the C compiler. ifndef default_cflags ifeq ($(release),stable) default_cflags := -g -O2 else default_cflags := -g -O endif endif |
# Default flags to pass the C compiler. ifndef default_cflags ifeq ($(release),stable) default_cflags := -g0 -Os -march=i386 -mcpu=i386 -pipe else default_cflags := -g -O endif endif |
The error, "configure: error: cannot determine asm global directive", while configuring glibc indicates a problem with the binutils installation. Likely it isn't statically linked. (You can check with "file $LFS/static/bin/as".) In any case, try reinstalling binutils.
You're missing /dev/null. Either you forgot to create it when the glibc build instructions say to, or you're using devfs and forgot to "mount --bind /dev $LFS/dev" before chrooting. You may have to delete and recreate the glibc-N.N.N and glibc-build directories after fixing that.
It's missing a device file. (AFAIK, /dev/null, but maybe /dev/zero.) Anyway, either you forgot to run MAKEDEV, or MAKEDEV failed, or you're using devfs and forgot to mount --bind it under $LFS.
If you're trying to build static sh-utils and you're getting an error like this:
gcc -g -O2 -static -o uptime uptime.o ../lib/libsu.a -lutil uptime.o: In function `print_uptime': /lfs/tmp/sh-utils-2.0/src/uptime.c:125: undefined reference to `getloadavg' collect2: ld returned 1 exit status make[2]: *** [uptime] Error 1 make[2]: Leaving directory `/lfs/tmp/sh-utils-2.0/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/lfs/tmp/sh-utils-2.0' make: *** [all-recursive-am] Error 2 |
http://archive.linuxfromscratch.org/mail-archives/blfs-support/2001/06/0507.html: This attempts to correct the incorrectly generated config.h and should be the correct solution if you can get it to work by following the description given in the post.
If that doesn't work, delete the sources, re-extract, and try this: http://archive.linuxfromscratch.org/mail-archives/blfs-support/2001/06/0495.html. This attempts to avoid compiling uptime at all since it won't be needed in chroot and compiling uptime dynamically in chroot doesn't have this problem.
Patches from GNU don't usually work. You can either download the full archive and try again or try the solution given in the message archived at http://archive.linuxfromscratch.org/mail-archives/lfs-dev/2002/06/0386.html.
If you're getting errors and you're using optimization settings, that may be the problem. If you ask on the list and they can't figure it out immediately, they'll likely suggest trying it without optimizations, so just retry it without before asking. You'll be one step ahead of them :)
Optimizations can cause many different even seemingly unrelated errors. They can cause configure scripts to fail. Optimizations that work for someone else may not work for you. Settings that used to work may break if you make the smallest, most innocent hardware change.
(If you don't know what optimization settings are, don't worry, really you don't need to.)
If you're getting errors and you're using a version of a package that differs from the version in the book (either newer or older), try the version in the book. Sometimes there are reasons why the book uses a particular version. Search the list archives if you're curious.
In particular, GCC 3 will cause problems. See the entry "Why isn't GCC 3.x in the book?".
Yes. You should always delete the source tree after installing and delete it and start over if anything fails.
The only exception is the kernel. Most people keep their kernel source so they don't have to reconfigure it from scratch if they need to make a small change. If a large change is needed, like changing processor type, it may be necessary to restart with a fresh tree even with the kernel.
Here's an example when everything works:
tar xvjf foo-0.0.tar.bz2 cd foo-0.0 ./configure --prefix=/usr make make install cd .. rm -rf foo-0.0 |
tar xvjf foo-0.0.tar.bz2 cd foo-0.0 ./configure --prefix=/usr . . . *** configure: error: foo requires libess 4.2 or greater please install libess and rerun configure. cd .. rm -rf foo-0.0 tar xvjf libess-4.2.tar.bz2 cd libess-4.2 ./configure --prefix=/usr make make install cd .. rm -rf libess-4.2 tar xvjf foo-0.0.tar.bz2 cd foo-0.0 ./configure --prefix=/usr make make install cd .. rm -rf foo-0.0 |
Ed. Note: The name of the fictional libess above follows libiberty (from glibc, AFAIK) and libofat. The reason comes from the gcc flag, -l, for linking a library when compiling. For instance,
gcc -o foo foo.c -lm |
gcc -o foo foo.c -liberty -lowfat -less |
Bonus points if you caught the reference to The Hitchhiker's Guide to the Galaxy, by Douglas Adams in the example.
When you compiled net-tools you enabled support for a protocol family (that's where the "pf" comes from) that you didn't enable support for in the kernel. (You probably just accepted the default answers.)
A full list of protocols is in /usr/include/linux/socket.h but here is a list of the likely culprits:
net-pf-3: Amateur Radio AX.25 (AF_AX25)
net-pf-4: Novell IPX (AF_IPX)
net-pf-5: AppleTalk DDP (AF_APPLETALK)
net-pf-6: Amateur Radio NET/ROM (AF_NETROM)
net-pf-9: Reserved for X.25 project (AF_X25)
Naturally the fix is to recompile net-tools without support for the things you don't need. (Or recompile your kernel with support if you find you actually wanted them.) The workaround to put a line like the following in /etc/modules.conf
alias net-pf-? off |
Replace the question mark with the correct number, of course. And rerun depmod.
If you get an error about net-pf-7, you probably need to enable support for the loopback network device (not block device) in your kernel. Or you may need to add the following line to /etc/modules.conf and rerun depmod.
alias net-pf-7 loop |
"char-major-10-135" refers to the character device, major 10, minor 135, which is /dev/rtc. It provides access to the BIOS clock, or RTC, the Real Time Clock. See /usr/src/linux/Documentation/rtc.txt for more information.
The error is because something, most likely hwclock, is trying to use /dev/rtc but you haven't configured kernel support for it in your kernel. Either delete /dev/rtc so hwclock won't try to use it or enable RTC support in your kernel. It's located in make menuconfig under "Character devices" -> "Enhanced Real Time Clock Support".
See the question "modprobe: Can't locate module char-major-10-135".
There several reasons why the kernel might be unable to mount the root filesystem.
Did you specify the correct partition in /etc/lilo.conf?
Did you remember to rerun lilo after changing /etc/lilo.conf?
Is support for the hard drive enabled in the kernel. For SCSI this means support for the specific SCSI adapter.
Is support for the hard drive compiled into the kernel, not just as a module. (Modules are stored on the filesystem. If a driver needed to access the filesystem is stored as a module on that filesystem, well. . . you know. . . . ;)
Is support for the filesystem compiled into the kernel. Again, not a module. Support for ext2 is enabled by default, but others like ext3, reiser, jfs, and xfs are not.
The documentation in the LILO distribution lists all errors (such as when it prints "LI" and stops), but a quick overview is available at http://sdb.suse.de/sdb/en/html/kgw_lilo_errmsg.html.
You need to install the net-tools package. (See the instructions in the LFS book.)
The hostname command your system is using is from sh-utils and doesn't support the -f option. When it is called with the -f option it assumes the hostname should be set to "-f". The hostname command from net-tools doesn't have this problem.
Because the LANG and LC_ALL environment variables aren't set. To fix that, set them in the ~/.bashrc file for each user or in /etc/profile by adding lines like this:
export LANG=en_US export LC_ALL=en_US |
Those lines can be added to /etc/profile with the following command:
echo -e 'export LANG=en_US\nexport LC_ALL=en_US' >> /etc/profile |
You'll have to change the "en_US" part if you don't use US English.