Arm-dev October 2018

arm-dev@lists.centos.org

13 participants
30 discussions

rng-tools missing and /dev/hwrng without driver
by SW＠EU 31 Oct '25

31 Oct '25

Hi, today I will report a problem that is released to ipa-server. This server contains a certificate authority and such service need many entropy. The default on CentOS 7 on a Banana PI is not enough, i.e. $(cat /proc/sys/kernel/random/entropy_avail) is less than 1000. I have solved this in meantime by installing and enabling of haveged from the EPEL repository. Normally it would be done by installing the rng-tools. But there are two problems: 1. The rng-tools was not in the repositories, so I have downloaded rng-tools-5-8.fc24.armv7hl.rpm because this are the same version which is included in CentOS 7.3 for x86_64. 2. This rng-tools are usable but the daemon starts and stops immediately with the following error message: # rngd -v /dev/hwrng: No such device /dev/tpm0: No such file or directory No entropy sources found, exiting This is not the problem of this binary it is a problem of the Kernel. /dev/hwrng exists and if I remove it then it reappears after reboot, but # ls -l /dev/hwrng crw-------. 1 root root 10, 183 1. Jan 1970 /dev/hwrng # udevadm info -a -n /dev/hwrng Udevadm info starts with the device specified by the devpath and then walks up the chain of parent devices. It prints for every device found, all possible attributes in the udev rules key format. A rule to match, can be composed by the attributes of the device and the attributes from one single parent device. looking at device '/devices/virtual/misc/hw_random': KERNEL=="hw_random" SUBSYSTEM=="misc" DRIVER=="" ATTR{rng_current}=="none" ATTR{rng_available}=="" there is no driver for this device. I have searched and found this link http://forum.lemaker.org/thread-23618-1-1.html which includes a link to the full story. If I read all right then on bananian /dev/hwrng appears only if the adapted or a more actual sun4i-ss.ko module is loaded (there is written: "module author has indicated this will be going into the mainline kernel shortly“). This module is also loaded on a Banana PI with current CentOS 7. So does the kernel of CentOS 7.3 for ARM32 include this patch and if yes why it does not work or otherwise why this device appears but has no driver? TIA, Silvio Sent with [ProtonMail](https://protonmail.com) Secure Email.

4 5

EPEL repo not available?
by Boyd Ako 31 Oct '25

31 Oct '25

Can anybody verify that the EPEL repo for ARMHFP isn’t available? I keep getting an error saying the REPOMD file isn’t there when running yum. It works if I use —disablerepo=epel\* when using yum. But, there might be some stuff in the EPEL that I’m looking for. Running it on a Raspberry Pi 3 and trying to get Nagios installed for home use. Domo, Boyd H. Ako boyd.hanalei.ako(a)gmail.com (424) 244-9653 https://www.boydhanaleiako.me “Coming together is a beginning. Keeping together is progress. Working together is success.” -Henry Ford PGP/GPG Public Key: https://sks-keyservers.net/pks/lookup?op=get&search=0xC58073B21618F134

5 4

Gigabyte MP30-AR0
by Gordan Bobic 31 Oct '25

31 Oct '25

Hi, I am toying with the idea of getting a Gigabyte MP30-AR0 board (despite the insanely exorbitant price tag). Has anyone got the aarch64 CentOS working on one of those? Any special instructions? Also, if I get the ISO, is it bootable on aarch64? Does the installer work? Or does the image have to be used like on 32-bit ARM? Thanks. Gordan

18 208

epel-release
by Robert Moskowitz 30 Jun '20

30 Jun '20

Ok, I see this epel-release in the epel1 repo that I installed via the wiki. So I decide to install it, and it created an epel.repo.rpmnew file. I swicth around the files and try a 'yum update' and get: epel/armhfp/metalink | 47 kB 00:00 Could not parse metalink https://mirrors.fedoraproject.org/metalink?repo=epel-7&arch=armhfp error was No repomd file One of the configured repositories failed (Unknown), and yum doesn't have enough cached data to continue. At this point the only safe thing yum can do is fail. There are a few ways to work "fix" this: .... File /var/cache/yum/armhfp/7/epel/metalink.xml does not exist So I put everything back.

3 7

Re: [Arm-dev] Add Marvell Armada7k8k NIC (mvpp2) support patches
by Marcin Wojtas 26 May '20

26 May '20

Hi Jim, It's been a while, since I sent the patch. Any objections about merging? Is v4.11 kernel still a valid baseline or for the next releases or we should use v4.14? When is that transition and next release supposed to happen? Best regards, Marcinsob., 23 cze 2018 o 08:18 Marcin Wojtas <mw(a)semihalf.com> napisał(a): > > Hi, > > I'm sending a patch that is applicable on top of the kernel > sig-altarch7-aarch64 branch. It enables ACPI support for the Marvell > Armada7k8k NIC - this required backporting very big amount of patches > (all merged upstream), hence I decided to attach the single commit, > instead of issueing 'git send-email' of it. > > Despite many attempts I wasn't able to build entire rpm package with > the mock build utility, however I managed to test the clean kernel > v4.11 with applied all patches and built with updated .config. Please > let know if this patch is sufficient and can be merged. > > Thanks, > Marcin

5 21

Different issues with "DTOVERLAY".
by Stephan Guilloux 26 Feb '19

26 Feb '19

Hello, Small issues, today, with dtoverlay gpio-shutdown/poweroff [root@mypi ~]# dtoverlay gpio-shutdown su: user pi does not exist * Failed to apply overlay '1_gpio-shutdown' (kernel) su: user pi does not exist [root@mypi ~]# dtoverlay gpio-poweroff su: user pi does not exist su: user pi does not exist [root@mypi ~]# Even if I add a fake user "PI", this does not work better. [root@mypi ~]# useradd -r pi -p pi [root@mypi ~]# [root@mypi ~]# [root@mypi ~]# dtoverlay gpio-poweroff * Failed to apply overlay '2_gpio-poweroff' (kernel) [root@mypi ~]# dtoverlay gpio-shutdown * Failed to apply overlay '2_gpio-shutdown' (kernel) [root@mypi ~]# But when I check the overlay list, I get: [root@mypi ~]# dtoverlay -l Overlays (in load order): 0: gpio-shutdown 1: gpio-poweroff [root@mypi ~]# At least, something is done :-) Last problems: [root@mypi ~]# dtoverlay -h gpio-shutdown * Help file not found [root@mypi ~]# dtoverlay -h gpio-poweroff * Help file not found [root@mypi ~]# dtoverlay -h rpi-rtc * Help file not found [root@mypi ~]# dtoverlay -h rpi-display * Help file not found [root@mypi ~]# In case ... [root@mypi ~]# cat /proc/version Linux version 4.14.65-v7.1.el7 (mockbuild(a)armhfp-03.bsys.centos.org) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-28) (GCC)) #1 SMP Mon Aug 20 19:04:20 UTC 2018 [root@mypi ~]# [root@mypi ~]# rpm -qa 'raspberrypi-vc*' raspberrypi-vc-demo-source-20170705-502.gitaa39775.el7.noarch raspberrypi-vc-libs-20170705-502.gitaa39775.el7.armv7hl raspberrypi-vc-utils-20170705-502.gitaa39775.el7.armv7hl [root@mypi ~]# Stephan.

2 3

MacchiatoBin support int the Centos7
by Marcin Wojtas 30 Oct '18

30 Oct '18

Hi Jim, Since the newest Centos7 works out-of-the box with the latest MacchiatoBin firmware and also the integrated NICs are supported (beggining from kernel-alt-4.14.0-49.13.1.el7a), can you please shift MacchiatoBin to 'Supported Hardware' section in https://wiki.centos.org/SpecialInterestGroup/AltArch/AArch64 ? Thanks, Marcin

3 3

Enterprise distros and the two faces of 'reliability'
by Fred Gleason 28 Oct '18

28 Oct '18

Howdy Folks: Our discussion of the distinctive elements of CentOS’s Aarch64 variant has gotten me pondering. What does an ‘enterprise’ distro bring to the table that makes it desirable over the alternatives available? (By ‘enterprise distro’, I here mean the stream of data originated by the Upstream Provider, as well as those modified and distributed by all the various downstream projects, including CentOS). To my mind, I see two basic categories that are relevant here: 1) ‘Enterprise’ features, by which I mean things like: supports ‘big iron’ systems, supports fault tolerance and scalability, interoperates well with all of the common ‘non-native’ protocols and features found in a typical large computing environment. 2) ‘Stability’ features, by which I mean: has a well-defined infrastructure for distributing code fixes and security updates, has a long support lifetime, manages the ABI carefully so as to ensure that system updates can be applied with good confidence that they will not break existing locally-installed applications. These two categories are largely orthogonal. I say ‘largely’ because there is a hidden implicit commonality: reliability. Yet the presence of one need not necessarily imply the presence (or even desirability) of the other. For example, a project that uses an ‘embedded’ board (BeagleBoard, etc) to make small, autonomous ‘widget’ type devices really does not care about about the presence of 1), while 2) can be a highly desirable attribute. Category 1) is essentially an *operational* attribute, desirable in certain use cases but superfluous (or even counterproductive) in others, while category 2) addresses *maintenance* issues, critical for long-term service and support of a system but largely irrelevant to the typical day-to-day operation of applications. All of this to pose the question: is an ‘enterprise’ distro (in the specific sense meant here) an appropriate long-term choice for an ‘embedded’ project? Given the stated intention of the Upstream Provider to support only ARM systems that integrate APCI and comply with SBSA [Server Base System Architecture] standards in future major releases (see https://lists.centos.org/pipermail/arm-dev/2017-October/003120.html) is such a distro an appropriate long-term choice for an ‘embedded’ project? Cheers! |----------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |----------------------------------------------------------------------| | A good plan today is better than a perfect plan tomorrow. | | -- General George Patton | |----------------------------------------------------------------------|

6 10

Hardware Giveaway
by Gordan Bobic 27 Oct '18

27 Oct '18

I've been meaning to get back to some of my ARM hardware, but inbetween all the work commitments it doesn't look like that's feasible before these ARMs will only be good for the landfill. So, if anyone here is interested, here is what is up for grabs, for free: - Toshiba AC-100 x3 (at least one is in it's original box) - Genesi Efika MX Smartbook (in original box) - Compulab SB-A510+CM-A510 (yup, in original box) - Compulab TrimSlice (you guessed it - in original box) All have been used, but are in condition ranging from excellent to mint. If anyone wants any of these for a purpose better than it gathering dust in their cupboard rather than mine, email me off list with a shipping label for posting from mainland UK, and I'll post it to you. Best regards. Gordan

1 1

hikey 960?
by Skorpeo Skorpeo 26 Oct '18

26 Oct '18

Has anyone been able to install centos using iso on a Hikey 960? The wiki says "The Hikey from 96boards mostly works, but setup is complex. The installer currently cannot be used as one would traditionally expect." Any guides out there on how to get it to work? I am only able to get it to the initial installation menu but no further, I tried playing with various kernel parameters but to no avail. Any guidance or suggestions would be appreciated!

4 7

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Arm-dev October 2018