On Fri, Jan 15, 2016 at 5:46 PM, Ken Moffat <[email protected]> wrote:
> 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.
>
And hardware support in the kernel does seem to be much easier and less
problematic than it used to be, at least that's been my experience.
>
> > [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
>
--
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
