Missing legacy ethX interfaces names

If you are a old school sys admin, and wants to keep the default ethX convention for internet names,  you can do it easily on Ubuntu and Debian.

When running Ubuntu and Debian on a virtual machine on top of KVM, you will see that the name is ibmvethX, instead of the ethX. This changes happened on newer version (Ubuntu 15.10+ and Debian 10) due to a lot of benefits of interfaces naming when doing PCI hot plugs and replacement.

So, in order to solve it you have two options, changing the full ifname mechanism as a general change, doing:

Changing ifname in the kernel

Edit your /etc/default/grub. Change the the following line from:



GRUB_CMDLINE_LINUX="net.ifnames=0 biosdevname=0"

And then running:

# update-grub

Other than doing it, youou can also just change one interface, so, you can have more control.

Persistent udev naming

In order to run persistent name, which I personally prefer better, you can create a file name /etc/udev/rules.d, with the following content:

SUBSYSTEM==”net”, ACTION==”add”, ATTR{address}==”4c:45:42:45:01:09″, NAME=”eth0″

This is going to tell udev that a interface with mac ‘4c:45:42:45:01:09‘ should be named eth0. After that, just replace your configurations at /etc/network/interfaces and reboot your system. You should see eth0 instead of ibmveth0 now.



Export X from server to local system

Every now and then I have to verify a graphical application running on the remote server. That must be done via graphical output, no way to do it from the command line.

For those scenarios I usually export the X from the remote interface to my local workstation. That can be done simply by issuing:

ssh -X -C -c blowfish <username>@<remote-server>

From the ssh man page:

     Enables X11 forwarding. (X11 forwarding should be enabled
     with caution. Read the man page);
    Requests compression of all data;
-c cipher_spec:
    Selects the cipher specification for encrypting the session.
    The supported values are “3des”, “blowfish”, and “des”.

Using a remote connection to a xenial ppc64el server from a Fedora24, I got the following error:

Unable to negotiate with <server>: no matching cipher found. 
Their offer: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,

Adding blowfish-cbc (taken from the openssh man page) to the ssh_config files did not “blow it away” though. So to get rid of the error I simply removed the ‘blowfish‘ cipher type, and left the task to the system.

After getting access you won’t notice any difference, for the result is the same as as regular ssh connection. The difference relies on the behavior when you run a graphical application from the CLI. Here I am running HardInfo in the remote system as an example:


Graphical interface being exported to a local workstation from a remote Ubuntu ppc64el system.

Please read the ssh man page carefully to get clearer all security considerations and get advantage of the X exporting when running graphical applications.

Have a nice day.

Debconf BoF presentation

At Debconf16, I was the chair of a nice BoF discussion around Power, covering all the three ports (powerpc, ppc64 and ppc64el).

There was some interesting discussion about powerpc and ppc64, and what to expect  in Stretch release. One of the discussions, raised by the release team, is regarding missing  porters. This should be more detailed later in the release team emails.

I also created a PDF to start the discussion, and I would like to share it here. You can find it clicking in the following like: ppc64el_bof.



Ubuntu 16.04.1

Ubuntu 16.04.1 will be the new Ubuntu release targeted for July 21st.

As a .1 release, this version will ship the very same kernel as the 16.04, plus some hardware enablement, usually seen as the HWE acronym.

If you are targeting any development for this release, this is the kernel schedule for it:

         24-Jun   Last day for kernel commits for this cycle
27-Jun - 02-Jul   Kernel prep week.
03-Jul - 15-Jul   Bug verification & Regression testing..
         18-Jul   Release to -updates.

Snap on Power

Ubuntu created an interesting way of distributing binaries called snap, and the snap tool is available in Power since Ubuntu 16.04.

Snap is a way to make packages available with their dependencies on a sandbox. You can install it using apt:

# apt-get install snapd

You can search for packages using the find parameter as:

1604 ➜  ~  snap find     
Name                Version               Developer    Notes    Summary
ab                  1.0                   snappy-test  -        Test snap with shortest name
audovia             3.2.2                 songbuilder  9.99USD  Database application for making music using JFugue MusicStrings
beagleblack         3.1                   mvo          -        OEM Beagle Bone Black
canonical-dragon    0.7.1                 canonical    -        The gadget snap for the dragonboard
canonical-i386      3.2.i386              canonical    -        The gadget snap for generic i386 systems
canonical-pc        3.2                   canonical    -        AMD64 generic package
canonical-pi2       3.2                   canonical    -        Raspberry Pi 2 support package
eeevil              1                     chipaca      -        very evil
hello               2.10                  canonical    -        GNU Hello, the "hello world" snap
hello-world         6.1                   canonical    -        Hello world example
htop                2.0.1                 maxiberta    -        Interactive processes viewer
http                4.6692016091          chipaca      -        HTTPie in a snap
morse-converter-py  1-2                   brunonova    -        Simple command-line Morse converter
snappy-debug        0.21                  canonical    -        Debug tools for ubuntu-core
sudo                1                     chipaca      -        not sudo
ubuntu-core         16.04+20160531.11-53  canonical    -        The ubuntu-core OS snap
ufw                 0.36pre-16.2          canonical    -        ufw (Uncomplicated Firewall) for Ubuntu Core
xkcd-webserver      16.04-6               canonical    -        Show random XKCD compic via a build-in webserver
1604 ➜  ~  snap install htop
error: access denied (snap login --help)

In order to install a package/snap you should use the install parameter:

1604 ➜  ~  sudo snap install htop
228.00 KB / 228.00 KB [=================================================================================================>_] 100.00 % 100.81 KB/s 

Name  Version  Rev  Developer  Notes
htop  2.0.1    18   maxiberta  -

And list the packages available using the word list:

1604 ➜  ~  snap list
Name         Version               Rev  Developer  Notes
htop         2.0.1                 18   maxiberta  -
ubuntu-core  16.04+20160531.11-53  125  canonical  -


Anyway, another  great tool for the Power ecosystem.

Compiling Jessie kernel with newer toolchain

If you compile Debian Jessie kernel, or any kernel older than 4.2, using a newer toolchain (GCC or Advance Toolchain), you might hit this problem:

/«PKGBUILDDIR»/arch/powerpc/kernel/vdso32/gettimeofday.S: Assembler messages:
/«PKGBUILDDIR»/arch/powerpc/kernel/vdso32/gettimeofday.S:42: Error: syntax error; found `@', expected `,'
/«PKGBUILDDIR»/arch/powerpc/kernel/vdso32/gettimeofday.S:42: Error: junk at end of line: `@local'
/«PKGBUILDDIR»/arch/powerpc/kernel/vdso32/gettimeofday.S:48: Error: syntax error; found `@', expected `,'
/«PKGBUILDDIR»/arch/powerpc/kernel/vdso32/gettimeofday.S:48: Error: junk at end of line: `@local'
/«PKGBUILDDIR»/arch/powerpc/kernel/vdso32/gettimeofday.S:83: Error: syntax error; found `@', expected `,'
/«PKGBUILDDIR»/arch/powerpc/kernel/vdso32/gettimeofday.S:83: Error: junk at end of line: `@local'
/«PKGBUILDDIR»/arch/powerpc/kernel/vdso32/gettimeofday.S:87: Error: syntax error; found `@', expected `,'
/«PKGBUILDDIR»/arch/powerpc/kernel/vdso32/gettimeofday.S:87: Error: junk at end of line: `@local'
/«PKGBUILDDIR»/arch/powerpc/kernel/vdso32/gettimeofday.S:195: Error: syntax error; found `@', expected `,'
/«PKGBUILDDIR»/arch/powerpc/kernel/vdso32/gettimeofday.S:195: Error: junk at end of line: `@local'
make[7]: *** [arch/powerpc/kernel/vdso32/gettimeofday.o] Error 1
/«PKGBUILDDIR»/arch/powerpc/kernel/vdso32/Makefile:42: recipe for target 'arch/powerpc/kernel/vdso32/gettimeofday.o' failed
make[6]: *** [arch/powerpc/kernel/vdso32] Error 2
make[5]: *** [arch/powerpc/kernel] Error 2
make[5]: *** Waiting for unfinished jobs....
/«PKGBUILDDIR»/scripts/Makefile.build:403: recipe for target 'arch/powerpc/kernel/vdso32' failed
/«PKGBUILDDIR»/Makefile:951: recipe for target 'arch/powerpc/kernel' failed

This problem happens because newer toolchain does not allow code generation targeting 32 bits Little Endian, and the kernel code was trying to use it for VDSO.

This problem was later solved by the following commit in kernel 4.2:

commit e0d0059169945c8ee16790d2e7244cea397dfd56
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Mon May 11 20:01:02 2015 +1000

powerpc/vdso: Disable building the 32-bit VDSO on little endian

The only little endian configuration we support is ppc64le. As such if
we’re building little endian we don’t need a 32-bit VDSO, because there
is no 32-bit userspace.

This patch is a fairly ugly mess of #ifdefs, but is the minimal logic
required to disable the 32-bit VDSO. We can hopefully clean up the
result in future with some further refactoring.

Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>

In order to circumvent this problem, you have three options:

  1. Cherry pick this commit into your old kernel, as being worked in Debian bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785065
  2. Move to a newer kernel (newer than 4.2)
  3. Use an older toolchain (4.8), that does not block code generation for 32-bits LE.


Kernel failure

I frequently see users trying to compile the kernel for ppc64el and facing a very common problem that is related to an assembly instruction that does not have an operand.

arch/powerpc/kernel/swsusp_asm64.S: Assembler messages:
arch/powerpc/kernel/swsusp_asm64.S:188: Error: missing operand
scripts/Makefile.build:293: recipe for target ‘arch/powerpc/kernel/swsusp_asm64.o’ failed
make[1]: *** [arch/powerpc/kernel/swsusp_asm64.o] Error 1
Makefile:907: recipe for target ‘arch/powerpc/kernel’ failed
make: *** [arch/powerpc/kernel] Error 2

It happens due to the following instruction tlbia not having an argument. It was added in commit 543b9fd3

This is also widely discussed in the wild. Anyway, if you face this problem, it is because you have CONFIG_HIBERNATION=y, and you turned it off, as, using:


We changed it for Ubuntu in the following bug.

Daily tests

It is all know that Debian and Ubuntu makes ISO builds every day, these builds contain the latest code available burned in a ISO image.

We* created an infrastructure, called  Daily Automation Tool, that tests the installation of these builds on ppc64el platform using different methods.

These are the builds we are testing daily:


  • Ubuntu 16.10 (Yakety Yak)
  • Ubuntu 16.04 (Xenial Xerus)
  • Ubuntu 14.04 (Trusty Thar)


  • Debian testing
  • Debian 9.0 (Stretch)

Everyday all these builds are installed on different type of hypervisor on Power, using different file systems. This is hypervisor that are being tested:

  • KVM guest
  • PowerVM
  • Bare Metal (Still being implemented)

These are the following file system paths that are being exercised:

  • Ext4
  • LLVM

This is an example of the tests that ran earlier today.


You can check this tool on the “Automated tests” menu above, or, following the direct link.

* This worked was done, in fact, by Erwan Prioul

Keeping my system updated automatically

It is all known that packages are upgraded daily in Ubuntu and Debian world. This is based on how Ubuntu and Debian works, and I personally like it.

The only nuisance is you need to upgrade your system frequently, otherwise you are going to use old package versions, making it difficult to report bugs, and also, being exposed to security vulnerabilities.

There is a solution on how to ask your system to automatically check for new packages, download and install them automatically.

I usually do that on my system. In order to do that, you need to install a package called cron-apt. Cron-apt, by defaul, only downloads packages which means that the actual installation must be done manually.

# apt-get install cron-apt

If you want to be install the packages automatically, you just need to add the upgrade or dist-upgrade line to be executed by the cron-apt. This is how I do this:

# echo dist-upgrade -d -y -o APT::Get::Show-Upgraded=true >> /etc/cron-apt/action.d/3-download

In this example, the system is dist-upgraded every day at 4:00 AM, as showed in the cron-apt cron entry:

$ cat /etc/cron.d/cron-apt

0 4    * * *    root    test -x /usr/sbin/cron-apt && /usr/sbin/cron-apt