LFS - how big a project, how much of use?
 

Short introduction:

It seems many of the ones who ask questions regarding trying LFS out come from people who have been into Linux just a while and want more. I myself have "been into Linux" for a long time, have used UNIX and it's variants (not to mention the young boy Windows) and am only now beginning to get interested in LFS.

The Question:

How long will it typically take to get a Linux From Scratch project ready enough so it can be called "a Linux OS", for the first time? Is it days, weeks, months? I know it varies a lot depending on machine power and time used per day, but on the average; how long did it take when you did it? I'll be using a laptop with 1,8GHz processor (AMD Sempron 3100+) and 512MB RAM, quite an ordinary pc (not too fast&furious, yet not slow). Then again: if I go through that a few times, to make sure I get the whole thing (if I still like it), will it be possible (meaning "not too difficult") to create a system with a package manager of some kind (not necessarily though), or even a CD-installer (or USB memory key, if I get it small enough some day)?

One more thing: I know I'll learn a lot from it if I just carry on, but nevertheless..is there some other way to learn the way of working of a Linux distribution than LFS? I've installed Gentoo, it had some compiling back then, but it didn't teach that much after all.

I'm hoping to get more knowledge trying LFS out, but not hoping to get a life-long project that'll be dying of its old age before I'm finished :)

Well, I use LFS nearly since I've bought my notebook (~8 months).
1.5 GHz Pentium-M 768MB memory 80GB disk (sliced in 10G-chunks). When I tried out LFS I haven't finished it (on a less powerful box). Log - how I installed everything can be found in my thirst thread http://www.linuxquestions.org/questi...d.php?t=364781 . It is long and a tire to do everything by hand (and no warranty of success, surely), my current installation is like create a partition, CVS checkout jhalfs, 15 minutes to understand options (oh, I don't remember them..) then - plug the box, some hundreds MB to auto-download (oh no, 140MB) and some 3 hours to build. And - I get a core GNU/Linux OS with gcc, perl, autotools, bash etc to start with. I didn't want to use auto-BeyondLFS, so I had all the fun myself... Xorg 7.1 is good (though I failed to run Xgl on i915, some people with other cards succeed). GCC 4.0.3 is even able to build MPlayer...

There are some instructions on the net how to create a bootable CD to install LFS you've build. And there is LiveCD to build system from.

About package management - there is make_uninstall, which helps to keep track of what is installed; there are some unionfs solutions; I use my-own-patched version on top of funionfs 0.4.1 (hope most of it will be included in funionfs 0.5, and funionfs 0.6 will work for me out-of-the-tar). Some people also use user-per-package ownership systems and fakeroot-installs, or opt-installs and symlink farms.

About learning - LFS is more SysV system than Gentoo with BSD-style rc. It's also useful to make a mistake in automated install and correct it by hand. By the way, I abandoned udev in favor of self-written shell-script..

So - I think it's worth to try. Join us!

Thank you for your post, sounds like something I'll try out. I wish I'll have enough time to spend on this..

By the way: how does it work if you have installed LFS and later plan to update gcc by compiling the new one from source? Will it work all right? I guess all the other software to be updated at some point don't cause more trouble than they normally do..

As I haven't compiled too much programs in Linux yet, I'll ask this one too: after I've successfully compiled and installed a program from source, then I can remove the source directory, right? Then what happens if I later get a newer version and wish to compile+install that, replacing the older one - will I need to remove the older one first somehow or just compile and install the new one?

Thanks again for answers!

Depends what you mean by a "Linux OS" especially since you already have a good Linux background.

For providing a basic LFS (BLFS not !):

About 5 hours on a 2.4 MHz P4 with 1 GB RAM, from a LiveCD LFS install. That should be it. I'm not saying that there won't be any problems, but it should be fairly smooth. I did it recently a few times. before that (i.e. about two years ago) I was using only LFS systems at home and at work for about 3 years and have developed a set of integrated shell scripts to build LFS and beyond (i.e. Xfree86, WindowMaker, many other apps, network stuff, etc...) that I still keep around and want to eventually update on of these days. The nice thing with LFS, since it's small, is that you can easily backup systems and restore them to reformatted drives and partitions (on same architecture with possibly some minor variations in graphic cards and such). When you get the hang of it, you simply get add-on sources and compile them and there you are.

As for a package management system, I've once considered symlink-based systems whose idea I find quite pratical: to use the file system itself for package management. Such as the system called Graft (there are others such as Stow and encap). There's even a Linux distro based on that type of symlink package management: Gobo Linux (gobolinux.org). But I never implemented to this date although it retains my attention and I'll surely try it when I update my LFS install scripts. Some people say it's somewhat difficult, but I tend to think that the idea is so simple that it can't be that complicated, especially if a set of scripts is developed to keep the procedure well-defined and easy to use.

Cheers.

I don't know how to update gcc right way. When I want to update gcc, I also want to update glibc (since we are talking of major update, and not to have main library linked with different ABI version relative to main compiler). And then - to have less problem - it is recommended just to rebuild all (not to have applications linked to different glibc)... Although, I would try minor gcc update side-by-side.

After having compiled a piece of software (and installed it) you can remove compile dir. You can install new version on top, but it can lead to pitfalls. Or not. And you'll have more unneeded files on disk. So think beforehand - there are many solutions.

About LFS is small - well, it depends.. I want apache, gimp, some proxy, some DNS, mozilla TB+FF, octave, mplayer, zsh, elinks... So my package install funionfs tree is steadily growing... Will probably reach 2G.

And about symlink-based system - remember, all the problems are caused by 5% of needed applications with ugly installation system. And it can make symlink-based system a nightmare - when you make a mistake installing fakeroot. I hope unionfs-ing all system dirs except /etc,/var,/home will help me (and it helps already).

So basically you're saying, if one has a "big" system with lots of apps installed already, it's a nightmare trying to update gcc (or other "core components")?

How do you update programs then, if compiling a newer version leads to having extra old files on the disc or other "problems"? Is it wiser to have the compilation directory on the disc, and when updating, first removing the old installation (using "make uninstall" or similar) and then install the new version? Sounds like a whole lot of work..

I hope that doesn't mean if you have a lot of apps and wish to update some of them (that potentially have new versions come up often), you should always recompile a whole lot of stuff or reinstall the whole system?

This unionfs sounds a bit fuzzy..I read some text about it and I think I almost got the idea why Slax is using it, but is it of that much use after all? What about desktop installations (on a harddisk rather than a removable media)?

Thanks again for your posts..seems like every answer raises many new questions, so I hope you have time to answer to them too. Oh, and carcassonne: by "Linux OS" I meant a system I can boot into and start adding programs without doing any major installation procedures anymore (like writing init scripts), not necessarily a complete distribution with everything on it. Just the basic thing with compilers and needed tools for getting the rest of the programs installed :)

Well, I didn't try it... But I guess it will consume some time (note: it is not disaster if you have some free disk space. You can work chrooted to old install and have rebuild with low priority in background).

About uninstall: there is make_uninstall, which takes care of having lists of file in each package installed, so you don't do unnecessary work of uninstalling. But now I use uninonfs-based solution, so I can go to store of packages and just rename package I want to temporarily uninstall - so unionfs doesn't find it anymore.

Surely, with that system reinstalling something non-core is not a pain. Although, there is also a chance of total binary incompatibility of X11R7.2 with all you graphical apps. But of course, to reinstall GIMP you have to reinstall only GIMP, its dependencies, and its reverse dependencies (I mean, all that wants GIMP).

About unionfs - you don't get the idea.. Soon Stephane Apiou will release a new version of funionfs, and maybe (worst-case) a version or two afterwise funionfs will be usable for it. It's in userspace, so it can be more complicated. My running version allows on-the fly addition of new directories to list. So when I want to install something, I create union-slices for it and attach them. Then install (application would not let me install it fakeroot? it is linux kernel modules_install? not my problem). It installs, logically on /, physically in fresh union-slices. I freeze union-slices. I have fun (and application installed). When I want to uninstall it temporarily, I rename union-slices for it, so they are invisible for funionfs. If I want to remove it - I delete a slice. If I want to see what files are installed and how much space do they take up - yes, I just look at the slice and run whatever POSIX utilities I want.

About GNU/Linux OS term - my post indicates I think the same way, doesn't it? Although, installing new software may require writing its new initscripts.

It's easy to use many versions of gcc if you need them, with any distro. Juts
install them in /opt for example and use 'CC='. But that's strictly about
gcc. Like if you need a different version for a specific job. Usually, as
raskin wrote, it's part of a major foundation update including glibc. And
when you change the foundation you'd be better to recompile everything aginst
the new foundations.

I'd be curious though to know if there's a distro that enables you to change
glibc without recompiling all other packages.

There's a huge difference between 'programs' and gcc/glibc. Look at the LFS
website. They are suggesting some package management systems. I think
there's even a mention now in the official LFS 6.1.1 book.

It's long and error prone to update packages manually, especially if they are
large. A package management system is definitively required. Keeping the
source trees is not really a viable alternative. Hmmm... perhaps archived
source trees ?

So that's about 5 minutes configuration time and 5 hours automatic install
time from a LFS 6.1.1 Live CD on a P4 2.4 MHz with 1GB RAM. Your mileage can
vary. I got last week 3 hours inside VmWare on a AMD dual core with 4 GB RAM.

All right thanks again for your time :) Next I'll have to get deeper into this funionfs-thing, it sounds interesting.

One more thing: do you recommend using the LiveCD from LFS or some harddisk-installed distribution for the job? LiveCD is slower and consumes more memory (I'd guess), but on the other hand they said it's got the suitable tools for the job. There is also this thing: if I used an installed distribution to create an LFS system, when I'd have to worry about removing the "builder distribution" and growing LFS on the entire disk (nowadays I dislike the idea of having multiple Linuxes on one HD, and I don't have two or external HDs..) So are there any serious problems using the LiveCD (like a drive getting sleep and then jamming, like happened to me once)?

Hmm about the package managers..so after I've compiled a base system (maybe a few times to get to know the process well), should I try to set up a package manager as the "first outsider-program", and can in handle the programs there are already compiled before the package manager could be installed?

Thank you.

I guess LiveCD is better. It's also small, so it isn't memory-consuming - things that are used get cached anyway, and it doesn't need in-memory unpacking. About package manager: I would really install it early. And I've done this. LFS packages.. Well, I left vim64 in normal build in place while installing huge 7.0 build. Certainly you can just log installation, and manually remove old files during upgrade.

I'd say install SuSE 10.0 with the full online update. That should add a good 3 hours to your LFS install. After LFS is installed, simply wipe off the SuSE system.

Really ! (not!)

LiveCD: That's about 5 minutes configuration time and 5 hours automatic install time from a LFS 6.1.1 Live CD on a P4 2.4 MHz with 1GB RAM. Your mileage can vary. (removed the scary part about the 4GB of RAM and the dual core CPU ;-)