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 > now.
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 > GCC? 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. robert
pgpexwm3p4Kmk.pgp
Description: PGP signature
-- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
