August 24, 2015

A Flashable CentOS Image for the Intel Edison

August 24, 2015 06:56 PM

A Flashable Image for the Intel Edison

The Intel Edison system-on-a-chip boards are pretty cool, a little compute module can plug into a number of different breakout boards. There’s an Arduino-style board, and another form-factor featuring a bunch of stackable modules (GPIO, SD Card, OLED Screen etc.) Since the system is a dual-core Atom, we can easily put CentOS on it! To start with we will focus on the userland components and use the kernel that comes bundled in the Edison toolkit.

If you’d rather not read the whole thing, here are some links to a flashable rootfs image and a yum repo containing the tools that go with it:
Bootable Image:
Sources and Yum Repo:

More of the upcoming work (building a kernel, and the rest of the SDK) will be done under the Alternate Architectures SIG once that is in full-swing. In the meantime I’d love to see discussion, bug reports, and collaboration on the centos-devel list.

My Email: brian (at) bstinson (dot) com

IRC: bstinson

Building your own rootfs image

If you’d like to spin your own image (instead of using the prebuilt image above) here are the steps you need to get a flashable image. The Edisons are fairly simple to install to (since the rootfs is simply an ext4 image)

To begin with we need a 1G file that will serve as our ext4 image

# Make a 1G file full of Zeros
root@host# dd if=/dev/zero of=~/projects/edison/edison-image-centos.ext4 bs=1M count=1024

# Put an ext4 filesystem on it
root@host# mkfs.ext4 ~/projects/edison/edison-image-centos.ext4

# Mount it someplace handy
root@host# mount -t ext4 ~/projects/edison/edison-image-centos.ext4 /mnt/edison-image-centos

Now that we have the image mounted in a useful place we can start installing

# Add the centos-release and centos-release-edison files
root@host# rpm --root /mnt/edison-image-centos -Uvh --nodeps\

# Tweak the basearch variable (allows you to do target install from an x86_64 host)
root@host# echo 'i386' > /mnt/edison-image-centos/etc/yum/vars/basearch

# Install the packages
root@host# yum --installroot=/mnt/edison-image-centos install bind-utils bash yum vim-minimal shadow-utils less iputils iproute firewalld rootfiles centos-release edison-modules edison-tweaks wpa_supplicant dhclient

Flashing the rootfs image

You can grab dfu-util for CentOS 7 from here

Connect the OTG port on the Edison breakout board to a USB port and it should show up as a dfu device.

# The dfu VendorID:ProductID is 8087:0a99 for the Edison
root@host# dfu-util -l -d 8087:0a99
dfu-util 0.8

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2014 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to

Found DFU: [8087:0a99] ver=9999, devnum=68, cfg=1, intf=0, alt=11, name=”initrd”, serial=”UNKNOWN”
Found DFU: [8087:0a99] ver=9999, devnum=68, cfg=1, intf=0, alt=10, name=”vmlinuz”, serial=”UNKNOWN”
Found DFU: [8087:0a99] ver=9999, devnum=68, cfg=1, intf=0, alt=9, name=”home”, serial=”UNKNOWN”
Found DFU: [8087:0a99] ver=9999, devnum=68, cfg=1, intf=0, alt=8, name=”update”, serial=”UNKNOWN”
Found DFU: [8087:0a99] ver=9999, devnum=68, cfg=1, intf=0, alt=7, name=”rootfs”, serial=”UNKNOWN”
Found DFU: [8087:0a99] ver=9999, devnum=68, cfg=1, intf=0, alt=6, name=”boot”, serial=”UNKNOWN”
Found DFU: [8087:0a99] ver=9999, devnum=68, cfg=1, intf=0, alt=5, name=”u-boot-env1″, serial=”UNKNOWN”
Found DFU: [8087:0a99] ver=9999, devnum=68, cfg=1, intf=0, alt=4, name=”u-boot1″, serial=”UNKNOWN”
Found DFU: [8087:0a99] ver=9999, devnum=68, cfg=1, intf=0, alt=3, name=”u-boot-env0″, serial=”UNKNOWN”
Found DFU: [8087:0a99] ver=9999, devnum=68, cfg=1, intf=0, alt=2, name=”u-boot0″, serial=”UNKNOWN”

# Flash the image
root@host# dfu-util -d 8087:0a99 -a rootfs -D ~/projects/edison/edison-image-centos.ext4

Connect to the newly installed Edison

Plug the Console port into a USB port and fire up your favorite serial terminal

root@host# screen /dev/ttyUSB0 115200
Flashing already done...
GADGET DRIVER: usb_dnl_dfu
reading vmlinuz
5383904 bytes read in 133 ms (38.6 MiB/s)
Valid Boot Flag
Setup Size = 0x00003c00
Magic signature found
Using boot protocol version 2.0c
Linux kernel version 3.10.17-poky-edison+ (sys_dswci@tlsndgbuild004) #1 SMP PREEMPT Wed Apr 29 03:54:01 CEST 2015
Building boot_params at 0x00090000
Loading bzImage at address 00100000 (5368544 bytes)
Magic signature found
Kernel command line: "rootwait root=PARTUUID=012b3303-34ac-284d-99b4-34e03a2335f4 rootfstype=ext4 console=ttyMFD2 earlyprintk=ttyMFD2,keep loglevel=4 g_multi.ethernet_config=cdc hardware_id=00 g_multi.iSerialNumber=88a7cbd65118ecb7cbe1fde0dd5174df g_multi.dev_addr=02:00:86:51:74:df platform_mrfld_audio.audio_codec=dummy"

Starting kernel …

[ 0.760411] pca953x 1-0020: failed reading register
[ 0.765618] pca953x 1-0021: failed reading register
[ 0.770719] pca953x 1-0022: failed reading register
[ 0.775838] pca953x 1-0023: failed reading register
[ 1.623920] snd_soc_sst_platform: Enter:sst_soc_probe
[ 2.028440] pmic_ccsm pmic_ccsm: Error reading battery profile from battid frmwrk
[ 2.046563] pmic_ccsm pmic_ccsm: Battery Over heat exception
[ 2.046634] pmic_ccsm pmic_ccsm: Battery0 temperature inside boundary

Welcome to CentOS Linux 7 (Beta)!

Expecting device dev-ttyMFD2.device…
[ OK ] Reached target Remote File Systems.
[ OK ] Listening on Delayed Shutdown Socket.
[ OK ] Listening on /dev/initctl Compatibility Named Pipe.
[ OK ] Listening on Journal Socket.
Mounting Debug File System…
Starting Apply Kernel Variables…
Starting Create list of required static device nodes…rrent kernel…
Mounting POSIX Message Queue File System…
Starting Setup Virtual Console…
Mounting Configuration File System…
Mounting FUSE Control File System…
Starting Journal Service…
[ OK ] Started Journal Service.
[ OK ] Listening on udev Kernel Socket.
[ OK ] Listening on udev Control Socket.
Starting udev Coldplug all Devices…
[ OK ] Reached target Encrypted Volumes.
[ OK ] Set up automount Arbitrary Executable File Formats F…utomount Point.
[ OK ] Reached target Swap.
Starting Remount Root and Kernel File Systems…
Expecting device dev-disk-by\x2dpartlabel-home.device…
[ OK ] Created slice Root Slice.
[ OK ] Created slice User and Session Slice.
[ OK ] Created slice System Slice.
[ OK ] Reached target Slices.
[ OK ] Created slice system-getty.slice.
[ OK ] Created slice system-serial\x2dgetty.slice.
[ OK ] Mounted Debug File System.
[ OK ] Started Apply Kernel Variables.
[ OK ] Mounted POSIX Message Queue File System.
[ OK ] Started Setup Virtual Console.
[ OK ] Mounted Configuration File System.
[ OK ] Mounted FUSE Control File System.
[ OK ] Started Remount Root and Kernel File Systems.
[ OK ] Started Create list of required static device nodes …current kernel.
Starting Create static device nodes in /dev…
Starting Load/Save Random Seed…
Starting Configure read-only root support…
[ OK ] Started udev Coldplug all Devices.
[ OK ] Started Create static device nodes in /dev.
[ OK ] Started Load/Save Random Seed.
[ OK ] Started Configure read-only root support.
Starting udev Kernel Device Manager…
[ OK ] Reached target Local File Systems (Pre).
[ OK ] Started udev Kernel Device Manager.
[ OK ] Found device /dev/ttyMFD2.
[ OK ] Found device /dev/disk/by-partlabel/home.
Mounting /home…
[ OK ] Reached target Sound Card.
[ OK ] Mounted /home.
[ OK ] Reached target Local File Systems.
Starting Trigger Flushing of Journal to Persistent Storage…
Starting Create Volatile Files and Directories…
[ OK ] Started Trigger Flushing of Journal to Persistent Storage.
[ OK ] Started Create Volatile Files and Directories.
Starting Update UTMP about System Reboot/Shutdown…
[ OK ] Started Update UTMP about System Reboot/Shutdown.
[ OK ] Reached target System Initialization.
[ OK ] Reached target Timers.
[ OK ] Reached target Paths.
[ OK ] Listening on D-Bus System Message Bus Socket.
[ OK ] Reached target Sockets.
[ OK ] Reached target Basic System.
Starting firewalld – dynamic firewall daemon…
Starting Dump dmesg to /var/log/dmesg…
Starting Disable the watchdog device on the Intel Edison…
[ 7.665241] intel_scu_watchdog_evo: watchdog_stop
Starting Permit User Sessions…
Starting Login Service…
Starting D-Bus System Message Bus…
[ OK ] Started D-Bus System Message Bus.
Starting LSB: Bring up/down networking…
[ OK ] Started Dump dmesg to /var/log/dmesg.
[ OK ] Started Disable the watchdog device on the Intel Edison.
[ OK ] Started Permit User Sessions.
[ OK ] Started LSB: Bring up/down networking.
Starting Getty on tty1…
[ OK ] Started Getty on tty1.
Starting Serial Getty on ttyMFD2…
[ OK ] Started Serial Getty on ttyMFD2.
[ OK ] Reached target Login Prompts.
[ OK ] Started Login Service.
[ OK ] Reached target Multi-User System.

CentOS Linux 7 (Beta)
Kernel 3.10.17-poky-edison+ on an i686

localhost login:

Connecting the WiFi Interface

From here, you can connect using the onboard wireless controller:

# Modify /etc/sysconfig/wpa_supplicant to include your device

# Add your network to the wpa_supplicant config
root@edison# wpa_passphrase MyHomeSSID "PasswordToMYWifi" > /etc/wpa_supplicant/wpa_supplicant.conf

# Start the wpa_supplicant service
root@edison# systemctl enable wpa_supplicant
root@edison# systemctl start wpa_supplicant

# Get an address on the interface
root@edison# dhclient wlan0

Known Issues

  • The disable-watchdog service starts late in the boot process, so touching
    /.autorelabel will result in a bootloop (the watchdog timer times out before
    the selinux relabel is finished)
  • We’re still using and distributing the Kernel from the toolkit, we will be
    working on building a CentOS kernel which may also allow for a 64-bit userland

July 29, 2015

Cloud In A Box: CentOS OpenStack Remix

July 29, 2015 04:58 PM

OpenStack is the current de facto standard for cloud computing platforms and is supported by all major Linux distributions. Coupled with its role as the base technology in the domains of NFV & SDN, it has become one of the hottest softwares for networking community. It is a combination of numerous components and services, which means that deploying openstack is often complex, time consuming and error prone, especially for beginners. Deployment options vary from manual setup i.e., to install and setup each individual component manually, to use of automated tools such as Devstack, Fuel and Packstack.

The easiest way for getting started with openstack is through automated tools but using them properly requires significant forum/manual scavenging effort. This is too daunting for cloud application developers or anyone whose primary concern is to evaluate the cloud technology.

To ease these deployment concerns, our goal is to provide a robust, pre-configured (yet customizable) and easily installed openstack setup. The result will be a “CentOS Remix” with an option to setup openstack during installation. This is implemented by integrating two efforts by the Red Hat community namely RDO and Packstack into the CentOS installer i.e., Anaconda.


The development involves integrating OpenStack from the CentOS Cloud SIG (which also feeds the Red Hat community’s openstack packaging effort, RDO ) and Packstack (openstack deployment tool) with Anaconda. The resulting remix will:

  • Install CentOS along with OpenStack in one installation cycle.
  • Use packstack to configure & deploy openstack (in post-install phase).

The integration will be achieved by developing an add-on for the Anaconda installer. Anaconda add-ons can be used to add support for custom configurations screens in the graphical and text-based user interface. OpenStack support can also be added to anaconda by modifying its source but add-ons are also extensible, maintainable, easier to debug  and test. They also provide an opportunity to extend openstack support to other Linux distributions that use anaconda.

Current Status:

Anaconda has three modes of operation i.e., Kickstart, Graphical and Text User Interfaces. Hence our add-on development is divided into adding openstack installation support for each of these three modes. Uptill now Kickstart support has been implemented i.e., user is able to install openstack through a kickstart file during setup.

Currently GUI support is being developed. After that TUI support and openstack customization options will be added. Final deliverable will be an “CentOS Openstack remix” ISO (~1.2GB) extending CentOS minimal ISO.

Project source along with testing instructions are available at Github

  • Email:
  • IRC: asad_ (#centos-devel)



July 24, 2015

RootFS Build Factory: The Story So Far

July 24, 2015 11:04 AM

Johnny Hughes has already posted images for Cubietruck and Raspberry Pi 2 and told you how to use them with your boards. In this post, I would like to tell you all the what has gone into development of RootFS Build Factory so far which includes a bit about the CentOS ARMv7 effort.

When I first started looking up project ideas for GSoC this year, the RootFS Build Factory idea caught my attention because it fit right into my interests and skill set. This was in the first week of March. Back then there was no CentOS ARMv7 and as far as I knew, the only person who had done any work in the area of building ARMv7 packages was Howard Johnson. His post on the CentOS arm-dev mailing list described his efforts of compiling CentOS for ARMv7 using Raspberry Pi 2 and Odroid C1. This was my first introduction to CentOS ARMv7.

Back then it seemed like the RootFS Build Factory project would require building a minimal CentOS ARMv7 first and then working on a set of scripts to re-bundle packages in this minimal build.
I got in touch with members on the CentOS team on #centos-devel and #centos-gsoc on Freenode and interacted with Jim Perrin and Ian McLeod (who later became my mentor for this GSoC project). With their inputs I started thinking of alternatives to Howard’s method of compiling packages and came across work done by msalter from Redhat

He had developed plugins to cross compile packages using mock and Koji and a yum plugin for installing non native rpms. This seemed great as I did not have any ARMv7 hardware at that point and the idea of generating ARMv7 on fast x86_64 desktop seemed like a good one. Later on, after discussion with msalter (which happened in the first week of June) and based on his advice we realized that this approach wasn’t going to work for CentOS as the pre/post install scripts in the RPMs wouldn’t run in a cross environment.

My original GSoC Proposal was based on using msalter’s yum plugin to build ARMv7 images on x86_64 but after discussion with msalter and in consultation with my mentor Ian, it was decided not to go forward with the yum cross plugin approach and to focus on the targets in my proposal which would involve building CentOS ARMv7 images using either ARMv7 hardware or QEMU.

There was still the big issue of how, where and who would compile CentOS ARMv7. This is where Fabian Arrotin’s efforts came in and took care of matters. His work using a plague farm he setup on the Scaleway nodes, got us a working set of ARMv7 packages. Until then Ian and I were contemplating doing the build ourselves using hardware we had at our disposal.

We decided that until the ARMv7 CentOS build was ready, we would use Fedora for development. Fabian Arrotin was very quick in creating the repositories which meant we didn’t have to use Fedora for long. Of course the first build of CentOS 7 ARM using the RootFS Build Factory happened on Fedora 21.

The present status of the project is this:

  • Tested generation of images for QEMU (, Cubietruck, Odroid C1, Raspberry Pi 2, Banana Pi, Cubieboard 2. Tests for the last two have been reported by Nicolas [nicolas at] and David Tischler [david.tischler at] respectively. The Odroid C1 and Raspberry Pi 2 images do not use the CentOS Kernel.
  • Untested Boards: Cubieboard, Wandboard{solo,dual,quad}, Pandaboard, CompuLab TrimSlice, Beaglebone. Support for these boards has been added based on information on the Fedora Wiki. I do not have these boards with me.
  • For adding support for more boards, you can refer to

Presently there are 3 main components in RootFS Build Factory

  • : takes a XML Template and generates an image.
  • : dialog based UI using the python2-pythondialog library to load/edit/create XML Templates.
  • : Takes a Generic/QEMU image, writes it to your microSD, then writes board specific U-Boot to microSD. This works for the boards where the CentOS kernel is used since the only difference between images for different boards is U-Boot. In case of Raspberry Pi 2 and Odroid C1, just the image generated by RootFS Build Factory is written to microSD.

The original proposal mentioned writing the UI in PyGTK but because cross development was out of the picture and I didn’t think people would run X11 in QEMU just for RootFS Build Factory, I chose a console based approach. Although the interface loads in the QEMU console, it doesn’t load the colors and there is some text visible on the edges while selecting files/directories. I suggest you set up bridge networking on your host and then SSH into the QEMU instance.

If you have any queries you can post them in the comments below or email me [emailmandar at] or discuss it on the CentOS arm-dev mailing list

Introducing Flamingo: A Lightweight Cloud Instance Contextualization Tool for CentOS Atomic Host

July 24, 2015 11:01 AM

When using on-demand instantiation of virtual machines in cloud computing,
users pass configuration data to the cloud and that data is used for
configuring the instances.
This process is called contextualization. Contextualization includes
identity(users, groups), network, system services and disk configuration.

Flamingo is a contextualization tool that is being developed under GSoC 2015

that aims to handle early initialization of cloud instances.

The current de facto standard for instance virtualization is cloud-init.
However, there are some problems with it. The most prominent ones are:

  • The usage of a scripting language (Python in this case), since scripting
    languages have the overhead of the interpreter, its dependencies and
    being slower than compiled ones due to their dynamic nature.
  • The documentation is lacking at best. There are examples of common
    use-cases. However, most of the code-base and plug-ins are undocumented.
    Inspecting the code-base is a prerequisite to extend the functionality or
    even understand it.
  • Test coverage is low. Making it hard to extend, maintain, and improve.

Don`t get me wrong it gets the job done. But, it has a lot of issuses and
these issues make it hard to use, extend and maintain.


Flamingo aims to solve the following problems encountered in cloud contextualization;

  • Speed
  • Dependency
  • Maintainability
  • Extensibility

Go is a very suitable choice for a tool like this. Since, it is fast,
it has cheap concurrency, and dependency management is a breeze (see godep).
It allows the distribution of a single executable binary with its dependencies.


Target Distribution

The first target for Flamingo is the CentOS Atomic Host and CentOS Linux generic cloud images. We would, ofcourse, like to see wider adoption and are interfacing with other projects and image builders to see how best we might collaborate on this moving forward.


Getting Involved
You can find the source code for the tool here.

For more details please check this blog post


In the meanwhile if you’d like to share your opinions, learn more,
or contribute please feel free to open an issue, mail to centos-devel,user-list or come to #centos-devel IRC channel to have a chat.


  • E-mail: contact _
  • IRC: tmrts


Tamer Tas


July 08, 2015

Continuous Integration (CI) Pre Release Testing for CentOS Linux Updates

July 08, 2015 03:46 PM

The CentOS Project has been performing daily CI testing for quite a while using our t_functional test suite.

This testing has solved numerous issues for us in the past, although since it was being run daily sometimes we needed to re-release problem packages after fixes were rolled in. We have gotten the run time down considerably now (less than 1 hour for all tests) so we have adopted the policy that we will be running this test suite now as a Pre-Release process for updates so that if there are problems, we can address them before release.

The t_functional suite lives on github and we would be happy for people to help us develop new tests or make the current tests better.  You can download and run the tests on a VM or machine that you can afford to reinstall (the tests are destructive and the machine is left in a state that is different than when the tests start, so it should never be run on production/important machines).  You can also submit new tests or updates via github. We use the CentOS-Devel mailing list for discussion of these tests and for requesting changes.

Please help the CentOS Project make CentOS Linux better by testing, designing and submitting to our t_functional suite.

July 07, 2015

CentOS Meetup in Pune, India – Sat Jul 11th 2015

July 07, 2015 11:00 AM


Humble and the guys in the CentOS-India group are organising a meetup in Pune this Saturday, the 11th July 2015. is a link to the meetup page. The Agenda looks great :

  • Basics of Systemd: Praveen Kumar
  • UEFI and secure boot: Yogesh Babar
  • Docker container and Atomic Host: Ranjith Rajaram
  • Debugging Kernel Issues: Gopal Tiwari

The Event kicks off at 9am with a welcome and intro. So if you are in the area and able to make it, sign up for the event and come along. If you are based in India, it would be great to see you sign up to the CentOS-India group anyway, so you can keep an eye on events coming to your areas, and if possible- maybe even help us run an event in your area!


- KB

July 02, 2015

CentOS Shirt Fridays

July 02, 2015 11:53 AM

Hi Everyone,

Over the last eight years we have handed out literally thousands of CentOS Project Tshirts. From Houston to Bangalore to Edinburgh to Sydney to Johannesburg to Porto Alegre to London and even the 4 that went to Antarctica. Lets get those shirts out every friday and see if we can get a CentOS Shirt Friday going. Get into them and lets get posting on social media! Lets use the #CentOSShirtFriday hashtag.

Thanks to Barton ( ) for the idea. And thanks to the folks at Cpanel ( ) for starting us off on this CentOS shirt journey many many years ago.

Dont have a CentOS shirt yet ? We typically have shirts at the events we attend as a project. You can see where we are going in the near future at the Events page ( ).

So, I’ll see you all tomorrow online, with my CentOS shirt on. Now, lets see if I can find the first one we ever did.

- KB

June 22, 2015

Another Proof of Concept armv7hl Release, this one for the Raspberry Pi2

June 22, 2015 11:41 AM

Ten days ago I wrote an article here about an armv7hl test image for the Cubietruck 32-bit ARM board.  I have just uploaded a similar armv7hl image for the Raspberry Pi2. Both of these images are created with the RootFS Build Factory (a 2015 CentOS GSoC Project from Mandar Joshi sponsored by the CentOS Project).

The Raspberry Pi2 image (as well as the sha256sums for the compressed and uncompressed images) is available here:

This RPI2 image actually uses the base kernel and boot files from the Raspberry Pi Firmware github site, and not the CentOS-7 armv7hl kernel.  This RPI2 kernel seems to be causing an issue with firewalld, and one must edit the file /etc/firewalld/firewalld.conf and change the variable IPv6_rpfilter from yes to IPv6_rpfilter=no.

Mandar has been making lots of progress on RootFS Build Factory and other people have reported that images generated from RBF for Odroid C1 and Banana PI are also functional, as is the image for QEMU.  I will be trying to obtain and post workable images from these boards soon.

I want to point out that the current images created are not signed and are taken directly from the output of our armv7hl builders ‘as is’ with no QA testing.  The armv7hl build is still very much a work in progress and the image manifest is based on a CentOS-7 (1503) minimal install from our x86_64 install media.  We have not yet completed the entire tree and the build repositories may at times NOT have complete closure and are only about 85% complete at this time.  We will finish the baseline build and then start the updates repository, but as of now these repos should be considered PRE-ALPHA and not production ready.

To use this image, you first extract it with this command:

unxz rpi2-centos-image.img.xz

Then just dd it to an SD Card and boot it in your Raspberry PI2 using a command like this from linux:

dd if=./rpi2-centos-image.img of=/dev/mmcblk0

(Note:  your SD Card device may vary .. you should be able to find the card device with fdisk -l )

If you are going to be at Red Hat Summit 2015 this upcoming week (June 23rd to 26th, 2015), please stop by the CentOS Booth in the Community Central area and we will have working armv7hl demos of a RPI2, Cubietruck, and Banana Pi .. as well as a working armv8 (aarch64) AppliedMicro X-Gene Server on a Chip  demo machine.  Hope to see you there.

June 17, 2015

AMD Seattle and CentOS on AArch64

June 17, 2015 12:46 PM

About a week after announcing the CentOS 7 alpha build for AArch64 hardware, I got an email from the fine folks at AMD asking for my address. Three days later, a pair of AMD’s Seattle AArch64 development boards showed up at my front door.  Hardware really is the best sort of gift, especially when you’re building for a new platform. I needed to make a couple modifications to my lab (okay fine, my home) network in order to make use of the new AMD gear due to the board layout. The boards I have don’t include USB by default, and I usually cheat and do USB based installs. Instead, I set up a proper pxe environment and loaded the OS up the right way.

Because the hardware was shipped with UEFI by default, there was very little to do in the way of configuration. I simply pointed the serial console at the pxe option and then did a normal vnc based install when the installer loaded. I don’t want to spend too much time here talking about the installation, because it was exceptionally simple. If you don’t have or want PXE, a pcie usb card would work fine. You can even simply yank the drive and dd the disk image directly to it, then power up. The only downside to the last approach is the need to run efibootmgr manually to set up the UEFI boot entry. In the coming days, I’ll be updating our AArch64 documentation to reflect the added hardware and providing more detailed directions for configuration and setup for the hardware.


Apart from being able to report that the AMD boards work just fine with the CentOS 7 AArch64 beta, I can also happily report that they’re proving quite useful. Since I have multiple machines, I’m now able to run a number of test cases and multiple configurations without the need to cannibalize my build system or boot from multiple drives. This has given me the ability to run our t_functional testing suite against the AArch64 beta, and identify a few minor build issues that I need to address before we can call the release GA. Thanks AMD!


June 16, 2015

Introduction to Cloud SIG talk in FUDCon Pune 2015

June 16, 2015 12:04 PM

FUDCon is the Fedora Users and Developers Conference, a major free software event held in various regions around the world, usually annually per region. This year the event in APAC is happening in Pune, India, from 26th to 28th June. I will be giving an introductory talk about the CentOS Cloud SIG (CCS) in the Openstack track on 27th June at 4:20pm.  CentOS Cloud SIG  is a group of people coming together to focus on packaging and maintaining different FOSS based Private cloud infrastructure applications that one can install and run natively on CentOS. We are a non vendor, non technology and non agent specific focus group, but we will gladly work with and build content to suit relevant niches or vendor ecosystems.

In this talk I will give a brief update about our work related to Openstack releases over CentOS 7 and CentOS 6. We will also see how OpenNebula is working towards a working build on the CBS. Anyone who wants to learn about these technologies or who wants to contribute to the SIG should attend this talk. I will be available all three days during the event. If you want to say hi or want to learn more about the CentOS Cloud SIG, please do ping me over @kushaldas or find me in person there.

June 12, 2015

CentOS IRC Meeting Calendar Now Available

June 12, 2015 12:17 PM

As of now, you can subscribe to a calendar feed (.ical) in your calendar program of choice by adding this feed url:!calendar.git/master/output!irc-meetings.ical

New meetings are added via pull-requests against this repository:

Why is this now available?

The number of SIGs and general project work has grown and more and more IRC meetings are
being scheduled. When KB announced he would begin holding office hours a discussion about how to best notify people and keep it on their minds sprang up on the centos-devel mailing list.

How is it implemented?

Louis Taylor mentioned that OpenStack had a yaml file driven calendar that didn’t require a central authentication mechansism. After a quick round of acceptances, I implemented the OpenStack model and the calendar was born.

Our next step is to host a web page that will serve as a landing zone for this information and list all of the scheduled meetings.

For those of you interested in the details, the calendar uses yaml2ical, a python module to convert the meeting yaml files into both an ical feed and an html listing. The current workflow is:

  1. A Pull Request on adds a new meeting yaml file
  2. A project member merges the pull and manually generates the new html and ical files
  3. The files are mirrored to

To Do:

  1. 1. Land the html file somewhere in our web infrastructure (to be tackled next week)
  2. Work with the yaml2ical community to land some patches for meeting duration and urls (in progress – see Issues on github)

Currently the meetings are listed in html with their frequency information. If someone knows of a simple ical->html or ical->text_list processor we can consider hosting a “calendar” view of the calendar.

CentOS-7 (1503) armv7hl Proof of Concept (pre-alpha) Image available for the Cubietruck

June 12, 2015 10:07 AM

As Jim Perrin pointed out in an earlier post here on, we have commenced an armv7 (actually, armv7hl) open build to try and produce CentOS-7 for arm32 boards like the Cubietruck, Raspberry Pi2, and ODROID-C1 (among others).

We now have a minimal sdcard only image for the Cubietruck from our unsigned (and as yet uncompleted) plague-builder output.

This image has been produced by the RootFS Build Factory (a 2015 CentOS GSoC Project from Mandar Joshi sponsored by the CentOS Project).  While the RBF is not yet close to being a finished product, it was able to be used to create this image.  This is our first published image built using RBF, which looks to be to be a very promising and useful GSoC project for CentOS on ARMv7.

Before I tell you where the image is, I want to point out (with emphasis :D) that THIS IMAGE IS PRE-ALPHA, PROOF OF CONCEPT ONLY !!!.  It is based on the Source Code from CentOS-7 (1503) release with none of the follow on updates and is not suitable for use in any environment that you care about at this point.  In fact, as this article is being posted, we only have 2068 of the 2523 Source Packages even built for armv7hl at this point.  The repositories used for this proof of concept are the unsigned direct output from our ongoing build of armv7hl and while the minimal install works (and should continue to work), there may not always be repoclosure there and some packages outside the minimal install may not have all their dependencies yet built, etc.

If you are interested in helping us get armv7hl working with CentOS-7, please join the Arm-Dev mailing list where we are doing the community build now.

The proof of concept, sdcard only, image is available here:

Install instructions are available from this post to the Arm-Dev mailing list.  If you are going to try this image, you should really join the list as that is going to be where the community can answer questions about it.

Next up on the armv7hl front should hopefully be a minimal install image from the same plague-builder repos for the RaspBerry Pi2 in the next week or so.

As I have already pointed out, we do not yet have an armv7hl release, in fact to date we only have about 82% of the packages for the release that actually build at this point.  We can use the help of people who understand the boards in question … especially vendors.  Join the Arm-Dev list and give us a hand.

June 11, 2015

Rolling ISO Media release 1505 for CentOS 7 (x86_64) Now Available

June 11, 2015 11:00 AM

The rolling ISO media releases for CentOS 7 for May 2015 (1505) are now available.

These rolling ISO media releases are basically just respins of the install media at release time with all bugfix, enhancement, and security updates since release rolled in.  The updated ISOs for 1505 are based on all updates in the CentOS 7 os and updates repositories at 0000 UTC on May 28th, 2015.

The goal is to make these media available on a monthly basis for CentOS 7, in much the same way as we make cloud and container images available.

Users can use the updated ISO images for installs that have far fewer updates required after install.  There is no difference between using these ISOs and the original CentOS 7 (1503) ISOs and a yum update run on May 28th at 0000 UTC.

The new ISOs are available here:

File: CentOS-7-x86_64-DVD-1505-01.iso
Sha256sum: 70c510b8ae7e742ef12e9378ef49a919361e4f891f8f4ad92b03209f2cbb3638

File: CentOS-7-x86_64-Everything-1505-01.iso
Sha256sum: 1b117390a908467723f166ee22aa300bd4b55c57f05bc37eb58fb6bf3331295e

File: CentOS-7-x86_64-LiveCD-1505-01.iso
Sha256sum: 2310f7d28ed10a9a19d3690378a6f523c666a5ad3bfd428cc2a1f6b7438cc560

File: CentOS-7-x86_64-LiveGNOME-1505-01.iso
Sha256sum: 76a9c62c363cd90d0c8235400498829dfad9fc9bbae85916b26d2346300b649f

File: CentOS-7-x86_64-LiveKDE-1505-01.iso
Sha256sum: b48e8d2798767674f9993929d6899ca8f2f0cb0f420251e5184b3cd047403399

File: CentOS-7-x86_64-Minimal-1505-01.iso
Sha256sum: d9d394dcfa40a73cf0cfad9ebc70b54fcdd29861694791a5b678c57368087306

More information is available from our announcement here:

June 08, 2015

Regular office hours

June 08, 2015 04:58 PM

Update: I’ve moved the Thurs evening slot to Wednesday so as to not clash with Atomic SIG meeting.


Starting this Thursday the 11th June, 2015 – I am going to make myself available to anyone who wants to come along and talk about CentOS Linux, the CentOS Project, the SIGs or anything else that is related to these.

To start things off, I am going to be available on all Wednesdays:

  • 04:00-04:30 pm UTC (5:00pm London, 12noon Eastern, 9am Pacific )

And on all Thursdays:

  • 08:30-09:00 am UTC (9:30am London, 2:00pm, India, 4:30pm Singapore)

During this time, you can find me on #centos-devel ( as ‘kbsingh’), and you can also call me on the phone at +44 207 009 4455.

Speak to you then!

- KB

June 02, 2015

Update on CentOS GSoC 2015

June 02, 2015 03:34 PM

Here’s an update on the CentOS Project Google Summer of Code for 2015 posted on the CentOS Seven blog:

This might be of interest to the Fedora Project community, so I’m pushing my own reference here to appear on the Fedora Planet. Much of the work happening in the CentOS GSoC effort may be useful as-is or as elements within Fedora work. (In at least one case, the RootFS build factory for Arm, the work is also happening partially in Fedora, so it’s a triple-win.)

June 01, 2015

CentOS and GSoC 2015 — suddenly come seven on 7

June 01, 2015 03:32 PM

The CentOS Project is now the proud mentoring organization for seven students to work on projects this summer under the Google Summer of Code (GSoC.)

Below is a quick snapshot of the projects and the communication channels for keeping track or participating in the activities the students will generate around themselves as the get to work. For the most part, these projects are focused on technologies around the latest Linux from the project, CentOS Linux 7.

To keep overall track of what is going on across all the students’ projects, watch the CentOS planet blog aggregator,; students individual blogs are found at the CentOS 7 blog

Getting this all together has been fun — working with the students- and mentors-to-be, organizing processes, all the way back to the idea generation and prep phases, all a whirlwind of activity. I’ve done GSoC as a mentor and administrator since 2006 (second year of GSoC) and other summer coding efforts, and it’s hard not to have things be a bit chaotic with so many moving parts. I’m really looking forward to the benefits newer organizations get from having to prepare and work with students throughout the effort.

May 21, 2015

CentOS 7 armv7hl build in progress

May 21, 2015 12:36 PM

As more and more people were showing interest in CentOS on the ARM platform, we thought that it would be a good idea to start trying building CentOS 7 for that platform. Jim started with arm64/aarch64 and got an alpha build ready and installable.

On my end, I configured some armv7hl nodes, "donated" to the project by Scaleway. The first goal was to init some Plague builders to distribute the jobs on those nodes, which is now done. Then working on a "self-contained" buildroot , so that all other packages can be rebuilt only against that buildroot. So building first gcc from CentOS 7 (latest release, better arm support), then glibc, etc, etc ... That buildroot is now done and is available here.

Now the fun started (meaning that 4 armv7hl nodes are currently (re)building a bunch of SRPMS) and you can follow the status on the Arm-dev List if you're interested, or even better, if you're willing to join the party and have a look at the build logs for packages that failed to rebuild. The first target would be to have a "minimal" install working, so basically having sshd/yum working. Then try other things like GUI environment.

As plague-server required mod_python (deprecated now) we don't have any Web UI people can have a look at. But I created a "quick-and-dirty" script that gathers information from the mysql DB, and outputs that here :

The other interesting step will be to produce .img files that would work on some armv7hl nodes. So diving into uboot for Odroid C1 (just as an example) ....

I'll also try to maintain a dedicated Wiki page for the arm32 status in the following days/weeks/etc ..

May 18, 2015

CentOS 7 with GlusterFS on AArch64

May 18, 2015 06:09 PM

Initially I meant for this to be a much more in-depth blog post about running GlusterFS on AArch64 hardware, but honestly it’s been ridiculously easyto get running. There isn’t much to say about running it that isn’t already covered in the GlusterFS quickstart guide. Even building GlusterFS on AArch64 was a snap; I simply pulled down the glusterfs-3.6.3 src.rpm and ran it through mock on my AArch64 build system. A few seconds later, I had around a dozen glusterfs packages ready for installation. After bringing up a test box, I was confident that this was working entirely too well and something would explode at any minute. I followed the quickstart, and a few minutes later, I had a working test implementation of GlusterFS up and running. There were no explosions, no fireworks, and no errors. The whole thing was incredibly painless to get working, and I can’t wait to see people using it in production.

gluster volume status and installed packages



Hopefully this means getting an official GlusterFS build for AArch64 will be as simple as asking nicely, and possibly working with the Storage SIG for access to the builders.

May 13, 2015

Firefox 38 and TLS less than 1.2

May 13, 2015 05:19 AM

Red Hat released the source code for Firefox 38.  We have (or willbe
today) releasing this for CentOS-5, CentOS-6, and CentOS-7.

It does not, by default, connect to https sites with TLS less than 1.2.
This means it will not connect to sites on CentOS-5, for example ..
there are many others.

In any event, here is a wiki article that explains potential issues and

May 08, 2015

Running CentOS Linux 7 on AArch64 hardware

May 08, 2015 09:07 PM

The journey for rebuilding the latest release of CentOS Linux 7 on AArch64 hardware has certainly been an interesting one. After a few bug reports, a couple minor patches, and several iterations through the build system, we finally have a release for community testing and consumption, which we’ll have available for install early next week. There are some differences with a traditional CentOS install that users wishing to experiment should keep in mind. Because AArch64 hardware is still very new, this build requires a newer kernel that we’ll be patching fairly regularly with help from the community as well as various vendors. The initial alpha release will ship with a kernel-4.0.0 based kernel, however we’re working on providing a 4.1 based kernel using ACPI very soon. After the initial kickoff next week, we’ll start setting expectations for fixes, release cycles (I’m thinking monthly, in keeping with other plans) and more. If you want to participate or contribute patches, please join our arm-dev list and say hi.

Teaser screenshots!

In the example below, I copied the boot.iso to USB via dd. For the hardware I have, the installer’s started over a serial interface, and then accessed via VNC. A text mode is available as well, just like the default CentOS 7 installer for x86_64 (you’ll probably want to use VNC initially).

Screenshot from 2015-05-05 18:35:40

The VNC based installer is identical to the one you’re already familiar with for CentOS. The only difference of note here, is that by default only the ‘minimal’ install is available. Additional packages may be installed after the installation completes. This is something we’ll improve on as the AArch64 build matures.

Screenshot from 2015-05-07 11:11:46


Just as you’d expect, once the installer completes successfully, you’ll be prompted to reboot.

Screenshot from 2015-05-07 11:19:04


After the installation completes and you have rebooted the system, the console login prompt shows the 4.0.0-1 kernel goodness, and you’re ready to deploy additional software and configure the system.

Screenshot from 2015-05-08 15:57:01

May 06, 2015

Signed Repository Metadata is now Available for CentOS 6 and 7 for the Updates Repo

May 06, 2015 02:35 PM

The CentOS Project is now providing a signed copy of the repodata metadata file (repomd.xml.asc) for our Updates Repository for both CentOS-6 and CentOS-7.  To use this feature, you would edit the file /etc/yum.repos.d/ CentOS-Base.repo and locate the [updates] section, the default looks like this:

#released updates
name=CentOS-$releasever – Updates

You would add in this option:


Currently we only have this option available on the [updates] repos for CentOS-6 and CentOS-7, but we will be rolling it out to all C6 and C7 repos in the future.

Yum will verify that the repo in question is signed with the RPM-GPG-KEY-CentOS-7  (or RPM-GPG-KEY-CentOS-6 for CentOS-6) key .. so you can be sure these updates come directly from the CentOS Project and no one else.

Here is a good read about GPG sign and verify RPM packages and yum repositories . It also explains why we are not rolling it into the CentOS-5 repos.

There is also further information on this CentOS Maillist thread.


Hacking initrd.img for fun and profit

May 06, 2015 06:16 AM

During my presentation at Loadays 2015 , I was mentioning some tips and tricks around Anaconda and kickstart, and so how to deploy CentOS , fully automated. I asked the audience about where to store the kickstart, that would be used then by anaconda to install CentOS (same works for RHEL/Fedora), and I got several answers, like "on the http server", or "on the ftp server", which is where most people will put their kickstart files. Some would generate those files files "dynamically" (through $cfgmgmt - I use Ansible with Jinja2 template for this - ) as a bonus point.

But it's not mandatory to host your kickstart file on a publicly available http/ftp/nfs server, and surely not when having to reinstall nodes not in the same DC. Within the infra, I sometimes have to reinstall remote nodes ("donated" to the Project) that are running CentOS 5 or 6 to 7. That's how injecting your ks file directly into the initrd.img really helps. (yes, so network server needed). Just as an intro, here is how you can remotely trigger a CentOS install, without any medium/iso/pxe environment : basically you just need to download the pxeboot images (so vmlinuz and initrd.img), provide some default settings for Anaconda (for the network config, and how to grab stage2 image, and so where is the install tree) On the machine to be reinstalled :

cd /boot/

Now you can generate and copy your kickstart file for that node and send it to the remote node (with scp, etc ..) Next step on that remote node is to "inject" the kickstart directly in the initrd.img :

#assuming we have copied the ks file as ks.cfg in /boot already
echo ks.cfg | cpio -c -o >> initrd.img

So now we have a kernel/initrd.img, containing the kickstart file. You can modify grub(2) to add a new menu entry, make it the default one for next reboot and enjoy. But I usually prefer not doing that, if you need someone to reset that node remotely if something wrong happens, so instead of modifying grub(2), I just use kexec to reboot directly with the new kernel (without having to power cycle the node) :

# can be changed to something else, if for example node is running another distro not using yum as package manager
yum install -y wget kexec-tools 
kexec -l vmlinuz --append='net.ifnames=0 biosdevname=0 ksdevice=eth0 inst.ks=file:/ks.cfg inst.lang=en_GB inst.keymap=be-latin1 ip=your.ip netmask=your.netmask dns=your.dns' --initrd=initrd.img && kexec -e

As you can see in the append line, I just tell anaconda/kernel to not use the new nic naming (default now in CentOS 7, and sometimes hard to guess in advance), assuming that eth0 is the one to use (verify carefully that !), and the traditional ks= line in fact now just points to /ks.cfg ( initrd.img being / ). The rest is self-explained.

The other cool stuff, is that you can use the same "inject" technique but for Virtual Machines installed through virt-install : it supports injecting directly files in the initrd.img, so easier than for bare metal nodes : you just have to use two parameters for virt-install :

  • --initrd-inject=/path/to/your/ks.cfg
  • --extra-args "console=ttyS0 ks=file:/ks.cfg”

Hope this helps

May 05, 2015

Last few days in CentOS, May 5th

May 05, 2015 05:32 PM

Just a short recap of some of the things going on around the CentOS Ecosystem.

* We have now got a 5 machine armv7 ( 32 bit ) Buildsystem running. Over the coming days and weeks you should keep an eye out for testing calls. If you can, and have interesting ARM hardware, feel free to join us at the arm-dev list ( – more information on the build system can be found in this thread:

* There is a lot of work being done to get XFCE in a good state for CentOS-6 and 7, you can track the conversation from this thread

* The RDO Project is running 2 test days for OpenStack on CentOS. You can get details and join the effort ( it runs 5th and 6th May ) at

* There is a Vagrant Box now available for CentOS, for user testing and feedback – if you use Vagrant on VirtualBox or Livbirt or vmware backends, please give this a try and send feedback to the centos devel list ( more info at :


* We had a great CentOS Dojo at Bangalore, India on the 29th April. About 70 CentOS users came together to talk about containers. Details of the meeting are at and you can see some pictures at

* OpenStack Summit is happening at Vancouver, CA from May 18th to 22nd. CentOS Project will have a presence there. If you are coming to the event, stop by and say hi! We will also have tshirts and stickers, so come along and help yourself to some of those.

* Netherlands UUG Spring Conference is taking place on the 28th May, ( ) I will be there speaking about CentOS Linux, The CentOS project and some of the new innitatives we are starting up, along with how people can get involved in these efforts.

In other news, 7 students have taken up the Google Summer of Code slots that were allocated to the CentOS Project, over the next few weeks expect to see some traffic on centos-devel list from those students – and we will be encouraging them to come and join the various SIG meetings and communicate outward their progress, and also ask for help if they get stuck in anywhere. They will be working on things ranging from Kpatch live patching, to Xen and Cloud installs, to improving our
documentation trails! I’m very excited to have these students onboard! Hope they have a great summer ahead and produce some great code.

- KB

April 22, 2015

Some recent news from CentOS : Apr 22 2015

April 22, 2015 11:37 AM


This is a summary of some of the major things going on in the project, its not a comprehensive list, but should cover most of the major traction points:

Firstly, lets all welcome Brian Stinson to the fold ( )

Updates for CentOS 5/6/7 : All updates from upstream are released into the CentOS Linux mirror network.

* Moving towards Signed Metadata ( ref: )

* Building a downstream CentOS based Atomic Host ( ref: )

Other interesting things:

* The CentOS Mini Dojo in Bangalore April 2015 :

* Fabian was speaking at Loadays a few weekends back and did a great session on Installing CentOS, Slides from his presentation are available
here :

* CentOS Project is participating in the Google Summer of Code for the first time this year, and we have been allocated 7 slots for projects. There are some very interesting projects in the pipeline. The landing page for the ideas is at – and conversation around this has been taking place in both centos-devel list and the gsoc list ( )

Finally, I am going to try and run this weekly with a few notes from various places. Any and all help is appreciated. You can send me news to post in this at kbsingh


March 31, 2015

CentOS-7 (1503) is released

March 31, 2015 06:32 PM

Today the CentOS-Project announced the immediate availability of CentOS-7 (1503), the second release of CentOS-7.


Find out more about the release announcement here:

Also don’t forget to read the release notes at the wiki:

March 20, 2015

CentOS-7 / CR repo has been populated

March 20, 2015 02:41 PM

Waiting for the new package set in the next CentOS-7 release ? A majority of them are now available on every CentOS-7 machine by running the following commands :

yum update
yum --enablerepo=cr list updates

Its important you run a ‘yum update’ first, since the cr repo definitions are only available in the newer centos-release rpms. Once you are happy with the new content that is going to come via the CR repos, you can apply them with :
yum --enablerepo=cr update

For more information on whats been pushed to these CR Repos, look at the announcement email at :

You can get more information on the CR process, the repository and the content inside it at :

– KB

March 11, 2015

CentOS-7 next release

March 11, 2015 03:36 PM

Red Hat Enterprise Linux 7.1 was released a few days back, You can go read the release notes now. Its a great way to find out the big changes and enhancements in this release.

On the CentOS side of things, we have been working through last week on getting the sources organised and the builds started up. We are pretty close to finishing the first cycle of builds. The next step would be to get the content into QA repos so people can start poking it. From there on, content will make its way into the CR/ repos, and we will goto work on the distribution media ( ie. the ISOS, Cloud Images, containers, live media etc ). Once that is done, we have another couple of days for QA around those bits, followed by the wider release.

This release for CentOS-7 is going to be tagged 1503 to indicate month of upstream release.

In terms of a timeline, this is where things stand : We hope to start moving content into the CR repos by the 13th/14th of March. This should set us up for releasing the distro around the end of the following week 18th to 20th of March. Ofcourse, this is a projected date and might change depending on how much time and work the QA cycles take up and any challenges we hit in the distro media building stages.

Note that the CR repos contain packages that have not been through as much QA as the content at release time, so while they do give people a path to early-access to next-release rpms and content, they come with the added risk.

Some of the special interest groups in CentOS are keen to get started with the new content, and we are trying to find a way to make that work – but at this time there is no mechanism that bridges the two buildsystems ( the CentOS Distro one, and the Community Build System used by the SIGs ). So for the time being the SIGs will just need to wait a few more days before they can start their trials and builds. For the future, its something we will try and find a solution for, so in the next release SIGs can start doing their builds and testing as the distro packages are being built.

– KB

March 10, 2015

SCALE 13x – no talking, all walking, and a great ally skills workshop

March 10, 2015 02:40 PM

For the first time in-I-can’t-remember I didn’t submit a talk to SCALE, so it was with a different personal energy that I attended SCALE 13x on 19 to 22 February this year. Not having a do-or-die public-speaking-scheduled-thing in front of me allowed for a more relaxed state of mind. Yet it was strange to not be one of the speakers this time. Still, all my old SCALE friends made me feel very welcome and accommodated. As usual, it was nice to have my family there, where so many know them as former speakers and regular attendees.

Rather than focus on talking to an audience, this time I spent my energy walking around the expo hall-and-wherever to talk with as many projects and companies as possible. My goal was to get an idea of who uses CentOS Linux, for what purposes, and get ideas of what people need and want from the project. I also provided information on what the Project has been up to especially around SIGs. That activity was fun, informative, and interesting.

Also I spent my share of time at the booth that housed the CentOS Project, RDO/OpenStack, oVirt, and OpenShift Origin. (I can’t wait to see the next iterations of Ryan’s Raspberry Pi 2 mini-cluster demo for OpenShift Origin.) I watched other people, including my wife, play with instruments and music software at the ever-popular Fedora Project booth (winners once again of a favorite booth award.) With a small rock concert and 3D printer, it was hard not to notice.

There were two sessions I was drawn to the most. The first was Ruth Suehle‘s keynote on Sunday morning, Makers:  The Next Frontier for Open Source. I’ve worked with Ruth a long time, seen her speak multiple times, seen lots of cool stuff that she’s made over the years, and I knew it would be an excellent talk. She used her great bully pulpit to teach and entreat the audience about the needs of the makers communities to get some serious clue and help from open source communities.

The other session was a workshop on Friday to learn skills as a man to be an ally for women when sexist things happen. This is something I’m interested in, being a better ally for people, including in the face of sexism and sexist behavior. For myself, I’ve begun calling myself a born again feminist. To me that means I’ve had a later-in-life realization that while I’ve always supported the ideas and topics around feminism, I wasn’t really aware how deeply pervasive sexism is, how blandly I’d looked past it, and that I could be part of the solution. Part of being part of the solution is not being afraid of being a feminist in name and action.

The workshop (described in detail here) was lead by Valerie Aurora, who’s gone from kernel hacker to executive director of the Ada Initiative. The Ada Initiative “supports women in open technology and culture …” Thus the workshop was primarily for people working in open technology and open culture. It started with a brief introduction that was useful in many ways, such as reminding us about how to best engage with difficult online exchanges (more advanced than ‘don’t feed the trolls’), the reason for needing male allies (hint:  it’s about doing something good with the privileged position and power that one has in society), and keeping it all in a useful context by not having the workshop be a place to debate “is there sexism?” Instead we acknowledge there is something broken, it needs fixing, and we here can do something about it. You can watch an introduction and highlights of the workshop in this video that Valerie gave to the staff at the Wikimedia Foundation, with closed captioned subtitles available for English.

For the majority of the workshop, we were in small groups (4 to 6 people) to discuss approaches we would take to certain scenarios. One scenario (as I recall them) was, “A woman is standing outside of your group at an event and looks as if she might be interested in joining the discussion. How would you handle this?” Another was, “At a work party someone comments that a co-worker with a large number of children must get a lot of sex.” Then the small groups discussed our approaches, and presented some ideas or questions back to the overall group. And then on to the next scenario.

The discussion/collaboration session was really useful in a number of ways. First, it helped give specific and general ideas of how to handle — and not handle — specific scenarios. Second, it also served to give a crosscut of different types of situations that do occur, so you can take skills from one scenario more easily in to another. Not only was it useful for dealing with sexist situations, it was easy to see the same thinking and skills could be applied to any situation where someone is objectified, made to be an Other, treated as a stereotype, and so forth — thus useful for handling racism, ageism, and so forth. Third, it was useful to get a chance to practice what to say in response when we witness sexism, partially because it’s helps us to have something to immediately say rather than being shocked and mute.

The format of the workshop was great. Elements included working in small groups, a person in each group being a gatekeeper who makes sure everyone in the group is heard from, presenting ideas back to the overall group in a discussion format, all the way down to how we introduced ourselves to our small groups. I also appreciated moving across groups at least once, that helped us get fresher perspectives with each scenario.

This is definitely a workshop I’d like to bring to any tech company. All of us can use help and perspective on how to react when someone does something sexist, or we have a chance to do something about systemic sexism. We can agree that it’s unkind to make people feel uncomfortable, and it’s kind to help people by pushing against the discomfort making.

There is something I’ve noticed for most of my life. When talking with my peers — people who are born mainly after the 1960s in a post-feminist-creation era — we are often in agreement about how people should treat each other along the axes of sex, race, gender, and so forth. And while I see in younger generations a huge amount of support for ideas such as “people should be able to legally marry whomever they want”, I still hear a lot of people afraid of the f-word — feminism. It’s as if people are in full agreement with the concepts behind the word, but afraid to use the word itself. This is the other part of my ‘born again’ experience, that I need to embrace the word as well as the concept in order to really align myself correctly, live correctly, and be a good ally of all people.

Building CentOS Linux 7 for ARMv8

March 10, 2015 11:06 AM

As I’d mentioned previously, the fine folks of Applied Micro were kind enough to give us an X-C1 development box to see if it was feasible to build and run CentOS Linux 7. My first attempt through, I realized I hadn’t been taking decent notes, so I scrapped most of the package work and started over. This time I took a few more notes, and hopefully I’ve documented some things that will help everyone. If you’re interested in discussing or joining the ARMv8 process, feel free to join our ARM development mailing list, or find me on Freenode’s irc network in #centos-devel (nick: Evolution ).


Initial Steps

The official Linux architecture name for ARMv8 is aarch64. However both terms seem to be in circulation and we use them to imply the same thing.

My plan for the X-C1 box was to install Fedora, and use mock to get a decent buildroot in order. Because the X-C1 box came with a uboot based image by default, I had to replace it with uefi first. The directions for doing that can be found on Fedora’s aarch64 wiki page. Once uboot was successfully replaced with UEFI, I installed Fedora 21 and mock. I chose F21 largely because there I couldn’t find a Fedora 19 image to work from, but there are Fedora 19 packages available to help bootstrap a C7 mock chroot, which is really what I was after. I copied this repository to a local system both to not hammer the remote machine, and to reduce the latency.


Host Modifications

While I worked on getting the roughly 150 packages needed for a basic mock buildroot built, I kept running into a recurring problem with failed tests for elfutils. Part of the elfutils test suite tests coredumps and it seems that the buildhost’s systemd-coredump utility was stealing them. After some time digging around with this, I ended up with the following commands:

# echo "kernel.core_pattern=core" > /etc/sysctl.d/50-coredump.conf
# sysctl --system

Once that was done, the elfutils build tests passed without issue.


Package Builds

Initially I attempted to work out a build order that would allow me to build from the ground up, but I quickly realized this was foolish. When starting from the bottom like this, everything has a build dependency on something else. Instead I chose to work toward a clean mock init first, and then work up from that point. Since I only have one board to build against, I’m currently abusing bash and cycling things through mock directly. The idea of using koji or plague seemed a bit overkill with just one build host doing the work. Once everything has been built (or thrown out of the build) against the F19 repository, it will be time to do the build again against itself to ensure that everything is properly linked and self-hosting.


It’s worth noting that some of the packages in the F19 repository are actually tagged as F20 and are newer than what exists in CentOS Linux 7. I found it necessary to exclude these newer versions, and often to exclude other packages as the build has progressed. While not an exhaustive list, examples are:

  • sqlite-3.8
  • tcl-8.5.14
  • tk
  • Various perl modules



I mentioned that a few packages have been ejected from the build outright. Some of these are because the build dependencies either aren’t, or can’t be met. The prime example of this is ADA support, which requires the same cross-compiled (or otherwise bootstrapped) ADA version to build (yay for circular dependencies). Since nothing appears to explicitly depend on the ADA packages like libgnat, for now I’ve removed them. Down the road, if I’m able to properly add support I will certainly revisit this decision.



There are a few packages from CentOS Linux 7 that I just won’t be able to use. The primary issue is the kernel. The 3.10 kernel just doesn’t have the support for aarch64 that’s needed, so my current plan is to target 3.19 as the kernel to ship for aarch64. This is still speculation, as I’ve been procrastinating on actually building it. I imagine that will happen for the next blog post update :-)

The other problematic package is anaconda. I’m unsure if I can patch the version in 7 to support aarch64, or if I’ll need to ‘forward-port’ and use a more recent version from fedora to handle the installation. If anyone from the community has insights or suggestions for this, please speak up.

I’ll continue posting updates as the build progresses, or as I find interesting things worth mentioning.


March 03, 2015

CentOS Linux 7 and Arm

March 03, 2015 11:54 AM


With the growing list of easily accessible ARM hardware like the RaspBerry Pi 2 and the ODROID-C1, several community efforts have sprouted, working out the details for getting CentOS-7 built and available for the new boards. One of our UK based community members has made the most progress so far, posting his build process on the CentOS arm development list. As he progresses, he’s also been keeping some fairly detailed notes about what changes he’s had to make. Once he’s been able to produce an installable (or extractable) image, we’ll see about incorporating and maintaining his changes as branches in git. With a bit more work, we should be able to start rolling out a fully community built and supported 32bit arm build of CentOS-7.armv7-web


Far from stopping there, work is underway on the 64bit ARM front as well. The fine folks at Applied Micro were kind enough to lend us two of their X-C1 ARMv8 development kits. After a bit of work to replace the default uboot with UEFI, and a few early missteps, the work on an aarch64 port of CentOS-7 is progressing along rather nicely as well. I’ll work on documenting the build system, steps to duplicate for anyone who has the hardware and wants to participate, and potential changes required.


If you’d like to get involved or want to follow the progress of the work, please join our arm development list, or join us in #centos-devel on freenode irc.

Powered by Planet!
Last updated: September 01, 2015 10:00 PM