All posts by Trond Endrestøl

I stopped counting my age years ago. Personal interests besides computers and computer networks include, but not limited to, astronomy, comics, music, and science (fiction).

Strange mSATA SSD behaviour on Dell Latitude E7240

One of our Dell Latitude E7240 exhibited strange mSATA SSD behaviour. Disk requests didn’t complete on time. This computer ran the A13 firmware.

The case was eventually solved by upgrading to the A21 firmware executed from an USB stick as the mSATA SSD was unreliable at this point. Apparently, the A18 firmware corrected some mSATA port settings. Also, this was a good opportunity to rid us of Intel’s SA-00075.

This isn’t the first case where disk behaviour suddenly changes to the worst on Latitude E-series laptops, only to be rectified by a firmware upgrade.

AMANDA 3.3.9 as of r441897

misc/amanda-{client,server} as of r441897 fails to create the directory /usr/local/etc/amanda and an empty file named /usr/local/etc/amanda/security.conf. The client will fail during client checks and backup runs claiming:

failed: planner: [Can't get realpath of the security file '/usr/local/etc/amanda/security.conf': No such file or directory]

Here’s the remedy in the short run:

mkdir -p /usr/local/etc/amanda
touch /usr/local/etc/amanda/security.conf

There is one additional issue, pkg-plist claims:

%%SERVER_ONLY%%%%ETCDIR%%/amanda-security.conf

while Makefile says:

--with-security-file=${ETCDIR}/security.conf

This file is needed on each client and the filenames must match.

Due to historical reasons, or is that hysterical raisins(?), /usr/ports/misc/amanda-server/Makefile.local contains

CONFIGURE_ARGS+=	--sysconfdir=/home

Watch PRs 219665 and 219850 for more development on this issue.

Debating with a compiler

I’m always delighted by the light touch and stillness of early programming languages. Not much text;
a lot gets done. Old programs read like quiet conversations between a well-spoken researcher and a well-studied mechanical colleague, not as a debate with a compiler. Who’d have guessed sophistication bought such noise?

– Dick Gabriel

Ref.: OSCON 2010: Rob Pike, “Public Static Void”, https://youtu.be/5kj5ApnhPAE?t=41

Upgrading PostgreSQL from 9.5.7 to 9.6.3

All commands were done as the root user unless indicated.

This time it was necessary to create a new ZFS hierarchy of filesystems rooted at /var/db/postgres/data96. Also, the new PostgreSQL DBMS runs as the postgres user, not the pgsql user.

# Dump the current database cluster.
su -l pgsql
pg_dumpall | bzip2 -9c > all-db-9.5.7-2017-05-15.sql.bz2
chmod 0400 all-db-9.5.7-2017-05-15.sql.bz2
exit

# Stop the DBMS.
/usr/local/etc/rc.d/postgresql stop

# Configure the new versions.
make -C /usr/ports/databases/postgresql96-server config-recursive

# Upgrade the components using portupgrade.
portupgrade -fpvo databases/postgresql96-client databases/postgresql95-client
portupgrade -fpvo databases/postgresql96-server databases/postgresql95-server
portupgrade -fpvo databases/postgresql96-contrib databases/postgresql95-contrib

# Upgrade everything depending on databases/postgresql96-client.
# Omit the components upgraded in the previous step.
portupgrade -fprv -x databases/postgresql96-client -x databases/postgresql96-server -x databases/postgresql96-contrib databases/postgresql96-client

# Create the new hierarchy.
zfs create zdata/var/db/postgres
zfs create zdata/var/db/postgres/data96
zfs create zdata/var/db/postgres/data96/base
zfs create zdata/var/db/postgres/data96/pg_xlog
zfs set logbias=throughput zdata/var/db/postgres/data96/base
zfs set logbias=throughput zdata/var/db/postgres/data96/pg_xlog
zfs set primarycache=metadata zdata/var/db/postgres/data96/base
zfs set primarycache=metadata zdata/var/db/postgres/data96/pg_xlog
zfs set recordsize=8K zdata/var/db/postgres/data96/base
zfs set recordsize=8K zdata/var/db/postgres/data96/pg_xlog
zfs set redundant_metadata=most zdata/var/db/postgres/data96/base
zfs set redundant_metadata=most zdata/var/db/postgres/data96/pg_xlog
chown -R postgres:postgres /var/db/postgres
chmod -R 0700 /var/db/postgres/data96

# Hide the base and pg_xlog filesystems for now.
zfs unmount zdata/var/db/postgres/data96/base
zfs unmount zdata/var/db/postgres/data96/pg_xlog

# Edit /etc/rc.conf, if necessary, and change postgresql_data to "/var/db/postgres/data96"

# Create the initial database cluster.
/usr/local/etc/rc.d/postgresql initdb

# Rename /var/db/postgres/data96/base and /var/db/postgres/data96/pg_xlog.
mv /var/db/postgres/data96/base /var/db/postgres/data96/base-old
mv /var/db/postgres/data96/pg_xlog /var/db/postgres/data96/pg_xlog-old

# Unhide the two special filesystems.
zfs mount zdata/var/db/postgres/data96/base
zfs mount zdata/var/db/postgres/data96/pg_xlog

# Copy the contents of /var/db/postgres/data96/base-old and /var/db/postgres/data96/pg_xlog-old.
cp -Rp /var/db/postgres/data96/base-old /var/db/postgres/data96/base
cp -Rp /var/db/postgres/data96/pg_xlog-old /var/db/postgres/data96/pg_xlog

# Delete /var/db/postgres/data96/base-old and /var/db/postgres/data96/pg_xlog-old.
rm -R /var/db/postgres/data96/base-old /var/db/postgres/data96/pg_xlog-old

# Start the DBMS.
/usr/local/etc/rc.d/postgresql start

# Copy the old DB dump and change the ownership.
cp -p ~pgsql/all-db-9.5.7-2017-05-15.sql.bz2 ~postgres
chown postgres:postgres ~postgres/all-db-9.5.7-2017-05-15.sql.bz2

# Recreate the old database cluster.
su -l postgres
bzcat all-db-9.5.7-2017-05-15.sql.bz2 | psql -f - template1

# Set a password for the postgres user/role within the database cluster.
psql template1
alter user postgres with password 'somethingsomething';
\q
exit

# Transfer all relevant settings from /usr/local/pgsql/data to /var/db/postgres/data96 for pg_hba.conf and postgresql.conf

# Restart the DBMS.
/usr/local/etc/rc.d/postgresql restart

# Create a new dump of the database cluster.
su -l postgres
pg_dumpall | bzip2 -9c > all-db-9.6.3-2017-05-15.sql.bz2
chmod 0400 all-db-9.6.3-2017-05-15.sql.bz2
exit

# You may now remove the old PostgreSQL hierarchy rooted at /usr/local/pgsql.

devel/py-setuptools27 renamed to devel/py27-setuptools

r436290 renamed devel/py-setuptools27 to devel/py27-setuptools.

Here are four portupgrade commands to make amends:

portupgrade  -ncfpvo devel/py27-setuptools devel/py-setuptools27
portupgrade    -fpvo devel/py27-setuptools devel/py-setuptools27
portupgrade -ncfprvx devel/py27-setuptools devel/py27-setuptools
portupgrade   -fprvx devel/py27-setuptools devel/py27-setuptools

Run similar commands for updating the origin of, say, devel/py-setuptools36 to devel/py36-setuptools.

Upgrading Qt4 and Qt5 after r434380

r434380 made massive changes to Qt4 and Qt5 in FreeBSD. Sadly, there are no instructions on how to upgrade an existing system. The changes to ports/head/UPDATING didn’t help at all. Here are the notes I made while upgrading my laptop running stable/11.

To successfully install misc/qtchooser and upgrade the remaining Qt4 and Qt5 ports, you need to recursively uninstall

  • devel/qt4-linguisttools,
  • devel/qt4-rcc, and
  • devel/qt4-moc.

At some point you to need to upgrade devel/qt5-core before everything else, e.g. portupgrade -fpv devel/qt5-core.