ok... at http://www.samnjack.com/crux-amd64 is an iso + my build tree for amd64 arch. i've not tried to boot the iso... not in front of my 64 bit box at the moment. should work, but no promises yet. if it doesn't boot for you, let me know what happens & i'll try & fix it. the cd image has udev, not devfs, and i've never tested this with a bootable cdrom before. here's the README: *********************************************************************** This is a modified version of CRUX for x86_64. It was built with an amd64 machine, so I can't say whether it'll work on an intel 64-bit box or not. A few things to note: 1. for the most part, the ports are out of the current cvs, NOT 2.0 ports. we use gcc-3.4.3, glibc-2.3.4, linux-2.6.11 headers, and some other updated stuff. having said this, note that using the crux ports system (we can only use httpup here, no cvsup for x86_64 yet...) is not at all foolproof. i recommend downloading my ports.tar.gz, decompressing somewhere neutral (like /tmp), and copying the base & opt directories to /usr/ports/base64 and /usr/ports/opt64. if you use prt-get (i can't live without it), edit your prt-get.conf to put base64 and opt64 (and optionally contrib64 & unmaintained64 etc) before base & opt. 2. the kernel i use has 32bit emulation enabled, but i've not provided any 32bit libraries, and gcc is build w/out multilib enabled. you can use a 32-bit crux install & chroot to it to build static 32-bit binaries if you like. 3. /lib and /usr/lib are symlinks to /lib64 and /usr/lib64 respectively. you need to install the filesystem port first on a new install, then the rest of the stuff. reason is, the ports/packages themselves don't know the difference between the real /lib64 or /usr/lib64 and the symlinked /lib or /usr/lib. please remember this! 4. i'm using udev, not devfs. the devfs port isn't included. it will build, and it will install, and it will work if you edit the rc scripts. i just like udev better. bit of a pain, though. i've not included an updated handbook or anything. basically, before chrooting, but after installing packages, run: # mknod /mnt/dev/console c 5 1 # mount --bind /dev /mnt/dev then chroot. skip the part where you mount devfs. 5. with regards to building ports, often software that's not been updated for a while barfs in ./configure stage, complaining about the architecture. often this can be overcome by copying a newer config.sub and config.guess into the source directory. see the dhcpcd port, for an example. some stuff is a real pain to get working. some stuff works just fine. 6. anyone who can and want's to make this better, please feel free. i'm a bit too busy to be a real maintainer of this stuff. well, maybe a bit too lazy is more appropriate. for the most part, i just plug away on my own pc without too much thought about whether what i'm doing is right or proper in a distribution development sense. 7. glibc is built with linuxthreads. i personally needed that to run some software that doesn't play nice with nptl. nptl ought to be easy enough to put back in: just edit the glibc port, recompile everything, & voila! you can contact me at jeremy at samnjack dot com enjoy! jeremy