Category Archives: portupgrade

Anything related to portupgrade

portupgrade uninstall error, broken pipe

I too was bitten by the portupgrade uninstall error, due to broken pipes, on my laptop running FreeBSD/amd64 stable/10. Others have identified the file 5.26 utility as the culprit, introduced in stable/10 as r298920.

Watch PR 209211 for any progress. base/head was corrected at r299234, and stable/10 will follow soon. Continue reading portupgrade uninstall error, broken pipe

Upgrading PostgreSQL 9.4.6 to 9.5.1

All commands were done as the root user unless indicated.

su -l pgsql
pg_dumpall | bzip2 -9c > all-db-9.4.6-2016-02-17.sql.bz2
chmod 0600 all-db-9.4.6-2016-02-17.sql.bz2
/usr/local/etc/rc.d/postgresql stop
make -C /usr/ports/databases/postgresql95-server config-recursive
pkg delete databases/postgresql94-contrib
portupgrade -fpvo databases/postgresql95-client databases/postgresql94-client
portupgrade -Nfpv databases/postgresql95-contrib
portupgrade -fpvo databases/postgresql95-server databases/postgresql94-server
portupgrade -fprv -x databases/postgresql95-client -x databases/postgresql95-server -x databases/postgresql95-contrib databases/postgresql95-client
mv /usr/local/pgsql/data /usr/local/pgsql/data0
su -l pgsql -c 'mkdir /usr/local/pgsql/data'
/usr/local/etc/rc.d/postgresql initdb
/usr/local/etc/rc.d/postgresql start
su -l pgsql
bzcat all-db-9.4.6-2016-02-17.sql.bz2 | psql -f - template1
# Transfer all relevant settings from /usr/local/pgsql/data0 to /usr/local/pgsql/data for pg_hba.conf and postgresql.conf
/usr/local/etc/rc.d/postgresql restart
su -l pgsql
pg_dumpall | bzip2 -9c > all-db-9.5.1-2016-02-17.sql.bz2
chmod 0600 all-db-9.5.1-2016-02-17.sql.bz2
rm -R /usr/local/pgsql/data0

Ascertaining installed ports for a specific architecture

When upgrading from one major version of FreeBSD to another, in my case from FreeBSD/amd64 stable/9 to FreeBSD/amd64 stable/10, it’s customary to upgrade the installed ports afterwards, beginning with ports-mgmt/pkg.

I forcefully upgraded all installed ports using portupgrade -afpv, but the upgrade of lang/ruby21 failed miserably.

I removed all traces of Ruby 2.1, i.e. ports-mgmt/portupgrade and databases/ruby-bdb, before manually compiling and installing lang/ruby21, databases/ruby-bdb, and ports-mgmt/portupgrade using the ports collection.

Now, I needed to know which remaining ports were still compiled for stable/9. The following snippet allowed me to gather the origins of such ports:

pkg query -a %o:%q | grep freebsd:9: | cut -d : -f 1

Now, I could feed that list to the newly installed portupgrade and upgrade the remaining ports:

portupgrade -fprv `pkg query -a %o:%q | grep freebsd:9: | cut -d : -f 1`

In the end, I should have removed lang/ruby21 completely after upgrading ports-mgmt/pkg, and reinstalled ports-mgmt/portupgrade manually using the ports collection. Only then is it safe to forcefully rebuild and reinstall all the other ports. Don’t forget to add devel/cvs if you used to rely on cvs in base, and adjust all references from /usr/bin/cvs to /usr/local/bin/cvs.

Upgrading lang/php5 to lang/php56

The 20150220 entry in /usr/ports/UPDATING contains no instructions for upgrading lang/php5 to lang/php56, at least not for us compiling our own ports.

I learned the hard way using portupgrade what needs to be done. I have summarised my steps into the script below. Use the script as a guide, and if you do run my script, then you’re on your own. To save you some effort, here’s the script ready for downloading. Continue reading Upgrading lang/php5 to lang/php56

Migrating FreeBSD from i386 to amd64

I have (successfully) attempted to migrate a running i386 stable/9 system into a running amd64 stable/9 system, and attempted to migrate a running i386 stable/10 system into a running amd64 stable/10 system, only to see if these tasks are in fact feasible. The results speaks for themselves, given the boundary conditions outlined below.

If your system has a separate root filesystem of less than 1 GiB, then I suggest you consider scrapping the 32-bit system altogether, and install a fresh 64-bit system. If you wish to continue having a separate root filesystem, make that filesystem no smaller than 2 GiB to accommodate future expansion. You may gain additional free space by deleting /boot/kernel*/*.symbols prior to installing a new kernel. If this isn’t good enough, then you should limit the modules installed using the MODULES_OVERRIDE directive in your kernel configuration file. (When 11.0 comes out, all kernel symbol files will live in /usr/lib/debug/boot/kernel, relieving the stress on the root filesystem.)

The boundary conditions are:

  • base built from the appropriate stable branch of the source code tree,
  • amd64 snapshot for the appropriate stable branch to speed up parts of the transition,
  • the system being able to run with the GENERIC kernel until a new custom kernel is optionally installed,
  • if your system needs a custom kernel to function properly, one can be precompiled on a spare 64-bit system and transferred to the subject at the right moment,
  • ports built from the ports collection with ports-mgmt/portmaster as a vital instrument, and
  • the ports listed below.

Continue reading Migrating FreeBSD from i386 to amd64

Upgrading FreeBSD from stable/8 to stable/9, and to stable/10

Update 2015-01-23

Order has once again been restored. I have successfully upgraded 8.4-RELEASE (r251259) to stable/8 r277528, and further to stable/9 r277528, and finally to stable/10 r277559.

Update 2015-01-14

Work is underway enabling latest stable/8 to go directly to latest stable/9.

All my FreeBSD systems have run stable/something-something, compiled from source, for as long as I can remember. I compile and install all ports using the ports collection and portupgrade. I used pre-built binary packages only to get devel/cvsup-nogui up and running, a long, long time ago. I have almost never ended up in a situation from which I could not recover. Continue reading Upgrading FreeBSD from stable/8 to stable/9, and to stable/10

Solving conflicts between print/texlive-base and devel/tex-kpathsea

The 20141214 entry in ports/head/UPDATING says:

AFFECTS: users of TeXLive

Several scripts in print/texlive-base have been moved to devel/tex-kpathsea. Upgrading them can fail because texlive-base depends on tex-kpathsea, and the new ex-kpathsea tries to install files which were installed by the old texlive-base. The following error message indicates this situation:

pkg-static: tex-kpathsea-6.2.0_1 conflicts with texlive-base-20140525_3 (installs files into the same place). Problematic file: /usr/local/bin/kpsewhere

To solve this problem, remove both of tex-kpathsea and texlive-base first and install the new versions:

# pkg delete -f tex-kpathsea texlive-base

The above is a bit drastic, at least for us who build our own ports. These two portupgrade commands gets the job done, albeit with some overhead:

portupgrade -fprv print/texlive-base
portupgrade -fprv devel/tex-kpathsea

gettext 0.19.3 in FreeBSD

devel/gettext, as of version 0.19.3, has been split into three ports:

  1. devel/gettext, the meta-port depending the two next ports;
  2. devel/gettext-runtime, the runtime libraries; and
  3. devel/gettext-tools, the tools for managing the message catalogs.

In my case, as I build my own ports, making the transition required manual intervention using both portupgrade and the ports collection tree:

portupgrade -fpvo devel/gettext-runtime gettext
cd /usr/ports/devel/gettext-tools && make && make install && make package && make clean
cd /usr/ports/devel/gettext && make && make install && make package && make clean
portupgrade -fprvx gettext -x gettext-runtime -x gettext-tools devel/gettext-runtime