A running description of activity related to DragonFly BSD.
It’s possible to have data corrupted on a HAMMER2 volume during a specific combination of a bulkfree operation and a lot of writing to disk. Matthew Dillon has a potential fix already. As he announced, it’s scheduled to go into 5.4 this weekend. It’s a rare bug, but if you want to check for it, look for CHECK FAIL entries in /var/log/messages.
And because every cloud has a silver lining: some not-yet-quantified performance improvements.
top(1) is no longer in DragonFly contrib/ directory, for a number of reasons. It’s still present in the system, of course, and I think needs to have someone re-add as a vendor branch – a relatively easy project for a volunteer, hint hint.
There’s some code changes for callout, where the actual lines of code that trigger it are stored in the callout structure. It’s a little thing, but it’s a big thing if you need it.
GCC 5.0 is no longer needed in DragonFly, so it’s not being built, and can be removed on your next ‘make upgrade’. As a bonus, buildworld is a little faster.
Thanks to Aaron LI, you can now (actually, since December) run ifconfig without involuntarily loading associated kernel modules, with the -n option. See his commit message for an example.
I’m finally cleaning out some things I never got to post when new: last October, the DragonFly installer gained the ability to ask for terminal type, when used over a serial cable. Thanks to Diederik de Groot for that one.
(A rare combination… but when you need it, you won’t have an alternative.)
A little thing: Matthew Dillon has made changes to vm_page_list_find2() which should improve performance in low-memory situations, though how much I don’t know. Mentioning it, cause every little bit helps – for knowledge and speed.
Because someone decided years and years ago that the CAM structures should be passed through to userland, smartctl, camcontrol, cdrecord, and some other tools will be broken in DragonFly-master for a few days. If you are on -stable (5.4) this won’t affect you.
Sepherosa Ziehau’s improvements to re(4), bringing it to Realtek’s 1.95 release, have been committed.
(Does Realtek have a public repo for this? A few minutes of Googling did not turn one up for me.)
If you were having trouble booting a DragonFly installer – or rather, you could boot but never find a disk to install on, this commit adding support for Sunrise Point, Lewisburg, Union Point, and Cavium ThunderX chipsets may fix your issue.
If you have a lot of RAM on your DragonFly system, there’s a patch that you may find useful. If you weren’t able to install that system, well, there’s another potential fix out there.
If you’d like to set a particular sysctl(8), you enter it into /etc/sysctl.conf. A common mistake is to copy the command line and put “sysctl foo=bar” in sysctl.conf instead of “foo=bar”. This used to cause a warning, but it still bit people, as it would cause a long stream of error messages during boot – with no clear reason, as the kernel tried to understand the command. Now, that typo is handled automatically.
I usually get all happy when I see sharing happen across BSDs, and note it here. Here’s an unexpected one: between DragonFly and Haiku.
As planned, there will be a 5.4. 1 release for DragonFly. Matthew Dillon’s work on HAMMER2 will be in there, as will be a fix for keyboard attachment and updates from Aaron LI on dhcpcd support. I will tag and build this weekend, so it’ll be just in time for Christmas.
I didn’t get a chance to mention this before release: script(1) has had a refresh, now sharing more options with the FreeBSD version. The update is in DragonFly-master and in the 5.4 release.
If you happen to have a Intel Centrino advanced 6035 wireless card, it now works on DragonFly, thanks to Tobias Heilig.
Bear with me; this is the history: wpa_supplicant is the program DragonFly uses to connect to most wireless networks. It’s been part of the base system for some time, but if you start it up, you will see a warning (at boot time) about how this version is deprecated. Installing from dports puts a newer version in place.
As is the case with most third-party include in any operating system’s base, there’s always lag between the newest version of software and what’s been included in. Dependencies creep in, or it’s duplicated work between packaging and basic OS maintenance, etc. (Who here used Perl on FreeBSD 4? That was frustrating, but a good example here.) Anyway, the dilemma is that since wpa_supplicant is a program that may be required in order to get online, it must be in the base install. However, since it has / had vulnerabilities, it must be updated. The base install doesn’t update as fast as the origin of the software, and there’s the mismatch.
All that’s a long explanation as to why network/wpa_supplicant is now on the DragonFly install CD, and gets automatically used if installed. Thanks for Aaron LI and Matthew Dillon for making it happen. The base package is still there, in case someone deletes their installed ports and needs to get online before they can reinstall. This is in master now and will be in the 5.4 release.
I tagged the first release candidate for DragonFly 5.4 last night. The commit message has summary lines from all the commits in this release, if you want to go through them – or wait for the release notes. I’m happy to see some new-to-me committer names in there, too.