On Fri, Jan 15, 2016 at 03:07:30PM -0800, Scott Czepiel wrote:
> Greetings long lost LFS'ers!
>
> It has been many years since my last build so I am very excited to
> embark on a build of LFS 7.8 on my new server. Hopefully it will be
> mostly smooth sailing, but of course it wouldn't be fun if I didn't
> run into a few head-scratching problems along the way!
>
> Even though it's been 15 years since I first discovered this wonderful
> project, this will only be my third "substantial" attempt at building
> an LFS system. My first build occurred way back in the Spring of
> 2001, and was based on version 2.4.3 of the book. I finished all of
> LFS and a good chunk of BLFS as well.
Hmm, ISTR I started on a 2.4 version, but got advised to use what
eventually became 3.0 because of build problems. So, I suppose you
pre-date me. And my memory suggests that BLFS was, if it existed
when I eventually completed LFS, minimal in those days (for a
desktop, probably not a lot more than XFree86). But maybe my memory
is as flakey as my athlon x4 ;-) Whatever - Welcome Back!
> The 2.4.3 LFS build included gcc 2.95.2, glibc 2.1.3, and kernel 2.4.4.
You definitely pre-date me : I don't recall which kernel I used (I'd
been playing with kernels since about 2.2.13), but when I got here
gcc was 2.95.3.
> In preparation for this endeavor, I've skimmed through the whole book
> to see if there have been any dramatic changes since the last time
> around. Version numbers have certainly changed, but the basic process
> is very familiar. One issue that came up in the olden days was subtle
> host-system toolchain dependencies bleeding into the LFS system
> binaries. It looks like a lot of work has gone into making the
> toolchain construction more robust, so I don't think that will be an
> issue anymore.
Hopefully, we've sorted it - until the next problematic distro
change. 5.0 ("pure LFS") was the initial change (LFS-4 had lots of
weird and wonderful issues on some people's machines), and nowadays
we have the Host System Requirements in the preface. But people who
have been dipping in to LFS in more recent years have noted a lot of
changes, particularly since 7.0 where the bootscripts were changed.
>
> Cheers!
> czep
>
I hope it all works out fine - at least modern hardware is a lot
faster.
> [1] If interested, here are the 3 essential burn-in steps I use to
> validate new hardware:
> 1) memtest86 - run it overnight to get a few passes.
Yep - I happen to use the memtest86+, but either seems fine.
> 2) smartmontools - this involves 4 tests: short, conveyance,
> badblocks, and long:
> smartctl -t short /dev/sdX
> smartctl -t conveyance /dev/sdX
> badblocks -ws /dev/sdX
> smartctl -t long /dev/sdX
> Review results with: smartctl --all /dev/sdX
> Note: DO NOT run the badblocks test on an SSD
Thanks for that - I have not come across 'conveyance' before - I
usually just run short and long - and on some SSDs (Crucial, I
think) the testing seems to not exist. For some reason, we don't
have smartmontools in BLFS, only an inadequate Lennartised
alternative which is a dependency for various desktop packages.
I haven't run badblocks in years - can you remind me why you run it
on "spinning rust" but not on SSDs, please ?
> 3) prime95 - run for a few hours and make sure nothing catches on fire!
Is there a Live CD, for that ? I've seen it mentioned in the usual
hardware sites, but only in the context of running under Windows.
ĸen
--
This email was written using 100% recycled letters.
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Do not top post on this list.
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
http://en.wikipedia.org/wiki/Posting_style
