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

Csaba Henk tphhec01 at
Fri Jun 13 14:46:49 PDT 2003

In article <Pine.LNX.4.55.0306122014360.1945 at>, Bill's LFS Login wrote:
> Folks,
> 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.

Hm. The device, which is usually referred to as /dev/fd0, isn't it of
major,minor 2,0 ?

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

When making a floppy, what difference does it make whether one uses devfs or
traditional device files with his/her LFS installation? The floppy itself
*should* use devfs.

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

As I see, LFS is just a linux system which is able to boot and bootstrap
itself. Neither of these tasks require a bootfloppy. Of course, a bootfloppy
is a very basic thing for a system used day-by-day. But there are other such
things in the BLFS-book. I think the boofloppy has also a good place in

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

IMHO there are some ideas which could ported to the BLFS bootfloppy from the
uClibc bootfloppy hint (authored by me). Eg., there it is done as follows:

* first, you build all your stuff in a specific directory;

* when you are ready, you measure up this stuff both in terms of disk usage
and number of files;

* with adding some extra to these measures, you create an ext2 fs of
respective size and inodes;

* mount the ext2 fs, copy your stuff there, umount fs, copy to disk. 

Thus the fs on the floppy is as close virginity as possible, and is as big
as it's needed. And the steps after the first are quite scriptable.

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

Yep, the disk could be enhanced with basic recovery tools. "so it can fit":
my comment is that the BLFS bootdisk is stuffed with a bunch of unnecessary
things. Why glibc? In the age of libc5 it was just nice to use it for the
distro and the distro's bootfloppy as well, but those days are gone. You
will hardly find any bootfloppy project on the net which would use glibc. (I
think uClibc should be used.) Why the system bootscripts? Why all the basic
groups of LFS (there is no use of /etc/{passwd,group} in a system without
login utils; the BLFS bootdisk has no login utils)? Why devfsd (devfs
without devfsd is just fine)? 

If you omit all this bloat, a bunch of recovery tools will fit, and there
will be space even for gpm for the comfortable ones.

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

There is a quite cryptic passage in BFLS bootfloppy: the rdev stuff. It's
absolutely unexplained what it does, and why are there those multiple
references to the kernel size. And don't say RTFM: the rdev manpage tells
nothing for one who doesn't know what it is all about.

* * *

When I started this reply, I didn't intend to be critical concerning the
BLFS bootfloppy. Anyway, it turned so. The nicety of this situation is that
my critic is absolutely constructive: you can find a bootdisk implementation
which avoids these (IMHO) flaws in the uclibc-bootfloppy hint. 

I'm not self-advertising --  it's just my $0.02 / 2 HUF.

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