phaqphaq

It has been some time now since development on Debian GNU/kFreeBSD started, which aims at bringing together the FreeBSD kernel with a GNU userland.

There exists a similar implementation called Gentoo GNU/kFreeBSD, although I had no time yet to review it.

The Debian developers made some notable progress since last year, but there are still lots of issues. Check out the project website for further details.

Now let’s look at an abscure idea, that struck me when I first looked at Debian GNU/kFreeBSD last spring.

Why not try to run Debian GNU/kFreeBSD inside a native FreeBSD jail (or inside a Debian GNU/kFreeBSD jail)?

One might argue where’s the point in doing so. But under that premise I could also ask, what’s the point then in having hundreds of Linux distros which basically do the same thing — only in a different way?

Let’s imagine the possibilities:

• Run native GNU/kFreeBSD hosts with both GNU/kFreeBSD and native FreeBSD userland jails
• Run native FreeBSD hosts with both GNU/kFreeBSD and native FreeBSD userland jails

If you’re familiar with the concepts of OpenVZ/Virtuozzo or the Linux VServer project, you’ll see some similarities and maybe even the reason for trying out this weird idea.

I must admit, that the current implementation is far away from production grade. There’s a lot of dirty handwork involved. Aparently there is no point in trying to streamline the process right now, since GNU/kFreebSD is still under heavy development. Automated setups should be easy to implement as soon as the Debian Installer is ported and package support is fixed in debootstrap.

Are you ready to read on? Ok, let’s go to work then…

(more…)

After I had finally found a solution to my 13W3-VGA adapter issue the time is ready to install Debian onto the machine.

There are lots of howtos out there which cover netinstalling Debian/mips onto an SGI machine, hence most of them predate the official Debian/mips manual.

One caveat is the fact the manual was written for a bootstrap server running Linux in mind (have a look at section 4.3.2 Enabling the TFTP Server).

Since my bootstrap server is running FreeBSD a slight variation of the steps as lined out in section 4.3.2 is needed.

Path MTU discovery is disabled like this:

#sysctl net.inet.tcp.path_mtu_discovery=0

To further restrict source ports for TFTP to stay below 32767 as required by most elder SGI PROM versions these additional commands must be run:

#sysctl net.inet.ip.portrange.first=2048
#sysctl net.inet.ip.portrange.last=32767

This will effectively allow bootstrapping the Debian/mips netinst image from a FreeBSD host.

Well, sometimes obvious things aren’t quiet as obvious as supposed.

After plugging in a dual Intel Pro 1000 into my Debian box and hooking it up to my ancient Cisco 1924 switch, I noticed this in the kernel logs:

Jul 31 09:10:35 localhost kernel: e1000: eth0: e1000_watchdog: NIC Link is Up 100 Mbps Half Duplex

I though it should be fairly easy set the interface speeds properly so the devices would actually talk to each other.

While doing so on the Cisco was actually easy, the Linux box would refrain from doing so at a first glance.

#ethtool -s eth0 speed 100 duplex full

Running the command given above resulted in an error preventing me to set the parameters. It took me a while to find out that I had to actually turn off auto negotiation to make it work, too.

#ethtool -s eth0 speed 100 duplex full autoneg off

Now I had to make this change permanent as it would reset to defaults after the next reboot. I did so by adding the post-up line to my /etc/network/interfaces file:

auto eth0
iface eth0 inet static
post-up /usr/sbin/ethtool -s eth0 speed 100 duplex full autoneg off
address 192.168.0.100
netmask 255.255.255.0
gateway 192.168.0.1

It should be noted, that the module documention at Intel’s website does not actually state that auto-negotiation must be turned off when setting interface speed and duplex modes. The question remains if this was only the case on my particular setup or if it is an absolute requirement after all.