A running description of activity related to DragonFly BSD.
If you are on DragonFly-master and you upgraded during select hours on the 25th of February, you may have been bit by a makefile error. The fix, as listed in that link, is simple:
cp /usr/src/share/mk/sys.mk /usr/share/mk
If you are not on -master or you did not upgrade in that timeframe: never mind.
Well, might rather than will , but I had to make a music reference. There’s a bug in versions of pkg from 1.4.6(ish) to 1.4.11 that can make it accidentally delete itself while updating packages. If this happens to you, there’s an easy fix, as posted to users@:
# cd /usr && make pkg-bootstrap
Once you’re on version 1.4.12+, you’re fine.
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.
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@
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.
If you are on DragonFly, using pf, using altq, and using fairq to control usage, there’s a latency bug that Matthew Dillon recently fixed. He’s posted an announcement and committed fixes to master and 3.8, so it’s only an upgrade away.
Because of some structure changes made by Matthew Dillon while chasing a pf bug, you will need to do a full buildworld/buildkernel on your next update – if you are running DragonFly-master. 3.8 users are unaffected by the bug or the change.
It seems pkg 1.3.6 was slightly scrambled. If you happen to have built and installed it, John Marino has special instructions on how to update to 1.3.7. If you are on DragonFly 3.8, you can follow those instructions now, and if you are on 3.9, that repo should be ready for an update in the next few days.
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.
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).
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.)
Sascha Wildner has removed some drivers in the x86_64 config. This will only really affect you if you use a custom kernel and still have entries for those drivers in the config file.
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.
NYCBUG is having a meeting tomorrow night with the theme “Cloud and Colocation“. However! Suspenders, the usual restaurant location, has closed. (Aw, I liked it) This meeting is happening at the About.com offices, which means you can’t just show up – send email if you plan to attend.
I’ve branched DragonFly 3.8, and tagged a release candidate. Please try the release candidate if you can. I have links in my post to users@/kernel@. Don’t forget the remaining issues! Planned release date is June 4th.
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.)
Sepherosa Ziehau has enabled GSI target CPU auto selection, by default, on x86_64. He says to let him know if there’s problems. I’m not sure what form the problems would take, cause I’m not sure what this does.
Here’s the announcement from Francois Tigeot: DragonFly now uses dynamic binaries in the root filesystem. You will need to do a full buildworld/buildkernel if on 3.7 and upgrading.
If you’re on DragonFly 3.7, you will need to build world before building the kernel again if you are updating to some point in the last 24 hours. Sascha Wildner points out the related commit.