DragonFly users List (threaded) for 2005-02
Re: upgrade from FreeBSD 4.11-RELEASE
Jake Maciejewski wrote:
On Thu, 2005-02-24 at 17:27 +0800, Bill Hacker wrote:
Janet Sullivan wrote:
Are there any known issues upgrading from FreeBSD 4.11 to Dragonfly, or
should the instructions at
http://www.dragonflybsd.org/docs/upgrade-freebsd.cgi still work just fine?
4.10 and later have a progressively increasing number of 5.X'ish
backports included. (I run 4.9 thru 4.11-STABLE).
When I upgraded from 4.10, the only thing I noticed was that some of the
changes in UPDATING had already been made.
I do not know if those steps will still work without further ado, but I
can say that if you can do so, a 'clean' DragonFlyBSD install from ISO,
newfs and all, is *very much* faster - and very trouble-free.
I agree that binary is cleaner and faster, but if you don't want the
downtime or want a custom kernel or optomizations, you'd have to build
from source eventually anyway.
Agree w/r building from source, either right after install or later, but
expect fewer 'distractions' if done on a box that was
DragonFlyBSD from the outset (or most recent newfs, anyway <g>.
Nothing is perfect - we've been 'bitten' a few times on ordinary FreeBSD
Going 4.X to 5.X, then having - with the taste of chaos in one's mouth -
to go back to 4.X, was not a lot of fun - which is why I am here <g>.
DragonFlyBSD is fixing what's broke, not what ain't broke.
Nowadays we break the RAID1, remount as two disks, install the new stuff
to one of the drives while the other carries the traffic, copy what we
need to preserve, reboot to the new, then overwrite the old from the new
'merged' drive, recreate the RAID1, edit fstab, and reboot. Sounds
complicated, but works well 'over the wire'.
Rebuild is background work, may take the better part of a full day, but
the box is in production nearly the whole time, needs only a couple of
40-90 second reboots, plus (recommended under atacontrol RAID1, anyway)
time for a forced fsck in /etc/rc, not just a preen, prior to going multi.
Seldom requires a trip to the data centre.
FWIW, we always do the cvsup and make cycle *twice*. Back-to-back.
Insures we have built the latest with the latest, as it takes exactly
one *bit* wrong in the wrong place to produce grief.