V4-mapped addresses out, TCP MTU discovery in

Sepherosa Ziehau has posted a note that V4-mapped addressing is no longer supported in DragonFly.  You will need to do a full buildworld/buildkernel if you are running master.  Also, TCP MTU path discovery is on by default.  Also also, he’s added a SOL_SOCKET/SO_CPUINT socket option for use to reduce load in heavy network activity.  As usual, I don’t quite comprehend.

DragonFly 4.0 released!

The 4.0 release of DragonFly is out!  Quoting from the release page:

Version 4 of DragonFly brings Haswell graphics support, 3D acceleration, and improved performance in extremely high-traffic networks. DragonFly now supports up to 256 CPUs, Haswell graphics (i915), concurrent pf operation, and a variety of other devices.

The more eagle-eyed downloader will notice it’s version 4.0.1, not 4.0.0.  That’s because nobody trusts .0 releases I tagged 4.0.0 just before a few useful commits went in, and it’s better to retag to make sure everyone got them.  See also my message to kernel@/users@

Bash vulnerability; check your dports

There’s a new bash vulnerability that could be a problem for a network-facing machine that happens to use bash.  (See here for test.)  As a BSD user, you can feel somewhat smugly superior since the default shell is tcsh and therefore it may not affect you – unless you’ve installed it from dports.

John Marino has already updated dports.  A new binary is forthcoming, though you can always rebuild by hand if you don’t want to wait.

Update: oh, wait, not done.

New kernel and new target

You should perform a full world and kernel install if on master.

Several people (including me) have been getting bit by a problem: when performing an installworld with a changed kernel, the vn kernel module is loaded, but it was built by the previous kernel and may cause problems when it doesn’t match up.

To fix that, vn is now built in, instead of being a separate module.  The rescue initrd (which is what is being mounted when it has this problem) is now installed via a ‘make rescue‘ command that can wait until a successful installworld and reboot.

Heads up: changing mfi to mrsas

The mfi(4) driver has had some data corruption problems on “Thunderbird” series RAID controllers.  There’s a newer driver, mrsas(4), that replaces mfi(4) for these controllers and does not have these issues, but switching may mean new drive locations and therefore some work to get booting correctly again.  Sascha Wildner has an extensive writeup about what this entails, and how to switch now if you have that hardware (recommended).

DragonFly 3.6 to 3.8 upgrade note

If you are upgrading a DragonFly 3.6 system to 3.8, make sure you have the absolute latest version of 3.6 first.  A few people have had a crash during install of the new initrd, which leaves the system in an unbootable state.

There’s a fix now in 3.6 from Joris Giovannangeli, so updating 3.6 and then moving to 3.8 will ensure this doesn’t happen.  He posted a heads-up notice too.

(Why, yes, that is why shiningsilence.com was down for some hours today…  With Matthew Dillon and Sascha Wildner’s help, I was able to copy bits of /boot and /usr from a live CD back on disk and get online again.)

DragonFly 3.8 released

The 3.8 release of DragonFly is out!  See the release page for a changelog and check your local mirror for download first.

Binary dports packages for 3.8 have been built; they are available for download.  (link goes to release versions of the packages.  Future updates will be in ../LATEST)

For upgrades from 3.6: You can pull the 3.8 source normally with git:

cd /usr/src
git fetch origin
git branch DragonFly_RELEASE_3_8 origin/DragonFly_RELEASE_3_8
git checkout DragonFly_RELEASE_3_8

Assuming you are using an unmodified kernel, here’s the steps I usually do for an upgrade:

# make buildworld && make buildkernel && make installkernel && make installworld && make upgrade

After upgrading from 3.6, pkg (as designed) will download the appropriate 3.8 packages with pkg upgrade.

Open source opportunity right now

If ever there was a golden moment, this would be it: with the news that networking hardware from the US is suspect, as is China’s, the best networking setup seems to be one you can look at yourself.  Someone get those OpenCompute Networking machines going!  More port density!  Running BSD!

(Suggestions on how I can get a system with 24+ 1G ports are welcome; I need that at work immediately.)