Arm-dev

arm-dev@lists.centos.org

1 participants
685 discussions

new aarch64 dev board "coming soon"
by Jim Perrin 22 Jun '16

22 Jun '16

There's a new board coming around october-ish according to their presentation at OPNFV summit and their website. From what I can make out, it doesn't appear to be fully SBSA compliant, but it appears that it *should* work with very little modification. I'm not making any promises though until I have a chance to get hands-on with it. If you're interested -> https://www.solid-run.com/product/armada-8040-networking-community-board/ -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77

1 0

CentosArm Kernel
by OM Ugarcina 21 Jun '16

21 Jun '16

Hello Guys, I have a question on the roadmap for the CentosArm kernel . One of the reasons why people love Centos is the fact that it enjoys a longer support cycle than other distributions , which force the user to upgrade the whole OS every 6 months . But at the same time Centos backports important fixes , and improvements to the kernel to keep it up to date . So having a long term OS combined with kernel that is maintained is a very good reason for using Centos . So I wanted to ask : What is the strategy for the arm kernels , is there going to be an active program to maintain the arm kernel ? I know that the regular Centos kernel is not viable for arm , it lacks a lot of support for arm hardware . We need a more modern version that is still long term supported but newer . My suggestion would be to take kernel 4.4 as the Centos arm main kernel . It has support for arm basic hw , and it is compatible with driver source code that is needed to be added for boards such as bananapi R1 (or also known as Lamobo R1) . I my self am using Fedora's 4.4 kernels made for the fc22 line , but am expecting soon for that to disappear once fc24 comes out . And then no more kernel updates from fedora . Best Regards Milorad

4 11

Aarch64 disk image
by Marcin Trendota 17 Jun '16

17 Jun '16

Hello I'm trying to download disk image for aarch64 but it's not available: The requested URL /altarch/7/isos/aarch64/CentOS-7-aarch64.img.xz was not found on this server. (from this link: http://mirror.centos.org/altarch/7/isos/aarch64/CentOS-7-aarch64.img.xz) Same for "rolling disk image". Is this intended? (sorry for posting this message to centos-devel list - my mistake). -- Over And Out MoonWolf

4 4

Re: [Arm-dev] [CentOS-devel] Rebuilding OpenStack for AArch64
by Marcin Juszkiewicz 15 Jun '16

15 Jun '16

On 10/06/16 14:04, Thomas Oulevey wrote: >>> How we can proceed? I think that first idea is good as it allows us to do >>> builds without touching x86-64 tag before we are ready for merging. But I do >>> not have koji experience so may be wrong. >> >> New tag is the way to go, we don't want to block x86_64. >> > > +1 > > The status, we have a blocker with mergerepo / mergerepo_c [1] which are > not merging package with a dist tag different on the source package and > the binary. > [1]: > > $ repoquery > --repofrompath=reponame,http://cbs.centos.org/kojifiles/repos/storage7-ceph-jewel-el7-build/latest/aarch64/ > --repoid=reponame -q json-c > > return no result > > The mergerepo tasks (mergerepo_c because it is more verbose, same issue > with mergerepo): > https://cbs.centos.org/kojifiles/work/tasks/4276/94276/mergerepos.log > > """ > 19:33:02: Reading metadata for json-c (0.11-4.el7.aarch64) > 19:33:02: Package json-c has forbidden srpm json-c-0.11-4.el7.src.rpm > """ This is because of 0.11-4.el7_0 on x86 compared to 0.11-4.el7 on aarch64, right? Should be fixable if we rebuild json-c 0.11-4.el7_0 on aarch64 and update repositories? Is there a tool to use which would list such differences?

1 1

Re: [Arm-dev] Rebuilding OpenStack for AArch64
by Itamar Reis Peixoto 10 Jun '16

10 Jun '16

Marcin Juszkiewicz <marcin.juszkiewicz(a)linaro.org> wrote: There were discussions on irc about it but I lost track of who I should speak with etc so decided to write to mailing list instead. The goal is to rebuild OpenStack 'mitaka' packages for AArch64 (AltArch) in CBS (there is one builder for this architecture). Question is how to make it in best way? One of ideas was: 1. create new tag (cloud7-openstack-mitaka-candidate-aarch64?) 2. import all 'noarch' builds from cloud7-openstack-mitaka-* tags 3. send all required packages to the builder 4. test resulting packages 5. import/merge all of them to proper cloud7-openstack-mitaka-* tag Other was about doing scratch builds and merging them with x86-64 ones. How we can proceed? I think that first idea is good as it allows us to do builds without touching x86-64 tag before we are ready for merging. But I do not have koji experience so may be wrong. --- build same sources, and fix in same repo ? Sent from my BLU smartphone device

1 0

Rebuilding OpenStack for AArch64
by Marcin Juszkiewicz 10 Jun '16

10 Jun '16

There were discussions on irc about it but I lost track of who I should speak with etc so decided to write to mailing list instead. The goal is to rebuild OpenStack 'mitaka' packages for AArch64 (AltArch) in CBS (there is one builder for this architecture). Question is how to make it in best way? One of ideas was: 1. create new tag (cloud7-openstack-mitaka-candidate-aarch64?) 2. import all 'noarch' builds from cloud7-openstack-mitaka-* tags 3. send all required packages to the builder 4. test resulting packages 5. import/merge all of them to proper cloud7-openstack-mitaka-* tag Other was about doing scratch builds and merging them with x86-64 ones. How we can proceed? I think that first idea is good as it allows us to do builds without touching x86-64 tag before we are ready for merging. But I do not have koji experience so may be wrong.

1 0

MP3-AR0 - Limiting SATA Speed
by Gordan Bobic 08 Jun '16

08 Jun '16

Is there a way to tell u-boot (or Tianocore) on the MP30-AR0 to limit the SATA port speeds to 3Gbit instead of auto-negotiating 6Gbit? I have a case with a SATA backplane that doesn't work properly at 6Gbit, and this sometimes causes the boot to fail. If I can get it to get as far as loading the Linux kernel, it's OK as I can specify a boot parameter there to limit it, but a non-trivial fraction of the time it doesn't get that far without erroring out. TIA. Gordan

1 0

Wrong permissions on /etc/sysconfig/network-scripts
by (GalaxyMaster) 31 May '16

31 May '16

Hello, I'm new here and I'm quite happy to discover that there is an effort to port CentOS 7 to ARM. I've just downloaded the image, put it onto the card and booted up my Pi3 from it. The following I noticed right away: === [root@centos-rpi3 ~]# rpm -V initscripts .....UG.. /etc/sysconfig/network-scripts [root@centos-rpi3 ~]# ls -ld /etc/sysconfig/network-scripts drwxr-xr-x. 2 1000 1000 4096 Nov 27 16:23 /etc/sysconfig/network-scripts [root@centos-rpi3 ~]# chown -h root:root /etc/sysconfig/network-scripts [root@centos-rpi3 ~]# rpm -V initscripts [root@centos-rpi3 ~]# === It is still my first 10 minutes with Pi3 and CentOS 7 on it, but given my background I think I'll be a regular here and would able to contribute from Ops and InfoSec perspective, if there is such need. For example, I think we can do much better in terms of a minimal CentOS 7 and we should be able to enforce SELinux. I'm going investigate on both and once I'm ready I will share :) P.S. In any case, I'm very grateful for all your effort for bringing this project to life! -- (GM)

3 8

unofficial EPEL package builds
by Jim Perrin 25 May '16

25 May '16

I know quite a few of you (myself included) have been waiting for EPEL to support some of the additional architectures like AArch64. We've been working with the EPEL team to try to help this along, but it looks like the earliest this will be available is around late August. Until then, we're producing an unofficial build based on the SRPMs pulled from the fedora/EPEL mirrors. This is meant as a temporary "use at your own risk" set of packages. They are unsigned, and the repository isn't checked for dependency closure. Once the official EPEL repository is available, we will stop maintaining this branch. If I haven't scared you off yet, you can use this temporary repository by creating an unofficial.repo file in /etc/yum.repos.d with the following contents: [unofficial-builds] name=CentOS unofficial extra package rebuild baseurl=http://buildlogs.centos.org/c7-epel.a64/ metadata_expire=6h gpgcheck=0 skip_if_unavailable=True If you find a missing package, or are interested in helping to improve the packages, there's an associated bugzilla at https://bugzilla.redhat.com//show_bug.cgi?id=1285484 Please start there, or discuss/contribute here on the arm-dev(a)centos.org mailing list. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77

4 4

Re: [Arm-dev] Raspberry Pi3 kernel (Was: Wrong permissions on /etc/sysconfig/network-scripts)
by (GalaxyMaster) 24 May '16

24 May '16

Fabian, On Sat, May 21, 2016 at 10:05 PM, Fabian Arrotin <arrfab(a)centos.org> wrote: > On 21/05/16 09:57, (GalaxyMaster) wrote: > I guess we can rebuild the kernel by changing the initial patch then. Yes, this is exactly what I did to confirm that SELinux is indeed usable. > I also had a quick look at the rpi kernel source tree and it seems they > rebased to 4.4.x so wondering if that's not a good time to also bump to > that release. Yes, they made the rpi-4.4.y branch to be their main branch. I also compared the difference between rpi and kernel.org branches and the effort required to backport this to the current CentOS7 upstream kernel. Although it is not huge (around 10MB of patches) it would require a week of my time to do so and I don't have a week right now. So I guess I'm fine with using rpi-* as upstream for now. Additionally, I looked at the spec file for the kernel we are building and it's a bit dirty (e.g. it does some post-install tweaking and creates files which are not tracked by the package management). I am going to create a kernel package with the latest kernel from rpi-4.4.y with a cleaner spec file. Will share a link to my GitHub repository once it's done. > To answer your question about el7 default : it doesn't support armhfp by > default (as there is no upstream EL7 kernel for this) , and even el7 > aarch64 deviates from the 3.10.0 kernel. I am fully aware of how RedHat maintains their stable kernel trees and of their backport strategy. What I meant was that if we want to be as close as possible to CentOS7 we should have taken the upstream package from EL7 and applied the armhfp support on top of it. Anyway, as I mentioned above, it's a full week work and I don't have enough time to do it right now. > That's also the reason why we call the armhfp release "CentOS 7 > userland", because kernel differs from the CentOS 7 x86_64 (see > https://wiki.centos.org/SpecialInterestGroup/AltArch/Arm32#head-447eb2193fd…) Thanks for the link (once we rebuild Pi3 kernel with the adjusted value we could update SELinux status on that page). -- (GM)

3 2

← Newer
1
...
42
43
44
45
46
47
48
...
69
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Arm-dev