Nov 122012

As the new slackware is out, I wanted to try a clean install on my rasperry-pis.
I referred to the super-detailed guide from dave (thanks!), but his build scripts needed just a little refreshing as upstream moved to a new firmware (boot changed slightly) and kernel version (ditching 3.1.9): more, they are committing on two kernel branches, one based on 3.2.27 (the default) and another based on 3.6.1.
So, at first I forked dave’s build script to build a 3.6.1 kernel, just to test, added some patches, rebuilt, and all went pretty well, but the installer wasn’t working.
Then I decided to go for the 3.2.27 branch, following upstream’s default: so I took the kernel config suggested by raspberrypi’s devs, added some modules to support various hardware, patched the kernel to support the BFQ I/O scheduler setting it as default.
The result are these new build scripts

and these premade packages/disk images

I’ll probably play with it a little in the next days to build a 3.6.1 kernel (and an installer with that) switching there too to a new .config with additions, but consider that times needed for building this stuff grows on the raspi, and running the complete build takes nearly 11 hours to complete.

Ah, while I was there I found some time to build a full LXDE, a Razor-qt/qtdesktop and other various packages for slackwarearm-14.0 using‘s scripts (I’ll try to organize this stuff as a repository soon)

Nov 022012

It has been some time since last post and many things happened: one of those is that I have been invited to work with the people at and I gladly accepted 🙂
Work there is really interesting and I feel like I’m learning a lot.

But the thing I felt most urgent, as I had chosen Slackware to host the services I administer at work and a new version of slackware is out, is to upgrade the lxc host and containers to slackware-14.0.

So I made some tests to adapt the procedure I described for slackware-13.37 (you might want to have a look at that too, mainly for the network setup) to the new version, trying at first to run a minimal slackware64-14.0 container on a slackware64-14.0 host.

I switched to slackpkg to install the packages in the container as I think, with just little modifications, it can be safely used as debootstrap is used on Debian: it also supports itself templates, so they can be used to install custom selections of packages (creating /etc/slackpkg/templates/mytemplate.template and passing the variable TEMPLATE=mytemplate to the lxc-create command).
So I patched it: here you can find the patched version for slackware and slackware64, and here is the one for slackwarearm.

I assembled a new template, placed it in my host filesystem as /usr/lib64/lxc/templates/lxc-slackware

cd /usr/lib64/lxc/templates
wget --no-check-certificate
mv lxc-slackware
chmod +x lxc-slackware

and installed my minimal slack with it

MIRROR= lxc-create -f /path_to/chuckd.config -n chuckd -t slackware
  • arch defaults to the host’s one. The template supports slackware{,64,arm} but this option makes sense only specifying arch=i486 on a x86_64 host to install a 32 bit container – only case possible/tested ATM
  • SUITE defaults to “14.0” (and it’s tested with that 😉 )
  • TEMPLATE defaults to “minimal-lxc” (in the previous article you can see the list of packages used)
  • MIRROR defaults to “” and points to a slackpkg mirror, the main tree, withouth the /slackware-$SUITE/ at the end.
    You can use also a local folder: supposing you have a mirror of the latest slackware64-14.0 in /my/path/slackware64-14.0 use MIRROR=cdrom://my/path. As this will be set as the default mirror in the container (during creation), in this case you surely have to edit it after (that path won’t be accessible by the container).
  • chuckd.config is the configuration file for the container (two examples are available in the previous article, depending on the chosen network setup)
  • chuckd is the name of the container
  • slackware is the linux flavour of the container

Then I edited /var/lib/lxc/chuckd/rootfs/etc/rc.d/rc.inet1.conf and /var/lib/lxc/chuckd/rootfs/etc/resolv.conf, the network configuration files of the container, with its network settings (IPADDR[0], NETMASK[0], GATEWAY and nameserver) and I started it with

screen -dmS init-chuckd /usr/bin/lxc-start -n chuckd

because launching it using a detached screen session leaves me an usable console (and I can reattach it, if needed).
And I happily connected to it through the network via ssh (or “lxc-console -n chuckd”) 🙂

While chatting with Alien Bob, he suggested me to try to install a full slackware on a lxc container, as a friend had tried it and got some problem logging in after.
I thought that happened because devices are defined outside of the containers and generally they don’t like manual adding or things like udev messing around, so I adapted the template also to disable an eventual /etc/rc.d/rc.udev and blacklisted the devs package (don’t install it in a container).
After that, I was able to install a full slackware64 in the container

slackpkg update
slackpkg install slackware64

While I was there, I tested also a remote connection through the nx protocol, installing freenx in the container with sbopkg

installpkg sbopkg-0.36.0-noarch-1_cng.tgz
sbopkg -r
sbopkg -i nx
sh /var/lib/sbopkg/SBo/14.0/network/freenx/
sbopkg -i freenx

and I connected to it from the host with nxclient.