Matthew Dillon reports changes to the kernel configuration file are needed now.Â Also, if you are running bleeding-edge code, a full buildworld/buildkernel is required on the next upgrade.
Branching for 1.8 will happen very soon; as soon as ACPI is ready.Â The release date has not slipped.
Simon ‘corecode’ Schubert had some trouble with the changed src layout while working on gcc 4.1.Â Matthew Dillon is changing it back, Wednesday.Â (So no commits on Wednesday, please.)Â This naming issue is apparently not new.
Matthew Dillon is renaming some I/O calls.Â It shouldn’t cause major problems, but as always, make sure to do a complete buildworld/buildkernel when next upgrading your bleeding-edge system.
Matthew Dillon is making trapframe changes – it will require a complete buildworld if you are following bleeding edge code.Â Read his post for more details.
TLS system calls are being renamed by Matthew Dillon.Â If you’re running HEAD (bleeding edge code), this will require both a kernel and world rebuild on your next update.
Matthew Dillon is performing some significant cleanup of the kernel startup/VM code, so watch out if you are using the bleeding edge code.Â He synced Preview before starting, so Preview users can move to the code version just before this (potentially) destabilizing code.
Matthew Dillon is renaming a number of functions and types (update) to remove some conflicts.
Matthew Dillon reported that DragonFly Preview code (version 1.7) have been synchronized with the bleeding-edge code, as it’s been stable.Â Also, the 1.8 release is definitely scheduled for January, at which point he plans to have “at least a basic userland kernel binary”.
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.
DragonFly 1.6.2 is released, along with 1.4.5, to include the recent changes that had been merged back to the branches.Â Simon ‘corecode’ Schubert moved the release up, and a changelog is available for 1.4 and 1.6.Â (changelogs are in forward chronological order, so skim down.)
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.
Due to the solving of a nasty locking problem, 1.6.1 is 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.
DragonFly 1.6 is released, (see announcement) with highlights including:
- 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.
Simon ‘corecode’ Schubert’s vinum changes were recently committed by Matthew Dillon.Â Simon follows up with a warning: ABI compatibility is broken by this, so vinum will have to be recompiled, if you are using it.
The 1.6 release is pushed back to next weekend, instead of this week as originally intended.
leaf.dragonflybsd.org’s drive was killed by a power outage. Matthew Dillon worked on restoring it yesterday, and it’s mostly back. If you had an account there, please check in and make sure your files are at least somewhat intact.
As a side effect, incremental backups are now possible with cpdup.
As predicted, the Preview tag has been synced with HEAD, meaning all recent changes are now available. Now’s a good time to update if you’re not on Release (1.4.4).Â Because of ABI changes, there’s a specific procedure one should follow.
If you’re running a development version of DragonFly; namely 1.5.3, it’s time to update to 1.5.4.Â Be careful, as your kernel has to be updated first.
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.
With some final changes, version 1.4.4 is available now. This is the recommended download/update for everyone. (Including me, so I’ll have to update tonight.)
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.”
Seen on tech-pkg, the pkgsrc mailing list: the pkgsrc version of Mozilla will, due to a temporary restriction, build without the Mozilla name and logo unless manually set to do so. A recent email copied to tech-pkg@ explains why and how it will be fixed soon.
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.
Matthew Dillon has added the new parallel routing code; expect some destabilization if you are running bleeding-edge code. His near-term plans are also posted, which include a start on the Cache Coherency Management System, and preliminary work to support ZFS.
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.
Matthew Dillon has committed a number of bug fixes back to Preview, and will bring them into 1.2 Release this weekend.
leaf.dragonflybsd.org will be out again, 9-10 PDT tonight.
dragonflybsd.org may be down at times this weekend, as Matthew Dillon is adding/moving a whole lot of hardware.
Update: There’s downtime tonight, starting 9 PM PDT. If you have data on leaf:/unused3, it’ll be gone.
The next release of DragonFly (1.4) will include pkgsrc, as Matthew Dillon described in a recent post. For those of us with 1.2 systems, some work is being done to create binary packages now, to ease the transition. The Wiki has some documentation on using pkgsrc.
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.
Joerg Sonnenberger posted two alerts: the first is that pam.d now replaces pam.conf, and that he’s mangling the ABI in HEAD (bleeding edge code) over the next few days in preparation for moving what’s in HEAD to PREVIEW (moderately stable code).
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.
Joerg Sonnenberger is changing errno to a thread-local variable this weekend, which means for those running the latest DragonFly code (i.e. from CVS, not 1.2.1), you will need to rebuild everything. That includes ports, and drastic changes like this will happen again.
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.
dragonflybsd.org’s T1 has been having some problems. It’s currently working, but there may be more outages today.
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.
The CVS tag for the next release, “DragonFly_RELEASE_1_2″ has been placed, which means commits are OK again.
There is a prerelease version of 1.2 on gobsd.com via HTTP or FTP, and also at pfsense.com via HTTP. Here’s the MD5:
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!.
Sascha Wildner saw that ‘make quickworld’ seems to be broken.
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 has seen some problems on his test machines for DragonFly_Stable, so he’s pushing the tag back to the Sept. 13th point, for reasons he detailed in a separate message. Make sure to be using this if you have a production machine.
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.
Matthew Dillon warned that the namecache work (stage 6 is committed) may destabilize the system somewhat while it is in flux; crashes may happen, though data should be generally safe. Use the DragonFly_Stable tag in your supfile if this is a problem and you’d like to upgrade…
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.