Linux From Scratch
The Linux From Scratch project is intended for Linux users who want to build their own custom Linux system. Reasons for wanting to build such a system are diverse. Perhaps you want to get into more detail as to what happens behind the scenes. Perhaps you are fed up with the bloated standard distributions. Or perhaps you don't want to rely on pre-compiled binaries out of concerns for security.
| Tags | Installation/Setup |
|---|---|
| Licenses | BSD Original |
| Operating Systems | POSIX Linux |
Recent releases
- 12 Jul 2005 06:06
Changes: This release includes a large number of package upgrades (including Linux 2.6.11.12, GCC 3.4.3, Glibc 2.3.4) and security fixes (including the recently disclosed zlib vulnerability). It also includes a large amount of editorial work on the explanatory material throughout the book, improving both the clarity and accuracy of the text.
- 08 Dec 2004 20:15
Changes: The Linux From Scratch community is pleased to announce the release of LFS 6.0. This major revision of the book includes a number of major package upgrades, including GCC 3.4.x, Linux kernel 2.6.8.1, and the Udev software package, allowing for dynamic creation of device nodes. The text has also been vastly rewritten for improved readability.
- 06 Jun 2004 03:03
Changes: This release fixed several release-process related problems and minor spelling and grammatical errors. The package and patch versions remain unchanged.
- 02 Feb 2004 04:20
No changes have been submitted for this release.
- 05 Nov 2003 14:14
Changes: This major milestone features a new method with strong emphasis on building a correct compilation environment and base libraries independent from the host system. It features Linux kernel version 2.4.22, the GNU C Library 2.3.2, the GNU Compiler Collection 3.3.1, and a bootloader change from LILO to GRUB, amongst other package upgrades. The book's explanatory texts have also been enhanced.
- All comments
Recent commentsRe: BSD License?
I won't argue for either license ... however, it's quite unclear what the BSD license applies to [from the FM description], so when I saw it the first time my thoughts were `WTF? How anyone can think she can relicense glibc, gcc, etc. under the original BSD license?'
Re: No package management
>
>
> I do what you suggest, but don't like
> the idea of running find 2 times, so I
> install with another prefix (for
> example, glibc uses make install
> install_root=/root/glibc), do a find at
> /root/glibc, and start moving
> /root/glibc with mc. But I rarely make a
> log, my mind is better than package
> managers and make uninstall.
I used to do that, install every package in
/usr/ and leave the package there.
This made for excellent removal: rm -r /usr/x
and the package was gone. After a while my
/usr partition had a few hundred subdirectories
which wasn't a bad thing, but my $PATH
variable grew immensely. And once you install
a package somewhere moving it elsewhere is not
always recommended as some packages hard-code
certain paths (to say config.files) to the place
where you have installed them.
Right now I install everything under /usr and use
the 'find' tecnique described earlier. I have most
of that processs scripted so I don't have to run
find twice or create diff outputs myself. I run one
command with the parameter (the package name
and version) and it does the find, configure and
install. I run a ./configure --help manually to see
if I need any special configure options (which I
then pass so that script) or other options. It's
primitive and simple but effective. The result is
I have a bunch of files now, one for every package,
that list every single file that was installed by that
particular package. It can be expanded to include
files that were changed, removed, etc.
Yes, this script is based on what Jesse Tie Ten Quee
came up with and I just expanded on it to automate
it a little bit
Anyways, to make a long story short: the point is
that I love the way things work now PM wise. That's
one of the beauties of LFS. I get to pick the
software I wish to use for something.
Re: No package management
>
>
> I do what you suggest, but don't like
> the idea of running find 2 times, so I
> install with another prefix (for
> example, glibc uses make install
> install_root=/root/glibc), do a find at
> /root/glibc, and start moving
> /root/glibc with mc. But I rarely make a
> log, my mind is better than package
> managers and make uninstall.
The point of running two find's is one before and one after the 'make install' (and whatever else commands that install files) so you can have a list of files that get installed, with that list, using standard command-line tools you can created backups, tarballs/packages, uninstall, etcetc..
But i agree, your head is the best thing..allthough in certain cases when you have ~10 boxes to look after and they are all running different versions it's nice to have *some* means ot PM, even if it so "primitive" (hey it works, 'nuff said ;)
Re: No package management
I do what you suggest, but don't like the idea of running find 2 times, so I install with another prefix (for example, glibc uses make install install_root=/root/glibc), do a find at /root/glibc, and start moving /root/glibc with mc. But I rarely make a log, my mind is better than package managers and make uninstall.
Re: No package management
Hmm... I used the LFS instructions precisely because package "management" makes it really painful to upgrade core system components, especially if you don't care for the compilation options used by the existing distributions or you apply a lot of custom patches. RPM just creates a tangled mess of dependencies. Mind you, I use RPM, but just for non-essential stuff I can conveniently rip out and reinstall if I need to. I certainly don't trust a tool as crude and unintelligent as RPM with my core system, especially not in a production environment. It's too easy to trash things and too hard to clean up after.