Frequently Asked Questions

The FAQ is divided in three documents. The General FAQ has links to all questions and answers. The LFS FAQ is a selection of LFS-specific FAQ's and the BLFS FAQ is a selection of BLFS-specific FAQ's.

General FAQ

General information about these FAQ's

Support guidelines

Frequently Reported Bugs

LFS FAQ:

Frequently Requested Enhancements

When reading and building LFS

General compilation errors

Package-specific errors

Configuration and booting issues

BLFS FAQ:

General BLFS questions

Compilation issues

Configuration issues

General information about these FAQ's

Why this FAQ?

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. Sometimes it will be necessary to add a pointer to the information in the documentation.

What is LFS?

LFS stands for Linux From Scratch which is a project that aims to teach you about the inner workings of Linux by building a Linux system by downloading, building, and installing the packages yourself.

Also check out the introduction to LFS.

What is BLFS?

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.

Contributing to this FAQ.

Suggestions are more than welcome. The FAQ maintainer can be reached either via direct email or on the LFS support 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.

If you intend to regularly contribute to this FAQ, you might want to subscribe to the FAQ mailing list. All suggestions, additions (and sometimes removals) of the FAQ's are discussed there. Patches against the FAQ's are also welcome, although regular text-based contributions are accepted as well.

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.

Back to the top.

Support guidelines

What if I'm a newbie to Linux or LFS?

If you've read the prerequisites and audience pages you know that the target audience of LFS are intermediate and advanced Linux users. Anybody who has a couple of months experience with Linux and especially the console should be able to successfully assemble an LFS system.

While LFS seems like a good guide for newbies to Linux, the reality is actually quite different. Experience with the support channels shows that LFS is hard to grasp and a frustrating experience for newbies because they lack understanding of the basic concepts.

Practically, this means that newbies should get some experience before starting with LFS. The prerequisites page lists the minimal required Linux knowledge, but please also read the "Essential pre-reading for life with LFS" hint.

These documents and this FAQ are your basic Linux survival guide. You'll have a great time with LFS if you've read them, and may have some difficulty with LFS and the community, but most likely yourself, if you haven't read them.

Where is the best place to get help?

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 ensure that you know enough not to embarrass yourself if you have to ask someone.

The Linux Documentation Project has the HOW-TOs and a great deal of other documentation. You might find something there.

The website's search includes the mailing lists. Many questions have been discussed there at least once.

For support-type help, IRC is often best. It's faster, and doesn't clog the mailing lists. There's more information about the IRC channels on the support webpage.

There are a few IRC channels of interest.

If you are asking a support question, you are more likely to attract competent and friendly help in #lfs-support.

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 on the support webpage and tells which list to use.

Please remember to provide enough information when you post to the mailing lists. In chapter 1 of LFS you find a good method for posting. Additionally, someone has written a hint which details the error reporting procedure.

Which list should I use for what topic?

Information about all the public mailing lists is available on the mailing list page. Here are some general guidelines about which list to use:

  • Send support questions for the stable released books to lfs-support. For anything which doesn't belong in LFS, use blfs-support. Bug reports are gladly accepted; you can report to the lfs-dev mailing list.
  • If you are not having trouble following the LFS Book itself, do not email lfs-support. You may ask questions via lfs-support if you are following the LFS Book with some customization or deviation, but you should mention your deviation in the mail to avoid from puzzling people.
  • 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 flame wars.
  • The price of beer, GNU versus BSD, Microsoft versus Linux, or Intel versus ARM flame wars, and hardware discussion unrelated to building and running LFS are prohibited.

Of special note is that if you mention Xorg, Wayland, KDE, GNOME, or anything in BLFS, you may be sure that your post does not belong on lfs-dev or lfs-support.

What about netiquette?

Here are some practical points of etiquette. They include only those items that will draw mention if missed. Those who've been around project mailing lists awhile will find the first few obvious. There are less obvious items toward the end.

The reasons for these points are omitted for brevity, but rest assured, these guidelines are more than just an individual's personal preference.

While the text refers to "the lists" exclusively, it doesn't intend to ignore the news groups that mirror the mailing lists.

With that out of the way, here are a couple manners oriented items followed by more "mechanical" stuff:

Please remember that it is rude to post questions that are answered in commonly available documentation such as the LFS and BLFS Books, this FAQ, the LFS Hints, the appropriate man pages, the list archives, and Google searches. As long as you can demonstrate that you've made an effort to find the answer and you're not offended by a pointer to documentation, no reasonable person will object to your question.

Most of the bothersome flame wars start when a newbie posts an obvious question, is then criticized (even in a kindly manner), and becomes publicly offended. Please try to avoid this situation. "Wordlessly" pointing to the exact spot in the documentation is sufficient. If you feel you must criticize, please do it via private email, not on the lists. The same applies to anything else that may become heated.

The lists have an international membership so slang of all sorts and idioms are likely to be misunderstood. (Witness the recent discussion of "bootstrapping".) Any mention of profanity, politics, war, or religion (even in signatures) is likely to upset someone somewhere in the world so please avoid them as well. Finally, it is considered polite to post in English since many more people on the lists know it than any other language.

Now for the more "mechanical" stuff.

  • Do not post in HTML. If you use Yahoo, Hotmail, or Outlook and haven't turned HTML off, then it is on. If you're using another mail client, please do check before posting. If you don't know how to turn HTML off, see nomime.html. Posts with HTML may reach the list but then rendered in a completely unreadable manner by the mail client of the subscribers, causing them to give up reading and replying your mail.
  • Wrap text at 72 characters. If you do not wish to do this by hand, set your mail client to do it automatically when sending.
  • Reply below quoted text.
  • Limit signatures to four lines.
  • Trim quoted text, especially signatures. But do not trim so that it is confusing to read your reply without consulting the original.
  • Do not click reply unless you're actually replying to a post. Use new, or compose, or whatever your mail client calls it, to ask a new question or start a new thread. Reply sets more than just the subject line and will cause your post to appear in the wrong place unless you're actually answering.

The following isn't major, but is useful to know. On the LFS lists, people usually clear the CC field and just mail the list with replies. This is probably not a good idea but is existing practice due to a political situation which is unlikely to change.

RFC 1855 "provides a minimum set of guidelines for Network Etiquette (Netiquette) and functions as a minimum set of guidelines for individuals, both users and administrators

Back to the top.

Frequently Reported Bugs

The "ln -s" commands in the Book are wrong.

No, the "ln -s" commands in the Book are correct. A symlink is just a special file containing the given filename. So that filename is relative to the link, not the working directory when the link is created. Try it and see. More information in man ln.

bash: [: missing `]'

You should understand how "conditions" like [ ... ] work in bash: "[" is a command and "]" should be its last parameter. So there must be a whitespace before "]", or the execution of "[" will fail.

Try "ls -i /bin/foo /bin/bar". Are the inode numbers the same? If so, they're not copies, they're hard linked.

For more information explaining the difference between hard and soft links, please take a look at the Q & A article on Linux Gazette at https://linuxgazette.net/105/pitcher.html.

Can I use a version newer than the one in the Book?

If this is your first time building LFS, using a version not in the book or varying from the book in any way is not a good idea. The IRC channel regulars have a saying, "FBBG", meaning "Follow Book, Book Good." They and the people on the lists have helped many an unhappy newbie who deviated from the book during that first build.

Once you've built a system "by the book", you have a stable knowledge base from which to experiment to your heart's content (or pain, as is often the case.)

There's a new version of package Foo.

If the new version is more than a day old, it is likely that someone has tested the release and reported it on the mailing lists. Please search the archives before posting questions about whether it works.

And, please note that different packages have different versioning schemes. For example, for many packages versions with an odd minor version ("y" in "x.y.z") are development snapshots and some other packages use patch levels ("z" in "x.y.z") greater than or equal to 90 for pre-releases. LFS/BLFS won't use development snapshots or pre-releases unless there is a good reason.

If you'd like to report the new release, follow these steps to avoid making a duplicate report.

  • Check for open LFS tickets or BLFS tickets to see if the release has been posted there.
  • If the release is not in an open ticket, report it to lfs-dev (or blfs-dev for packages in BLFS). And if you like, test it and report any problems or changes in compilation instructions, too.
The Delete key doesn't work.

Please read the LFS inputrc page.

The system shuts down when fsck errors out!

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.

Where are the lfs-packages tarballs or wget scripts?

Package tarballs are available at the LFS file repository. There is also a wget-list linked in the book, near the bottom of the Packages and Patches Introduction page.

How do I find a package or command?

Please refer to the download LFS webpage.

How do I upgrade my LFS/BLFS system?

You probably know this already, but LFS is not a distro in the traditional sense. Its primary goal is: teaching people how a Linux system works internally.

While this means you have great control over your system ("Your distro. Your rules."), it also has the drawback of having to take care of updating it yourself.

Please read the section named "Upgrade Issues" carefully before upgrading any package.

If you've built an LFS system and have extended it to become your primary system, the best thing to do is to decide on an upgrade policy. Do you want to keep the latest version of every package? Then be careful, because you're going to be burned. I recommend slight conservatism when upgrading to keep a healthy system. A general rule of thumb which works for most people is: only upgrade packages if they have security fixes. Periodically check LFS and BLFS security advisories, and subscribe to LWN to keep yourself informed about security fixes. Another rule of thumb is: don't upgrade glibc and Linux kernel headers unless you're going to rebuild your entire system. These packages form the heart of your LFS system, destroying them means destroying the ability to compile packages or even run binaries.

Remember that updating packages is at your own risk. LFS takes great care to present a stable mix of packages which are compatible all the way up to BLFS so you can compile OpenOffice.Org and Java (which are real dinosaurs to compile). This means that your LFS system may get slightly outdated but ensures compatibility and stability. You can compare this to Debian's stable and testing releases, although LFS stable is generally bleeding-edge compared to other distro's.

In general it is safe to upgrade single packages; they'll just overwrite the old contents. Package managers take care of uninstalling old versions, and it's really convenient to have some sort of package management system in place. Have a look at the hints; there are several, ranging from RPM to DEB to TGZ (Slackware) to Checkinstall to package users.

A final comment: what package instructions should you use when updating a package? In general, you can use the standard LFS instructions, although you shouldn't blindly assume they will apply to all packages. To keep yourself informed about upgrades and new package instructions, subscribe to lfs-dev. Keep in mind that this is not a support list but a development list.

The commands in LFS/BLFS book does not work with sudo!

sudo can only run executables as root. It does not understand internal grammar constructs of the shell, for example "case", "cd", "for", "if", "|" (piping), ">" (redirecting output to a file), etc.

For example, when the book tells to run echo /bin/zsh >> /etc/shells as the root user, you cannot run sudo echo /bin/zsh >> /etc/shells as a non-root user and expect it to work. The output redirection is performed by the shell, so the shell needs to open /etc/shells for write and doing so requires a privilege. But sudo has no way to raise the privilege for the current shell. It can only raise the privilege for the echo command with /bin/zsh as the parameter, but this is not helpful at all.

For another example, when the book tells to run for i in /usr/lib/libfoo*.so; do chmod 755 $i; done, you cannot prepend sudo before the command and run it as a non-root user. for is a shell grammar construct, not an executable. So sudo will report "for: command not found".

If you do not know how to use sudo correctly, don't use it.

Back to the top.

Old and expired FAQ's

I'm using a version not in the book. Is that a problem?

There's already a FAQ entry which describes this. Since hardly anyone refers to this entry it's now obsolete.

Where's which?

Obsolete on account of the BLFS book.

Where's portmap?

Obsolete on account of the BLFS book.

Where can I get LFS Logos?

Obsolete on account of the BLFS artwork webpage.

My optimized build of glibc is failing in spinlock.c

Let's not encourage people to optimize glibc. Besides, the when using optimization flags (setting CFLAGS) entry should take care of this question.

Thanks

This FAQ is dedicated to all the hard-working people on the support lists who keep me busy with this FAQ ;-).

Thanks go to...