Onward branch

Robert Connolly robert at linuxfromscratch.org
Wed Aug 27 20:07:57 PDT 2008


On Wednesday August 27 2008 03:19:27 am Jan Dvorak wrote:
> 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,
> > 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.
>
> I don't like the idea of having /tools floating somewhere around final
> system.

The temporary system's initrd, and /tools, would be a working example of a 
rescue system, whether it's on a cdrom or hard disc. Keeping it is optional.

> 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.

I don't want to add packages that won't be used by everyone, like support for 
RAID or braille. These can be added on your own if you need them. Hlfs is 
intended for users who are already comfortable with LFS, so adding these 
packages to /tools shouldn't be a problem.

Something should be done with boot scripts though, because I would personally 
need sshd. lfs-bootscripts, and blfs-bootscripts, could be installed 
to /tools/etc/rc.d/, to handle the first boot. I haven't looked at how clfs 
deals with this.

> 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
> initrd.
>
> 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.

As soon as you have more than one program it's better to link dynamically. In 
every other instance static linking will use more storage and memory.

> 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.

The lfs-bootscript maintainers are open to suggestions. We need 
blfs-bootscripts compatibility. I would like it if the bootscripts would 
continue when daemons hang (like if the network is down), maybe with a 30 
second timer... this could also be configurable.

> > 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.
>
> 	- Mordae


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.linuxfromscratch.org/pipermail/hlfs-dev/attachments/20080827/e1635283/attachment.sig>


More information about the hlfs-dev mailing list