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:
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:
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.
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:
More information is available from our announcement here:
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, planet.centos.org; students individual blogs are found at the CentOS 7 blog seven.centos.org.
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.
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.
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.
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.
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).
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.
Just as you’d expect, once the installer completes successfully, you’ll be prompted to reboot.
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.
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:
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.