On 09/14/2014 07:16 PM, Ken Moffat wrote:
On Sun, Sep 14, 2014 at 06:10:08PM -0400, Alan Feuerbacher wrote:
Hmm. Up to this point I've done most BLFS stuff on the host system, because
I found several years ago that it was much easier having all the tools
available that are not yet installed on the target system.
What are the implications of doing most BLFS stuff on the host system in
chroot, as opposed to doing it on the running target system? In my
ignorance, I would have thought that using chroot on the target system was
the way to go.
Alan
Building in BLFS in chroot is mostly ok. Occasionally, people get
strange errors : one package, probably firefox, has a note that in
chroot you need to specify the shell : I have no opinion on whether
or not that is true (specifically, it was true for somebody, so I
suppose I have no opinion on whether it is _still_ true and applies
to _all_shells_.
In chroot, there are three things you cannot test:
1. booting, in particular: does the kernel config work for you, and
is your grub config ok ? For both of these, I would prefer to find
out sooner rather than later. Mostly. I edit the grub file on the
host system. and build from the same kernel on the (LFS) host. And
in _all_ cases I build some of BLFS at the end of LFS (e.g. fcron,
nfs, openssh, rsync, links, some of alsa).
2. bootscripts or systemd units.
3. in general, you cannot test if what you have just built actually
works when you run it.
So, if I'm dubious about the kernel, or grub, configs then I will
try to boot the new system to check them. Sometimes, I build past
firefox in chroot so that the new system will be partially-usable,
other times I boot and accept a limited usability while I build the
rest of it [ fun if it doesn't build, e.g. my experience last week
with the ati xorg driver ].
But once you have built LFS a few times, you really ought to be
looking at scripting it (and, from my experience, understanding what
happens _when_ your scripts fail). They don't have to be your own
scripts, but sticking with the project and building it all by copy
and paste is a tedious process.
Let me "tailgate" on what Ken said.
I have found that what he says is true, but working in chroot on the
host system is convenient. Two or three terminal emulators open, browser
open, copy and paste in one environment. For my last three "complete"
{,B}LFS builds, I have pushed hard to get to Xorg and a terminal
emulator to get this convenience as soon as possible to "regain" this
convenience. Historically, I have tried to use Lynx and GPM so that I
could build. I shifted back and forth between terminals and got
frustrated and went back to chroot.
Although successful, as Ken said, there is some "wierdness." In
contemplating the build of LFS-7.6, I have realized that my scripts are
ready for both LFS and BLFS. I'm going to use my scripts in the
non-graphical environment of LFS-7.5. I'll use one terminal for Lynx and
the other for the build. This is necessary because some of the
pre-configure, configure and patching commands change from version to
version in LFS.
My general approach will be the same. Push for Xorg and then build
Firefox and Thunderbird.
My build of 7.6 may be delayed while I "play" with GRUB for UEFI. My
sense is that I'm right on the verge. But afterwards, I hopefully can
adopt the hint for Package Users and publish the scripts that system
uses now. I know there is some hesitance to use that hint, but the
current scripts can be adapted to LFS in general. One can't "walk away"
from the build, but package installation becomes much less pedantic.
Dan
--
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
