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.
Category: Heads Up!
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.”
The kernel mailing list is getting hit with a Windows mail virus in a big way; be careful when viewing it through your mail client/news interface if you use Windows.
Update: fixed now.
Matt Dillon has added bind-9.2.4rc4 to
contrib. This replaces bind8 that was being used for DragonFly (and I assume FreeBSD-4) by default. Things may be somwhat unstable for a few days; if that is trouble for you, don’t update your system this week.
The latest dev numbering changes from Matt Dillon will break the NVIDIA binary driver, if you are using it. Emiel Kollof is working on a new version, and until that’s set, avoid updating if you want to keep your NVIDIA driver working.
Matt Dillon’s tracked down a nasty filesystem corruption bug in the
lockf code; everyone should update, rebuild, reboot, and do a
fsck to make sure your disk is intact.
Because of a commit at 2004/04/29 03:06:41 PDT, your next upgrade will need a buildworld –
make quickworld won’t catch it. This was helpfully noted by David Rhodus.
If you updated your kernel today and you are having wierd graphical issues or crashing, put this in
The issue should be fixed very soon.
Matt Dillon’s still missing some parts to the PIPE code in last night’s import from FreeBSD 5. Until this is fixed (hopefully by tomorrow) , the codebase will be somewhat unstable.
Matt Dillon posted that he is doing major work on buildworld code; you may want to update tomorrow and not today, if it was on your agenda. Following is his description of his work plans:
binutils 2.14 is being added in by Matt Dillon, over the next few days.
David Rhodus and Matt Dillon are getting GCC2 and GCC3 into the base system today; updating your source during the next 24 hours may bring you an unstable version.
There’s been a number of people reporting various breakages during install or boot time. To weed out problems caused by old data right away, remember to:
rm -rf /usr/obj
Matt Dillon’s bringing in the ‘DragonFly’ name to replace ‘FreeBSD’ in the source, which may break a number of things over the next few days, including all ports.
James Frazer found, and David Rhodus corroborated, that NTFS support tain’t working.
As part of another discussion, it’s been noted that trying to boot FreeBSD 5.1 and DragonFly from the same disk currently may not work if it’s UFS1, and definitely won’t if it’s UFS2.
/bin/sh had a big introduced recently that would make it crash when booting with a new world. It’s been fixed, so recompile
/bin/sh with updated sources when possible.