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

Bill's LFS Login lfsbill at
Fri Jun 13 16:50:35 PDT 2003

On Fri, 13 Jun 2003, Csaba Henk wrote:

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

Yes. But the kernel loads the initial ram disk automatically and
mounts it. The ram disk contains the needed /linuxrc (busybox in this
case) and the FS structure needed to run. So specifying "0,0" (equiv-
alent of saying "no device root specified") allows the kernel to then
use the ram disk components (most importantly /linuxrc in this instance)
and you are ready to fly. It *might* work with /dev/fd0 specified (or
2,0) but that then requires the existance of some special directories
(used to be /initrd) on the ram disk FS so that the ramdisk could be
rotated there and programs could continue to execute. With the new boot
procedures, the name(s) have changed (something like old-root? I have
not looked recently) and pivot-root is used now. Since the BLFS book
does not have the needed directories, I *suspect* the /dev/fd0 (2,0)
will not work. And on my system (he-he) it didn't. In a past life it
worked because I provided the needed supporting structure and code.

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

I beg your pardon? If your kernel does not have devfs support, how can
your kernel support it? Am I mis-rembering? I thought you had to enable
defvs in kernel config. I have never enabled it in my kernel.
Corrections gleefully accepted though.

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

> 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

I agree with one exception. It is a platform for continued development,
installation and education. If you have just spent a substantial time
installing this very useful tool and then a tragedy happens before you
are able (or realize you *ought*) to make a recovery floppy (acts of
God, lightening, coffee in the keyboard - whatever) you may experience
great angst. Since I try to "walk a mile in their shoes", it occurred to
me that the "final act" of LFS install should be safeguard against
tragedy (well, pointing to BLFS would come after, I guess).

><snip some space saving ideas>

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

First, I have no opinion re glibc, libc5, uClibc et al. I have always
worked in restricted spaces and found my way around impediments. I
wanted to suggest only *minimal* change to the current book text and
recovery floppy contents so that a certain *minimal*, IMO, functionality
could be made available. With the common availability of CDs and the
ability to tell the boot floppy to read it (or even additional root FS
floppies) to acquire additional needed components, I see no good
justification for the effort to completely rework a basically sound
procedure that uses components already available on the (B)LFS system
the user has just built. Of course, outside of the book, I think we all
should try new things just for the educational value, even if for no
other reason.

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

First, IIRC, a decision was made long ago that all the explanations
about program purpose/functionality would be "one liners". That explains
the brevity of the text.

I haven't researched extensively recently, but basically the various
forms of rdev alter some locations in the kernel image that specify vga
handling, ramdisk size (and whether the initrd is on the boot floppy or
another floppy - prompt the user for it before starting the initrd load)
and what the real root device is supposed to be. If you replace that
"0,0" I used earlier with the hex values (or the /dev/... form) for an
HD partition with a good root FS on it, you are back in business
(assuming the proper directories need for pivot-root exist there). Very
useful for recovery situations. Especially is you do a custom /linuxrc
and use it to create/mount additional ramdisks. That can yield some
*very* fast and flexible recovery processes - all automated.

> * * *
> 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 usuall see these things as constructive suggestions. Your bias
toward "reduced bloat" is not unusual. There are many situations in
which the effort to reduce the bloat is justified. IMO, the books
orientation means that it is not one of the places the effort is really

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

I should be - I need a job!  :-\

> Csaba

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