jan.dvorak at sitronicsts.com
Wed Aug 27 00:19:27 PDT 2008
On Wednesday 27 August 2008 03:00:27 Robert Connolly wrote:
> I was thinking today that adding Busybox to the temporary system would
> be helpfull, to get modprobe, /sbin/init, dhcp client, text editor,
> 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.
I don't like the idea of having /tools floating somewhere around final
I'm all for initrd, however. It's actually pretty simple to create one.
You get yourself busybox, udev, device-mapper, mdadm and lvm in the final
system (I suggest adding these to the book, you can rarely see a system
without them where I work.). Then you create some nice script that takes
a list of wanted files, `ldd`s them for dependencies, copies them to a
separate directory, adds some /usr/share/initrd/* files and then `cpio`
and `gzip` them.
If you do not plan on using LVM or software RAID, you don't really need
many tricks. Basically, you need a kernel that supports your disks and
that's it. Everything else can be loaded later. If you need mdadm to
activate software RAID or lvm to activate all PV/VG/LV, you need an
For the installation, what about compiling these to /tools, linking them
statically? That will get you a nice initrd for initial boot, you can
generate proper one later, when the system is finished.
Hell, just give me a basic book I can compile and I'll make you what you
need plus make it extendable so users can add whatever they need. You
mentioned additional packages as runable book "pages"? Fine with me,
we'll just add initrd files same way we add init scripts.
Which reminds me... I don't like current boot scripts.
> 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.
No idea, I have all of them floating around. From 2.3 to 2.7. From a
sysadmin's perspective - never had a problem. From dev's perspective - I
don't want to write for several years old libc.
More information about the hlfs-dev