Matthew Dillon is making major changes to the namecache over the next 24 hours or so; watch out until it stabilizes.Â These changes should make nullfs mounting more memory-efficient, among other things, and lays a foundation for union or shadowing filesystems.
Category: Heads Up!
Matthew Dillon warns that he is doing some virtual kernel memory mapping work; it may destabilize the bleeding-edge of DragonFly.
dragonflybsd.org is going down 9AM – 1PM PST for power and UPS testing.
Matthew Dillon is starting some work that will possibly destabilize HEAD for a bit.Â The work involves vnode reference counting and locking.Â The advantage is that it will remove the hard locks that filesystems can experience, such as waiting for NFS mounts to time out.
Joerg Sonnenberger is temporarily taking packages.stura.uni-rostock.de down for disk reorganization; there’s a bulk build of pkgsrc packages running for 1.6. Most packages built for 1.4.4 will work with 1.6, in any case.
- even better pkgsrc integration, with over 93% of pkgsrc‘s 6,000+ packages building on DragonFly
- significant 802.11 improvements including ath(4) support
- clustering progress
- and many other changes.
- See the diary or the release page for exhaustive update detail.
ISO images and/or source updates are available from a number of mirrors, though I suggest the torrent.
DragonFly 1.6 has been branched in CVS, with the release happening at the end of the week.
As Matthew Dillon posted, SMP builds may be broken for the next few days, so rebuild with caution.
Matthew Dillon warned that he is committing a lot of work on multiprocessor support over the next few days; if you are one of the people who run bleeding-edge versions of DragonFly (1.5 from CVS, or ‘HEAD’), there will probably be some instability. It’s not called bleeding-edge for nothing…
wiki.dragonflybsd.org is down, along with gobsd.com.Â The wiki was on a separate server from the rest of dragonflybsd.org, so the rest of the domain is fine, but there’s currently no details on when the wiki will be running again, as the hosting company has apparently taken the server offline.
Matthew Dillon’s merged a heap of bugfixes from the current code back into the 1.4 release branch; the update to 1.4.4 won’t happen until Friday, however.
Matthew Dillon has moved the Preview release to 1.5.3, as it’s stable enough for more testing.Â In addition, Release is moving to 1.4.4 in about a week to incorporate recent fixes; details are in his post.
As Matthew Dillon and others have described, if you install the latest bleeding-edge code (1.5) of DragonFly, there is a bug in the installer. To keep from being bit, first log in as ‘root’ and type:
ln -s a /etc/malloc.conf
Then log out and log in as ‘installer’ and proceed normally.
The release version of DragonFly has been brought to 1.4.3 to incorporate the recent Sendmail security update, among other things.Â Bleeding edge code has been brought up to version 1.5.2, because Matthew Dillon has added (after the bump) his potentially destabilizing BUF/BIO code.Â If you like running Preview, update and plan to stick with it a while until this new technology gets sorted out.
My house was robbed today; I lost my desktop computer, among other things. Not surprisingly, posting here may be slow for a little while…
Matthew Dillon has issued a warning: HEAD (the bleeding edge code) is currently very stable. Update now, for it’s going to become pretty unstable soon. The base of the cache-coherency management system will be coming in, which he calls “probably the single most complex piece of code that is planned for DragonFly.”
Joerg Sonnenberger warns that libtool is in need of an update, and new packages should not be built until you have a version of libtool other than 1.5.22 installed.
Freshports.org is changing servers, so it may be intermittently unavailable over the next few days.
Joerg Sonnenberger found a slight problem with linking to gettext, which only can happen when building a pkgsrc package from source; binary users are unaffected. Details and a link to a workaround are in his message.
dragonflybsd.org will be down temporarily; I’m pasting Matthew Dillon’s mailing list message below as it’s silly to link to a message about downtime on the site that’s going down:
There was a lot of lightning last night and then a small explosion outside that sounded like the transformer on the telephone poll. Then the lights starts to flicker continuously and the UPS started clicking in and out and… well, I decided to shut everything down overnight :-)
There will probably be some more downtime tonight. I have a UPS monitor but I never hooked up the client/server feature that shuts down all related machines automatically if power isn’t restored in 20 minutes. I am going to get that working properly tonight.
Oh hell. Power just failed again. I’m gonna probably have to shut things down again soon :-(
Do you use wireless? Specifically, the iwi, ipw, wi, or ndis drivers? Do you need WPA encryption? You need Andrew Atrens’ large patch.
Simon ‘corecode’ Schubert plans to commit this patch before the next release if he can get at least one person using one of each of the drivers listed above to test. That means before December 15th, so time’s a-wasting! Andrew Atrens has already been using this patch in production.
Joerg Sonnenberger posted a warning for those running DragonFly 1.2 systems that plan to move to 1.4: the RC system is changing slightly, removing a keyword issue.
If you’re running the latest Development code, you will need to do a full build/install of world and kernel, because of a libc change. Matthew Dillon says so.
Matthew Dillon is moving the FreeBSD-based pkg binaries out of the regular location to make room for the pkgsrc version, which will be in the next release. That next release, by the way, is coming before the end of the year.
On a related note, Simon ‘corecode’ Schubert has proposed moving to rsync instead of cvsup to get updated code; cvsup works well but requires a lot of resources to build.
Chris Pressey found out the hard way that installing DragonFly and then FreeBSD can lead to DragonFly being wiped out by the FreeBSD installer.
There’s a whole lot of changes in the development branch (HEAD) of DragonFly. These are good changes, especially if you are a multiprocessor user, but HEAD users will shortly need to recompile everything – kernel, world, and ports/pkgsrc! Matthew Dillon lays it out in a recent post.
If you are running bleeding edge DragonFly code (HEAD), you will need to have COMPAT_DF12 in your kernel config file, unless you’re using the GENERIC kernel. This is because of the stat(2) work Joerg Sonnenberger plans to commit.
shiningsilence.com is moving tomorrow from one physical location to a new one – it’s just a few miles, but it means an outage. The domain will probably go down tonight when I package up hardware, and should hopefully return over the next few days as my new link is installed and DNS updates.
Hiten Pandya has warned that his recent changes will require a full buildworld/buildkernel. This affects you only if you are running bleeding edge code, of course.
Matthew Dillon sent out a large warning. Here’s a summation:
* The Preview tag has been slipped.
* All bug fixes made since 1.2.0 was released will be added to that release branch.
* Unless you want to deal with major breakage, stick with the 1.2.0 Release or the -WORKING code; the CURRENT code will have severe modifications going on, including libc revisions.
* Upgrading from FreeBSD-4.x will break! Updating to DragonFly 1.2.0 and then to a more recent version of DragonFly will be the only way.
Are you using the most recent DragonFly code from CVS? Matthew Dillon warns that the new red/black tree work may be causing file system problems. If this worries you, you should be running with a less dangerous tag in your cvsup file. (See his post for details.)
Matthew Dillon warned that a number of new, destabilizing technologies are going to be entering the bleeding edge DragonFly code, otherwise known as HEAD. Unless you enjoy trouble, the PREVIEW-tagged code (formerly known as STABLE) is a better target.
Correct tags to use in your CVSup files are named on the Download page.
MD5 (dfly-20050406-pre1.2.iso.gz) = 9b382c84e629b391bd4ce38c7ca724bd
If you can bear waiting, I would advise waiting for the official release later this week, just in case something is found in the next day or two.
Matthew Dillon announced the Stable tag will be slipped Sunday, with release engineering following until the next release, later this week! The only commits at this point should be bugfixes.
Stable has slipped.
If that doesn’t make sense to you, this means that the current “bleeding edge” code has been moved to “Stable” status, as there’s no outstanding problems with it. If you’re using the “DragonFly_Stable” tag in your CVSup file, you’ll have some new things to download.
leaf.dragonflybsd.org is apparently down or unreachable, at least from where I’m standing.
Update: Working, now – thanks, Hiten!.
Matthew Dillon issued this warning to folks with accounts on leaf: Due to an increase in automated ssh scans, he’s implemented a security policy that may lock you out if you goof up your login. Mail him if that does happen.
I’ve seen these same ssh scans with some frequency for at least a few months; these scans appear to be looking for poorly configured machines. Not a huge threat, but enough to warrant a closer eye.
So as to not conflict with other CVS repositories, the DragonFly repositories are going to change in name. Matt Dillon detailed it.
Matthew Dillon’s planning to synchonize the stable DragonFly code with the newest code, since there’s been so few problems lately. It’ll happen tomorrow!
Joerg Sonnenberger has placed gcc-3.4.3 into DragonFly; it is still considered experimental, so use it by setting the environment variable CCVER to ‘gcc34′ only after careful thought. His post has other details.
FreeBSD 4.11, the final release in the FreeBSD-4 series, is due around the end of January. The next official release of DragonFly will probably be out soon after, which makes a handy upgrade path if you are trying to avoid the FreeBSD-5 experience.
Joerg Sonnenberger warned that several drivers will be removed in the next two weeks from all flavors of DragonFly, including Stable, unless someone needs them:
- GPLed math emulator
- GPLed dgb driver
- GPLed awe driver
- old pre-newbus rp driver (use nrp instead)
- OLDCARD AKA pcic (also not built as module by default)
The Stable tag has been moved up to the most recent code, as some critical fixes required what’s in the most recent code. In general, this should only be positive, unless you are using unionfs or nullfs, as they will be broken if you upgrade. So, if you are using those file systems, hold off on upgrading for a few weeks. When you do upgrade, it has to be a full buildkernel/buildworld.
Matthew Dillon reported a hard disk failure knocked out the DragonFly website and mailing lists over the weekend; there’s a new disk, filled from backups, back in place now.
Matthew Dillon reported that he and David Rhodus have tracked down and eliminated a longstanding bug that caused VM/filesystem corruption, dating from FreeBSD 4, which may even still be present in FreeBSD 5.
As a side effect, Matthew Dillon’s VFS work will get pushed into the most current code (HEAD). Unionfs and nullfs work has not been completed in the VFS code, so that means if you use HEAD and also use unionfs/nullfs, either don’t update for the next week or so, or drop back to DragonFly_Stable.
Matthew Dillon posted about some changes to the way the mailing lists work; this is to avoid the ever-increasing spam that has been coming in. The short summary is that is you post through news, or use your subscribing address when posting mail, it should work normally. Otherwise, read his plan further.
Matthew Dillon wrote that the DragonFly_Stable tag is being moved up to the current code, as his potentially destabilizing VFS work is going to be going into the tree, starting tomorrow.
The moral: if you have production or near-production machines, stick with the stable tag, for now.
Joerg Sonnenberger warned that a full buildworld will be needed when next upgrading your system. You will also want to recompile any ports that use cam/libcam, like many CD-reading tools.
Joerg Sonnenberger has commited a whole pile of updates to various network drivers, among them axe(4). He warns that anyone with a axe(4) device should give it a whirl, as the driver is untested at this point.
MAtthew Dillon warned that the ongoing VFS work will make the use of buildkernel/installkernel absolutely necessary for kernel installation, for anyone using filesystems other than those built into the kernel.
Due to a typo, now fixed, in the disklabel man page, the Installer for DragonFly 1.0A used a too-large fragment size for disks larger than 1G. You may run out of inodes depending on the size of your disk and the number of files you have on it. Matthew Dillon suggested this temporary workaround when installing, until the Installer is changed.
Matthew Dillon noted that a full make buildworld/kernel and installworld/kernel is needed on the next update, due to a number of changes he has made.
If you haven’t updated recently to catch the scheduler changes, you may want to do this in any case.
forknibbler.com is down; that’s where I host builds of material that is in doc CVS. It’ll be up as soon as I can get to the physical location.
There’s a new image available that fixes the installer problem when installing to a partition that isn’t the last one on the disk.
Quoted from the download page:
IMPORTANT ERRATA ADDENDUM: Using the installer on a multi-slice disk will improperly resize the target slice when it is not the last slice, to be the same size as the last slice, leading to a corrupt disk! We will have an update to fix this problem in the next 24 hours!
Matt Dillon posted an announcement about 1.0RC1 last night on the kernel mailing list; it contins some important notes about ACPI.
A few people using Postfix for mail have reported system hangs at irregular intervals; Joerg Sonnenberger and Matt Dillon have been trying to track this down. Joerg posted these steps to take if you are so fortunate as to encounter this problem:
“Please try to provide the following for us for download:
- a tarball of your
/var/spool/postfix[if this doesn't contain private mail, save it and try to remove them as long as the problem persists]
- a crash dump of the system when it hangs and the kernel.debug, please test that ‘
gdb -k kernel.debug vmcore.X‘ actually works and gdb doesn’t crash.
- if you can easily reproduce the problem, compile
kern/kern_lockf.cwith -DLOCKF_DEBUG, use the ddb command ‘
w lf_print_ranges 1‘ to set the lockf debugging and give us the
I really want to fix this, but neither Matt nor I can reproduce this problem and the code is not obviously bad. There is some interaction going on, but the crash dump we had so far doesn’t work (see above about testing). It would be nice, if you can use bzip2 or gzip on all this data.”