Chapter 3. After LFS ... Issues - Creating a custom bootdisk

Csaba Henk tphhec01 at
Sun Jun 15 00:53:38 PDT 2003

In article <Pine.LNX.4.55.0306140731390.321 at>, Bill's LFS Login wrote:
> On Sat, 14 Jun 2003, Csaba Henk wrote:

>> Dont'ya build a specific kernel for the bootfloppy? Having devfs support in
>> your everyday kernel, and in the kernel for the floppy are absolutely
>> different things.
> Yes I did, this time. With other procedures I have done, nope. But the
> thing is, I don't have it enabled in my normal kernel, why should I
> enable it for the recovery diskette? Remember that I have walked this
> maze a few times before and recognized some issues before I finished
> reading. Leaving it disabled gains me a few more bytes on the floppy. Of
> course, if your host is devfs, you would want it in there.

Again, I don't see connection beetween devfs support of host and bootfloppy.

My religion is that bootfloppies *should* use devfs. But I also have some
argument to support it.

It's a characteristic of bootfloppies that they have a static content but
they meet various hardware environment (and the contrary is true for
harddisk-resident installations).

* As they have a static content, it is not likely to happen that some day a
new app gets installed which has problems with devfs. As I experienced,
those basic apps which are usually installed to a bootfloppy, has no problem
with devfs (and need no devfsd).

* As they meet various hw, the list of necessary dev files is always due to
change. If you put there all dev files which you can image, congrats, a new
garden of unnecessary bloat is created. If you put there a specifically
trimmed tight list of dev files, you loose the flexibility given by the
portable character of your media. OK, you can say it is for your host
machine. But many people have multiple machines, with various configs. And
why would you throw a feature away in vain?

"Leaving it [devfs] disabled gains me a few more bytes on the floppy": are
you sure? I made some tests on it, and got that they occupy the same amount
of space by and large. OK, devfs support increases your kernel a bit, but
then you get rid of that (in context of floppies) huge amount of devfiles
you would have to create otherwise. 100-150 inodes take quite much space!

If you use devfs, you simply don't have to think about how to trim you /dev
directory for the floppy. Thus it's comfortable. 

To put it another way: I see not any advantage of static device for a
floppy. Do you?

>> Yeah, I admit that there is some reason in putting together a bootfloppy with
>> minimal efforts. But a bootfloppy is limited enough to make the coexisentce
>> of bloat and features impossible. If you want useful features like recovery
>> stuff, then you should customize the floppy (first of all, get rid of
>> glibc). So: 1) either we choose to include the fastest way of making a
>> bootfloppy in the BLFS book with no features 2) or we go for a more useable
>> bootfloppy, but then saying goodbye to glibc is a must.
> If you restrict to just one floppy and no more and no CD or available HD
> partition from which other components can be used, yes. Otherwise, there
> are *many* good ways to do it that does not require replacing major com-
> ponents. Also, if you want simplicity in the construction of the
> recovery process, there may be good reason to replace components. But
> all this is moot if the book folks decided to take the simplest, albeit
> less-than-all-possible-features approach. In their situation, I would.

Anyway, isn't it much better if your floppy is a self-contained complete
recovery tool? If you intend to use a CD, do so, but use *only* a CD, make
it bootable. Harddisk-resident recovery utils just sound stupid for me. But
again, if you want to be over this stuff as fast as you can, you can do that
you dump your host system to a floppy and you keep your arsenal in the HD,
say, in a designated partition. Concerning me, I don't think it's an utterly
superior way of organizing your life.

>> Now the BLFS book seems to be settled with 1), which is OK, but its bloated
>> in a way which is not even comfortable -- repeating myself: it uses system
>> startup scripts, /etc/{passwd,group} files, devfsd. Purging these out would
>> make the section even shorter.
> For anti-bloaters, every little byte and unneeded feature is important.
> For the "world at large", these are less important than other issues.

Problem with the above mentioned things that they are bloat but
not feature at all. Sure, some bloat is to be considered as a feature, which
is unnecessary (hence the status of being a bloat is subjective), but these
things are pure bloat. I claim these things have no use at all. It's an
objective statement. Tell me why I am wrong if you think I am wrong.

It's just the smaller problem that these things occupy a few bytes. The
bigger problem is that it confuses the reader. S/he will perform these steps
as it's ordered and will think: "yes, if I want devfs on my floppy, I have
to install devfsd". I as well thought so for quite a long while.

>> >> There is a quite cryptic passage in BFLS bootfloppy: the rdev stuff. It's
>> >> absolutely unexplained <snip>
>> OK -- just for "giving a point in the right direction, beyond just \"copy
>> any other binaries and libraries you need...\"", the Bootfloppy HOWTO should
>> be referred to, that's the place where these things are explained nicely.
> Yes. For folks who want to know more, refs to existing docs are useful.
> But, they could also locate that themselves. I'm not sure specific TLDP
> docs should be referenced everywhere they might apply. That would really
> be "bloat" in another medium.

The problem is that the stock documentation (which is included in your
system: man/info pages, etc.) suck in this case. I wouldn't think that the
reader shouldto go on the on the net and hunt for HOWTOs to understand a
certain command. I think it's a good barrier: expect him/her to figure out
things in case s/he cam do it offline.

Unsubscribe: send email to listar at
and put 'unsubscribe blfs-dev' in the subject header of the message

More information about the blfs-dev mailing list