FreeSA

History

Accessing The Hard Disk after ""if you are going to boot"":http://freesa.org/mips/boot/introduction.html section of CLFS'

To get the freesa disk accessible, have the kernel sources from when you built the kernel. If you don't have them, you need to rebuild the kernel.
Then you need to build the "kernel module "diag"":http://www.tiedyedfreaks.org/eric/diag.tar.bz2 which is from OpenWRT. You have to build it with the SAME COMPILER that the kernel itself was built with. The build will need to know where to find the kernel sources, and by default it will look at /lib/modules/${uname -r}/source, which will of course not work.

#!/bin/bash
make ARCH=mips \
     CROSS_COMPILE=${CLFS_TARGET}- \
     KERNELDIR=/path/to/mips-clfs/build/linux-2.6.23-owrt9339 &&
echo YAY || echo DARN

Next insmod's diag.ko ... wait five seconds (the 5 second wait inside diag isn't long enough for the disk to spin up) ... then follow the instructions in AccessingTheHardDisk: insmod the other IDE modules with a two-second wait between them. At the end of the insmodding, the disk should materialize, at which point you can partition and create swap and so on.

(Random has a script for the insmodding and waiting.)

How To Chroot

One thing one might consider: suppose you have the disk accessible in an NFS-root-mounted freesa box. Well, at that point you can create partitions and unpack the CLFS-to-date onto the actual disk, and then you can jump tracks to the "if you are going to chroot" scheme -- chrooting from the NFS-mounted partial-CLFS environment to an internal-disk partial-CLFS environment. Then complete the build using the local disk, which is apt to be much faster than the NFS environment.

The other advantage being, IF you have a tarball lying around from the "if you are going to boot/chroot" decision point, you can do the "if you are going to chroot" scheme from the get-go, and not have to worry about all of the files contaminating the final directory structure

CLFS Issues and package users conflicts

glibc

/usr/include/scsi needs to be an install dir
/usr/include/scsi/sg.h is already installed by linux-headers; mv linux-headers version out of the way
/usr/include/scsi/scsi.h is already installed by linux-headers; mv linux-headers version out of the way
/usr/include/scsi/scsi_ioctl.h is already installed by linux-headers; mv linux-headers version out of the way
should we move the linux-headers versions back after the glibc install completes?

binutils * Tests are unlikely to work out-of-the-box.

root:/# expect -c "spawn ls" 
spawn ls                                                                        
The system has no more ptys.  Ask your system administrator to create more.     
    while executing                                                             
"spawn ls"

* had to mkdir /dev/pts then mount devpts * had change the top-level Makefile's definition of MAKEINFO to deal with some problem with the missing command

#MAKEINFO = /usr/src/binutils/binutils-2.18/missing makeinfo
MAKEINFO = makeinfo

Also available in: HTML TXT

Wiki