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.
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.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
As I have been following the instructions for LFS I begun to realize that I could save a lot of retyping by running the commands from scripts. I have got to the point where I expect to install most of the installation from just four or five scripts.
I am seeing some problems and worries. If one installation doesn't go, the script may just go to the next installation. Still, if you have ever had to do a long installation over again, the utility of scripts looms enormously.
Has anyone else applied any scripts in their installations? Basically all you do is type the commands into a text file and 'chmod a+x /TheTextFile' and then type the name of the text file as if it were a command. But all the resources of the shell are available and there is some programmability possible in even the simple bash shell scripts.
I'd try Automated Linux From Scratch, but there does not appear to be a 4.1 profile yet. Any experience here with that?
I'm not trying to be rude... however I thought that the biggest difference between LFS and something like Gentoo was the lack of automation? I thought the reason for LFS was for people who WANTED to compile everything by hand and piece together a linux system bin by bin.
again, I am not trying to be rude and I'm sorry if my reply seems a little harsh... just putting in my $0.02
Distribution: Ubuntu 11.4,DD-WRT micro plus ssh,lfs-6.6,Fedora 15,Fedora 16
i don't know much about LFS, but i would say that i's a clever idea , after all i'ts still doing the work of building a system from basically scratch, it's just cutting down on the boring parts and allowing it to be more fun
I agree that the spirit of LFS is to cobble everything together by hand. But the way that you are instructed to assemble LFS really suggest scripts. In fact the scripts I use are just typed directly from the commands given using the vi editor. It really seems so obvious that I imagine the author hoped the reader might catch on. That really is a lot of typing to do to compile all that. Especially if you have to do it over somewhere.
I looked at your scripts and they are nothing like what I am applying. I can't even tell how they work. The scripts I use are just the commnds copy and pasted from the book. I think going through every step by hand every time is of limited educational use unless you are just learning to use the keyboard with touch typing. Every Linux user should know how to apply scripts since scripts are such an important part of Linux functionality. Scripts really are very, very simple tools. Even a script per section would be a big improvement for many of the more complicated sections.
Yeah, I agree, my scripts are horribly convoluted :-)
Comes from needing to handle many and varied different versions of packages (hence seds instead of patches) and multiple architectures.
(they're more a test framework than buildscripts)
I'm working on a script right now with what I HOPE to be fairly simple maintenance.
To address the point before, yes, LFS is meant to teach you something the first time you do it. Maybe even the second. But what happens when you have three machines to install it on? How frustrating is it to mis-type a configure/make command only to find out much later in the process that something, somewhere earlier got screwed up, and start the process again.
As for ALFS, I don't know about you folks, but the way it's set up doesn't scream user-friendly. Well, let me re-phrase that, the documentation provided did not give me a sense of "full understanding" in using the tool. All I felt comfortable with was marking EVERYTHING as a compile. If there was an error, well, mark EVERYTHING again. Ultimately, the ALFS approach would be the most robust, but until I feel comfortable with using it, I'll keep working on my scripts.
I believe I'm 90% done with a script to handle the static installation portion of the book. Ideally, the goal would be to automate static compile and shared compile in one script. I'm not sure how feasible that is considering the user must change to root to execute chroot in-between the static and shared stages. I for one, would be timid about giving my script root access. Not to mention someone else running a script they didn't author themselves.
I can post it when I clean it up a little more if anyone is interested. Like I said, the idea is to try and make it fairly easily maintained. I do that by breaking each package compile into basically five commands: pre, cfg, make, install, and post. In theory, each of those five contain a single command (if any at all), but the pre and post commands will typically take the form of "<command> && <command> && ...". Using a few greps, you could see what the commands for any one package are and compare them to the book. If a package changes, it should be reasonably simple to run sed on the script to update that package's commands.
And the script does have error-checking. I am being fairly religious about that. Almost every command verifies good exit status. If a command fails, the script displays the message, and exits with the same failure value. I also intend to add a command-line argument to start the script at a given package; to pick up where you left off in case of an error.
I can post it when I clean it up a little more if anyone is interested.
Sounds great, I would be interested. I'll try and do the same. I guess this would be the difference between LFS and some other "distro". People are apt to be making all kinds of scripts. This is a good thing. Linux users and computer users in general should be more fluent in writing scripts. In Linux especially, it is just too easy.
and follow the LFS script link on the left. You'll need to right-click, "save as", and remove the ".html" extension it wants to put by default.
If you just follow the link, it'll post it, but it's be badly mis-formed. I just didn't see a way to create a link to directly download a file, but that might be due to a complete lack of knowledge when it comes to HTML.
Anyway, let me know if you think it has promise, is the most horrid thing you've ever seen, or you'e happy with it just the way it is...
I got it! And my first impression is that it is good. Mine is much, much simpler and follows the book more closely, but has no way of bailing out if something doesn't go in right and you can see by my posts that this does happen.
What really mystifies me about your script is the vast amount of text processing that must have gone on. This was a recurring challenge for me in making even my simple script. For example, you have a list of packages. How do you get that into text into the script without typing it out? There must be a way right? There is, but figuring that out was an obstacle for me. I suspect there are many other such tricks. I used vi and cat, but I am sure there are other tools. Did you employ similar tricks in creating your script? How much was actually typed in by hand?
Have you seen Ryan's script below? What do you make of it? I'm not even sure what it is for.
The script evolved as I started to type it up. At first, I planned to just copy-and-paste the commands from the book into a script. When I realized I couldn't do that and just run it (I was getting some kind of error), I decided to change it up a bit. Long story short, I looked at other scripts in general, picked up enough information to search through bash's man page, and drew on my knowledge of C to make it as modular as possible.
So, the short-short answer to your question is: I copy-and-pasted the commands from the book. It's an initial investment in time to do that, but will require little maintenance over time. Each new release of the book won't be a complete rewrite; Only a handful of packages (on average) should change. So going through the book and realizing which packages have changed and updating the relevant section of the script should be relatively painless.
I do have greater aspirations than copy-and-paste glory though. Downloading the book in XML format would make it feasible to extract the commands. Essentially that's what nALFS is doing. I wouldn't plan to go that far though. I'm thinking you would rip out the compilation commands in the XML (using greps and cuts), compare them against what the script uses (more greps), and finally, update the script if necessary (sed). And presto! it should work. The reliability of these modifications depends on the reliability of the grep commands properly locating commands to rip out. That's why the names of the variables at the top of the script are so uniform: to help with grep'ing against the script's contents since all the important stuff is assigned to those variables.