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;
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: firstname.lastname@example.org,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.
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 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.
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.
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: *** [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: *** [arch/powerpc/kernel/vdso32] Error 2
make: *** [arch/powerpc/kernel] Error 2
make: *** 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:
Author: Michael Ellerman <email@example.com>
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 <firstname.lastname@example.org>
In order to circumvent this problem, you have three options:
- Cherry pick this commit into your old kernel, as being worked in Debian bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785065
- Move to a newer kernel (newer than 4.2)
- Use an older toolchain (4.8), that does not block code generation for 32-bits LE.
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: *** [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.
Finally Ubuntu KVM is going to have support for Dynamic DMA Window. The package is at the ubuntu-virt PPA and you can learn on how to install it following these steps.
PS: At this moment, due to a problem the package is not at the ppc64el repository, but will show up soon.
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
- Bare Metal (Still being implemented)
These are the following file system paths that are being exercised:
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
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
I wrote an article on how to tune a 10Gbps NIC performance on Linux on Power. Although it is 7 years old, it is still valid and I still see a lot of references to it, and still receive mails about it.