upgrade questions 4.10 -> 5-stable

[Bruce A. Mah]

If memory serves me right, Dariusz Kulinski wrote:

> Tuesday, September 21, 2004, 8:41:16 AM, you wrote:
> 
> >> It's nice guide, but I personally think there few important thing stat
> >> are missing (and I was trying to found answer, but without luck):
> >> - what directories, should be especially backed up and restored after
> >>   upgrade, I know /etc /usr/local/etc, /var/mail /var/cron /var/db
> >>   what else?
> > For the case of a reinstalling from installation media, what to
> > restore depends on how you've configured your system.  It's beyond the
> > scope of the document to try to enumerate all possible directories
> > that might be holding data you care about.  At a bare minimum, things
> > I usually care about on my systems can be found in /boot, /etc,
> > /usr/local/etc, /var, and whereever home directories live.  Beyond
> > that, it depends too much on how your own system is set up.  That's
> > why you want to make sure you've saved *everything* to backup media,
> > so if you miss restoring something you can always go back and get it
> > later.
> 
> What about directories that I definitively shouldn't restore, for
> example:
> /usr/include /usr/lib most likely /bin /sbin /usr/bin /usr/sbin /stand
> and so on, maybe that could help me better.

Here's the deal.  For any of the systems I maintain, I wouldn't
restore any of these from backups after a source upgrade because in
general, those directories contain *only* files installed from the
base system.  But how can I tell how *you* have *your* system set up?

> >> - how to upgrade config files while while doing source upgrade, is it
> >>   possible to use mergemaster, what are recommended steps?
> >>   Overwrite all the new files and run mergemaster or there is better
> >>   way?
> > Step 16 of the source upgrade procedure says specifically to use
> > "mergemaster -i".
> 
> That step was in source upgrade category, so I assumed it might not
> be correct for binary upgrade.

You *asked* about the source upgrade procedure above.

For binary upgrades, it's probably best to carefully examine the files
in your backups and merge the changes in by hand.  After a binary
install, the old files will be gone, so there won't be anything for
mergemaster to operate on.

Good candidates for merging are:  /etc/passwd, /etc/group, and
/etc/rc.conf.  Don't just blindly drop in your backup files.

> >> - some other stuff that I just forgot
> 
> > Sorry, can't help you with that part.
> 
> What about ports, I know that I need to recompile them, but will they
> work for that time?

We believe that most ports will work if you install the compat4x
libraries and don't upgrade anything.  But there's a few that *need*
to be upgraded, due to changes in the statfs structure.  Also if
you're going to upgrade ports in the future, it's probably safest to
reinstall all ports.

> >> Basically I would like make the migration flawlessly, and in shortest
> >> time possible.
> > In my experience, sometimes those two goals are at odds with each
> > other.
> > You didn't say anything about the machine(s) you're trying to upgrade,
> > but if any of them happen to be providing mission-critical services, I
> > highly recommend running through the upgrade process on a scratch
> > machine first.  Or even better, build up a new system and gradually
> > migrate data and services over to it.
> 
> It's not really mission-critical, but it's like that for me :)
> It works as my mail/web server so I want to have shortest downtime
> possible :)

Then you want to take your time and do things carefully so that you
don't have a longer downtime caused by screwing up the upgrade.  I've
had this happen more times than I can count (not on FreeBSD, but the
experience applies).

Bruce.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20040923/7b0b7fa5/attachment.bin