Note: This article is part of my Testing stuff with QEMU series.
From the Debian GNU/kFreeBSD port page:
Debian GNU/kFreeBSD is a port that consists of GNU userland using the GNU C library on top of FreeBSD's kernel, coupled with the regular Debian package set.
Q: Why would anybody want to do that?
A: Why not? [1]
So, after we have talked about that, let's start:
apt-get install qemu
wget http://glibc-bsd.alioth.debian.org/install-cd/kfreebsd-i386/20070313/debian-20070313-kfreebsd-i386-install.iso
qemu-img create -f qcow2 qemu_kfreebsd_i386.img 5G
qemu -boot d -cdrom debian-20070313-kfreebsd-i386-install.iso -hda qemu_kfreebsd_i386.img
ALT-F3. Do it.
At the end you must select "No" as you're told to do, then reboot via "Exit Install". You can then shutdown QEMU.
qemu -hda qemu_kfreebsd_i386.img
passwd
nano /etc/network/interfaces/etc/init.d/networking restartapt-get update && apt-get dist-upgradeapt-get install vim xorg icewm xterm
apt-get install kbdcontrol
adduser uwevi /etc/X11/xorg.conf
Section "InputDevice"
Option "Device" "/dev/psm0"
Option "Protocol" "PS/2"
[...]
Section "Device"
Driver "vesa"
startx
Wasn't all that hard, eh? Now, if you've got some spare time, head over to the Debian GNU/kFreeBSD wiki page and help improving this port ;-) You should probably start with reading the PORTING guide.
Both kfrebsd-i386 and kfreebsd-amd64 seem to be reasonably stable already (and more than 70% of the whole Debian archive builds fine on these architectures, see kfreebsd-i386_stats and kfreebsd-amd64_stats). I'll quite likely install kfreebsd-amd64 on one of my boxes soonish and start using it, maybe I'll even find some time to fix/patch/port some packages...
[1] More elaborate answer(s) and reasons are available in the Debian wiki.
Update: "Testing stuff with QEMU"-articles published so far:
Here's a quick HOWTO to get you started with the QEMU emulator, the Debian installer (etch beta 3), and SELinux. If you execute the following steps you'll be left with an SELinux-enabled Debian unstable QEMU image, but not with a complete working and perfectly configured SELinux system. A more detailed article about SELinux will probably follow...
Basic Debian unstable install in QEMU:
apt-get install qemu
wget http://cdimage.debian.org/cdimage/etch_di_beta3/i386/iso-cd/debian-testing-i386-binary-1.iso
qemu-img create -f qcow /path/to/debian.img 5000M
qemu -hda /path/to/debian.img -boot d -cdrom debian-testing-i386-binary-1.iso
/etc/apt/sources.list if needed, and then dist-upgrade to the latest stuff:apt-get update && apt-get dist-upgrade
halt" in the emulated Debian, wait for the shutdown to complete, press CTRL+ALT+2 to switch to the QEMU console, and type "quit").
Creating a QEMU overlay image:
QEMU has a nice feature called overlay images which allows you to "clone" an image, where the new (overlay) image will only store the "diffs" to the original one, thus saving lots of space. This also allows you to remove the overlay image at any time and restart from the original image (which is nice for testing stuff which may break).
qemu-img create -b /path/to/debian.img -f qcow /path/to/debian_selinux_overlay.img
qemu -hda /path/to/debian_selinux_overlay.img
Basic SELinux setup:
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_SECURITY=y
Luckily the Debian kernels are xattr-enabled by default so we don't have to do anything at all here.
apt-get install checkpolicy policycoreutils selinux-policy-refpolicy-src
setfiles utility is in the wrong place, see #384850), but there's a simple workaround:ln -s /sbin/setfiles /usr/sbin/setfiles
cd /etc/selinux/refpolicy/src/policymake relabelln -s /etc/selinux/refpolicy/src /etc/selinux/targeted
selinux=1 to enable SELinux in the kernel (press "e" to edit the boot options).
sestatus", which should print some information on the running SELinux system. If it says "SELinux status: disabled" something went wrong.
Congratulations! You now have a QEMU image with minimal SELinux support and you can start playing with it, tweaking the policy, finding and reporting bugs, reading tons of documentation on how SELinux actually works etc. etc.
As SELinux is (half?) a release-goal for Debian etch, it would be nice if many people could test it before the release, and this is one method to do so without breaking your production systems.
Update 2006-08-28: You don't really need user_xattr support for SELinux, only xattr support (for security.selinux xattrs) for the filesystem you use, which is available per default in Debian kernels (thanks Russell Coker).
This is what happens to you, if you try to perform too many code changes at once. It's usually better to perform small, incremental changes and run your unit tests (hopefully many) after each of them to check if you messed up.
I don't want to even think about cases where you don't have any test cases at all. In such a case, debugging nightmares are preassigned.
I'm currently involved in multiple Ruby projects where I make extensive use of unit testing. Ruby ships with a built-in, easy to use unit testing library called Test::Unit, so you really don't have any excuse for not unit testing your code.
Recent comments
21 weeks 4 hours ago
47 weeks 1 day ago
1 year 2 weeks ago
1 year 3 weeks ago
1 year 3 weeks ago