Redhat

Steve Hayashi sth at andrew.cmu.edu
Sun Jan 14 15:14:30 PST 2001


Actually, I'm not.  I only started writing scripts to do it for me a
couple days ago.  The reason for the slow change was that if I had a
script to do my compiling for me, and there was a compile error, I'd never
know that I would have one until it was too late (that happened to me with
glibc.  I didn't realize there was an error until I tried dynamically
compiling bash).

I suppose getting a copy of the basic startup scripts would be pretty
handy.

My latest problem with sysklogd, I have no idea where it came from.  I'm
doing a full reinstall now and see if it goes away (I've been using Win98 
WAY too much, I know).

But still, it can take upwards of 2-3 hours to do a normal install of LFS,
and that's not counting the initial distro installation.  That's probably
why it's not a feasible enterprise OS.

-Steve

On Sun, 14 Jan 2001, ken_i_m wrote:

>  >My only guess towards it is that installation requires constant monitoring
>  >and it's entirely too easy to f*** it up (for every perfect installation
>  >I've had of LFS, I've easily had 20 that didn't make it)
> 
> I was doing better then 1 in 20 and I feel you may be exagerating a little 
> though that is moot to the point I am going to make. I found that the 
> blotched installs were a result of typos or forgotten instructions. To this 
> end I created a series of shell scripts that automate the process a great 
> deal. Then when I want to build a new system with an updated  package, for 
> example, the kernel. I make changes to the script that handles that. By 
> letting the scripts do all the repititve work I need not worry about 
> inadverently introducing new errors via typo etc.


-- 
Unsubscribe: send email to lfs-discuss-request at linuxfromscratch.org
and put unsubscribe in the subject header of the message




More information about the lfs-dev mailing list