Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 23 Sep 2004 08:54:19 -0700
From:      "Bruce A. Mah" <bmah@freebsd.org>
To:        freebsd-stable@freebsd.org
Cc:        "Bruce A. Mah" <bmah@freebsd.org>
Subject:   Re: upgrade questions 4.10 -> 5-stable
Message-ID:  <20040923155419.GB53845@tomcat.kitchenlab.org>
In-Reply-To: <12247499375.20040921100534@takeda.tk>
References:  <20040920211231.89904.qmail@web53808.mail.yahoo.com> <200409201753.38308.so14k@so14k.com> <414F9C6D.9020709@corp.grupos.com.br> <20040921041017.GA963@tomcat.kitchenlab.org> <127205680265.20040920222835@takeda.tk> <20040921154116.GB36705@tomcat.kitchenlab.org> <12247499375.20040921100534@takeda.tk>

next in thread | previous in thread | raw e-mail | index | archive | help

--V0207lvV8h4k8FAm
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

If memory serves me right, Dariusz Kulinski wrote:

> Tuesday, September 21, 2004, 8:41:16 AM, you wrote:
>=20
> >> 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.
>=20
> 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".
>=20
> 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
>=20
> > Sorry, can't help you with that part.
>=20
> 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.
>=20
> 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.

--V0207lvV8h4k8FAm
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (FreeBSD)

iD8DBQFBUvGr2MoxcVugUsMRAnsiAKDRM+p3JK1r53rK5kWpZFZnwvuYYQCfdFjS
R2o+8l6VgqoPX+v6qRJWx+k=
=JWYV
-----END PGP SIGNATURE-----

--V0207lvV8h4k8FAm--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040923155419.GB53845>