Boot disk/Rescue Disk Oversight?

Bill maltby - LFS Related lfsbill at
Thu Oct 10 16:33:58 PDT 2002

If all below is now out-of-kilter because we have started "upgrading" to
non-noob content, please excuse me and just let me know. If any of this is
useful, I will be glad to generate a patch if you would like.

The commands after "The following commands will build us a 4 MB image.",

  dd if=/dev/zero of=/tmp/rfloppy bs=1k count=4096 &&
  mke2fs -m 0 -N 2000 /tmp/rfloppy &&

do a mke2fs. Would it be better to go ahead and do the losetup to asso-
ciate /tmp/rfloppy with /dev/loop* before mke2fs is done? This would add a
small educational snippet at the expense of modifying the mke2fs to refer-
ence the loop device, rather than the file, and the mount command (be-
low) to use the pre-assigned loop device, rather than the file name.

I note that the code for this uses a mount point which, IIRC, has not been
created in LFS or BLFS. Possibly the addition of a mkdir is needed?

  mkdir -p /mnt/loop1 &&  # Really should be done elsewhere?

If the losetup -s done in advance, the mount would be modified to:

  mount -t ext2 /dev/loop1 /mnt/loop1 &&  # We could forego the "-t ext2"

Later, when copying the dev directory, I see cp -dpR. This could be
shortened to cp -a, if so desired.

BTW, I think a note should be added that the user should replace the above
command with a custom built of their own if *not* using devfs. The reason
for this is compression. Copying all the /dev entries and then "trimming"
them will leave a lot of non-zero, but unused, sectors laying around. This
will reduce the maximum effective compression achieved, which is important
if trying to squeeze the most out of your minimal floppy space.

Some of this loss may be ameliorated by the subsequent activities, like
the busybox addition, but it may be better to be "squeeky clean".

These same comments apply to the copy of the /etc/rc* stuff later.
For the /etc contents, I have a couple of suggestions.

The switch to noauto could be eased by replacing the following,

  cp -ax /etc/fstab /mnt/loop1/etc

with (non-devfs)

  sed -e '/^\/dev\/hd[a-z0-9]*.*[^n][^o]auto/s/auto/noauto/' \
      -e '/^\/dev\/sd[a-z0-9]*.*[^n][^o]auto/s/auto/noauto/' \
      /etc/fstab >/mnt/loop1/etc/fstab

This will also introduce some sed, which is being phased out of the LFS
book AFAIK. If needed for devfs use, we could show those names instead.

This lets you eliminate the paragraph about "... automatic mounting of
hard ..." and put a one-liner in about what the above does. The scripts
should probably be improved somewhat to assure that only the intended
"auto" strings are affected.

Adding a "cat" wrapper around the two /dev/... lines in the book would
make a more "seamless" creation of the fstab.

  cat >>/mnt/loop1/etc/fstab <<EOF
  /dev/ram0       /               ext2    defaults
  /dev/fd0        /               ext2    defaults

Of course, we could also cat /etc/fstab and the two /dev/... lines in a
"here document" to make it completely seamless.

Busybox is available in .bz2 form, as indicated by the ref [400], but the
commands to be run show a .tar.gz command.

The && conditional execution operators are used inconsistently.

BTW, I see no mention of needing ramdisk and initial ramdisk support in
the rescue image that is built. Is it needed? I had it enabled in my
kernel, but would be happy to lose the extra memory if they are not

The cp -ax /var/utmp /mnt/loop1/var && should fail because there is no
such file on a bare-bones LFS base installation. I got around this by


"Put this in /mnt/loop1/etc/init.d/rcS" should be "Put this in
/mnt/loop1/etc/rc.d/init.d/rcS"? And only for devfs use?

The math for the rdev process is correct, but the command shown

  rdev -r /dev/floppy/0 16738

should be

  rdev -r /dev/floppy/0 16814

I've done a short bash $((...)) that takes the dd stdout and does the
calculation if you feel it would be useful. It "wraps" around the dd
command, so should not distract from the main point terribly.

An losetup -d is also needed when we are all done, unless umount is able
to handle it for us (is it affected by the mtab symlink problem?).

Bill Maltby
billm 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