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

Csaba Henk tphhec01 at
Sat Jun 14 03:44:06 PDT 2003

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

Thanks for the enlightment. I think I will change the uClibc bootfloppy hint
according to this.

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

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. 

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

If you worry that people after completing LFS just go out contentedly to
have a beer, rather than doing the last polishments their system requires,
then it would be more sane to put a pointer in the "What now?" section of
LFS to the _"After LFS Configuration Issues"_ chapter of BLFS (and not just
simply to BLFS as such). But there is no much point in arguing about this
*here*. Anyway, your original question was "is there a point in suggesting
the addition of a bootfloppy to LFS". I think your "fears" are justified:
lfs-dev ppl will say, "man, we have enough trouble with putting
now-existing things to shape, leave us alone with enhanchments". But the
best way of getting the experience is trying :)   

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

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.

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.

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

Again, there is "After LFS Configuration Issues". If one "moves quickly from
LFS to BLFS", wouldn't it be the first to read in the BLFS book? The
phenomenon that people move quickly from LFS to BLFS just strenghtens the
view that it doesnt' matter so much that where are certain things described.
Anyway, I agree that navigating away from the "copy any other binaries and
libraries you need" attitude should b helped.

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

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.

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