non-destructive ports/packages update

[Perry Hutchison]

I'm looking for a way to move everything connected with ports and
packages aside, so that I can start fresh but with the ability to
easily roll it back when things go badly (as they surely will).

I have in mind to something like this:

# cd /usr
# mkdir old
# mv ports local old
# mkdir ports local
# cd /var/db
# mkdir old
# mv ports pkg old
# mkdir ports pkg

Is there anything else that needs to be saved before fetching a
new ports tree and starting to build things (or install prebuilt
packages)?

This is on 8.1, although I suspect the answer does not depend on
the OS version. And yes, there's plenty of space in /usr and /var.
_______________________________________________
freebs...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-port...@freebsd.org"

[Xin Li]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 4/19/13 11:34 PM, Perry Hutchison wrote:
> I'm looking for a way to move everything connected with ports and
> packages aside, so that I can start fresh but with the ability to
> easily roll it back when things go badly (as they surely will).
>
> I have in mind to something like this:
>
> # cd /usr # mkdir old # mv ports local old # mkdir ports local # cd
> /var/db # mkdir old # mv ports pkg old # mkdir ports pkg
>
> Is there anything else that needs to be saved before fetching a new
> ports tree and starting to build things (or install prebuilt
> packages)?
>
> This is on 8.1, although I suspect the answer does not depend on
> the OS version. And yes, there's plenty of space in /usr and
> /var.

If you use ZFS, it's possible to take snapshot, then install new
ports, then if something blows up, you can rollback.

With UFS, it's still possible to take snapshot but rollback is not atomic.

If you use portmaster, it can save packages (I think portupgrade can
do it too). But this approach depends on the fact that the port is
well written, and is not atomic in terms of package set.

BTW. Speaking for 8.1, it's past EoL, please consider upgrading to a
supported release.

Cheers,

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJRcjpRAAoJEG80Jeu8UPuzdjkIAICtMrOW87AWrtE+3FCGbG9d
4XOPZD6fgFw0eOJ4KpaxyW//e4wqILofyoLmpepYTkiZQG+fzQ8sdHLO6WNdqRo8
ilzpzwpmu3rAaI6YvPj90Oz5Er4Q+yGG1u/1jFfWPDpiWOtVlaYC3HdERqoSQCfo
NCfjEk6UYjRiRSGfw9qynf87WCinhi8su71+/A0RusuDHXeLQWkgfOPrTerm77KM
HBFXKg2F7DlLx9ZdXxv0Tk+8QwHSlYB249oC047MLx/dT0KBOfD2nWK1xhB4pDJo
RRbWKUmb0B/aT0FLLD/swWSbx/59menyHDJBG/ZMmxB58vAhSrkPXtu7SNOlZwU=
=OSk7
-----END PGP SIGNATURE-----

[Perry Hutchison]

Xin Li <del...@delphij.net> wrote:

> On 4/19/13 11:34 PM, Perry Hutchison wrote:
> > I'm looking for a way to move everything connected with ports and
> > packages aside, so that I can start fresh but with the ability to
> > easily roll it back when things go badly (as they surely will).
> >
> > I have in mind to something like this:
> >
> > # cd /usr
> > # mkdir old
> > # mv ports local old
> > # mkdir ports local
> > # cd /var/db
> > # mkdir old
> > # mv ports pkg old
> > # mkdir ports pkg
> >
> > Is there anything else that needs to be saved before fetching a
> > new ports tree and starting to build things (or install prebuilt
> > packages)?
>

> If you use ZFS, it's possible to take snapshot, then install new
> ports, then if something blows up, you can rollback.
>
> With UFS, it's still possible to take snapshot but rollback is not
> atomic.

I'm aware of filesystem snapshots, but I only want to checkpoint the
ports and packages, not the whole filesystem -- a rollback needs to
be fast, easy, and obviously correct; preserve the failure logs; and
not undo changes that may have been made elsewhere in the meantime.
(BTW I don't use ZFS: the machine doesn't have enough memory, and to
me ZFS -- especially on 8.x -- doesn't yet seem sufficiently proven.)

> If you use portmaster, it can save packages (I think portupgrade
> can do it too). But this approach depends on the fact that the
> port is well written, and is not atomic in terms of package set.

And then a rollback requires re-installing the saved packages, which
is surely slower than moving a few directories and/or files around.

The question is, what (if anything) else -- besides /usr/ports,
/usr/local, /var/db/ports, and /var/db/pkg -- needs to be checkpointed?

[Chris Rees]

Are you installing any drivers? You may need to back up /boot too.

Chris

[Peter Pentchev]

Some ports might store "run state" in /var/db/<portname> or a similarly
named directory. The thing is, the decision whether to save this and
restore it or to keep it across runs actually depends on the port: for
database management systems such as MySQL, PostgreSQL, etc, you'll
probably want to keep the databases even if the ports themselves are
reinstalled, rolled back, restored, whatever. For some other systems,
you might want to remove the "current state" information of the version
that you are about to replace.

G'luck,
Peter

--
Peter Pentchev ro...@ringlet.net ro...@FreeBSD.org p.pe...@storpool.com
PGP key: http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
Thit sentence is not self-referential because "thit" is not a word.

[Perry Hutchison]

Chris Rees <uti...@gmail.com> wrote:
> On 21 Apr 2013 02:13, "Perry Hutchison" <per...@pluto.rain.com> wrote:

> > ...

> > The question is, what (if anything) else -- besides /usr/ports,
> > /usr/local, /var/db/ports, and /var/db/pkg -- needs to be checkpointed?
>

> Are you installing any drivers? You may need to back up /boot too.

No drivers from ports here (nor any ports which overwrite base), but
good to note this for the archives :)

[Perry Hutchison]

Peter Pentchev <ro...@ringlet.net> wrote:

> Some ports might store "run state" in /var/db/<portname> or a similarly
> named directory. The thing is, the decision whether to save this and
> restore it or to keep it across runs actually depends on the port: for
> database management systems such as MySQL, PostgreSQL, etc, you'll
> probably want to keep the databases even if the ports themselves are
> reinstalled, rolled back, restored, whatever. For some other systems,
> you might want to remove the "current state" information of the version
> that you are about to replace.

Good catch. No DBMS on this system, so no problem there, but there
are two non-empty X11-related directories under /var/db: dbus and
fontconfig. (The machine does have some X client apps, but not the
X server.)

[Peter Jeremy]

On 2013-Apr-20 18:03:17 -0700, Perry Hutchison <per...@pluto.rain.com> wrote:
>The question is, what (if anything) else -- besides /usr/ports,
>/usr/local, /var/db/ports, and /var/db/pkg -- needs to be checkpointed?

If you're running any Linux compatibility packages: /compat/linux
BOINC packages: /var/db/boinc

Unless you've moved to pkgng,
$ grep @cwd /var/db/pkg/*/+CONTENTS | grep -v /usr/local
will give you an overview of what "unusual" locations have been
installed to.

--
Peter Jeremy

[Chris Rees]

Actually grep "^@cw*d", because @cd is an equivalent syntax that is
sometimes used.

Chris

[Perry Hutchison]

Chris Rees <cr...@FreeBSD.org> wrote:

> On 23 April 2013 20:41, Peter Jeremy <pe...@rulingia.com> wrote:
> > On 2013-Apr-20 18:03:17 -0700, Perry Hutchison <per...@pluto.rain.com> wrote:
> >>The question is, what (if anything) else -- besides /usr/ports,
> >>/usr/local, /var/db/ports, and /var/db/pkg -- needs to be checkpointed?
> >
> > If you're running any Linux compatibility packages: /compat/linux
> > BOINC packages: /var/db/boinc
> >
> > Unless you've moved to pkgng,
> > $ grep @cwd /var/db/pkg/*/+CONTENTS | grep -v /usr/local
> > will give you an overview of what "unusual" locations have been
> > installed to.
>
> Actually grep "^@cw*d", because @cd is an equivalent syntax that is
> sometimes used.

A further refinement:

grep "^@cw*d ." /var/db/pkg/*/+CONTENTS | egrep -v '/usr/local|:@cwd \.$'

The "^@cw*d ." excludes ports (like graphviz) that have an @cwd
without an operand. The :@cwd \.$ alternative excludes "." as
the operand -- a construct which seems to be fairly common.