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: http://people.centos.org/bstinson/edison/edison-image-centos.ext4.xz
Sources and Yum Repo: http://people.centos.org/bstinson/edison/7/

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 http://buildlogs.centos.org/centos/7/os/i386/Packages/centos-release-7-1.1503.el7.centos.2.8.1.i686.rpm\

# 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 dfu-util@lists.gnumonks.org

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 systemd.unit=multi-user.target 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

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: asadxflow@gmail.com
  • IRC: asad_ (#centos-devel)



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 http://lists.centos.org/pipermail/arm-dev/2015-February/000089.html 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 https://www.redhat.com/archives/fedora-buildsys-list/2009-July/msg00000.html

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 (https://github.com/mndar/rbf/blob/master/doc/QEMU_README.md), Cubietruck, Odroid C1, Raspberry Pi 2, Banana Pi, Cubieboard 2. Tests for the last two have been reported by Nicolas [nicolas at shivaserv.fr] and David Tischler [david.tischler at mininodes.com] 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 https://github.com/mndar/rbf/blob/master/doc/ADD_SUPPORT_README.md

Presently there are 3 main components in RootFS Build Factory

  • rbf.py : takes a XML Template and generates an image.
  • rbfdialog.py : dialog based UI using the python2-pythondialog library to load/edit/create XML Templates.
  • rbfinstaller.py : 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 gmail.com] or discuss it on the CentOS arm-dev mailing list http://lists.centos.org/mailman/listinfo/arm-dev

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 _ tmrts.com
  • IRC: tmrts


Tamer Tas


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.

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.

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!


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.

As of now, you can subscribe to a calendar feed (.ical) in your calendar program of choice by adding this feed url:


New meetings are added via pull-requests against this repository: https://github.com/CentOS/Calendar

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 https://github.com/CentOS/Calendar 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 git.centos.org

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.

As Jim Perrin pointed out in an earlier post here on seven.centos.org, 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.