Ubuntu 18.04 netplan on multiples interfaces

Ubuntu 18.04 deprecated ifupdown package to configure the network. Instead, they moved to a much more modern application called netplan.

Today I needed to modernize my machine configuration, and I moved from ifupdown configuration to netplan.

I had the following file:

# cat /etc/network/interfaces
# The primary network interface
auto eth0
iface eth0 inet static
 address 9.3.3.XX
 gateway 9.3.3.XX
 # dns-* options are implemented by the resolvconf package, if installed
 dns-nameservers 9.3.1.YY
 dns-search foo.bar.ibm.com

auto eth2
iface eth2 inet static
 mtu 9000

auto eth4
iface eth4 inet static
 mtu 9000

Moving to netplan is quite simple, I just moved to:

# cat /etc/netplan/01-netcfg.yaml
 version: 2
 renderer: networkd
 dhcp4: no
 addresses: [9.3.3.XX/24]
 gateway4: 9.3.3.X
 addresses: [9.3.1.YY,]

 addresses: []
 mtu: 9000

 addresses: []
 mtu: 9000

After this move, you just need to run netplan apply and you should start to use the newer mechanism.

You can also migrate the scripts from ifupdown to netplan meachnism automatically using netplan ifupdown-migrate command.

PS: If you see errors like `uknown key addrress` means you have something on that block. For example, if I write addresseZ instead of addresses on eth2 block, then I will see the following error points to the  ‘eth2‘ line (Line XX below), but in fact, the error would be on line XX + 1 instead of XX

Error in network definition //etc/netplan/01-netcfg.yaml line XX column Y: unknown key addresss


SSH pubkey authentication

Today I found a weird problem on my systems, where one of the system was not able to use pubkey SSH authentication, although the private key and authorized keys were properly set. Also, all the permissions were correct.

After checking it several times, I was not able to ssh, and this was annoying me:

sid ➜ ~ ssh-copy-id breno@
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: “/home/brenohl/.ssh/id_rsa.pub”
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed — if you are prompted now it is to install the new keys
breno@’s password:

Number of key(s) added: 1

Now try logging into the machine, with: “ssh ‘breno@′”
and check to make sure that only the key(s) you wanted were added.

sid ➜ ~ ssh-copy-id breno@
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: “/home/brenohl/.ssh/id_rsa.pub”
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed — if you are prompted now it is to install the new keys
breno@’s password:

I was also having the same issue on github authentication. Looking at the logs it just show something that does not help a lot.
Client side:

debug2: key: /home/brenohl/.ssh/id_rsa (0x1000d9ff370)
debug2: key: /home/brenohl/.ssh/id_dsa ((nil))
debug2: key: /home/brenohl/.ssh/id_ecdsa ((nil))
debug2: key: /home/brenohl/.ssh/id_ed25519 ((nil))
debug3: send packet: type 5
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup gssapi-keyex
debug3: remaining preferred: gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-keyex
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug2: we did not send a packet, disable method
debug3: authmethod_lookup gssapi-with-mic
debug3: remaining preferred: publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure. Minor code may provide more information
debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/brenohl/.ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 60
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug2: input_userauth_pk_ok: fp SHA256:kA9jpmFpb7LbwIplSpr3JishbUwY/A0vH43xrKg98bY
debug3: sign_and_send_pubkey: RSA SHA256:kA9jpmFpb7LbwIplSpr3JishbUwY/A0vH43xrKg98bY
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Trying private key: /home/brenohl/.ssh/id_dsa

Although very verbose, I was not able to find anything useful. Then I tried to debug the server side, which was showing the following log:

Jan 08 09:45:07 debra sshd[14332]: error: RSA_public_decrypt failed: error:0407006A:lib(4):func(112):reason(106)

Looking at this 106 reason, I found something very weird, since my pubkey at the client was wrong. I was not expecting that the pubkey in the client would have any influence in the authentication with the server.

I would expect that the client uses the private key, and the server uses the pubkey, but there is a validation and if your pubkey in the client is wrong, you might face this issue.

The solution was basically removing the wrong pubkey in the client, and then I was able to ssh into the server without any issue.



Cscope on FreeBSD

I definitely can’t survive without cscope. Now that I am hacking FreeBSD, I was not able to find `make cscope` as we have in Linux.

Thus, I created this very simple script to index the whole FreeBSD kernel.

find . -name "*.[chxsS]" -print | grep -v arm64 | grep -v riscv | grep -v x86 | grep -v i386 | grep -v mips> cscope.files
cscope -q -b -k cscope.files

pwndbg – A nice pluging for GDB

I spend a lot of my day on GDB trying to catch some bugs. I found a very nice plugin for GDB that is helping me a lot, it is called pwndbg.

pwndbg (/poʊndbæg/) is a GDB plug-in that makes debugging with GDB suck less, with a focus on features needed by low-level software developers, hardware hackers, reverse-engineers and exploit developers.

This is the new face for pwndbg. It shows part of the assembly, the source, the stack and the backtrace. It could be redefined if you do not like.


It also has a lot of helpers. The one I found very useful the the register dumps, called `regs`. It show where each register is pointing to. This is an example:



Anyway, this is a nice tool that might help you on ppc64el debugging. Please find more info about it at:


Float clobbering on inline asm

On inline assembly, I spent some time trying to clobber float registers on inline assembly.

I was trying to clobber a float register, and I was getting:

unknown register name ‘f10’ in ‘asm’

After some debugging I found that the float registers should be clobbered as fr, so, here is an example where we are using and clobbering Counter Register, Conditional register, VSX and FP registers.

asm (
 // prepare to merge low and high
 "mtvsrd 33, %[high_vs0] ;"
 "mtvsrd 34, %[low_vs0] ;"


// vs0 = 0x5555555555555555555FFFFFFFFFFFFFFFF
 "xxmrghd 0, 33, 34 ;"


// vs32 = 0x5555555555555555555FFFFFFFFFFFFFFFF
 "xxmrghd 32, 33, 34 ;"

 * Wait an amount of context switches so load_fp and load_vec
 * overflow and MSR.FP, MSR.VEC, and MSR.VSX become zero (off).
 "mtctr %[counter];"
 "1: bdnz 1b ;" /*Decrement CTR branch if CTR non zero */

 * Do or don't touch FP prior to the test.
 * set MSR.FP = 1 before provoking a unavailable in TM
 * exception
 "cmpldi %[test_fp],0;"
 "beq no_fp ;"
 "fadd 10,10,10 ;"
 "no_fp: ;"

 * Do or don't touch VEC prior to the test
 * set MSR.VEC = 1 before provoking a unavailable in TM
 * exception
 "cmpldi %[test_vec],0;"
 "beq no_vec ;"
 "vaddcuw 10, 10, 10 ;"
 "no_vec: ;"

 * Perhaps it would be a better idea to do the
 * compares outside transactional context and simply
 * duplicate code
 "tbegin. ;"
 "beq trans_fail;"

/* Do we do FP unavailable? */
 "cmpldi %[exception],%[ex_fp];"
 "bne 1f ;"
 "fadd 10,10,10 ;"
 "b done ;"

/* Do we do VEC unavailable? */
 "1: cmpldi %[exception],%[ex_vec];"
 "bne 2f ;"
 "vaddcuw 10,10,10 ;"
 "b done ;"

 * Not FP or VEC, therefore VSX. Ensure this
 * instruction always generates a VSX Unavailiable.
 * ISA 3.0 is tricky here.
 * (xxmrghd will on 2.07 and 3.0)
 "2: xxmrghd 10,10,10;"

"done: tend. ;"
 "trans_fail: ;"

/* Give values back to C */
 "mfvsrd %[high_vs0],0 ;"
 "xxsldwi 3,0,0,2 ;"
 "mfvsrd %[low_vs0],3 ;"
 "mfvsrd %[high_vs32],32 ;"
 "xxsldwi 3,32,32,2 ;"
 "mfvsrd %[low_vs32],3 ;"

/* Give CR back to C so that it can check what happend */
 "mfcr %[counter];"

: [high_vs0] "+r" (high_vs0),
 [low_vs0] "+r" (low_vs0),
 [high_vs32] "=r" (high_vs32),
 [low_vs32] "=r" (low_vs32),
 [counter] "+r" (counter)
 : [test_fp] "r" (flags.test_fp),
 [test_vec]"r" (flags.test_vec),
 [exception]"r" (flags.exception),
 [ex_fp] "i" (FP_UNA_EXCEPTION),
 [ex_vec] "i" (VEC_UNA_EXCEPTION),
 [ex_vsx] "i" (VSX_UNA_EXCEPTION)

 * It is a mystery to me as to why "f10" doesn't work
 * in the clobbers
 : "cr0", "ctr", "v10", "vs0", "vs10", "vs3", "vs32", "vs33", "vs34", "fr10"

Alpine supports on Power

I am pleased to announce the Alpine Linux distribution has added support for Power systems with the recent release of Alpine 3.6.

Alpine uses different approaches[1] than traditional Linux distros, thus, they were able to build a very small footprint Linux image. Version 3.6 minirootfs for Power contains less than 2Mb[2]. This small footprint capability makes it heavily favored in the containers realm[3].

Please check the Release Notes for the 3.6 release:


For technical questions, please check the Community page[4].


Boot and stop at petitboot

Depending on how you configured your POWER8 petitboot, you might want it to skip the kernel selection and boot on the default kernel.

If your default kernel is having any issue, and you want to re-select it, or, just drop at Petitboot for some other management changes, you can ask IPMI to stops at petitboot, and do not load the default kernel.

In order to do so, you should use the following ipmi command:

ipmitool -H   Host  -I lanplus  -U USER -P PASSWORD chassis bootdev bios


Installing NGNIX on FreeBSD/powerpc64


As you might know, FreeBSD is also running on IBM POWER8 processor.

I just installed FreeBSD 11.0 on a VM, and installed NGINX. At this moment, FreeBSD does not have the pkg infrastructure for powerpc64, so, you need to use the ports infrastructure to install any software.

I tested it and everything I tried to build (git, zsh, vim, etc) worked fine.

This is the receipt on how to install NGINX after you install the base image:

# portsnap fetch
# portsnap update
# cd /usr/ports/www/ngninx
# make install clean

After that, NGINX will be installed on your system, and you could enable it adding the following line to /etc/rc.conf: