robert at linuxfromscratch.org
Tue Aug 26 18:00:27 PDT 2008
On Tuesday August 26 2008 03:00:00 am Jan Dvorak wrote:
> No need to use boot scripts. Just add few logins to inittab, let it spawn
> dropbear and reboot. Things like setting console font, activating swap
> and remounting root in read/write mode can wait and be done manually for
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.
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
All of the toolchain could use an upgrade. Binutils and Glibc only seem to
maintain their last release version, and abandon old ones. GCC maintains
older releases for a long time. Using old versions of Binutils and Glibc
means watching their development for bug fixes, and backporting them, and/or
shadowing a distribution who does this (alt-linux has a ton of bugfix
backports for glibc-2.5). Kernel versions go either way... some are
maintained for a long time, and some are not.
In general I think it's a good idea to wait 6 months, for example, before
upgrading to new releases. This gives everyone else time to discover bugs.
Waiting longer than that has a risk of using an unmaintained release, but
tracking distribution backports and patches helps minimize this risk.
And to complicate things some more, each package is unique. Upgrading Binutils
is usually safe... they tend to be very conservative and take their sweet
time with final releases (with rare exceptions). Glibc, GCC, and Linux, seem
to like to live on the bleeding edge and have a lot of fast development, so
more caution is needed with them, but they have good a good track record.
It's really hard to say what is the "best" version of each to use.
My gut tells me to stay with the mature versions, except for Binutils... so
binutils-2.18, gcc-4.1.2, and glibc-2.5 (with bugfix backports). Linux
versions track whatever grsecurity is with. I'm curious to know the
statistics on which Glibc version is currently being used, and maintained by
distributions, the most. New versions are nice, but the majority of the Linux
world does not use them, so they're not stabilized yet.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: not available
More information about the hlfs-dev