$Id: freesbie_notes.txt,v 1.11 2007/09/19 15:34:09 db Exp db $ Using freesbie in /usr/ports/sysutils/freesbie ---------------------------------------------- (This is a work in progress, most current freesbie_notes.txt is at http://people.FreeBSD.org/~db/freesbie_notes.txt) I recently used the freesbie port to build a live hamradio oriented BSD CD. I ran into a few undocumented hitches and bugs. I thought I'd put the ones I found into point form. Normally, the freesbie folks use a "wrapper" script 'builder' which runs itself in a chroot, but this means yet another set of chroots and a system which does not necessarily match your running system. However, the customroot files needed to add a freesbie user and the homedir is kept with the builder not with the freesbie port itself. I discovered this eventually after reading through the http://wiki.freesbie.org pages. I suggest checking their current freesbie scripts in cvs, in case the freesbie port is out of date. This bit me early on when I found a bug in the freesbie scripts in the port and they had already fixed it in cvs. From their wiki 1. obtain FreeSBIE 2 toolkit from cvs (cvs -z3 -d :pserver:anonymous@cvs.freesbie.org:/cvs co -P freesbie2) After some digging I found http://cvs.freesbie.org You can get some of the necessary customroot files from freesbie cvs by doing: cvs -z3 -d :pserver:anonymous@cvs.freesbie.org:/cvs co -P buildsets cd builder/default-i386/customroot tar up customroot and place into freesbie2/extra/customroot This is where you will set your boot bitmap etc. I cheated and copied one from a live freesbie 2.0 CD You can also find the /usr/home/freesbie directory which should also be placed under freesbie2/extra/customroot; I believe I found that in buildsets/default-amd64/customroot/usr/home/freesbie (need to double check...) You can also boot a FreeSBIE CD, tar up the freesbie home dir and copy that to your working directory on the build machine. At about this point, you may wish to simply use the freesbie folks builder and buildsets to continue. I did start with the builder but discontinued rather quickly because I wanted my custom setup and I also thought it would take less space and be easier to just use my default running system. I already have one huge tinderbox set up. (One of these days, it would be nice to combine the two) If I was to start again, I might very well go with the builder approach, but I cannot help you much with that at the moment. (September 1, 2007) I still have not worked out how to use their builder scripts, last time I tried, I managed to remove a lot of ports from my own working system. Bugs and 'gotchas' ----------------- 1. freesbie uses the installed ports as in on the system, (when the freesbie folks make a release, they generate it from 'builder' which is a chroot system.) it does not use the set of packages from your /usr/ports/packages. It converts the installed programs into packages, which it then uses to install on the target image. This has a major consequence. A port which installed cleanly on tinderbox is not necessarily "clean" on a running system. This is due to assumptions made by the port writer that are not necessarily true. In my case, I am an xemacs user, it appears some ports assume if emacs is installed it is emacs not xemacs and have hard coded file names for emacs not xemacs. xemacs has a different site-lisp than emacs. The consequence of this is, the package will not build properly and that package will fail to install on the target. 1) Check the .done_pkginstall log, look for "Cannot stat" messages. These are an indication that a package build went wrong and a package might get dropped. 2. I have modified the pkginstall.sh script to use pre-built packages if available from /usr/ports/packages if they exist, rather than always creating a package on the fly. This appears to make building the freesbie-fs much faster. This does mean I have to remember to portupgrade -P, but I have more than one FreeBSD box here anyway. --- ../pkginstall.sh Thu Jun 14 23:57:32 2007 +++ pkginstall.sh Tue Jun 12 16:35:26 2007 @@ -167,9 +167,14 @@ fi count=$((${count} + 1)) - echo "Running pkg_create -b ${pkg} ${CHROOTWD}/${pkg}.tar" >> ${LOGFILE} - pkg_create -b ${pkg} ${CHROOTWD}/${pkg}.tar >> ${LOGFILE} 2>&1 - + if [ -e /usr/ports/packages/All/${pkg}.tbz ]; then + echo "Using existing tbz package ${pkg}" >> ${LOGFILE} + cp /usr/ports/packages/All/${pkg}.tbz ${CHROOTWD}/${pkg}.tbz + bunzip2 ${CHROOTWD}/${pkg}.tbz + else + echo "Running pkg_create -b ${pkg} ${CHROOTWD}/${pkg}.tar" >> ${LOGFILE} + pkg_create -b ${pkg} ${CHROOTWD}/${pkg}.tar >> ${LOGFILE} 2>&1 + fi echo "Running $pkgaddcmd ${chrootpkgpath}/${pkg}.tar" >> ${LOGFILE} $pkgaddcmd ${chrootpkgpath}/${pkg}.tar >> ${LOGFILE} 2>&1 @@ -183,7 +188,7 @@ delete_old_packages() { echo "Deleting previously installed packages" chroot ${BASEDIR} pkg_delete -a >> ${LOGFILE} 2>&1 -# rm -rf ${BASEDIR}/usr/local + rm -rf ${BASEDIR}/usr/local } # Deletes workdirs I kept the original pkginstall.sh and stuck my version into .../scripts/custom It's not pretty but it works. 3. The nastiest is when the CD boots but does not start up X, look at mount, /usr/local/etc the default is 10mb, if set too small, /usr/local/etc is too full and files get left off. This is due to using etcmfs and having the localetcsize too small. check in extra/etcmfs/etcmfs.rc increase if your /usr/local/etc is larger than 10mb Same goes similarly for etcsize. Obviously, you'll want to check the size of freesbie-fs/usr/local/etc (normally /usr/local/freesbie-fs) before wasting a CD with a too small etcsize or localetcsize etcmfs is set in EXTRA= in freesbie.conf covered in Hint 1 You will also find similar for rootmfs and varmfs i.e. if rootmfs is too large or too small, you can adjust it by changing freesbie2/extra/rootmfs/rootmfs.rc The variable in this case is rootsize. 4. I wasn't sure if this was a gotcha or a hint. If you do decide to change the hostname as set in /etc/rc.conf be sure to change /etc/hosts to match, or xfce4 will not come up properly. Hints ===== 1. Start with conf/freesbie.conf # Set EXTRA variable to the additional plugins you want to run in your # system. Please note that plugins are executed in the same order as # listed in this variable # #EXTRA="customroot rootmfs etcmfs" EXTRA="sound customroot adduser xconfig mountdisks swapfind etcmfs rootmfs varmf s" You could decide to leave etcmfs and rootmfs out, but in that case you better make sure the user never needs to edit a local etc file. I may very well leave out rootmfs in a future custom CD as I don't think I'll need a writable / dir, but I have cut it down to 5mb as mentioned later. The names listed in EXTRA are scripts that will be run under the extra subdir i.e. sound will be a script run from freesbie2/extra/sound.sh 2. It is possible to boot the resulting image under qemu to test that it boots etc. before you make a coaster. qemu -cdrom FreeSBIE.iso -boot d 3. It is also possible to run programs under the FreeSBIE image under jail, programs run this way run much faster than under qemu, but you cannot test the desktop or boot as easily. From the jail man page mount_devfs devfs $D/dev i.e. mount_devfs devfs /usr/local/freesbie-fs/dev ifconfig nic alias some_ip jail /usr/local/freesbie-fs freesbie some_ip /bin/sh It is a little more work, but you can actually have the jailed freesbie image now connect to your local display and use it, so you can check that X11 programs will work properly in the final CD. Start your local workstation with startx -listen_tcp You can then use xauth on both sides the local workstation side and the freesbie jail, to allow the freesbie jail X11 clients to talk to your local workstation X11 server. It is not pretty but it works. xauth list take the local one on :0, take the MIT-MAGIC_COOKIE-1 paste into the freesbie xauth "xauth add . hexcodes" on the freesbie jail do export DISPLAY=workstation_ip:0 xterm & You will now have a freesbie xterm running in the jail displayed on your local workstation. You can then proceed to test X11 programs before burning your CD. 4. You can also just run in a chroot, it runs just fine this way This is considerably simpler than running as a jail if you don't need to run up any X apps. I found the jail useful for tracking down X bugs but most of the time, chroot is fine. chroot /usr/local/freesbie-fs /bin/sh a) It makes it very easy to check for missing dependencies, just ldd -a your binaries and look for undefined. b) You can copy an externally generated package into the chroot /tmp and install this package under the chroot. Of course this goes for removing packages. In fact, once you have a rough image set up this is a very fast way of cleaning up the rough edges or adding a missing package. 5. As I mentioned in gotchas, I had a memfs for /usr/local/etc that was too small. As it happened, the xinitrc needed for xfce4 was in that directory causing my CD not to boot into X11. I increased the memfs size for /usr/local/etc, but you may also want to decrease some of the other memfs to compensate as I did. My /etc memfs was way too large, so I trimmed that down. Here is what I ended up with on my testbox: Filesystem Size Used Avail Capacity Mounted on /dev/iso9660/FreeSBIE 709M 709M 0B 100% / devfs 1.0k 1.0k 0B 100% /dev /dev/md0.uzip 2.2G 1.9G 128M 94% /usr /dev/md1 9.9M 2.0M 7.1M 22% /etc /dev/md2 15M 12M 1.8M 87% /usr/local/etc /dev/md3 30M 12M 16M 43% /usr/home /dev/md4 4.8M 14k 4.4M 0% /root /dev/md5 32M 19M 11M 64% /var /dev/md6 20M 16k 18M 0% /tmp /dev/ad0s1 40G 9.0G 31G 23% /mnt/ntfs.1 .../freesbie2/extra/etcmfs/etcmfs.rc name="etcmfs" etcsize="10m" localetcsize="15m" .../freesbie2/extra/rootmfs/rootmfs.rc . /etc/rc.subr name="rootmfs" rootsize="5m" 14k is just rattling around in 5m I suggest leaving /var and /tmp alone. 7. Last document I suggested disabling sshd to protect against root logins. As pointed out on #pcbsd (forgot who, remind me?) sshd will not allow root logins anywa, so this one was moot. ============= - Diane VA3DB