My work on Kolla

During last month I was working on one of OpenStack projects: Kolla. My job was adding support for non-x86 architectures: aarch64 and ppc64le. Also resurrecting Debian support.

A bit of background

At Linaro we work on getting AArch64 (64-bit ARM, arm64) to be present in many places. We have at least two OpenStack instances running at the moment – on AArch64 hardware only.

First we used Debian/jessie and Openstack ‘liberty’ version. Was working. Not best but we helped many projects by providing virtual machines for porting software.

It was built from packages and later (when ‘mitaka’ was released) we moved to virtualenv per component. Out second “cloud” runs that. With proper Neutron networking, live migration and few other nice things.

But virtualenvs were done as quick solution. We decided to move to Docker containers for next release.

And Kolla was chosen as a tool for it. We do not like to reinvent the wheel again and again…

Non-x86 support in Kolla

The problem was typical: Kolla being x86-64 centric. As most of software nowadays. But thanks to work done by Sajauddin Mohammad I had something to use as a base for adding aarch64 support.

I took his patch, slashed out most of it and concentrated on getting minimal changes needed to get something built on AArch64 . Effect was sent for review and is now at 10th version.

Docker images started to appear. But at beginning I was building Ubuntu ones as Debian support was “basically abandoned, on a way out”. From CentOS guys I got confirmation that official Docker image will be generated (it is done already).

I spent some time on making sure that whole non-x86 support is free from any hardcoding wherever possible. As you can see in my working branch it went quite well. Most of arch related changes are related to “distro does not provide package ZYS for that architecture” or to handling of external repositories.

Debian support

And here we come to Debian support. At Linaro we decided to support two community based distributions: CentOS and Debian. But Debian was on a way out in Kolla…

As this was not related much to non-x86 work I decided to use one of x86-64 machines for that stuff.

First builds were against ‘jessie-backports’ base tag. I had to make a patch to tell APT that if I want backports then I really want them. It was sent for review as rest of patches.

Images were building but not so many as for Ubuntu. So I went through all of them and enabled Debian where it was possible. Resulting patch went for review as usual.

Effect was quite nice (on x86-64):

  • debian-binary: 158
  • debian-source: 201

But ‘jessie’ was missing several packages even with backports enabled. So after discussion with my team I decided to drop it and go for Debian/testing ‘stretch’ one instead. It is already frozen for release so no big changes are allowed. Patch in review of course.

At that moment I abandoned one of previous patches as ‘jessie-backports’ was not something I planned to support.

Turned out that ‘stretch’ images have a bit different set of packages installed than ‘jessie’ had. So ‘gnupg’ and ‘dirmngr’ were missing while we need them for importing GPG keys into APT. Proper patch went to review again.

Did rebuild on x86-64:

  • stretch-binary: 137
  • stretch-source: 195

A bit less than ‘jessie-backports’ had, right? Sure, but it also shows that I have to make a new build to check numbers (laptop already has ~1500 docker images generated by kolla).

Cleaning of old Power patch

Remember the patch which all that started from? I did not forgot it and after building all those images I went back to it.

Some parts are just fugly so I skipped them but others were useful if done properly. That’s how new changes were done and some updates to previous ones.

Then I managed to put remote hands on one of Power machines at Red Hat and started builds:

  • debian-binary: 134
  • debian-source: 184
  • ubuntu-binary: 147
  • ubuntu-source: 190

No CentOS builds as there was no centos/ppc64le image available.


Non-x86 support looks quite nice. There are some images which can not be built as they rely on external repositories so no aarch64 nor ppc64le packages to use.

Debian ‘stretch’ support is not perfect yet but it is something which I plan to maintain so situation will be going to improve. Note that most of my work will go into ‘source’ type of builds as we want to have same images for both Debian and CentOS systems.

Fresh WordPress

I am running my blog for nearly 12 years now. And through all those years it was running same WordPress installation. Until today.

At beginning it was WordPress MultiUser (WPMU) as I used it to run both my blog and website for my consulting company. It was fun. Some WP plugins were working with WPMU, some not. Then WordPress developers decided to merge both projects into one. And it was good.

When I started blogging I did not used categories for posts but tagged them instead. Months turned into years and at some moment WP got tags natively so UltimateTagWarrior plugin went to trash (after converting to WP tags).

I was changing blog theme every few years to bring some change. The other thing which was changing was http server – from Apache to Lighttpd and now it is powered by Nginx + PHP-fpm.

Company website got trashed in meantime. Our wedding page appeared for few months as other blog. There was map with all required placemarks for church, flower shops, family homes, hotels and other useful services. Wish list for those who wanted to know what to give was also present. With “sepulki” as last entry — no one knows what “sepulki” are as they appear in one of Lem’s books. The only known thing is that you need to be married to be allowed to use them. Some guests had interesting ideas for it ;D

At some moment I had a page with Mira’s photos. Page required registration and logging. Long time removed.

And then Ania (my wife) requested page for her psychotherapist services. So she got it.

At some moment I was running three different domains using one WP installation. It was mess. Terrible mess. At some moment there were authorization issues so I had to change something…

So now I have fresh WordPress installed. Websites partially restored from backup to not keep settings/tables from long time not used plugins. Hope it will work fine ;D

2016: computer museums

During previous year I visited some computer related museums. Not every I planned to but still there were a few of them.

Faculty of Information Technology, Brno

In February, during conference, I visited their small “IT Museum” where several machines used in Czechoslovakia were presented.

There were mainframe setups, several storage units and operating memories from different decades.

80s (and 90s) called with several ZX Spectrum clones, PMD-85 with it’s clones and some other microcomputers from this side of Iron Curtain.

It was nice place to visit even just to see all those computers made in Czechoslovakia.

For more photos please go to my “2016-02 it museum” album.

Technical Museum, Warsaw

In April I came to Warsaw for OpenSource day conference. And visited Technical Museum there to see some Polish computers of mainframe era.

There were many interesting machines. One of them was AKAT-1, the first transistor-based differential equation analyzer:

Other was K-202 — first Polish 16bit computer. Never became popular due to being shutdown by goverment.

Few years later Mera 400 was released. It used K-202 technology:

There were also few Odra systems:

For full resolution photos go to my Muzeum techniki w Warszawie album.

The National Museum Of Computing, Bletchley Park

May came. I went to UK to visit Bletchley Park. Awesome place to visit. And right next to it is The National Museum Of Computing (TNMOC in short).

Inside there is history. I mean HISTORY.

By mistake I entered museum through wrong door and started from oldest exhibition. It was showing the story of breaking Lorentz code used by Germany during second world war. And hardware designed for it. Contrary to Enigma there was no Lorentz machines in Allies possession.

Rebuild of British Tunny Machine:

Rebuild of Heath Robinson machine:

Next to it was room with working replica of first computer: Colossus.

And here you can see it running:


There were several other computers of course. I saw ICL 2900 system, several Elliotts and PDP systems, some IBM machines and others from 50-70s.

One of them was Harwell Dekatron Computer (also known as WITCH). It is oldest working computer:

Then there was wide selection of microcomputers from 80s and 90s. Several British ones and others from anywhere else. There was a shelf with Tube extensions for BBC Micro but it lacked ARM1 one:

For full resolution photos check my The National Museum Of Computing album.

The Centre for Computing History, Cambridge

This museum was on my list for far too long. When I was in Cambridge few years ago it was closed. Next time I did not managed to find time to go there. Finally, during last Linaro sprint, we agreed that we have to go there and we went during lunch break.

For me the main reason of going there was my wish to see ARM1 cpu. It was available only as Tube (extension board for BBC Micro) and only for some selected companies which makes it quite rare.

The first thing I saw after entering museum was “Macroprocesor”. Imagine CPU in size of 70s mainframe with LED on each line, register bit etc.

Next room was arranged in a form of British classroom. Set of BBC Micro computers arranged with monitors, manuals, programs.

And then I went to look around. There were many different computers shown. Some behind glass, some turned on with possibility to play with them (or on them). It was opportunity to see how design was changing through all those years.

There were also several Acorn machines — both ARM and 6502 powered ones.

As most of computer museums that one also has some exclusive content. This time it was NeXT workstation which was used as first web server by Tim Berners-Lee:

And Apple Macintosh SE 30 owned by Douglas Adams, author of “Hitchhiker Guide to the Galaxy”. Note a towel on top of computer:

Other interesting thing was comparison of storage density through all those years. Note 5MB hard drive being loaded into plane in top right corner.

And again — for more pictures and higher resolution visit my The Centre for Computing History album.

2017 plans

In 2017 I would like to visit Computer History Museum in Mountain View and museum in Paderborn. Maybe something more 😉

Nokia and their standard batteries

Nokia. A company everyone knows and most of us probably even used one of their phones in past. They were better or worse but one thing was good – most of them shared batteries…

My daughter (8.5y old) uses Nokia E50 as her daily phone. Sim card is covered by duct tape to not fall out when phone hit a floor (previous one went missing in such situation). Mira records how she and her friends sing, does some photo sessions to her dolls etc.

But during weekend phone stopped charging. Hm… Is it charger? Nope, it was original Nokia one. Tried some crappy Chinese one with same result. So let’s check the battery.

Opened drawer, took Nokia 101. Inside was BL-5CB battery. Inserted into E50 got phone back online. But I like my 101 and keep it as a spare just in case.

Digged in a drawer with old devices. The one where I keep Sharp Zaurus c760, Sony Ericsson k750i, Openmoko FIC-GTA01bv3 and few other pieces of junk with some sentimental value. What I found there was Nokia 6230i which I got from Ross Burton during GUADEC 2007. Last time I used it about 5 years ago. But it had original Nokia BL-5C inside!

So I put that battery inside of E50, plugged charger and guess what… It started charging and phone booted! With over 11 years old battery!

During next few days I will buy BL-5C clone somewhere (they are 3-8€ now) and put it in my daughter’s phone.

System calls again

Few months ago I created a page with HTML table. For own use basically. Then presented it to the people and found out that it got useful for them. So started improving and improving so it became side project.

Yes, system calls again. I wrote about it in past but yesterday I rewrote code so it now uses Linux source so I can generate tables for far more architectures without need of other computers (either real or emulated).

Next step was work on presentation layer. Old version was just table with added sorting. Things were ugly when scrolled as header was gone. Now it sticks to the top of page so it is easier to note which column relates to which architecture.

Odd/even lines are coloured now which makes is easier to find numbers for syscall.

And speaking of searching — there is filter box now. You can type syscall name (or part of it) there and have table filtered. Same can be done with system call number as well. You used Valgrind and it said that has no idea how to handle syscall 145? Just enter number and you see that it is getresuid(), nfsservctl(), readv(), sched_getscheduler(), setreuid() or setrlimit() — depends which architecture you are testing.

You wonder what that that system call does? There are links to man pages provided.

Go here to check it out and comment here, open a new issue if you found a bug or would like to colaborate. Patches are welcome.

Linaro Connect: interesting hardware

Before going for Linaro Connect I had a plan to look at all those 96boards devices and write some complains/opinions about them. But it would be like shooting fish in a barrel so I decided against. But there were some interesting pieces of hardware there.

One of them was Macchiatobin board from SolidRun. I think that this is same as their Armada 8040 community board but after design changes. Standard Mini-ITX format, quad core Cortex-A72 cpu (with upto 2GHz clock), one normal DIMM slot (max 16GB, ships with 4GB), three Serial-ATA ports, PCI-Express x4 slot, one USB 3.0 port, microSD slot.

UPDATE: SolidRun confirmed – this is final design of their Armada 8040 community board.

Photo (done by Riku Voipio) shows which goodies are available:

Network interfaces from top to bottom are (if I remember correctly):

  • 10GbE (SFP + RJ-45)
  • 10GbE (SFP + RJ-45)
  • 2.5GbE (SFP)
  • 1GbE (RJ-45)

When it comes to software I was told that board is SBSA compliant so any normal distribution should work. Kernel, bootloaders (U-Boot and UEFI) are mainlined.

Price? 350USD. Looks like nice candidate for AArch64 development platform or NAS.

Other device was Gumstix Nodana 96BCE board which is 96boards complaint carrierboard for Intel Joule modules.

On top it looks like typical 96boards device (except USB C port):

But once reversed Intel Joule module is visible:

This is first non-ARM based 96boards device. Maybe even one of most compliant ones. At least from software perspective because when it comes to hardware then module makes it a bit too thick to fit in 96boards CE specification limits.

Note that 96boards Consumer Electronics specification does not require using ARM or AArch64 cpu.

Linaro Connect: Las Vegas sightseeing

One of cool things of being Linaro assignee is going to Linaro Connect conference. This time it was Las Vegas, USA. I was flying Berlin Tegel -> London Heathrow -> Las Vegas. Last part was fun as I met several Linaro folks at the airport ;D

Arrived in Vegas, went to hotel and fall asleep. Sunday was planned for some Ingress playing and for sightseeing. As usual I had several places marked on Google Maps to make things easier.

So Sunday… It was really Sun day. I took some water with me and refueled several times during day just to stay hydrated. With Las Vegas climate I was not even felt sweety as it vaporated right away…

But let’s start from beginning. I walked few hundred meters from hotel and caught public transport bus which took me to Freemont Street (or somewhere around). When I walked I felt like the only person on the Earth or in a no-go zone. There was basically no one on the street. After some walking and few photos I got asked something like “who are you and what you are doing here???” from security guy. It turned out that some part of Freemont Street (and surroundings) were closed due to some arts/music festival. I probably missed some ‘no entry’ plate…

Anyway I did not get any problems and was pointed where the gate is. Walked around, saw some places, bought souvenirs (including fridge magnet to my collection), another water bottles and decided to walk to another point on my map.

Yes, it may feel strange but I walked. And walked. And walked. Then Arts district happened.

OMG it was awesome. Deserted streets, shops with some retro furniture/stuff, shops with some crazy junk, shop with wax figures from Last Supper etc. But the best part was murals and graffitis. Lot of them, different styles and quality. I spent about 2 hours just walking there and taking photos.

Next step was the Strip. All those big hotel/casino buildings. At Circus Circus I found room with arcade machines and spent 25 cents on Galaga. In Venetian I looked at their version of Venice canals (have to go to Venice and compare one day :D). Few minutes later I saw Eiffel tower (or rather miniature version of it). Decided to skip searching for copy of Statue of Liberty and instead crossed street and went to take a look at Bellagio fountains show. Have to admit that it was nice. I saw three shows (had to sort few things around) and then took a cab back to the hotel.


More photos in Google Photos album

Linaro Connect: good to be back

One of things you do while you are at Linaro is going to Linaro Connect conferences. My previous one was 2012 Copenhagen one so it was good to be back.

All those people from different companies or projects… Some faces I recognized, some not. Several people recognized me, some said that my beard complicated it. Fun ;D

Discussions about random things, random hacking (not all Snow chromebooks are the same), talks to attend, talks to give…

And speaking of speaking — our team had a speak about OpenStack on AArch64. It was recorded but volume level is very low.


Complaining. Sure, there was some. And I got my badge upgraded just to show all those impersonators that I am back.

bagde with the main complainer text on it

There was jetlag as usual so I was a bit of excluded from evening events but those which I attended were great. Like team dinner with the Big Kahuna cheeseburger (with Sprite to drink).

Next year I have to organize trip in a way that I would do some personal sightseeing on a week before conference. According to rumours it would be in one of areas where I have some places to visit ;D

Downgrading Fedora ‘rawhide’ -> Fedora 24

Time to downgrade my main desktop finally came. This time I decided to provide more details about process as my system uses Rawhide with set of external repositories (RPM Fusion (official + my rebuilds), few COPR ones etc).

So first step is to enable caching because dnf by default erases all downloaded packages. And downgrade involves fetching many of them. Edit ‘/etc/dnf/dnf.conf’ file and add “keepcache=1” line there.

First try:

10:48 root@puchatek:hrw# dnf --releasever 24 --disablerepo rawhide --enablerepo fedora --enablerepo updates  distro-sync  --best --allowerasing
Error: package python2-deltarpm-3.6-17.fc25.x86_64 requires deltarpm(x86-64) = 3.6-17.fc25, but none of the providers can be installed.
package libcrypt-nss-2.24.90-6.fc26.x86_64 requires glibc(x86-64) = 2.24.90-6.fc26, but none of the providers can be installed.
package gmp-c++-1:6.1.1-1.fc25.x86_64 requires gmp(x86-64) = 1:6.1.1-1.fc25, but none of the providers can be installed.
package iproute-tc-4.7.0-1.fc26.x86_64 requires iproute(x86-64) = 4.7.0-1.fc26, but none of the providers can be installed.
package ffmpeg-libs-3.1.1-1.fc26.x86_64 requires, but none of the providers can be installed.
package pcre-cpp-8.39-3.fc26.x86_64 requires pcre(x86-64) = 8.39-3.fc26, but none of the providers can be installed.
package perl-libintl-perl-1.26-1.fc25.x86_64 requires perl(:MODULE_COMPAT_5.24.0), but none of the providers can be installed.
package python3-rpm-4.13.0-0.rc1.46.fc26.x86_64 requires rpm(x86-64) = 4.13.0-0.rc1.46.fc26, but none of the providers can be installed.
package systemd-pam-231-4.fc26.x86_64 requires systemd = 231-4.fc26, but none of the providers can be installed.
package libvirt-libs-2.2.0-1.fc26.x86_64 requires, but none of the providers can be installed.
package glibc-2.24.90-6.fc26.i686 requires glibc-common = 2.24.90-6.fc26, but none of the providers can be installed.
package python2-rpm-4.13.0-0.rc1.46.fc26.x86_64 requires rpm(x86-64) = 4.13.0-0.rc1.46.fc26, but none of the providers can be installed.
nothing provides needed by ffmpeg-libs-2.6.3-1.fc22.x86_64.
package ffmpeg-libs-3.1.1-1.fc26.x86_64 requires, but none of the providers can be installed

As you see there is set of blockers. One of them is “ffmpeg-libs” from RPM Fusion, others are from normal Fedora repositories. One of reasons can be that packages got split/renamed since F24. Let’s try to handle some of them:

10:52 root@puchatek:hrw# dnf --releasever 24 --disablerepo rawhide --enablerepo fedora --enablerepo updates --best --allowerasing downgrade rpm glibc
Dependencies resolved.
 Package                      Arch     Version                 Repository  Size
 rpm-python                   x86_64   4.13.0-0.rc1.27.fc24    fedora     102 k
 rpm-python3                  x86_64   4.13.0-0.rc1.27.fc24    fedora     102 k
 libcrypt-nss                 i686     2.24.90-6.fc26          @rawhide    34 k
 libcrypt-nss                 x86_64   2.24.90-6.fc26          @rawhide    36 k
 python2-rpm                  x86_64   4.13.0-0.rc1.46.fc26    @rawhide   182 k
 python3-rpm                  x86_64   4.13.0-0.rc1.46.fc26    @rawhide   190 k
 glibc                        i686     2.23.1-10.fc24          updates    4.3 M
 glibc                        x86_64   2.23.1-10.fc24          updates    3.6 M
 glibc-common                 x86_64   2.23.1-10.fc24          updates    862 k
 glibc-devel                  i686     2.23.1-10.fc24          updates    936 k
 glibc-devel                  x86_64   2.23.1-10.fc24          updates    936 k
 glibc-headers                x86_64   2.23.1-10.fc24          updates    501 k
 glibc-langpack-en            x86_64   2.23.1-10.fc24          updates    276 k
 glibc-langpack-pl            x86_64   2.23.1-10.fc24          updates    133 k
 glibc-static                 x86_64   2.23.1-10.fc24          updates    1.5 M
 rpm                          x86_64   4.13.0-0.rc1.27.fc24    fedora     513 k
 rpm-build                    x86_64   4.13.0-0.rc1.27.fc24    fedora     139 k
 rpm-build-libs               x86_64   4.13.0-0.rc1.27.fc24    fedora     117 k
 rpm-libs                     x86_64   4.13.0-0.rc1.27.fc24    fedora     295 k
 rpm-plugin-selinux           x86_64   4.13.0-0.rc1.27.fc24    fedora      54 k
 rpm-plugin-systemd-inhibit   x86_64   4.13.0-0.rc1.27.fc24    fedora      54 k

Transaction Summary
Install     2 Packages
Remove      4 Packages
Downgrade  15 Packages

Total download size: 14 M
Is this ok [y/N]: 

Went fine. So next set of blockers goes:

10:54 root@puchatek:hrw# dnf --releasever 24 --disablerepo rawhide --enablerepo fedora --enablerepo updates --best --allowerasing downgrade *deltarpm* gmp* iproute*
Dependencies resolved.
 Package                 Arch         Version              Repository      Size
 python-deltarpm         x86_64       3.6-15.fc24          fedora          37 k
 gmp-c++                 x86_64       1:6.1.1-1.fc25       @rawhide        23 k
 iproute-tc              x86_64       4.7.0-1.fc26         @rawhide       660 k
 python2-deltarpm        x86_64       3.6-17.fc25          @rawhide        44 k
 deltarpm                x86_64       3.6-15.fc24          fedora          89 k
 gmp                     i686         1:6.1.1-1.fc24       updates        305 k
 gmp                     x86_64       1:6.1.1-1.fc24       updates        315 k
 gmp-devel               x86_64       1:6.1.1-1.fc24       updates        185 k
 iproute                 x86_64       4.4.0-3.fc24         fedora         658 k
 iptables                x86_64       1.4.21-16.fc24       fedora         425 k
 iptables-services       x86_64       1.4.21-16.fc24       fedora          53 k

Transaction Summary
Install    1 Package
Remove     3 Packages
Downgrade  7 Packages

Total download size: 2.0 M
Is this ok [y/N]: y
Downloading Packages:
(1/8): deltarpm-3.6-15.fc24.x86_64.rpm          139 kB/s |  89 kB     00:00    
(2/8): gmp-6.1.1-1.fc24.x86_64.rpm              384 kB/s | 315 kB     00:00    
(3/8): gmp-6.1.1-1.fc24.i686.rpm                320 kB/s | 305 kB     00:00    
(4/8): gmp-devel-6.1.1-1.fc24.x86_64.rpm        445 kB/s | 185 kB     00:00    
(5/8): iptables-services-1.4.21-16.fc24.x86_64. 437 kB/s |  53 kB     00:00    
(6/8): python-deltarpm-3.6-15.fc24.x86_64.rpm   303 kB/s |  37 kB     00:00    
(7/8): iptables-1.4.21-16.fc24.x86_64.rpm       1.0 MB/s | 425 kB     00:00    
(8/8): iproute-4.4.0-3.fc24.x86_64.rpm          1.1 MB/s | 658 kB     00:00    
Total                                           475 kB/s | 2.0 MB     00:04     
Running transaction check
Transaction check succeeded.
Running transaction test
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: Transaction check error:
  file /usr/lib64/ from install of iptables-1.4.21-16.fc24.x86_64 conflicts with file from package iptables-libs-1.6.0-2.fc25.x86_64
  file /usr/lib64/ from install of iptables-1.4.21-16.fc24.x86_64 conflicts with file from package iptables-libs-1.6.0-2.fc25.x86_64
  file /usr/lib64/ from install of iptables-1.4.21-16.fc24.x86_64 conflicts with file from package iptables-libs-1.6.0-2.fc25.x86_64

Error Summary

So let’s go level deeper with packaging:

10:56 root@puchatek:packages# rpm -e iptables-libs
error: Failed dependencies:
        iptables-libs(x86-64) = 1.6.0-2.fc25 is needed by (installed) iptables-1.6.0-2.fc25.x86_64 is needed by (installed) iptables-1.6.0-2.fc25.x86_64 is needed by (installed) systemd-231-4.fc26.x86_64 is needed by (installed) systemd-container-231-4.fc26.x86_64 is needed by (installed) iptables-1.6.0-2.fc25.x86_64 is needed by (installed) iptables-1.6.0-2.fc25.x86_64 is needed by (installed) iproute-tc-4.7.0-1.fc26.x86_64
10:57 root@puchatek:packages# rpm -e iptables-libs --nodeps iproute-tc
10:57 root@puchatek:packages# rpm --oldpackage -U iptables-1.4.21-16.fc24.x86_64.rpm

And repeat previous dnf command as it works this time.

So next set of blockers has to go:

11:00 root@puchatek:packages# dnf --releasever 24 --disablerepo rawhide --enablerepo fedora --enablerepo updates --best --allowerasing downgrade systemd* libvirt* pcre*
Dependencies resolved.
 Package                           Arch     Version            Repository  Size
 systemd-compat-libs               x86_64   229-13.fc24        updates    152 k
 libvirt-libs                      x86_64   2.2.0-1.fc26       @rawhide    22 M
 pcre-cpp                          x86_64   8.39-3.fc26        @rawhide    39 k
 perl-Sys-Virt                     x86_64   2.2.0-1.fc26       @rawhide   824 k
 systemd-pam                       x86_64   231-4.fc26         @rawhide   282 k
 libvirt                           x86_64     updates     47 k
 libvirt-client                    x86_64     updates    4.4 M
 libvirt-daemon                    x86_64     updates    619 k
 libvirt-daemon-config-network     x86_64     updates     47 k
 libvirt-daemon-config-nwfilter    x86_64     updates     50 k
 libvirt-daemon-driver-interface   x86_64     updates     90 k
 libvirt-daemon-driver-libxl       x86_64     updates    163 k
 libvirt-daemon-driver-lxc         x86_64     updates    724 k
 libvirt-daemon-driver-network     x86_64     updates    241 k
 libvirt-daemon-driver-nodedev     x86_64     updates     89 k
 libvirt-daemon-driver-nwfilter    x86_64     updates    114 k
 libvirt-daemon-driver-qemu        x86_64     updates    528 k
 libvirt-daemon-driver-secret      x86_64     updates     82 k
 libvirt-daemon-driver-storage     x86_64     updates    274 k
 libvirt-daemon-driver-uml         x86_64     updates     98 k
 libvirt-daemon-driver-vbox        x86_64     updates    197 k
 libvirt-daemon-driver-xen         x86_64     updates    161 k
 libvirt-daemon-kvm                x86_64     updates     46 k
 libvirt-daemon-qemu               x86_64     updates     46 k
 libvirt-python                    x86_64   1.3.3-3.fc24       updates    255 k
 pcre                              i686     8.39-3.fc24        updates    413 k
 pcre                              x86_64   8.39-3.fc24        updates    404 k
 pcre-devel                        x86_64   8.39-3.fc24        updates    544 k
 pcre2                             x86_64   10.21-6.fc24       updates    414 k
 qemu                              x86_64   2:2.6.1-1.fc24     updates     63 k
 qemu-common                       x86_64   2:2.6.1-1.fc24     updates    323 k
 qemu-img                          x86_64   2:2.6.1-1.fc24     updates    828 k
 qemu-kvm                          x86_64   2:2.6.1-1.fc24     updates     62 k
 qemu-system-aarch64               x86_64   2:2.6.1-1.fc24     updates    2.5 M
 qemu-system-alpha                 x86_64   2:2.6.1-1.fc24     updates    1.9 M
 qemu-system-arm                   x86_64   2:2.6.1-1.fc24     updates    2.5 M
 qemu-system-cris                  x86_64   2:2.6.1-1.fc24     updates    1.4 M
 qemu-system-lm32                  x86_64   2:2.6.1-1.fc24     updates    1.4 M
 qemu-system-m68k                  x86_64   2:2.6.1-1.fc24     updates    1.9 M
 qemu-system-microblaze            x86_64   2:2.6.1-1.fc24     updates    2.7 M
 qemu-system-mips                  x86_64   2:2.6.1-1.fc24     updates    8.4 M
 qemu-system-moxie                 x86_64   2:2.6.1-1.fc24     updates    1.4 M
 qemu-system-or32                  x86_64   2:2.6.1-1.fc24     updates    1.4 M
 qemu-system-ppc                   x86_64   2:2.6.1-1.fc24     updates    6.8 M
 qemu-system-s390x                 x86_64   2:2.6.1-1.fc24     updates    1.7 M
 qemu-system-sh4                   x86_64   2:2.6.1-1.fc24     updates    3.7 M
 qemu-system-sparc                 x86_64   2:2.6.1-1.fc24     updates    3.3 M
 qemu-system-tricore               x86_64   2:2.6.1-1.fc24     updates    1.4 M
 qemu-system-unicore32             x86_64   2:2.6.1-1.fc24     updates    1.4 M
 qemu-system-x86                   x86_64   2:2.6.1-1.fc24     updates    4.5 M
 qemu-system-xtensa                x86_64   2:2.6.1-1.fc24     updates    2.7 M
 qemu-user                         x86_64   2:2.6.1-1.fc24     updates    8.3 M
 systemd                           x86_64   229-13.fc24        updates    5.1 M
 systemd-container                 x86_64   229-13.fc24        updates    1.0 M
 systemd-devel                     x86_64   229-13.fc24        updates    288 k
 systemd-libs                      i686     229-13.fc24        updates    482 k
 systemd-libs                      x86_64   229-13.fc24        updates    457 k
 systemd-udev                      x86_64   229-13.fc24        updates    1.2 M
 xen-libs                          x86_64   4.6.3-4.fc24       updates    574 k

Transaction Summary
Install     1 Package
Remove      4 Packages
Downgrade  54 Packages

Total download size: 80 M
Is this ok [y/N]:


Error: Transaction check error:
  file /usr/lib64/ from install of pcre-8.39-3.fc24.x86_64 conflicts with file from package pcre-utf32-8.39-3.fc26.x86_64
  file /usr/lib64/ from install of pcre-8.39-3.fc24.x86_64 conflicts with file from package pcre-utf16-8.39-3.fc26.x86_64

Let’s go back to rpm:

11:14 root@puchatek:packages# rpm -e pcre-utf16 pcre-utf32 --nodeps  
11:14 root@puchatek:packages# dnf --releasever 24 --disablerepo rawhide --enablerepo fedora --enablerepo updates --best --allowerasing downgrade -y "pcre*"    
Dependencies resolved.
 Package            Arch           Version               Repository        Size
 pcre-cpp           x86_64         8.39-3.fc26           @rawhide          39 k
 pcre               i686           8.39-3.fc24           updates          413 k
 pcre               x86_64         8.39-3.fc24           updates          404 k
 pcre-devel         x86_64         8.39-3.fc24           updates          544 k
 pcre2              x86_64         10.21-6.fc24          updates          414 k

Transaction Summary
Remove     1 Package
Downgrade  4 Packages

Total size: 1.7 M
Downloading Packages:

Now previous dnf command succeddes.

Last blocker is “perl-libintl-perl” package. In F24 it was named “perl-libintl” so dnf is not able to handle downgrading. Simplest way is removal of it. Will install removed packages later.

11:23 root@puchatek:packages# dnf remove perl-libintl-perl                      Dependencies resolved.
 Package                      Arch   Version                     Repository
 libpaper                     x86_64 1.1.24-12.fc24              @rawhide  83 k
 mutt                         x86_64 5:1.7.0-1.fc26              @rawhide 5.4 M
 perl-Class-Inspector         noarch 1.28-15.fc25                @rawhide  57 k
 perl-Class-Method-Modifiers  noarch 2.12-3.fc25                 @rawhide 100 k
 perl-Class-MethodMaker       x86_64 2.24-6.fc25                 @rawhide  20 M
 perl-Convert-BinHex          noarch 1.125-3.fc25                @rawhide  98 k
 perl-Data-Perl               noarch 0.002009-7.fc25             @rawhide  89 k
 perl-Devel-GlobalDestruction noarch 0.13-7.fc25                 @rawhide  17 k
 perl-Exporter-Tiny           noarch 0.042-6.fc25                @rawhide  78 k
 perl-File-ShareDir           noarch 1.102-7.fc25                @rawhide  19 k
 perl-Filter-Simple           noarch 0.92-365.fc25               @rawhide  50 k
 perl-GnuPG-Interface         noarch 0.52-5.fc25                 @rawhide 136 k
 perl-Import-Into             noarch 1.002005-3.fc25             @rawhide  20 k
 perl-List-MoreUtils          x86_64 0.416-1.fc25                @rawhide 200 k
 perl-MIME-tools              noarch 5.508-1.fc26                @rawhide 508 k
 perl-MailTools               noarch 2.18-2.fc25                 @rawhide 193 k
 perl-Moo                     noarch 2.002004-1.fc25             @rawhide 180 k
 perl-MooX-HandlesVia         noarch 0.001008-6.fc25             @rawhide  43 k
 perl-MooX-late               noarch 0.015-9.fc25                @rawhide  37 k
 perl-Net-IDN-Encode          x86_64 2.300-4.fc25                @rawhide 292 k
 perl-Role-Tiny               noarch 2.000003-3.fc25             @rawhide  39 k
 perl-SelfLoader              noarch 1.23-378.fc26               @rawhide  23 k
 perl-Text-Balanced           noarch 2.03-365.fc25               @rawhide 153 k
 perl-Type-Tiny               noarch 1.000005-7.fc25             @rawhide 581 k
 perl-Unicode-EastAsianWidth  noarch 1.33-8.fc25                 @rawhide  13 k
 perl-libintl-perl            x86_64 1.26-1.fc25                 @rawhide 4.2 M
 perl-strictures              noarch 2.000003-2.fc25             @rawhide  34 k
 pgp-tools                    x86_64 2.2-3.fc25                  @rawhide 449 k
 texinfo                      x86_64 6.1-3.fc25                  @rawhide 4.5 M
 tokyocabinet                 x86_64 1.4.48-6.fc24               @rawhide 1.3 M
 urlview                      x86_64 0.9-19.20131022git08767a.fc24
                                                                 @rawhide  49 k

Transaction Summary
Remove  31 Packages

Installed size: 39 M
Is this ok [y/N]: y

Ok. All blockers removed. Time to call distro-sync:

11:24 root@puchatek:packages# dnf --releasever 24 --disablerepo rawhide --enablerepo fedora --enablerepo updates  distro-sync  --best --allowerasing

[.. long list of packages ..]

Transaction Summary
Install      11 Packages
Upgrade      13 Packages
Remove        4 Packages
Downgrade  2224 Packages

Total size: 2.1 G
Total download size: 2.1 G
Is this ok [y/N]:

Error: Transaction check error:
  file /usr/lib64/ from install of lua-5.3.3-2.fc24.x86_64 conflicts with file from package lua-libs-5.3.3-3.fc25.x86_64

This is less fun… RPM needs Lua to work. So I went around. Unpacked Lua package from F24, then “rpm -e –nodeps lua-libs” and copied “lib64” from just unpacked package directly into system. Then downgraded “lua” using dnf.

Next step? Distro sync of course. This time it works. Now kernel needs to be taken care of.

I had 4.6.0 kernel installed from I have no idea when. Booted it and it allowed me to remove all “4.8-rc” kernels I got from rawhide. Then simple “dnf install kernel” to get 4.7.2 from updates repo and after one more reboot I got:

15:52 hrw@puchatek:~$ lsb_release -a
LSB Version:    :core-4.1-amd64:core-4.1-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-4.1-amd64:desktop-4.1-noarch:languages-4.1-amd64:languages-4.1-noarch:printing-4.1-amd64:printing-4.1-noarch
Distributor ID: Fedora
Description:    Fedora release 24 (Twenty Four)
Release:        24
Codename:       TwentyFour

As you see it took far more time than I expected it will. I learnt that ‘keepcache’ is not enabled (had to fetch 2GB of packages again), found ‘minrate’ dnf config option which helps me avoid slow Austrian mirror.

PowerVR is other way to say headless

Yesterday Acer announced convertible Chromebook R13, first MediaTek powered Chromebook. With AArch64 cpu cores. And PowerVR GPU.

As it was in the evening I did not notice PowerVR part and got excited. Finally some AArch64 Chromebook which people will be able to buy and do some development on. Specs were nice: 4GB of memory, 16/32/64GB of emmc storage, 13.3″ FullHD touchscreen display. But why they use that GPU :((

There are few graphics processing units in ARM/AArch64 world. Some of them have FOSS drivers (Ardeno, Tegra, Vivante), some are used with 2D units (Mali) and some just sucks (PowerVR).

Mali is kind of lost case as no one works on free driver for it (so-called “lima” looks like ARM Ltd secret task to get people from trying to do anything) but as it is paired with 2D unit users have working display. And there are binary blobs from ARM Ltd to get 3D acceleration working.

But PowerVR? I never heard about anyone working on free driver for it. I remember that it was used in Texas Instruments OMAP line. And that after few kernel releases it just stopped working when TI fired whole OMAP4 team so no one worked on getting it working with binary blobs.

So now MediaTek used it to make cpu for Chromebook… Sure it will work under ChromeOS as Google is good at keeping one kernel version for ages (my 2012 Samsung Chromebook still runs 3.8.11 one) so blobs will work. But good luck with it under other distributions and mainline kernel.

Heh, even Raspberry/Pi has working free driver nowadays…