Re: upgrade from FreeBSD 4.11-RELEASE

[Bill Hacker <wbh@xxxxxxxxxxxxx>]

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 
changes.

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.

YMMV,

Bill