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:
Aligning under space16.
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
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
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
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.
You can find inspiration how to add new arch in Spacewalk in recent work of adding support for Debian. See commits: 473b5d6ab2220389d71bc9fb7910d1eb0cc72373 a52b4e5c4d7ff57b7890319f16982181b99e7b30
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
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
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.
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. :(
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
Created attachment 581767 [details] something like what arm should look like i think the arm schema should be something like i have attached
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.
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.
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.
> 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.
[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
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
Moving ON_QA. Packages that address this bugzilla should now be available in yum repos at http://yum.spacewalkproject.org/nightly/
Spacewalk 1.8 has been released: https://fedorahosted.org/spacewalk/wiki/ReleaseNotes18