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

Bill's LFS Login lfsbill at
Sat Jun 14 05:11:23 PDT 2003

On Sat, 14 Jun 2003, Csaba Henk wrote:

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

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

Glad I provided a useful idea!


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

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? Remember that I have walked this
maze a few times before and recognized some issues before I finished
reading. Leaving it disabled gains me a few more bytes on the floppy. Of
course, if your host is devfs, you would want it in there.

> >> As I see, LFS is just a linux system which is able to boot and bootstrap
> >> [...] I think the boofloppy has also a good place in BLFS.
> >
> > I agree with one exception. [...] 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,

What! No celebration allowed?  ;)

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

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

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

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

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 that does not require replacing major com-
ponents. Also, if you want simplicity in the construction of the
recovery process, there may be good reason to replace components. But
all this is moot if the book folks decided to take the simplest, albeit
less-than-all-possible-features approach. In their situation, I would.

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

> >> > 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,[...] 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.

Good point.

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

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

Yes. For folks who want to know more, refs to existing docs are useful.
But, they could also locate that themselves. I'm not sure specific TLDP
docs should be referenced everywhere they might apply. That would really
be "bloat" in another medium.

> 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