With the latest release of CentOS-7, we have added several new Alternative Architecture (AltArch) releases in addition to our standard x86_64 (x86 {Intel/AMD} 64-bit) architecture.

Architectures (aka arches) in Linux distributions refer to the type of CPU on which the distribution runs.  In the case of our standard release, it runs on x86 64-bit CPUs like Intel Pentium 64-bit and AMD 64-bit processors.  A few months ago, in the CentOS 7 (1503) release, we added the x86 32-bit (i686) as well as the Arm 64-bit (aarch64) architectures to CentOS-7.  These two arches have been updated to our latest CentOS-7 release (1511).

We have additionally added 3 new architectures to our latest release.  Arm32 Userland (armhfp), PowerPC 7 (ppc64) and PowerPC 8 LE (ppc64le).  Here is the Release Announcement.

These new architectures provide a long lived community based platform based on our x86_64 releases many new machine types.  The CentOS team is very excited to be able to provide our code base for these architectures and we need help from the community to make them all better.

We are hosting a CentOS Dojo in Brussels, Belgium on the 29th Jan 2016. Lots of the key people working on the AltArch builds will be present there and it would be a great forum to engage with these groups. You can get the details for the event HERE, including the registration links. (Note: Registrations are currently closed, but we are trying to find more space, so they could open before the event)

We will also have a booth at FOSDEM 2016, as well as talks in the Distributions DevRoom, see you there.

With the release of 7.2, we’ve seen a rise in bugs filed for container build failures in docker. Not to worry, we have an explanation for what’s going on, and the solution for how to fix it.

The Problem:

You fire off a docker build, and instead of a shiny new container, you end up with an error message similar to:

Transaction check error:
file /usr/lib64/libsystemd-daemon.so.0 from install of systemd-libs-219-19.el7.x86_64 conflicts with file from package systemd-container-libs-208.20-6.el7.centos.x86_64
file /usr/lib64/libsystemd-id128.so.0 from install of systemd-libs-219-19.el7.x86_64 conflicts with file from package systemd-container-libs-208.20-6.el7.centos.x86_64
file /usr/lib64/libsystemd-journal.so.0 from install of systemd-libs-219-19.el7.x86_64 conflicts with file from package systemd-container-libs-208.20-6.el7.centos.x86_64
file /usr/lib64/libsystemd-login.so.0 from install of systemd-libs-219-19.el7.x86_64 conflicts with file from package systemd-container-libs-208.20-6.el7.centos.x86_64
file /usr/lib64/libudev.so.1 from install of systemd-libs-219-19.el7.x86_64 conflicts with file from package systemd-container-libs-208.20-6.el7.centos.x86_64
file /usr/lib64/security/pam_systemd.so from install of systemd-libs-219-19.el7.x86_64 conflicts with file from package systemd-container-libs-208.20-6.el7.centos.x86_64

This is due to the transition from systemd-container-* packages to actual systemd. For some reason, the upstream package doesn’t obsolete or conflict, and so you’ll get errors when installing packages.

The fix:

The fix for this issue is very simple. Do a fresh docker pull of the base container.

# docker pull centos:latest

or

# docker pull centos:7

Your base container will now be at the appropriate level, and won’t have this conflict on package installs so you can simply run your docker build again and it will work.

But I have to use 7.1.1503!

If for some reason you must use a point-in-time image like 7.1.1503, then a package swap will resolve things for you. 7.1.1503 comes with fakesystemd, which you must exchange for systemd. To do this, execute the following command in your Dockerfile, prior to installing any packages:

RUN yum clean all && yum swap fakesystemd systemd

This will ensure you get the current package data, and will replace the fakesystemd package which is no longer needed. That’s all there is to solving the file conflicts and systemd dependency issues for CentOS base containers.

 

Today we’re announcing an update to CentOS Atomic Host (version 7.20151118), a lean operating system designed to run Docker containers, built from standard CentOS 7 RPMs, and tracking the component versions included in Red Hat Enterprise Linux Atomic Host. Please note that this release is based on content derived from the upstream 7.1 release.

CentOS Atomic Host is available as a VirtualBox or libvirt-formatted Vagrant box, or as an installable ISO, qcow2 or Amazon Machine image. These images are available for download at cloud.centos.org. The backing ostree repo is published to mirror.centos.org.

CentOS Atomic Host includes these core component versions:

  • kernel-3.10.0-229.20.1.el7.x86_64
  • cloud-init-0.7.5-10.el7.centos.1.x86_64
  • atomic-1.6-6.gitca1e384.el7.x86_64
  • kubernetes-1.0.3-0.2.gitb9a88a7.el7.x86_64
  • etcd-2.1.1-2.el7.x86_64
  • ostree-2015.6-4.atomic.el7.x86_64
  • docker-1.8.2-7.el7.centos.x86_64
  • flannel-0.2.0-10.el7.x86_64

Upgrading

If you’re running a previous version of CentOS Atomic Host, you can upgrade to the current image by running the following command:

$ sudo atomic host upgrade

Images

Vagrant

CentOS-Atomic-Host-7-Vagrant-Libvirt.box (409 MB) and CentOS-Atomic-Host-7-Vagrant-Virtualbox.box (421 MB) are Vagrant boxes for Libvirt and Virtualbox providers.

The easiest way to consume these images is via the Atlas / Vagrant Cloud setup (see https://atlas.hashicorp.com/centos/boxes/atomic-host). For example, getting the VirtualBox instance up would involve running the following two commands on a machine with vagrant installed:

$ vagrant init centos/atomic-host && vagrant up --provider virtualbox

ISO

The installer ISO (673 MB) can be used via regular install methods (PXE, CD, USB image, etc.) and uses the Anaconda installer to deliver the CentOS Atomic Host. This allows flexibility to control the install using kickstarts and define custom storage, networking and user accounts. This is the recommended process for getting CentOS Atomic Host onto bare metal machines, or to generate your own image sets for custom environments.

QCOW2

The CentOS-Atomic-Host-7-GenericCloud.qcow2 (934 MB) is suitable for use in on-premise and local virtualized environments. We test this on OpenStack, AWS and local Libvirt installs. If your virtualization platform does not provide its own cloud-init metadata source, you can create your own NoCloud iso image. The Generic Cloud image is also available compressed in gz format (408 MB) and xz compressed (323 MB).

Amazon Machine Images

Region Image ID
sa-east-1 ami-39348e55
ap-northeast-1 ami-cec7e4a0
ap-southeast-2 ami-5e421b3d
us-west-2 ami-cb6878aa
ap-southeast-1 ami-49a4652a
eu-central-1 ami-f72b399b
eu-west-1 ami-3c2ff54f
us-west-1 ami-48e88628
us-east-1 ami-19d59073

SHA Sums

cf7c5e67e18a3aaa27d1c6c4710bb9c45a62c80fb5e18a836a2c19758eb3d23e CentOS-Atomic-Host-7.20151101-GenericCloud.qcow2 92cf36f528ae00235ad6eb4ee0d0dd32ccf5f729f2c6c9a99a7471882effecaa CentOS-Atomic-Host-7.20151101-GenericCloud.qcow2.gz 263c1f403c352d31944ca8c814fd241693caa12dbd0656a22cdc3f04ca3ca8d1 CentOS-Atomic-Host-7.20151101-GenericCloud.qcow2.xz dfe0c85efff2972d15224513adc75991aabc48ec8f8ad49dad44f8c51cfb8165 CentOS-Atomic-Host-7.20151101-Installer.iso 139eb88d6a5d1a54ae3900c5643f04c4291194d7b3fccf8309b8961bbd33e4ec CentOS-Atomic-Host-7.20151101-Vagrant-Libvirt.box 63ab56d08cdc75249206ad8a7ee3cdd51a226257c8a74053a72564c3ff3d91a0 CentOS-Atomic-Host-7.20151101-Vagrant-Virtualbox.box

Release Cycle

The CentOS Atomic Host image follows the upstream Red Hat Enterprise Linux Atomic Host cadence. After sources are released, they’re rebuilt and included in new images. After the images are tested by the SIG and deemed ready, we announce them.

Getting Involved

CentOS Atomic Host is produced by the CentOS Atomic SIG, based on upstream work from Project Atomic. If you’d like to work on testing images, help with packaging, documentation — join us!

The SIG meets weekly on Thursdays at 16:00 UTC in the #centos-devel channel, and you’ll often find us in #atomic and/or #centos-devel if you have questions. You can also join the atomic-devel mailing list if you’d like to discuss the direction of Project Atomic, its components, or have other questions.

Getting Help

If you run into any problems with the images or components, feel free to ask on the centos-devel mailing list.

Have questions about using Atomic? See the atomic mailing list or find us in the #atomic channel on Freenode.

Red Hat released their second point release to the EL7 series today. Most if not all of the sources seem to already be in place on git.centos.org, so we can start the rebuild and QA cycle. Red Hat release notes can be found here.

It is not yet decided, if we do a CR-release with the build packages, or if it will be a release with ISOs and all. Our reading of the errata released with 7.2 indicates no critical security update. We will post news on this matter here. Those errata can be found here.

As Regulars know, this will take some time, and the next minor release of CentOS-7 will be done when it is done. So it can be either 7.1511 or 7.1512.

Stay tuned.

The Alternative Architecture Special Interest Group (AltArch SIG) is happy to announce the release the x86 32-bit version of CentOS Linux 7.  This architecture is also known as i386 or i686.  You can get this version of CentOS from the INFO page.

This version of CentOS Linux 7 is for PAE capable 32 bit machines, including x86 based IOT boards similar to the Intel Edison.  It joins the 64-bit ARMv8 (aarch64) architecture as a fully released AltArch version.

Work within the AltArch SIG currently continues on the 32-bit ARMv7, 64-bit PPC little-endian, and 64-bit PPC big-endian architectures.

 

 

Today we’re announcing an update to CentOS Atomic Host (version 7.20151001), a lean operating system designed to run Docker containers, built from standard CentOS 7 RPMs, and tracking the component versions included in Red Hat Enterprise Linux Atomic Host.

CentOS Atomic Host is available as a VirtualBox or libvirt-formatted Vagrant box, or as an installable ISO, qcow2 or Amazon Machine image. These images are available for download at cloud.centos.org. The backing ostree repo is published to mirror.centos.org.

CentOS Atomic Host includes these core component versions:

  • kernel-3.10.0-229.14.1.el7.x86_64
  • cloud-init-0.7.5-10.el7.centos.1.x86_64
  • atomic-1.0-115.el7.x86_64
  • kubernetes-1.0.3-0.1.gitb9a88a7.el7.x86_64
  • flannel-0.2.0-10.el7.x86_64
  • docker-1.7.1-115.el7.x86_64
  • etcd-2.1.1-2.el7.x86_64
  • ostree-2015.6-4.atomic.el7.x86_64

If you’re running a previous version of CentOS Atomic Host, you can upgrade to the current image by running the following command:

Upgrading

$ sudo atomic host upgrade

Images

Vagrant

CentOS-Atomic-Host-7-Vagrant-Libvirt.box (389 MB) and CentOS-Atomic-Host-7-Vagrant-Virtualbox.box (400 MB) are Vagrant boxes for Libvirt and Virtualbox providers.

The easiest way to consume these images is via the Atlas / Vagrant Cloud setup (see https://atlas.hashicorp.com/centos/boxes/atomic-host. For example, getting the VirtualBox instance up would involve running the following two commands on a machine with vagrant installed:

  vagrant init centos/atomic-host && vagrant up --provider virtualbox 

ISO

The installer ISO (672 MB) can be used via regular install methods (PXE, CD, USB image, etc.) and uses the Anaconda installer to deliver the CentOS Atomic Host. This allows flexibility to control the install using kickstarts and define custom storage, networking and user accounts. This is the recommended process for getting CentOS Atomic Host onto bare metal machines, or to generate your own image sets for custom environments.

QCOW2

The CentOS-Atomic-Host-7-GenericCloud.qcow2 (393 MB) is suitable for use in on-premise and local virtualized environments. We test this on OpenStack, AWS and local Libvirt installs. If your virtualization platform does not provide its own cloud-init metadata source, you can create your own NoCloud iso image. The Generic Cloud image is also available compressed in gz format (391 MB) and xz compressed (390 MB).

Amazon Machine Images

Region Image ID
------ --------
sa-east-1 ami-1b52c506
ap-northeast-1 ami-3428b634
ap-southeast-2 ami-43f2bb79
us-west-2 ami-73eaf043
ap-southeast-1 ami-346f7966
eu-central-1 ami-7ed1d363
eu-west-1 ami-3936034e
us-west-1 ami-6d9c5a29
us-east-1 ami-951452f0

SHA Sums

96586e03a1a172195eae505be35729c1779e137cd1f8c11a74c7cf94b0663cb2 CentOS-Atomic-Host-7.20151001-GenericCloud.qcow2 33d338bb42ef916a40ac89adde9c121c98fbd4220b79985f91b47133310aa537 CentOS-Atomic-Host-7.20151001-GenericCloud.qcow2.gz 73184e6f77714472f63a7c944d3252aadc818ac42ae70dd8c2e72e7622e4de95 CentOS-Atomic-Host-7.20151001-GenericCloud.qcow2.xz 4e09f6dfae5024191fec9eab799861d87356a6075956d289dcb31c6b3ec37970 CentOS-Atomic-Host-7.20151001-Installer.iso 92932e9565b8118d7ca7cfbe8e18b6efd53783853cc75dae9ad5566c6e0d9c88 CentOS-Atomic-Host-7.20151001-Vagrant-Libvirt.box 8f626bdafaecb954ae3fab6a8a481da1b3ebb8f7acf6e84cf0b66771a3ac3a65 CentOS-Atomic-Host-7.20151001-Vagrant-Virtualbox.box

Release Cycle

The CentOS Atomic Host image follows the upstream Red Hat Enterprise Linux Atomic Host cadence. After sources are released, they’re rebuilt and included in new images. After the images are tested by the SIG and deemed ready, we announce them.

Getting Involved

CentOS Atomic Host is produced by the CentOS Atomic SIG, based on upstream work from Project Atomic. If you’d like to work on testing images, help with packaging, documentation — join us!

The SIG meets weekly on Thursdays at 16:00 UTC in the #centos-devel channel, and you’ll often find us in #atomic and/or #centos-devel if you have questions. You can also join the atomic-devel mailing list if you’d like to discuss the direction of Project Atomic, its components, or have other questions.

Getting Help

If you run into any problems with the images or components, feel free to ask on the centos-devel mailing list.

Have questions about using Atomic? See the atomic mailing list or find us in the #atomic channel on Freenode.

Today we’re releasing a significant update to the CentOS Atomic Host (version 7.20150908), a lean operating system designed to run Docker containers, built from standard CentOS 7 RPMs, and tracking the component versions included in Red Hat Enterprise Linux Atomic Host.

CentOS Atomic Host is available as a VirtualBox or libvirt-formatted Vagrant box, as an installable ISO image, as a qcow2 image, or as an Amazon Machine Image. These images are available for download at cloud.centos.org. The backing ostree repo is published to mirror.centos.org.

Currently, the CentOS Atomic Host includes these core component versions:

  • kernel 3.10.0-229
  • docker 1.7.1-108
  • kubernetes 1.0.0-0.8.gitb2dafda
  • etcd 2.0.13-2
  • flannel 0.2.0-10
  • cloud-init 0.7.5-10
  • ostree 2015.6-4
  • atomic 1.0-108

Upgrading

If you’re running the version of CentOS Atomic Host that shipped in June, you can upgrade to the current image by running the following command:

$ sudo atomic host upgrade

If you’re currently run the older, test version of the CentOS Atomic Host, or if you’re running any other atomic host (from any distro or release in the past), you can rebase to this released CentOS Atomic Host by running the following two commands :

$ sudo ostree remote add centos-atomic-host http://mirror.centos.org/centos/7/atomic/x86_64/repo
$ sudo rpm-ostree rebase centos-atomic-host:centos-atomic-host/7/x86_64/standard

Images

Vagrant

CentOS-Atomic-Host-7-Vagrant-Libvirt.box (393 MB) and CentOS-Atomic-Host-7-Vagrant-Virtualbox.box (404 MB) are Vagrant boxes for Libvirt and Virtualbox providers.

The easiest way to consume these images is via the Atlas / Vagrant Cloud setup (see https://atlas.hashicorp.com/centos/boxes/atomic-host. For example, getting the VirtualBox instance up would involve running the following two commands on a machine with vagrant installed:

$ vagrant init centos/atomic-host && vagrant up --provider virtualbox

ISO

The installer ISO (682 MB) can be used via regular install methods (PXE, CD, USB image, etc.) and uses the Anaconda installer to deliver the CentOS Atomic Host. This allows flexibility to control the install using kickstarts and define custom storage, networking and user accounts. This is the recommended process for getting CentOS Atomic Host onto bare metal machines, or to generate your own image sets for custom environments.

QCOW2

The CentOS-Atomic-Host-7-GenericCloud.qcow2 (922 MB) is suitable for use in on-premise and local virtualized environments. We test this on OpenStack, AWS and local Libvirt installs. If your virtualization platform does not provide its own cloud-init metadata source, you can create your own NoCloud iso image. The Generic Cloud image is also available compressed in gz (389 MB) and xz compressed (303 MB) formats.

Amazon Machine Images

Region         Image ID
------         --------
sa-east-1      ami-47ed785a
ap-northeast-1 ami-3458d234
ap-southeast-2 ami-05511e3f
us-west-2      ami-a5b6ab95
ap-southeast-1 ami-dc99938e
eu-central-1   ami-8c111191
eu-west-1      ami-0b6e4d7c
us-west-1      ami-69679d2d
us-east-1      ami-69c3aa0c

SHA Sums

a132d59732e758012029a646c466227f4ecf0c71cc42f0a10d3672908e463c0c CentOS-Atomic-Host-7.20150908-GenericCloud.qcow2
aad5d39e0683dc997f34902b068c7373aac3f7dc9b2c962a6ac0fe7394e2aa58 CentOS-Atomic-Host-7.20150908-GenericCloud.qcow2.gz
c8432175a012e7f13b7005fe9c1fe43e03e47ca433db8230ab6d5d1831d2cbe0 CentOS-Atomic-Host-7.20150908-GenericCloud.qcow2.xz
b222702942d02da2204581de6f877cf93289459a99f9080e29016e3b90328098 CentOS-Atomic-Host-7.20150908-Installer.iso
5531fa99429b38c6e6c4aca87672bd5990ab90f6445cc0e55c9121ad62229141 CentOS-Atomic-Host-7.20150908-Vagrant-Libvirt.box
bdcf58772117dd3a84100e5902f4f345daeea7c04f057c0ab6e29bfef3c82eab CentOS-Atomic-Host-7.20150908-Vagrant-Virtualbox.box

Release Cycle

The rebuild image will follow the upstream Red Hat Enterprise Linux Atomic Host cadence. After sources are released, they’ll be rebuild and included in new images. After the images are tested by the SIG and deemed ready, they’ll be announced. If you’d like to help with the process, there’s plenty to do!

Getting Involved

CentOS Atomic Host is produced by the CentOS Atomic SIG, based on upstream work from Project Atomic. If you’d like to work on testing images, help with packaging, documentation, or even help define the direction of our monthly release — join us!

The SIG meets weekly on Thursdays at 16:00 UTC in the #centos-devel channel, and you’ll often find us in #atomic and/or #centos-devel if you have questions. You can also join the atomic-devel mailing list if you’d like to discuss the direction of Project Atomic, its components, or have other questions.

Getting Help

If you run into any problems with the images or components, feel free to ask on the centos-devel mailing list.

Have questions about using Atomic? See the atomic mailing list or find us in the #atomic channel on Freenode.

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
packages

# 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\
http://people.centos.org/bstinson/edison/7/i386/Packages/centos-release-edison-1-1.el7.centos.noarch.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
emulator

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
INTERFACES="-iwlan0"

# 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.

Implementation:

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