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

Bill's LFS Login lfsbill at
Sun Jun 15 05:28:44 PDT 2003

On Sun, 15 Jun 2003, Csaba Henk wrote:

> 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?<snip>

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

There is none. And I haven't made one. I have no devfs in my kernel and
chose not to enable it just for the recovery diskette. Since I have the
knowledge to make that choice, it seemed reasonable for *my* circum-

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

I don't do religious crusades. If you and/or the book want to do devfs, I
see no problem with that. I have suggested adding a few lines about using a
static /dev directory because the LFS book uses it and that would allow a
user, new or otherwise, to do "what comes natural" to him/her. If it is
decided that is not appropriate, I also have no issues about it. What I do
consider important is that the end of LFS either make the recovery diskette
there or at least point the user to the proper part of BLFS immediately, as
you, IIRC, suggested.

So let's let it ride after this post, ok?

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

Not necessarily, when you "roll your own". AFAICT, the book is *not* making a
general purpose recover-any-hardware-os diskette such as an administrator of
a variety of platforms might need. For such an administrator, there is good
reason to make such a diskette. And there may be good reason for a
non-admin to do so.

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

*sigh*. I have a few tty entries, a few HD entries, a console, a CD etc.
This "forest" is not created by *me*. I know this is a recovery diskette
and include *minimal* functionality. If I was really paranoid, or an
administrator (redundant?), I guess I would add a few more things. Maybe
its a "garden" - certanly not a forest.

But, again, I don't care either way which path the book chooses to go. If it
works and meets the user's needs, it is good. If it is easier one way or the
other for the user, it is better. If it can be done with no effort and wipe
one's ass too, that's great.

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

As above, I agree that the need's of the user/administrator should be the
driving force. Not everyone *needs* all capabilities, but they may still
*choose* to have it.

> "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!

I have no "huge amount" of devfiles. I don't have 100-150 inodes for that

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

Yep. One less thing to change in the kernel. If I chose not to use it in my
production kernel and the kernel will fit on the floppy with all that it
needs without having to recompile kernel, that is good. Since I use modules
a lot, I may be able to get all on the floppy. But I haven't tried for
(B)LFS and I haven't thought about it at all yet. And I don't care. The
floppy made, very similar to the book version, meets my needs. It is
"good", but not "better" or "great".

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

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

> 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

For a boot floppy, I agree. My boot floppy depends on no HD-based tools.
If they are available, I can , of course, use them.

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

I always plan a multi-tier approach appropriate to the circumstances. If the
HD stuff is available when recoverying, use the advantages it provides. If
they are not, the diskette and/or other means must be available and complete
enough to do the job in a reasonable time. That's organized enough for

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

How did this migrate into a disagreement? There has been *no* implication or
overt statement to that effect, IIRC. Your religious zeal is overwhelming
your recollection of what my OP, and subsequent exchanges, said, I guess. You
are not "trolling" are you?  ;)

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

I never thought that. But I am one of the lucky ones who seem to read
and understand quite quickly (usually - there are some things that
baffle me for a long time).

> >> >><snip>

> Csaba

Let's wrap this all up. As when an excessively long thread about devfs
occurred on LFS-*, there are many good point for devfs. You make many
good points for having a devfs regardless of environment. I have *no*
disagreements with that. I have suggested that the book *might* want to
include a non-devfs paragraph or so because LFS does not introduce
devfs. Nothing more.

The turn this thread took since my OP has been surprising.

Have a good one.

Bill Maltby
lfsbill at
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