Onward branch

Kevin Day thekevinday at gmail.com
Wed Aug 27 07:50:45 PDT 2008


> I'm planning to start a new branch (like Neo), in plain text, named Onward.
> Before hlfs was xml it was in text, and pages worked as shell scripts. The
> pages can be read, or run as shell scripts, to install packages. I'm sure
> there is a way to convert the plain text book into simple html, wiki, or
> whatever.
I have considerable experience at building plain text or similar
script systems, considering that I have a pretty complete system
myself for building distributions. As I may have mentioned before.

So, if you need any suggestions, tips, etc.. just ask.


>
> Furthermore, the chroot system will be replaced by a reboot. This will
> eliminate host system requirements for the final system... Glibc test suites
> will all pass, livecd maintenance can be covered by the temporary system,
> kernel version and capabilities module would not be an issue on the final
> host system, the host of the final system can be trusted, etc. An html viewer
> (web browser) will not be needed because the book is usable as shell scripts.
> The 'more' program is enough to read the book, but users can certainly
> install whatever text file reader they choose to /tools. An sshd daemon
> (dropbear) will be needed in the temporary system for remote installs. Boot
> scripts will need some modifications to use /tools/bin. A second reboot will
> not be strictly needed.
This almost begged for a pivot_root + kexec, but sadly, kexec has host
kernel dependencies so the reboot method would still be the way to go.

So the idea would then be to build a toolchain, kernel, and an initrd
system, then boot to those?

That would support your desire to have the tool's directory on a
separate partition.
In which case, the tool's partition should have a standard suggested
LABLE, such as "hlfs_tools" or "onward_tools".


On Tue, Aug 26, 2008 at 8:00 PM, Robert Connolly
<robert at linuxfromscratch.org> wrote:
>
> I was thinking today that adding Busybox to the temporary system would be
> helpfull, to get modprobe, /sbin/init, dhcp client, text editor, etc.
>
> Furthermore, an initrd with busybox could remain as a rescue system, so /tools
> is kept after the final installation. This would work best if /tools was its
> own partition, which is not normally mounted. This way nothing is wasted.
Just be sure to have some explanation of what a partition is, how to
create one, and how to use one.  Afterall, first time users will
generally have too large of a plate to deal with. I can imagine a
constant cycle of support requests asking about their disappearing
"tools directory problem.


>
> For installation, I guess we would do a pivot_root out of busybox/ramfs into
> the temporary system, after mounting partitions and swap.
>
> Does this seem like a good idea?
>
>> > The combined toolchain will probably be dropped, because it doesn't
>> > always work... gcc and binutils need to share compatible libiberty
>> > libraries, among other things, or else they won't build in the same
>> > tree. The combined tree build method is very nice, but it is not
>> > flexable enough yet. I want to bump to binutils-2.18, but that doesn't
>> > work in a combined tree with gcc-4.1.2.
>>
>> What about 4.2, or even 4.3? Are there any reasons why not go for a newer
>> GCC?

As far as I remember, 4.2 had some serious problems with hardened and
possibly with uClibc. I would imagine that 4.2 and 4.3 should by now
have a sufficient number of bug fixes.  Because 4.3 is considered
stable by GCC, it will be more actively maintained and more likely to
accept new issues/patches that this project may come across.

So, it looks like I typed myself out of giving you a reason to _not_
go for 4.3 or 4.2.


-- 
Kevin Day



More information about the hlfs-dev mailing list