Submissions: upgrades on OnePartitionHint, dosemu, new hint about errors

Alex Kloss alex at
Tue Oct 7 05:55:13 PDT 2003

Hi there!

Here are my newest releases. I hope you like it!

-------------- next part --------------
AUTHOR:	Alex Kloss <alex at>

DATE: 2003-09-19

LICENSE: GNU Free Documentation License Version 1.2

SYNOPSIS: Setting up dosemu with freeDOS or any other DOS.

Sometimes you want to use the good old Disk Operating System, e.g. for 
playing some real old games (like commander keen), but you don't want to 
shutdown your linux box and don't have a DOS bootdisk anyway...

[ATTENTION: dosemu is discontinued in favour of dosbox (available on - but it's still faster in most cases!]

PREREQUISITES: - dosemu-1.0.2.tgz
FreeDOS kernel binary (is included in package) or any other DOS's
gcc-2.95.3 (segfaults when compiled with gcc-3.x, I'm doing some testing
about this at the moment...)

First edit the compiletime-settings to match your preferences.
The file explains the usage of these
options. I myself used the following options:

config {
  experimental on
  sbemu on
  mitshm on
  x on
  net on
  dodebug on
  slangforce on
  oldslang off
  runasroot off
  linkstatic off
  newint on
  aspi on

Next edit the base-configure file so:

mv base-configure base-configure.bak
sed -e s/-m486/-march=i686/g -e s/-malign/-falign/g base-configure.bak \
 > base-configure
chmod 755 base-configure

Now run the installation:

export CC=/opt/gcc-2.95.3/bin/gcc &&
./rebuild all &&
cp bin/* <wanted prefix, e.g. /usr/bin> &&
mkdir /var/lib/dosemu /var/lib/dosemu/dosemu &&
cp src/plugin/commands/*.com /var/lib/dosemu/dosemu

now try "dos" or "xdos". If xdos complains about not finding
the necessary fonts, you should edit your etc/X11/XftConfig
and add to the first lines

dir "/usr/X11R6/lib/X11/fonts/misc"

and restart X.

A minor problem is that the src/plugin/commands dir does not
contain all of the dosemu stuff, for example the cdrom.sys
driver is missing. You'll find the turbo C sources in
/src/commands. Since you propably don't have turbo C, you'll
have to find a way to 1. extract that driver from the binary
distribution or 2. compile it without turbo C:

cd src/commands &&
for i in aspi cdrom ems emufs; do
  as86 -b ${i}.sys ${i}.S
done &&
cp *.sys /var/lib/dosemu/dosemu

Just don't mind the errors. The drivers should work anyway.

>From the freedos kernel binary:

unzip the to a temporary directory. You'll only need the
to copy the kernel.sys file:
cp kernel.sys /var/lib/dosemu &&
ln -s /var/lib/dosemu/dosemu/ \

any other dos:

mkdir /var/lib/dosemu/dos &&
cp /<wherever it is>/io.sys /var/lib/dosemu &&
cp /<wherever it is>/msdos.sys /var/lib/dosemu &&
cp /<wherever it is>/ /var/lib/dosemu

You may be interested in copying other files you want (himem.sys,, etc.) to this directory. Since dosemu comes with its
own replacement (, you don't need, but only io.sys and msdos.sys (or however your
DOS calls these files).

For configuration, copy etc/dosemu.users.[easy|secure] and 
etc/dosemu.conf to /etc and edit them to match your preferences.

You may create config.sys and autoexec.bat to match your needs.
In most cases, you'll be fine with those:

cat >> /var/lib/dosemu/autoexec.bat << "EOF"
@echo off
set TEMP=c:\tmp
prompt $P$G
echo "Welcome to dosemu %DOSEMU_VERSION%!"
unix -e

cat >> /var/lib/dosemu/config.sys << "EOF"
rem buffers=10
rem devicehigh=c:\dosemu\cdrom.sys
shell=c:\ /e:1024 /p

You may now start "dos" or "xdos" and install your DOS software at will.

  * Initial Hint.
  * Conversion to new hint format, some changes.
  * Small fixes in conversion.
  * Added gcc-2.95.3 stuff for LFS-5.x.
-------------- next part --------------
AUTHOR:	Alex Kloss <alex at>

DATE: 2003-10-07

LICENSE: GNU Free Documentation License Version 1.2

SYNOPSIS: What to do on errors

The LFS Book has a short, but nice chapter about errors. A longer essay about 
how to spot where the error is, how to describe it (on IRC or the mailing 
list), and possibly get around it is the goal of this hint.

Common sense, LFS, patience.

Almost every LFS adept has seen lines like:

- make[1]: Error
- Segmentation Fault
- ld returned signal 2: ...

The first urge is to write to the mailing list or on IRC something like:

I have an error in program <fill in whatever is appropriate>!

Mostly further informations about the errors are missing, which is a nuisance
for both the one who asks and the one who tries to answer, because of the
annoying dialogue that is often following. I have to admid that the LFS mailing
list and IRC never failed to solve my problems (and that in a rather cheerful
way), but I reached a point at where I wanted to solve as much of my problems
myself. So I had to learn a much, which was undoubtedly fun.


You have to distinguish between the different kinds of errors. The more you 
can tell about the error, the easier it is to solve.

This should be a normal hint, but I guess it is easier to draw a chart:

Question: When did it happen?   What happened?      Where did it happen?

                                                  , Compiling (gcc) ...
                              , ... not found ---<
          Compile-time Error <                    ` Linking (ld)
       ,'                     `.
Error <                          Segfault
       `.                     ,'
          Run-time Error ----<          , full
                              ` Hangup <
                                        ` Prog 

That looks pretty simple, eh? But that's only the beginning. We will have a 
look at each of these error types closely!

1. Compile-time Errors

When you are about to ./configure && make && make install your package, you
sometimes get the error that something is missing or malformed or simply

1.1 ... not found

1.1.1 Compiling (gcc)

There is a lot gcc may be unable to find. If there is something to include, it 
may be the file that should be included, that is missing. The questions here 
are: 1. what's missing? and 2. what to do against? Missing header file

If only a header file is missing, you will experience an error message like:

foo.c:3:31: /usr/include/bar.h: No such file or directory

If there's a file missing, you may want to search your system for it:

find / -name <filename> or
locate <filename> (run updatedb, if locate demands it)

If you don't find the file, the next question would be: where should this file
come from? Is there a prerequisite you forgot? Are all tools available in the 
required versions?

In most cases the file will be in another directory than the developer thinks 
it is. The easiest way around that would be a symlink, but that is not a clean
way. So we search the sources for occurrences of the "missing" file first:

grep -R "<missing file's path and name>" *.*

Now edit every file that uses the wrong path in it's #include statements. The
lazy user can utilize sed:

for i in *.*; do 
 mv $i $i.bak
 sed s|'<"missing" file>'|'<found file'>|g $i.bak > $i

This should solve the problem; you can continue building the package. Missing declaration

Another fine errormessage goes about a missing declaration:

foo:124:4: bla undefined

if "bla" is a function from generic libraries (like glibc), it will probably be
documented with a manpage which holds informations about which header file(s)
it needs to be included:

man bla

Look at /usr/share/man/man3 for documented function calls: The manpage will
look something like that:

FUNC(3)				Linux Programmer's Manual		FUNC(3)

	func, ffunc, vfunc - Example function without any use

	#include <stdfunc.h>
	int func(char *format, ...);
	int ffunc(FILE *stream, const char *format, ...);

	#include <vstdfunc.h>
	int vfunc(const char *format, va list ap);


In most of the cases the header file is not included where it's neccessary, so
you just write it into the file where it is missing: "#include <stdfunc.h>".

If the definition is nowhere any standard library, you will have to search the
codebase of the program you are about to compile for the function it's missing:

grep "<function name>" *.* | less

Now search for something like "#define bla ( const char * ...". If you don't
find anything, the function is likely to be included in other sources, so you
better check the requirements of the package you are about to compile, in case
something is missing.

If the file where the definition is included is a header file (*.h), simply
include it, otherwise copy and paste the definition into the file gcc is
complaining about.

1.1.2 Linking (ld)

Linking mostly fails because of missing libraries. Make sure your
/etc/ contains all directories with libraries in it. In case, another
directory is needed, use LDFLAGS: "export LDFLAGS=-L/usr/X11R6/lib" to include
XFree86's libraries for sure.

1.2 Segmentation Fault

This is most annoying. It means an application had an error that is so bad it
rather drops core and stop immediately.

1.2.1 Segfault during compilation

Segmentation faults during compilation are very seldom. You only get SIG11 if
the memory is full while building a package and will happen only on systems
with few memory. You can add a loop device to swap to expand your memory; this
will make compilation much slower, but at least it will work on such devices
that contains too few memory:

dd if=/dev/zero of=/tmp/swapspace bs=1M count=128
losetup /dev/loop0 /tmp/swapspace
mkswap /dev/loop0
swapon /dev/loop0

will set up 128MB of swap space (or virtual memory). If it still fails,
increase the amount of disk space used (count=256; count=512; count=XXX).

1.2.2 Segfault during execution

If a program segfaults, there isn't much you can easily do to hunt the error
down if you don't have some programming skills. Contact the developer and give
him a detailed view of your system; maybe in /var/log is something about the

1.3 Hangup

Hangups are the most annoying errors there are. Fortunately, they are as seldom
as annoying with Linux (unless you use bleeding edge sources only).

1.3.1 Full Hangup

You recognize a full hangup by pressing the [CAPS LOCK] key. If the led is
flashing, the keyboard is still hooked to the console, so that's no full
hangup. Try pressing different keys then. If nothing else works, use a hard 
reboot (that is always the last means of getting back to work). If the
keyboard is still available, but the screen is blank, try to reboot with
[ALT][CTRL][DEL]. If even that doesn't work, you may be lucky to have the sysrq
key feature compiled into your kernel. For further informations, read

1.3.2 Program-only Hangup

If the program hangs up leaving the rest of the system intact, you can use the
kill command to get rid of it. 

Hope this was helpful!

    * Started to write this hint.

    * Initial Version.
-------------- next part --------------
AUTHOR:	Alex Kloss <alex at>

DATE: 2003-10-07

LICENSE: GNU Free Documentation License Version 1.2

SYNOPSIS: Install LinuxFromScratch using only 1 bootable Linux-partition

If you got no spare partition to build your LFS on, you could turn a file into 
a partition, using the so-called loop-device. The transfer of the system to 
the root partition is a bit tricky, though.

You need to have loop device support compiled into your kernel (if you're 
unsure, run "grep LOOP /usr/src/linux/.config"; if the last letter is y or
m, the kernel compiled with that options has loop device support enabled),
otherwise run 

sed s/\#\ CONFIG_BLK_DEV_LOOP\ is\ not\ set/CONFIG_BLK_DEV_LOOP=m/ \
usr/src/linux/.config > conf && mv conf /usr/src/linux/.config &&
cd /usr/src/linux && make modules modules_install && insmod loop &&
cd /dev && ./MAKEDEV loop

Now your kernel should have loop device support through a module. Other
than that, you need about 1GB (rather make it a bit more, the filesystem is
stored in the file as well and adds up to some MB of data) of free space on 
your root partition (or any other partition you intend to store your loop 
file on). The commands "cd /dev && ./MAKEDEV loop should be omitted on systems
which are using devfs).

The following text describes the changes you have to make to the normal LFS 
installing procedere when using only 1 bootable partition. It's not complete
without the LFS Book. It is just a description of the things you ought to do
in a different way than declared in the LFS book. It splits up into 2 parts
that differ from the Book: first, of course, the making of partition, which is
replaced by the making and setup of a loop device file, and next, the deletion
of the previous system due to the need of diskspace for the new one and the
installation and boot setup, that differs a bit, too.

If you're using reiserfs, this hint is almost unusable for you due to deletion 
errors on a recursive mounted volume with reiserfs (the files will be deleted, 
but the space wouldn't be freed). You could still use the hint to make every-
thing ready for a transfer using a bootdisk/CD, but don't try the "Delete the 
previous System" section or further. You've been warned!

Make yourself a bootdisk or bootCD, whatever is sufficient on your system. You 
can prevent a lot of trouble when rebooting fails. 

If you don't know how to make a bootdisk or bootCD, look at the hints, the BLFS 
section about it or search for bootdisk on freshmeat. Be sure that the bootdisk
or -CD is able to read/write your root partition, e.g. a tomsrtbt is currently 
not able to mount reiserfs.

When you come to the part of the LFS Book which is called:

"Creating a new partition"

You don't want to create a new partition! That's why you're trying to use this 
hint. Therefore, this should be replaced with:

Making a loop device file:

Be sure to be superuser and that you have all variables ($LFS) set up like
you're told in the book. Then make a file containing enough MB of
nothing running:

dd if=/dev/zero of=/tmp/lfs.disk bs=1M count=XXX

"dd" is short for "disk dump"; it will dump the contents of an device or file
into another device or file. We dump from input file "/dev/zero", so everything 
in the new output file "lfs.disk" will be empty space. This file /tmp/lfs.disk 
will become our loop device file soon. The newer versions of software you use, 
the more space you will probably need for compiling; you might want to replace 
XXX with 800-900 MB for LFS 2.x, 900-1000 MB for LFS 3.x and 1000-1100 MB for 
LFS 4.x/5.x or even more to be on the safe site.

Setting up the loop device:

You load the file you made to the loop device with the command

losetup /dev/loop0 /tmp/lfs.disk

which will bind /tmp/lfs.disk to the loop device /dev/loop0; everything
written to /dev/loop0 will go directly into /tmp/lfs.disk.

Creating a ext2 file system on the new partition:

We don't have a new partition. But we have our file "lfs.disk" (or whatever 
you called it) on the /dev/loop0 device. So instead of creating the file 
system on /dev/hda2 or any other partition, we're using the command on the
loop device our file is attached to:
mke2fs /dev/loop0

This will write an ext2 filesystem to our /tmp/lfs.disk file using the loop
device. You could also use mkreiserfs or any other filesystem that is capable 
of handling unix-style attributes (So dosfs/vfat doesn't count, but umsdos 
does), but be warned that a journalling filesystem like reiserfs produces 
grossiping amounts of overhead, so prepare yourself in patience for a slow 
installation. I hear your questions why reiserfs should be slower than ext2fs 
at a loop device. This is because the reiserfs uses a journal which is 
accessed every time at write accesses, so you have to write almost any data 
twice vs. once using ext2fs.

If you haven't got any idea about what I was writing about the last paragraph,
just believe me using ext2fs is the best method. If your main system uses a
journalling filesystem, the data is safe anyway, because lfs.disk will be
included in the journal, too.

Mounting the new partition:

mount /dev/loop0 /mnt/lfs

Instead of mount e.g. /dev/hda2 to /mnt/lfs, we're using our loop device. From
now on, the installation may proceed as in the book.

Before entering the chrooted environment (which usually happens in Chapter 6), 
you can safely put the sources in your /home/lfs directory and unpack them 
directly there. When entering the chrooted environment, you can reduce the 
needed space by unpacking the sources from another login in which you do not 
enter the chrooted environment.

Of course you can delete every packagedir (even the kernel) after installa-
tion, unless the book tells otherwise. 

Halting the Building of LFS:

So you found that building LFS using this hint takes too long to do it in one 
pass? Never mind. All you have to do is save the system in a secure state so 
you can shut down safely. When in chroot'ed mode, first umount everything
that's mounted to /mnt/lfs, then get every shell away from /mnt/lfs and umount
/mnt/lfs itself.

Then exit the chrooted mode. Now unmount the lfs "partition":

umount /dev/shm
umount /dev/pts
umount /proc
exit # the chrooted environment
cd # get out of /mnt/lfs
umount /mnt/lfs

Now you can safely set back the loop devices:

losetup -d /dev/loop0

Now you can safely shut down your system. When you start again, you need to 
perform those steps "backwards", like you already did in the beginning:

losetup lfs.disk /dev/loop0
mount /dev/loop0 /mnt/lfs

Now chroot and mount proc if necessary (use the commands you find in the LFS
Book, they may differ from version to version). 

The following steps are quite the same. The only differences starts again when 
you want to make this drive bootable:

Making the LFS System bootable:

A thought on making the kernel in LFS: why reconfigure everything? Even
if you've got an old kernel, most of the things you've chosen (or not)
during kernel configuration have not changed a bit. You could fasten up
this if instead of

make menuconfig

using out of the chroot'ed environment:

cp /usr/src/linux/.config $LFS/usr/src/linux
<enter chroot>
make oldconfig

Now you only get asked on the things that weren't configured with your new 
kernel (which should be somewhat less work than choosing every menu). If 
you're unsure, you could still check it with "make menuconfig".

Make your kernel and grub (or lilo, if you are using an version < 5.x) in the 
chroot'ed environment as described in the LFS book. Don't try to start grub or
lilo now! Stop here! I hope you're still in the chroot'ed environment, other-
wise go back there.

The only bootable partition you've got is the one your current distro is 
running on. 

If you want to use the /tmp/lfs.disk file for anything else than installing 
LFS over your distribution, you'll probably not need the following part.

You're about to install LFS on the partition, deleting the distro. But before 
you get started, read the following warning carefully:

               Do yourself a real big favour and get a bootdisk! 

If you delete your distribution and have a power failure, you would lose
your whole system (including the lfs.disk file that you can't access
anymore without a bootable linux system unless you get a bootdisk).

Mounting the main partition:

Mount the main partition to "/mnt" in the chroot'ed environment suggesting 
your main partition is /dev/hda1, otherwise fill in what is necessary:

mount /dev/hda1 /mnt

The main partition is now mounted to a directory in a file attached to a block
device which is mounted on the main partition (that is mounted to a directory
and so on...). This is a really nice example for recursion. And this could get 
another nice example of an almost infinite loop (depending on your harddisk's 
size), if you try to copy everything to mount. Or an destructive loop, if you 
try to delete everything in /mnt (because this also holds the file currently 
working as your root environment). If you're asking what I'm talking about, 
never mind, just follow the next instructions very, very carefully.

Making sure init finds his getty:

If you know what I'm talking about, you could go straight to the following 
paragraph. Anyone else may read the explanation: "init" is the process that is 
started by the kernel to start everything else during the bootup.

Everything else, that is, all calls that are in /etc/inittab. In this inittab,
you should find some version program getty, for example agetty or mgetty, but
maybe only getty. This program is used to load the programs that allow you to 
login into your system. Now imagine you delete the whole old stuff including 
the old getty. Imagine further the LFS's agetty is different from the distro's
version, or in a different directory (Debian, for example, uses getty). The 
inittab should remain in the memory. Init would try (on your next login) to 
use a getty that's not there, meaning you wouldn't be able anymore to login 
into your system, which could be fatal in the current state.

Before you logout of the chroot'ed system you should be sure that the init 
process will find the version of getty named in the inittab, otherwise you 
would be unable to access the system anymore and need the the bootdisk! A 

cat /mnt/etc/inittab | grep getty

shows wether your previous system is using getty, agetty, mgetty or any
other version possible. If it's using any other version than agetty
(that's what Linux From Scratch is using), you should do a symlink like

ln -s /sbin/agetty /sbin/<the distro's getty version>

Now you can safely replace the old system.

Deleting the previous System:

To repeat the previous warning: That DOESN'T WORK well with reiserfs. I've
double-checked if the issue would be resolved in the current reiserfs
version, but the result was negative: the deletion of recursive mounted
file systems leaves the emptied space unusable, because it's not cleared in
the journal! So don't try the next steps if you are using reiserfs! If you are
using an ext3 partition, you may mount it as ext2 and covert it back after you
copied the new LFS to your main partition. Anyone using reiserfs should create
a boot-CD with the new LFS in a .tar.gz file. You'll find a short description
at the end of this hint

You'll have to get the main partition entirely clean from everything that is 
not /mnt, /tmp/lfs.disk and proc, which holds another file system:

for dirname in `ls -1 /mnt | sed -e /tmp/d -e /proc/d -e /mnt/d`; do 
 rm -r /mnt/$dirname; done &&
for filename in `ls /mnt/tmp | sed s/lfs.disk//`; do 
 rm $filename; done

You may omit other directories at will by adding "-e /<directory>/d" to the
first sed command. The second line is only needed if you want to clear the /tmp
directory, too.

Now the partition should be clean enough for copying the LFS system. If you 
want to keep other files and are not so sure about your shell scripting skills,
better delete all unnecessary files by hand (don't touch /tmp, /proc or /mnt).

Copying the system to the root partition:

Now we may copy the new system. Everything but the /mnt directory, to which 
the device that we are filling with LFS is mounted and the directory /proc, in 
which are dynamic files written by the kernel. 

for dirname in `ls -1 / | sed -e /mnt/d -e /proc/d -e /tmp/d`; do 
 cp -a $dirname /mnt; done

Command explanations

cp -a ... /mnt:

copies in "archive" mode, so the whole directories are copies with their 
content and all subdirs and all filemodes are kept, if possible. For the 
for ...; do; done constructions look at the previous command explanation.

Now the LFS is on your primary partition logout of the chroot'ed environment 
into the new system. Now you can perform grub/lilo and this stuff.

logout (or exit)
cd /
umount /mnt/lfs/proc
umount /mnt/lfs
losetup -d /dev/loop0

Command explanations


Get out of 1. a bash, 2. a chroot'ed environment.

cd /

we change to the root dir not to have former access on the device we're
about to unmount.


First we need to unmount the proc device from the loop device, so you
can unmount this.

losetup -d /dev/loop0

delete the binding from /dev/loop0 to /tmp/lfs.disk.

You may now delete lfs.disk, unless you don't want to use it otherwise.

You could e.g. pipe the disk dump to install over network. If anybody is plan-
ning an LFS installation like that I beg you to contact me via IRC in #lfs on to 1. get further support and 2. let me share your 

Then you can get back to the book (installing grub/lilo and all that stuff).

Now for those who are using reiserfs and need to make a bootcd to copy the new
system over: 1. make a bootdisk (like in the BLFS section), add all utilities
you may need (like reiserfsprogs) 2. make a .tar.gz archive of your new LFS 
(of course after exiting the chrooted environment):

cd $LFS
mkdir /tmp/lfscd
tar czfv /tmp/lfscd/LFS-<version>-<date>.tar.gz 

Now create an isofs which uses the bootdisk image as El-Torito bootimage:

mkdir /tmp/lfscd/boot
cp <bootimg> /tmp/lfscd/boot
cd /tmp/lfscd
mkisofs -r -o /tmp/lfscd.iso -b /tmp/lfscd/boot/<bootimg> \ 
 -c /tmp/lfscd/boot/catalog

Now use cdrecord to write the iso image on a CD. The LFS on this CD may not run
on other Systems, especially older systems will need an cross-compiled version
of LFS (see cross-compiling hint).

[Summer 2000]
  * After doing this little trick on my own notebook, I urged myself to write 
    a hint (after all, I had a lot fun with LFS and wanted to help spread it).

[Somewhen later 2000]
  * While using my own hint when I tried to make a LFS BootCD without using 
    the hint (I'll never do that again), I stumbled over a nice information 
    about losetup, which opens a better way to handle loop devices and added 
    it to that hint.

  * After a few month, I wanted 1. to do a new LFS using my hint again (not 
    only for the fun of it, I also wanted the System as new as possible),
    2. try to reorganise this hint and 3. make the scripts on the end a bit 
    Note: I had to enlarge the lfs.disk file a bit, due to the fact that on
    some systems, during glibc compilation in chapter 6 the disk usage con-
    quers 800MB.

  * Corrected a bad typo

  * I'm trying to keep this hint up to date, so another installation is about 
    to take place. I want to go a bit beyond the current version, so I'll try 
    to use gcc-3.0.4 and another few versions not yet used by the book. Wish 
    me luck!

  * Currently testing LFS 4.0 on a One Partition Build. Since the chapters 
    have a new structure and the static utils are stored in a separate 
    directory, the advantages should be used in this hint, too.

  * Updating to the new format, removed unnecessary stuff, checking for 
    LFS 5.0-pre1 (test build).

  * Further updates to 5.0-pre2 (since pre1 had some show-stopper bugs),

  * Finished testing with 5.0-pre2 (successfully), minor changes to
    match the new book style (command explanations after each command), added a
    short section about the bootcd stuff for reiserfs users.

Many thanks goes to Gerard, without his book, developing this hint had never 
been possible.
Thanks to the whole bunch of people that usually idles the whole day on 
#lfs at for helping me in so many ways.
And thanks to all the people not mentioned here for not minding it...

More information about the hints mailing list