Category: Heads Up!
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.
pkg 1.2 is coming out. This brings a number of new features, but as John Marino posted, you may want to delete your old pkg.conf to keep the new version from complaining about an old config file. This upgrade is a step on the way to signed packages, which is a Good Idea.
John Marino has put in a large patch to DragonFly 3.5, updating all sorts of language-related items. As he warns, you will need a full buildworld/buildkernel in a specific order to update. On the plus side, you can now probably use your native language for nvi and for git.
If you are running DragonFly 3.5, make sure you do a full buildworld depending on how recent your version is. Just a quickworld will cause problems. DragonFly 3.4.x users are unaffected.
It’s been 2 years since the pkgsrc packages for DragonFly 2.12/2.13 were getting updated, so I am going to remove them. If you’re running DragonFly 2.12, you’ll want to either build from source or upgrade DragonFly.
As posted in my email to users@: Version 3.4 of DragonFly is officially out.
The release ISO/IMG files are all available at the usual mirrors:
The release notes have details on all the changes:
If you are planning to try the new dports system for installing third-party software, check the DPorts Howto page:
If you have an installed DragonFly 3.2 system and you are looking to upgrade, these (not directly tested) steps should work, as root:
git fetch origin
git branch DragonFly_RELEASE_3_4 origin/DragonFly_RELEASE_3_4
git checkout DragonFly_RELEASE_3_4
… And then go through the normal buildworld/buildkernel process found in /usr/src/UPDATING. If you are running a generic kernel, that can be as simple as
make buildworld && make buildkernel && make installkernel && make installworld && make upgrade
(and then reboot)
If you encounter problems, please report them at bugs.dragonflybsd.org. I get better at testing for each release, but I also get better at discovering new problems just after release.
There’s an as-yet-undiagnosed problem with the @dragonflybsd.org mailing lists; you won’t see any mail from them right now. I don’t have an ETA for a fix because I don’t know the underlying cause yet…
Update: Fixed; I think – dragonflybsd.org DNS server was not responding, and it had a ripple effect.
If you’re running DragonFly 3.3, make sure you perform a full buildworld and buildkernel when you next upgrade. Sascha Wildner is mentioning this as a cautionary note after experiencing issues when using quickkernel, after removing a number of syscalls. Once past that point, it should be safe to go back to quickworld/quickkernel.
On the 10th of November, I’m going to remove the binary pkgsrc packages from mirror-master.dragonflybsd.org for DragonFly 2.8 through 2.11. They are closing in on 2 years old at this point, and are from a pkgsrc branch that hasn’t been updated for that long.
If you are actually using version of DragonFly that old, you can continue building from pkgsrc normally; these are just prebuilt packages.
I’ve written a release email that includes the steps for updating from source and updating pkgsrc for existing installs. This release enjoys better performance and new packages, so go, enjoy.
The pkgsrc packages for DragonFly 3.2 are still building… I’ve tagged the release, so it will be ready as soon as the packages are ready.
Remember the new scheduler work? Well, it continued, and now Francois Tigeot has posted pgbench benchmarks of the progress and benchmarks of DragonFly vs. other operating systems. The links are to PDFs; scroll down as each have multiple pages.
The summary result: If you’re running Postgres, you probably want to do it on DragonFly. The numbers are the best results for any BSD, even better to some extent than Linux, which has had its own issues with schedulers and Postgres. DragonFly 3.2 will include these improvements.
As I typed elsewhere, my general plan is to branch DragonFly 3.2 on the 8th, and release on the 22nd. That should give the recent scheduler and gcc work a chance to settle, and perhaps get a new version of USB support in too. It will probably be using pkgsrc-2012Q3, also, though we may not have binary i386 packages. 3.2 is shaping up to be a much more significant release than I expected.
According to Aleksej Saushev, pkgsrc is going to start defaulting to Postgres 9.1 instead of Postgres 8.4 by default, in just a few weeks. That means an upgrade in the next quarterly release, so keep that in mind.
The short version: MySQL, compiled a certain way, will allow 1 out of 256 root login attempts to work no matter what. I was going to link to this for the startlingly large number of MySQL installations found allowing connections from the public Internet, which means breaking into any affected servers would be easy. Then I thought about it… I don’t see a my.cnf installed by pkgsrc for at least MySQL 5.1 by default.
To fix this for your own installation, put
in /usr/pkg/etc/my.cnf to disallow remote connections. I don’t know if MySQL on DragonFly from pkgsrc is vulnerable to the issue, but it’s a good idea to not allow remote connections to the database, and ought to be on by default.
Or just use Postgres, if possible.
If you are running bleeding-edge DragonFly, libpthread was broken for a short period. If you built anything in the last … 12 hours? You may want to rebuild it. If that doesn’t describe you, it’s a nonevent.
It’s funny that I’m reporting a short-term break in bleeding-edge operating system code as any sort of surprise. It shows something about how stable DragonFly-master is most of the time.
There’s a Day Against DRM sale going on for O’Reilly. 50% off everything, and all the books are DRM-free. I found out about this through Michael Lucas, whose No Starch books are represented there too. It’s a fantastic deal and it’s today only, so strike now while you have the chance.
(I should make a ‘buy buy buy!’ tag for articles.)
If you’re running bleeding-edge DragonFly (meaning version 3.1), you will need to do a full buildworld on your next update. ‘make quickworld’ will appear to succeed but the kernel won’t work.
If you’re running DragonFly 3.0.x, this does not affect you.
Matthias Schmidt found a discussion about DragonFly’s password encryption. The result, if I am reading it correctly, is that brute-forcing the password from available hashes is quicker than it should be. Matthias also found a contributed fix. Samuel Greear updated to match the reference SHA implementation also in Linux, with this very pertinent warning.
The answer is “not very”. As I wrote in a post to kernel@, DragonFly 3.0 will be tagged soon, and released when there’s pkgsrc-2011Q4 packages to go with it. Probably a week if everything goes to plan.
The presence of /usr/include/crypt.h in DragonFly (starting in December 2010) meant that some programs compiled during that time will expect that file to always be there. It was recently removed, so any programs compiled in that timeframe will also need to be recompiled. Right now, this affects you only if you are running DragonFly 2.13 , since that’s the only place crypt.h was removed. This may be an issue for the release, but we’ll worry about that when we get there… I’m kicking off new 2.13 bulk builds now.
There’s a rare crash in DragonFly 2.10, where applications would segfault. The system would run find. This is apparently more likely to happen in 2.12, though reports on this vary. It’s real, though.
Matthew Dillon went looking for this bug, and happened to roll back vm_token, the last lock in DragonFly that presented a serious impediment to multiprocessing. It’s a big patch. It fixes the problem, which is great! It also happens to make DragonFly buildworlds almost twice as fast depending on the number of cores in the system.
Holy crap we want to get that out… but it makes some significant changes to the system and needs to be tested. So, the next release probably won’t be for a few weeks.
If you want to help, build master and do something with it – move data, run server programs, whatever. Report crashes. This performance improvement is worth working for.
Some ISA devices have been removed from DragonFly. That probably affects approximately 0% of everyone, cause they’re old devices, but a few of them
are were in the GENERIC kernel configs, so you’ll get an error for an unrecognized option when you next rebuild your kernel using a GENERIC-based config, based on an older version of GENERIC. The description of which drivers went is quite sensibly placed in UPDATING.
If you’re running 64-bit DragonFly, and you’re on version 2.11, you will want to rebuild with the latest sources. Peter Avalos found a bug with file descriptor passing, and Venkatesh Srinivas fixed it. It will require a quickworld/kernel build – maybe a full buildworld and kernel? I’m not sure. Some pkgsrc packages might need recompilation, too if they also passed file descriptors around.
17 different ISA device drivers have been removed by Sascha Wildner. The commit message has device descriptions. This may mean you need to change your kernel configuration file on the next buildkernel, since some of them were in the GENERIC kernel. If you need any of them, speak up. (I don’t think I’ve ever used any of them. Oh darn.)
If you are a Summer of Code student or mentor, make sure you’ve filled out your midterm survey. Without it, your project fails – and they are due for everyone in roughly the next 24 hours!
The SMP option is now in the GENERIC kernel config. This means you’ll have a SMP-capable kernel even on an uniprocessor machine, unless you configure a special kernel.
Also, Matthew Dillon has made version 6 the default version of Hammer in DragonFly 2.9. Version 6 has improved handling of directory names in some circumstances. Just don’t ask me which, cause I lost track. It’s been a hard day!
The mentor signup page for Google Summer of Code 2011 as of this writing still says “We have temporarily disabled the creation of new requests and invites in preparation of the launch of the new UI for Melange later this week.”, as it has said since the 20th.
So, if you’re wanting to mentor, keep an eye on it. I’ll send mentor requests to any of the names on my list of people that have already expressed interest, if I get to a working version of the page before you do…
A full buildworld/buildkernel is probably the best strategy. I’ll be rebuilding all the pkgsrc packages for 2.9 using gcc 4.4… This will take at least a week.
avalon.dragonflybsd.org, also known as mirror-master.dragonflybsd.org, is back up at a new location, with new disks and new connectivity. pkg_radd should work by default again, as should git.dragonflybsd.org.
Avalon, the machine that works as the master mirror site for DragonFly, and also as git.dragonflybsd.org, is being moved. Binary package downloads and source updates won’t work in the meantime. If you can’t wait for the system to come back, change the settings for pkg_radd or in /usr/Makefile to point at a different host.
Bleeding-edge DragonFly may suffer some instability issues; Matthew Dillon is making scheduler changes to accomodate larger numbers of CPUs. On the other hand: yay, better performance!
The index page of the DragonFly site has been updated by Matt Dillon with some notes regarding the status of the 2.8 release. Among these, it is mentioned that the GUI image will be making a return for 2.8! There will be no DVD image this time, only an image suitable for writing to a disk, such as a usb stick.
DragonFly 2.8 (technically 2.8.1; see here for the .1 changes) is due to be released tomorrow. There should be at almost the same time pkgsrc 2010Q3 packages available. There will also be a LiveDVD for this release, too, though the window manager has changed.
Matt Dillon and Venkatesh Srinivas conspired to fix another nmalloc issue, which should resolve any remaining problems people were having with Firefox, and possibly other applications as well. Due to an oversight of sorts, all locking operations on nmalloc’s depot were ineffective, as if there were no locking at all. Curiously, it worked remarkably well considering such a large race condition was present.
Our mirror of the never-quite-official git repository for pkgsrc is being rebuilt, so it will be temporarily inaccessible. Matthew Dillon is working on building a new one directly from pkgsrc CVS, which will have a different link.
Update: It’s finished. Matthew Dillon’s posted a summary of the changes and what you need to update in order to use it.
A little work has snowballed into even more of the network systems in DragonFly being pulled apart in order to get rid of the Giant Lock. It may delay the 2.8 release by a week or two, but it’s already paying dividends, such as NFSv3 now performing at maximum physically possible speeds on gigabit Ethernet.
Full buildworlds again, as there’s more commits that make it necessary. If you’re running 2.7, you should probably just plan on using buildworld, and not quickworld for rebuilding.
System data structures have changed again, so make sure your next rebuild is a full buildworld/buildkernel if you’re running 2.7. There’s been a lot of changes to pull more and more out from under the Giant Lock.
- If you are running DragonFly 2.7, Matthew Dillon has made some kernel changes, so updating your 2.7 machine will require a full buildworld cycle, not quickworld.
- The binary packages for 2.6 and 2.7 have been updated to pkgsrc-2010Q2. This means that pkg_radd will automatically pull down newer packages, and you should make sure your /usr/pkgsrc is using the pkgsrc-2010Q2 release if you want to be sure there’s no version mismatches.
I recently sent out a description of what built for pkgsrc-2010Q2 , though the section on not changing the stable link is no longer true.
Matthew Dillon posted a warning about both Samuel Greear’s kqueue work and Alex Hornung’s LVM2 work. Both are now committed to DragonFly 2.7. These are dramatic (and useful!) changes, so some instability may happen for bleeding-edge users. His post does include some minor detail on what was touched.
Alex Hornung has imported LVM2 from NetBSD, along with cryptsetup and dm. (Not dm(8), but devicemapper) LVM(8) stands for Logical Volume Management, and it makes storage management much easier; you may have encountered it on NetBSD or Linux. Those additional tools make it possible to encrypt volumes. Alex has published details on how to use it.
Also: Alex’s not-really-related-but-I -mistakenly-linked-to-it udev/libdevattr work.
Matthew Dillon set up a git copy of the pkgsrc repository some time ago. However, it’s had syncing problems, and there’s an ‘official’ pkgsrc git repository now which does not have the problems. You can still pull from the same place, but it’s the ‘master’ branch now. His heads-up message describes how to switch.
From my email to users@:
- I almost have pkgsrc-2010Q1 builds done for every architecture, so I’ll point the default load location for pkg_radd to them within the next 24 hours.
- Are you still using a DragonFly system older than 2.4 and downloading binaries? If so, tell me.
- A project: enhancing pkg_search and pkg_radd to be able to tell when a package is missing because of license restrictions. Anyone want to try it?
If you use Apache, as many people do, some of the default building choices have changed in pkgsrc. Read Matthias Scheler’s post for details.
The naming convention for the daily snapshots of DragonFly has changed, to make the file names more readable. This may lead to some confusion as the mirrors settle, but it’ll pan out. If you run a mirror, double-check your downloads.
We’ve got a third year in Summer of Code!
The timeline shows about a week and a half for planning, and then student applications begin on the 29th of March, and run to April 9th.
If you want to participate as a student, start planning now by talking with people on IRC (#dragonflybsd on EFNet) or on the mailing lists. You cannot be over-prepared.
Simon ‘corecode’ Schubert’s host for DragonFly, chlamydia.fs.ei.tum.de, is down for good. Since it had excellent bandwidth, it was frequently used as the source for a lot of the DragonFly mirror sites out there.
If you were using it for your own mirror, switch to mirror-master.dragonflybsd.org, and tell Matthew Dillon at @dragonflybsd.org your contact info so you can be notified of changes. (If you’re not mirroring, please download from the nearest site that is.)
The next release, 2.6, is scheduled for mid-March. Please make sure things are running well, as there’s a lot of new features already ready for this release.
Most of the dragonflybsd.org machines will be down for a short period Wednesday; this is for an upgrade that includes an SSD for the recent swapcache work. Everyone should notice a speedup, since while crater.dragonflybsd.org is getting the SSD/swapcache, a lot of crater’s directories are mounted on other machines via NFS.
Matthew Dillon is setting up DragonFly to be able to use a fast disk (like a SSD) for disk cache, reducing the effect swap has on speed. This means very large amounts of data could be read into memory – greater than the available RAM in the system – without having the normal paging out problems that happen when memory is exhausted. It’ll work for any filesystem on the machine – HAMMER, UFS, or NFS. His inital notes have more. Other notes include details on the NFS benefits, and possibilities with SSDs. Wear-leveling may make SSDs last much longer.
Work has started, and there’s an update (with examples) that people can try, though it may destroy all your data at this point. Test results in that update show, if I’m reading it right, a better than doubling of speed on a repeated md5 test on a large file when using the new caching system. This should be a huge benefit.
If you’re running DragonFly 2.5 and updated in the past week or so, and have UFS disks, there’s some instability introduced by Matthew Dillon’s recent work. It ought to be better by next week.
Users of Hammer, or of UFS only as /boot, don’t have anything to worry about.
This has been bouncing around other news outlets, but I’ll mention it here: There’s an out of data SpamAssassin rule that can potentially mark mail as spam because of the 2010 date. A mail to firstname.lastname@example.org describes the various fixes.
The step of ‘sa-update && /etc/rc.d/spamd restart’ seems to have fixed it for me. Incidentally, if you are using SpamAssassin, sa-update is a good tool to run on a regular basis.