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

Bill's LFS Login lfsbill at
Thu Jun 12 17:53:34 PDT 2003


Just remade my custom bootdisk using the 20030603 CVS book. I don't use
devfs, so I don't know if this applies. But since I have some experience
with booting, I thought I would mention this, and make an offer too.

The command "rdev /dev/floppy/0 /dev/floppy/0" seems to me to not do the
right thing. The first "/dev/floppy/0" is correct, I guess. On my system
I use "/dev/fd0", the normal /dev entry in a non-devfs system. But the
second entry says to set the root device to the floppy, IIRC. Since the
floppy in the drive at that time is not a file system, it should not
work, if I understand these things correctly. But if I specify 0,0 in
place of the second floppy specification, the root device defaults to
the ram disk just loaded. This is as it should be, again, if my under-
standing is correct.

Tested and works *just fine*. BTW, this is with a 2.4.20 kernel, which I
know has changed the boot process slightly since 2.4.18.

Now, as to my offer. I'm thinking two things. First, since LFS default
build is a "static" /dev directory, I think we should offer a few
commands for that scenario. If there is agreement that it should be
included, I'll be glad to cobble something together and sub some patched
sections for y'all to peruse and include if appropriate.

A couple last notes. It seems to me that it is rediculous for LFS to
help one create a basic platform without some kind of backup/recovery
tool - especially one as basic and critical as a recovery or boot
floppy. I feel strongly that we should lobby to get a basic boot
diskette into LFS book. Am I off base? Is it worth bringing that up on
the LFS dev list? I really don't feel like using a lot of bandwidth just
to start a thread that may be known doomed to failure at the outset.

Another suggestion is that we tell the user to make an edited fstab (and
any other files that will vary from what's on their box) *before* copying
it to the new FS. The process of editing "in place" will cause some
additional i-nodes to become non-zero and leave some "holes" in the FS
that will reduce compression ratio, albeit slightly. Every little bit

Along the line of space, mention that in most case 2000 i-nodes will be
excessive. I used 1600, still have about 400 or so left and gained about
45K, IIRC, of additional free space. That's enough room for 1.5 mke2fs
binaries. By playing with that value, a *substantial* amount of space can
be made available. Of course, when compression of binaries is
considered, the gain on the initrd is not as substantial as we might
like, but every little bit...

Last, I think the addition of some verbiage about including an
appropriate *fsck capability on the diskette should be included. I know
this requires the recompilation of, for instance, e2fsck to be
re-installed dynamically (possibly just for the diskette) so it can fit,
but what good is a nice floppy if you can't at least run fsck on your
FS? Further, a mk*fs should be recommend along the same lines. You might
have great backups of partitions/data, but if you can't make an FS,
and your FS is *gone*, what's the point of the backup? This is
especially on my mind as I just finished my first hint contribution
(booting related) and, while thinking critically about what to include,
realized that between LFS and BLFS, very little direction/suggestion
about these issues are given to the rapidly growing (and
less-experienced?) community.

I know that one valid response is that anybody that has progressed to
the point of BLFS should be aware of, and know how to do, these things.
But if you watch the lists, you will see that many people move quickly
from LFS to BLFS without the background to even be aware of these basic
issues. My feeling is that giving a point in the right direction, beyond
just "copy any other binaries and libraries you need..." would be a
useful expenditure of time.

What'chall think?

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