Category: Heads Up!
Since Matthew Dillon’s working on the disklabel code, be careful if you’re running bleeding edge code in the next few days.Â Disklabel errors eat data.
If you have a DragonFly system, you should update it now.Â (Point releases have been rolled for 1.8, 1.6, and even 1.4)Â Non-DragonFly systems should also be updated, if available.
The title says it all – visit the download page for 1.8 to get it.Â Most every mirror appears to have it right now – not just the ones on the 1.8 page.
Note that some sites have an early version of the 1.8.1 release that lacks the installer; that image is ‘dfly-1.8.1.iso.gz’.Â Instead, be sure to download ‘dfly-1.8.1_REL.iso.gz’, which should be the newer file of the two.
Sepherosa Ziehau warned bleeding-edge users that recent network interface changes will require a rebuild of both kernel and world when next updating.Â This does not apply to 1.8 users.
DragonFly 1.8.1 will be released this weekend, so if you have something that you need added, speak up!Â This release will include the rtld fixes that enable parts of KDE to work again, among other things.
You may need to copy in a new
/etc/localtime file to account for daylight savings time changes in the U.S. and Canada, especially if you have an older system; Matthew Dillon explains.
www.dragonflybsd.org and leaf.dragonflybsd.org are getting upgraded to 1.8; this may mean some intermittent downtime over the next week.
If you are running a DragonFly system older than version 1.6, and you are in North America using something other than UTC time, you will need to manually update your tzinfo files to reflect the changed (in 2005, taking effect this year) Daylight Savings Time start and stop dates.Â If you are on UTC or are running 1.6+, you are fine.
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.
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 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.
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.