postfix upgrade can fail due to "newaliases: fatal: inet_addr_local[getifaddrs]: getifaddrs: Address family not supported by protocol" under qemu-static

[Scott Moser]

this happened during a maas image build, but I assume it can happen elsewhere though i've not seen it fail. its likely a result of postfix recently having made it into the cloud image, pulled in by recommends of mdadm.

apt-get dist-upgrade
...
13:36:01 Setting up lxd-client (0.25-0ubuntu1) ...
13:36:01 Setting up postfix (2.11.3-1ubuntu3) ...
13:36:08
13:36:08 Postfix configuration was untouched. If you need to make changes, edit
13:36:08 /etc/postfix/main.cf (and others) as needed. To view Postfix configuration
13:36:08 values, see postconf(1).
13:36:08
13:36:08 After modifying main.cf, be sure to run '/etc/init.d/postfix reload'.
13:36:08
13:36:09 Running newaliases
13:36:09 newaliases: fatal: inet_addr_local[getifaddrs]: getifaddrs: Address family not supported by protocol
13:36:10 dpkg: error processing package postfix (--configure):
13:36:10 subprocess installed post-installation script returned error exit status 75
13:36:10 Setting up python-cffi-backend (1.4.2-2ubuntu1) ...
...

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: postfix 2.11.3-1ubuntu2
ProcVersionSignature: User Name 4.3.0-2.11-generic 4.3.0
Uname: Linux 4.3.0-2-generic x86_64
ApportVersion: 2.19.3-0ubuntu2
Architecture: amd64
Date: Tue Jan 5 21:00:22 2016
DuplicateSignature: InvalidHostOrDomain
Ec2AMI: ami-0000072f
Ec2AMIManifest: FIXME
Ec2AvailabilityZone: nova
Ec2InstanceType: m1.small
Ec2Kernel: None
Ec2Ramdisk: None
EtcMailname: localhost.localdomain
Hostname: Error: command ['hostname', '--fqdn'] failed with exit code 1: hostname: Name or service not known
PostconfMydomain: localdomain
PostconfMyhostname: localhost.localdomain
PostconfMyorigin: /etc/mailname
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ResolvConf:
 # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
 # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
 nameserver 10.245.160.2
 search openstacklocal
SourcePackage: postfix
UpgradeStatus: No upgrade log present (probably fresh install)

[Scott Moser (smoser)]

This only seems to fail on "cross" builds, where we modify arm64 images via chroot using qemu-static.
We can get the apt-get upgrade out of the way and see the failure with just the following:

$ sudo apt-get install -qy qemu-user-static

$ arm64_img_url=http://cloud-images.ubuntu.com/daily/server/xenial/20151212/xenial-server-cloudimg-arm64.tar.gz
$ wget "$arm64_img_url" -O xenial-server-cloudimg-arm64.tar.gz
$ tar -xvzf xenial-server-cloudimg-arm64.tar.gz
$ ls -l xenial-server-cloudimg-arm64.img
-rw-r--r-- 1 ubuntu ubuntu 1426063360 Dec 13 00:22 xenial-server-cloudimg-arm64.img

$ cp --sparse=always xenial-server-cloudimg-arm64.img root.img
$ sudo mount -o loop root.img /mnt
$ sudo cp /usr/bin/qemu-aarch64-static /mnt/usr/bin/qemu-aarch64-static
$ sudo chroot /mnt/ /usr/bin/newaliases
newaliases: fatal: inet_addr_local[getifaddrs]: getifaddrs: Address family not supported by protocol

Note, mounting additional filesystems (/proc and /sys) does not seem to help.

[Scott Moser (smoser)]

I've noticed that 'ifconfig' or 'ip addr' fail generally the same way:
$ ifconfig
: error fetching interface information: Device not found
$ ip addr
Cannot open netlink socket: Address family not supported by protocol

it seems bug 1323001 is related. Also https://github.com/nodejs/node-v0.x-archive/issues/8616 has node's issue dealing with this same basic issue.

[Scott Moser (smoser)]

worked around this in maas image build by dpkg-divert'ing newaliases when inside a cross and replacing it with /bin/true.

[Kev Bowring (flocculant)]

got this coming up as the bug previously reported - xenial updating, postifx fails

[starkus (starkus)]

after todays kernel upgrade on 15.10 on my new computer I could log in a partition with 16.04 having had installed on my old computer. I started the system and applied the upgrades apt-get showed me. While updating the crash happened. I could start handling it with

sudo apt-get update && sudo dpkg --configure -a && sudo apt-get install -f && sudo apt-get dist-upgrade && sudo apt-get upgrade && sudo apt-get autoremove && sudo apt-get clean && sudo apt-get autoclean

[Ivan (ivan-nieto-sousa)]

happened to me, I think I fixed it just editing the line

those variables are not initializated, so I thought adding an equals symbol could solve it, and it does

sudo gedit /etc/postfix/main.cf

find: "permit_sasl_authenticated,permit_mynetworks,reject_unauth_destination"

add an equals symbol at the end: "permit_sasl_authenticated,permit_mynetworks,reject_unauth_destination ="

then:

sudo apt-get update && sudo dpkg --configure -a && sudo apt-get install -f && sudo apt-get dist-upgrade && sudo apt-get upgrade && sudo apt-get autoremove && sudo apt-get clean && sudo apt-get autoclean

[hackeron (hackeron)]

Any permanent solution to this? :)

[hackeron (hackeron)]

This is affecting xenial clean install also :(

[junior0 (igor-travov-gmail)]

This bug appear`s when I installing gitlab packages and message about wrong dependences merged. While installing something with postfix also appear.... Please fix it I need gitlab and do not want to go to another linux distributive.....

[chrisber (chrisber)]

I'm interested in this topic as well.
My use case is running a docker raspberry pi arm container on Ubuntu 14.04 x64 with qemu-static.

My steps to reproduce are the following:

# docker pull philipz/rpi-raspbian:latest
# docker run -it --rm -v /usr/bin/qemu-arm-static:/usr/bin/qemu-arm-static philipz/rpi-raspbian bash
root@3b4ddc174279:/# ip addr
Cannot open netlink socket: Address family not supported by protocol

A fix or an workaround would be awesome.

note: we are also working with a embedded arm distro which has no package manager available, would be nice if the workaround would not depend on apt-get

[Rolf Leggewie (r0lf)]

newaliases-related bugs:
bug 1586745
bug 1057100
bug 1531299
bug 820870

[Robie Basak (racb)]

> its likely a result of postfix recently having made it into the cloud image, pulled in by recommends of mdadm.

Is this something we even want? It seems wrong to me. Our cloud images shouldn't have an MTA installed by default, should they?

[Somnath Banerjee (somnathb)]

For me the problem solved by just downloading a package of mail-transport-agent.

[nopq (nopq)]

I was linked to this bug, not sure if it's the same. The error message said that etc/mailname could not be located.

What fixed it for me was changing etc/mailname to $mydomain in /etc/postfix/main.cf. So

sudo gedit /etc/postfix/main.cf

myorigin = $mydomain