Archaic wrote:

In an attempt to get this info both archived, and presented to the
larger community, I am writing up a synopsis of ideas that have been
floating around on IRC as to how to handle the chroot/reboot phase of
the cross-lfs book. I will list them and give a brief pro/con for each
as I understand it.

1) Tar up the temptools and *somehow* move them to the target.
|-> This one has many drawbacks as it requires that the host already has
   an OS and that host has the ability to create partitions, etc. in
   preparation for the tarball. If the system is remote, then it will
   require uploading a sizable tarball to the host, assuming the host
   knows what to do with it. Even in the day of high-speed personal
   internet, upload speed sucks. :)

2) Put the target's HD in the host's machine and then swap it back out
  when ready to reboot.
|-> This assumes that one has physical access and that the HD's are
   easily swappable. If they are, this method works, but there are too
   many situations that will not work (i.e. any remote build, a laptop
   vs. desktop HD, and even the niche boxes like the mac mini).

3) Have the book create a bootable CD of the temptools upon completion
  then use that to boot into the target.
|-> This assumes that the host can burn a CD and that the target can
   boot a CD. The later is likely moot as there are very few systems
   that can't boot a CD in proportion to those which can (not unlike
   the old argument over having a /boot partition in the first 1024
   cylinders). This also assumes physical access.

4) Make a boot floppy to load the CD.
|-> The day is fast approaching where floppies are no longer included
   as part of a new system. Especially in laptops. This also assumes
   physical access.

And now for a novel concept.... Have the book officially support
HOST=TARGET with a chroot (no rebooting) and then point to hints if
someone feels the need to use a different host.

Pros/cons of this idea:

One has to be able to burn a CD *only* if the target system isn't
running linux.

One has to have physical access *only* if the target system isn't
running linux.

The CD can be a minimal CD, unlike the liveCD and with compression could
easily be brought under 50 MB for the iso download. Again, only needed
*if* the target isn't running linux.

As you can see, the biggest hurdle is overcome by the host having a
linux system already which has been the assumption for LFS since day
one. Even so, many people have successfully been using knoppix for years
and the lfslivecd since its inception. Here we can cater to a
minimalistic host on CD for any supported arch and the book can stay as
linear as possible.

Ideas? Comments? Suggestion? We need your input. Multiple perspectives
ultimately make for a better book. The above is merely my perspective
and likely does not cover all aspects needed to make a good decision.



My idea is the netboot thing. Since all the bootloaders in question will work with NFS or TFTP booting.

--
------
[EMAIL PROTECTED]
[EMAIL PROTECTED]

LFS User # 2577
Registered Linux User # 299986

--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Reply via email to