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
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
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'
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
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
I decided to upgrade my PostgreSQL server today. I did this upgrade slightly different than the last time. All commands were done as the
root user unless indicated. Continue reading Upgrading PostgreSQL 9.2.10 to 9.4.1
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
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.
databases/ruby-bdb, before manually compiling and installing
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
The 20150220 entry in
/usr/ports/UPDATING contains no instructions for upgrading
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
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
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.
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
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
The 20141214 entry in
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
devel/gettext, as of version 0.19.3, has been split into three ports:
devel/gettext, the meta-port depending the two next ports;
devel/gettext-runtime, the runtime libraries; and
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
The announced EOL of the old
pkg_* tools is coming fast. Here are some notes from my experience on converting from the old
/var/db/pkg structure to the new SQLite 3 based approach, pkg(ng). Continue reading pkg2ng – some notes from my experience