Luckily, I was able to figure a way out of the iptables compilation error on Step 7.
The error I was getting indeed was related to libdl.so. To fix it, I removed the /lib/libdl-2.3.2.so file, ran ldconfig, went back to the kernel source tree, ran `make; make modules_install` (I did not clean the kernel tree, running a simple make was enough, as a matter of fact it might not even be necessary), finally, went back to the iptables source tree cleaned it, ran ./configure and compiled it again.
Now, when I look back, I’m pretty sure I may have messed up on the step to fix links to /lib/libdl.so, as shown towards the end of Step 6. The gotcha is that if you find yourself with libdl.so linking errors in iptables compilation, not only you need to fix the library links, but also go into the kernel tree and do a quick make and make modules_install, only then you can get back to the iptables compilation.
With iptables out of the way, I was able to move foward into xtables compilation. In xtables-addons compilation I faced the following error:
root@zeroshell extensions> make
Xtables-addons 1.32 - Linux 188.8.131.52
if [ -n "/lib/modules/184.108.40.206/build" ]; then make -C /lib/modules/220.127.116.11/build M=/DB/hdb/xtables-addons-1.32/extensions modules; fi;
make: Entering directory `/DB/hdb/usr/src/linux-18.104.22.168'
Building modules, stage 2.
MODPOST 37 modules
make: Leaving directory `/DB/hdb/usr/src/linux-22.214.171.124'
make -f ../Makefile.iptrules all;
make: Entering directory `/DB/hdb/xtables-addons-1.32/extensions'
In file included from /usr/local/include/xtables.h:16,
../include/linux/netfilter.h:53: error: parse error before "__be32"
../include/linux/netfilter.h:57: error: parse error before '}' token
make: *** [libxt_CHAOS.oo] Error 1
make: Leaving directory `/DB/hdb/xtables-addons-1.32/extensions'
make: *** [user-all-local] Error 2
I was able to find that, for whatever reason, the “__be32” type definition is not available at /usr/include/linux/types.h. I don’t know why is that, but when looking at the types.h file at the 126.96.36.199 source tree, the “__be32” type definition is there. So I edited /DB/hdb/xtables-addons-1.32/extensions/Makefile and appended a -I option to the libxtables_CFLAGS variable around line 163. Here is how it should look like once edited:
libxtables_CFLAGS = -I/usr/local/include -I/lib/modules/188.8.131.52/build/include
That forces the compilation to use the types.h that came with the new kernel instead of the other one, already available at /usr/include/. Note that this workaround makes gcc complain about the usage of kernel headers to compile a user space binary. These warnings seem to be harmless, and, when I looked over the reference the warning points to at kernelnewbies.org (http://kernelnewbies.org/KernelHeaders), it does not seem all that alarming.
Onto Step 11, when creating the cdrom.iso file with mkisofs, it bails out complaining about duplicated indexes for the rr_moved directory, that was an easy fix, and all I had to do is to remove the /DB/hdb/sz-roots/rr_moved directory before running mkisofs (that directory seems to be created automatically by mkisofs, that is why it can’t be there in the first place). This rr_moved directory got copied from the original /cdrom directory in the beginning of Step 9.
Well, after going through these, all other steps rolled out just fine with a few tweaks here and there, like cd’ing into the correct directory and such.
Now I’m running a neat version of ZeroShell with 184.108.40.206 kernel and as a byproduct I have my own development environment to adventure myself in customizing ZeroShell even more. Note that for anyone trying out rda’s instructions, please follow then through as they are documented, only if you run into the same issues described above you should try to work around or fix them, with luck you won’t even run into any of them.
Thanks rda for creating this outstanding material and thanks Fulvio for creating ZeroShell!