This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 719609

Summary: [RFE] Architecture `armv7l-redhat-linux' is not supported
Product: [Community] Spacewalk Reporter: Jiri Kastner <jkastner>
Component: ServerAssignee: Miroslav Suchý <msuchy>
Status: CLOSED CURRENTRELEASE QA Contact: Red Hat Satellite QA List <satellite-qa-list>
Severity: medium Docs Contact:
Priority: medium    
Version: 1.5CC: cperry, dennis, jyundt, msuchy, ndevos
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: spacewalk-schema-1.8.29-1 Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-11-01 12:17:15 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 245418, 737830, 871344    
Attachments:
Description Flags
something like what arm should look like none

Description Jiri Kastner 2011-07-07 09:14:00 EDT
Description of problem:
armv7l machines are not supported by spacewalk. generally, there is no way to create arm channels.

Version-Release number of selected component (if applicable):


How reproducible:
always with armv7l kernel 

Steps to Reproduce:
1. get some armv7 capable device and install there fedora armv5tel
2. run rhnreg_ks against spacewalk
3. check results
  
Actual results:

[root@dhcp-27-216 rhn]# rhnreg_ks --serverUrl=https://hp-dl360g7-01.lab.eng.brq.redhat.com/XMLRPC --sslCACert=/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT.hp-dl360g7-01.lab --activationkey=1-843fdd5b193d8219f59e962ff043831c
D: Warnings collected during dmidecode import: /dev/mem (mmap): Operation not permitted
No SMBIOS nor DMI entry point found, sorry.

D: rpcServer: Calling XMLRPC registration.welcome_message
D: opening  db environment /var/lib/rpm cdb:mpool:joinenv
D: opening  db index       /var/lib/rpm/Packages rdonly mode=0x0
D: locked   db index       /var/lib/rpm/Packages
D: loading keyring from pubkeys in /var/lib/rpm/pubkeys/*.key
D: couldn't find any keys in /var/lib/rpm/pubkeys/*.key
D: loading keyring from rpmdb
D: opening  db index       /var/lib/rpm/Name rdonly mode=0x0
D: added key gpg-pubkey-97a1071f-4c49d6fe to keyring
D: Using legacy gpg-pubkey(s) from rpmdb
D: opening  db index       /var/lib/rpm/Providename rdonly mode=0x0
D: rpcServer: Calling XMLRPC registration.new_system

Error Message:
    Architecture `armv7l-redhat-linux' is not supported
Error Class Code: 24
Error Class Info: Unsupported server architecture.
Explanation: 
     An error has occurred while processing your request. If this problem
     persists please enter a bug report at bugzilla.redhat.com.
     If you choose to submit the bug report, please be sure to include
     details of what you were trying to do when this error occurred and
     details on how to reproduce this problem.

D: closed   db index       /var/lib/rpm/Providename
D: closed   db index       /var/lib/rpm/Name
D: closed   db index       /var/lib/rpm/Packages
D: closed   db environment /var/lib/rpm


Expected results:
machine registered

Additional info:
Comment 1 Jan Pazdziora 2011-07-20 07:48:18 EDT
Aligning under space16.
Comment 2 Clifford Perry 2011-08-05 11:18:51 EDT
Patches accepted. In general adding a new arch requires schema entries plus app code changes. Global grep for things like IA64 or x86_64, understanding what is going on there and add new arch as needed. 

Cliff
Comment 3 Clifford Perry 2012-04-10 11:44:03 EDT
I'd love to know what Fedora's roadmap is for making this an officially supported arch. I hope (unlike Sparc) it moves quickly into mainstream (even if for a subset of core packages). 

Do we have standardized strings for RPM arch and others we can use, since we do hard code stuff (in schema db entries).

Cliff
Comment 4 Jiri Kastner 2012-04-11 03:45:23 EDT
http://fedoraproject.org/wiki/Features/FedoraARM

http://lists.fedoraproject.org/pipermail/arm/2012-March/thread.html#2945



[e-ndy@ac100 ~]$ rpm --showrc | grep arm
build arch            : armv5tel
compatible build archs: armv7l armv6l armv5tejl armv5tel armv4tl armv4l armv3l noarch
install arch          : armv7l
compatible archs      : armv7l armv6l armv5tejl armv5tel armv4tl armv4l armv3l noarch
optflags              : %{__global_cflags} -march=armv7-a -mfloat-abi=soft
        gpg --batch --no-verbose --no-armor --passphrase-fd 3 
-14: __isa_name armv7l
-14: _arch      arm
-14: _build_arch        arm
-14: _host      armv7l-unknown-linux-gnueabi
-14: _host_cpu  armv7l
-11: _target    armv5tel-linux
-11= _target_cpu        armv5tel
-14: arm        armv3l armv4b armv4l armv4tl armv5tel armv5tejl armv6l armv7l armv7hl armv7hnl
-14: ghc_arches %{ix86} x86_64 ppc ppc64 alpha sparcv9 armv7hl armv5tel s390 s390x
-14: mono_arches        %{ix86} x86_64 sparc sparcv9 ia64 %{arm} alpha s390x ppc ppc64
-14: ocaml_arches       alpha %{arm} %{ix86} ia64 x86_64 ppc  sparc sparcv9 ppc64
-11: optflags   %{__global_cflags} -march=armv5te -mfloat-abi=soft
Comment 5 Niels de Vos 2012-04-11 05:24:24 EDT
Currently Fedora ARM is building packages for armv5tel and armv7hl. These are the two architectures as RPM knows them that will be supported by Fedora ARM.

Example packages of glibc on Fedora ARM:
- http://arm.koji.fedoraproject.org/packages/glibc/2.15/28.fc17/

The kernel may identify itself (uname) as armv7l, but this is not the architecture of the OS installation. The command "rpm -E '%{_target_cpu}'" can be used to check the architecture of the OS itself, and should return either 'armv5tel' or 'armv7hl'.

There are hopes to make ARM a Primary Architecture (this is likely what you mean by 'officially supported') with Fedora 18, if that does not work out, any subsequent release will be the new target. The feature page given in comment #4 (http://fedoraproject.org/wiki/Features/FedoraARM) contains the most up-to-date information for the FESCo to (dis)approve the promotion of ARM to Primary Architecture.
Comment 6 Miroslav Suchý 2012-04-11 05:36:49 EDT
You can find inspiration how to add new arch in Spacewalk in recent work of adding support for Debian. See commits:
473b5d6ab2220389d71bc9fb7910d1eb0cc72373
a52b4e5c4d7ff57b7890319f16982181b99e7b30
Comment 7 Miroslav Suchý 2012-04-27 06:39:52 EDT
Commited as:
* 586b29c (HEAD, tag: spacewalk-schema-1.8.23-1, origin/master, origin/HEAD, master) Automatic commit of package [spacewalk-sche
* 7e5f181 719609 - add support for armv5 channels
* fbb584e 719609 - Add support for armv7l cpu and armv7 channels
Comment 8 Miroslav Suchý 2012-04-30 10:55:07 EDT
commited to spacewalk.git:
* 3e2afef (HEAD, tag: spacewalk-schema-1.8.26-1, origin/master, origin/HEAD, master) Automatic commit of package [spacewalk-sche
* f60aea5 719609 - make arm channels compatible with noarch packages
Comment 9 Dennis Gilmore 2012-05-02 09:58:04 EDT
The base arches in yum are arm for software floating point and armhfp for hardware floating point. Each base arch has multiple sub arches. The channels likely should not be called armv5 or armv7 though I have not looked at the patches yet to see what exactly has been done.
Comment 10 Miroslav Suchý 2012-05-02 11:33:33 EDT
Another commit:
* 3c9a0c0 719609 - add support for armv7hnl package arch

To Dennis:
right now we have channels ARMv5 and ARMv7

ARMv5: can have package arches armv5tel and noarch
ARMv7: can have package arches armv7hnl, armv7hl, armv7l, armv5tel and noarch.

And only machine with arch armv7l can connect right now to Spacewalk.
I'm sure there is more, but I do not have hardware to test it. :(
Comment 11 Dennis Gilmore 2012-05-02 23:32:28 EDT
Miroslav, 

I have hardware of different types i can test on. 

what you are calling ARMv5  is the basearch of arm in yum. compatible arches for it are armv5tel armv6l armv7l  and noarch.  the rpms are all compiled using software floating point.  you can install any of those arches and only those arches.  depending on the hardware you could only get a subset of the arches available,  its like i386 i486 i586 i686 in the x86 world

what you are calling ARMv7 is the basearch of armhfp in yum. compatible arches for it are armv7hl armv7hnl and noarch.  the packages are compiled for hardware floating point and they are not compatible with software floating point compiled packages.  

uname -m on all hfp systems is armv7l  its also the same on systems running sfp that have a v7 cpu v5 and v6 cpus will only ever run software floating point. 

a armv7 client needs to decide if it should use arm or armhfp based on what is installed
Comment 12 Dennis Gilmore 2012-05-02 23:35:51 EDT
Created attachment 581767 [details]
something like what arm should look like

i think the arm schema should be something like i have attached
Comment 13 Miroslav Suchý 2012-05-03 05:23:12 EDT
Dennis,
I investigated the situation even more (grrr, documentation sucks, no hardware to test it :( ) and I agree that main difference is floating point (FP). But I disagree with compatibility of CPU arch ARMv5 and package arch armv6l. Simply because if package is compiled for armv6l it may contain Thumb-2 instruction, which are not present in ARMv5 CPU.

So I think the structure should be as follows:
ARMv5: can have package arches armv5tel and noarch
ARMv7 soft FP: can have package arches armv7l, armv5tel and noarch.
ARMv7 hard FP: can have package arches armv7hnl, armv7hl, armv7l, armv5tel and noarch.
Comment 14 Dennis Gilmore 2012-05-03 09:02:13 EDT
yum and rpm will not install a armv6l or armv7l rpm on a armv5 machine. you can have armv5tel armv6l and armv7l packages in the same repo.  say something like pixman you would build for all 3 so that you get optimised version for your particular hardware. 

however there is no point putting armv7l, armv6l or armv5tel rpms into a hardware floating point repo since yum will rightly refuse to even look at and consider them for instalation. they are not compatiable.  hard and soft float are not multilibed and and not compatiable it is a one or the other use case. 

arm: can have armv7l armv6l armv5tel noarch
armhfp: can have armv7hnl armv7hl noarch

thats it. thats exactly how we make the repos in fedora.
Comment 15 Dennis Gilmore 2012-05-03 09:03:18 EDT
while a v7 cpu in theory can run hardware or software floating point. in practice its not possible and not supported. its a one or the other situation.
Comment 16 Peter Robinson 2012-05-03 09:05:02 EDT
> So I think the structure should be as follows:
> ARMv5: can have package arches armv5tel and noarch
> ARMv7 soft FP: can have package arches armv7l, armv5tel and noarch.
> ARMv7 hard FP: can have package arches armv7hnl, armv7hl, armv7l, armv5tel and
> noarch.

You can not run a mixed hardfp and softfp userspace so binaries compiled for softfp should no be run in a hardfp userspace even though it's running on the same underlying processor. It's almost impossible to detect this at runtime so there is an artificial restriction programmed both in rpm and yum to ensure it's not possible. Welcome to the joys of ARM arch!

You also miss armv6 (which we don't specifically target in Fedora but it's possible to build them). So you're above should be:

ARMv5: can have package arches armv5tel and noarch
ARMv6: can have package arches armv5tel, armv6 and noarch
ARMv7 soft FP: can have package arches armv7l, armv6, armv5tel and noarch.
ARMv7 hard FP: can have package arches armv7hnl, armv7hl, and noarch.

The inheritance is documented as it should be in the redhat-rpm-config package.
Comment 17 Jiri Kastner 2012-05-16 05:53:13 EDT
[root@virt-arm1 rhn]# uname -a
Linux virt-arm1 3.0.8 #16 Wed Mar 28 15:07:56 CEST 2012 armv5tejl armv5tejl armv5tejl GNU/Linux

[root@virt-arm1 rhn]# rhnreg_ks -vvvv --activationkey=1-f17-sfp --profilename=virt-arm
D: rpcServer: Calling XMLRPC registration.welcome_message
D: opening  db environment /var/lib/rpm cdb:0x401
D: opening  db index       /var/lib/rpm/Packages 0x400 mode=0x0
D: locked   db index       /var/lib/rpm/Packages
D: loading keyring from pubkeys in /var/lib/rpm/pubkeys/*.key
D: couldn't find any keys in /var/lib/rpm/pubkeys/*.key
D: loading keyring from rpmdb
D: opening  db index       /var/lib/rpm/Name 0x400 mode=0x0
Error reading networking information: <class 'socket.error'>
D: opening  db index       /var/lib/rpm/Providename 0x400 mode=0x0
D: rpcServer: Calling XMLRPC registration.new_system
Error communicating with server. The message was:

Error Message:
    Architecture `armv5tejl-redhat-linux' is not supported
Error Class Code: 24
Error Class Info: Unsupported server architecture.
Explanation: 
     An error has occurred while processing your request. If this problem
     persists please enter a bug report at bugzilla.redhat.com.
     If you choose to submit the bug report, please be sure to include
     details of what you were trying to do when this error occurred and
     details on how to reproduce this problem.

D: closed   db index       /var/lib/rpm/Providename
D: closed   db index       /var/lib/rpm/Name
D: closed   db index       /var/lib/rpm/Packages
D: closed   db environment /var/lib/rpm
Comment 18 Miroslav Suchý 2012-05-22 08:32:37 EDT
changed according #14 and added arm5tejl according #17

* 3a2effb (HEAD, tag: spacewalk-schema-1.8.35-1, origin/master, origin/HEAD, master) Automatic commit of package [spacewalk-s
* 4b620e3 719609 - set priorities between server and package arch
* 2b18806 719609 - allow upgrade from arm to noarch and vice versa
* 1aa128d 719609 - add support for server arch armv5tejl
* 793c737 719609 - for arm create channel-armhfp and channel-arm
Comment 19 Jan Pazdziora 2012-10-30 15:22:22 EDT
Moving ON_QA. Packages that address this bugzilla should now be available in yum repos at http://yum.spacewalkproject.org/nightly/
Comment 20 Jan Pazdziora 2012-11-01 12:17:15 EDT
Spacewalk 1.8 has been released: https://fedorahosted.org/spacewalk/wiki/ReleaseNotes18