>>>> On Wed, Apr 27, 2016 at 1:18 PM, Chanho Park <parkch98@gmail.com>
>>>> wrote:
>>>> > Hi all,
>>>> >
>>>> > I want to use the armhf fedora rootfs on the aarch64 bit kernel.
>>>>
>>>> You can't, it's not a use case we support.
>>>
>>>
>>>
>>> To further this piece, you would need to have code changes in rpm,
>>> dnf,
>>> yum,
>>> packagekit, mock and everything else dealing with rpm installation
>>> and
>>> removal. none of the tooling supports what you are asking.
>>
>>
>> That must be some very recent code. I can confirm that CentOS 7
>> armv7hl works just fine with just the /etc/rpm/platform configured
>> appropriately in the chroot on an aarch64 host (with a non-default
>> kernel built with 4KB pages). No dnf, granted, since that is more
>> recent than F19, but all the rest of it works just fine.
>
> Maybe that's something that CentOS have added (don't know, haven't
> looked), RHELSA doesn't support it that I'm aware of and they're
> definitely only 64K page size. The biggest change is in rpm and the
> arch mappings there.
They might not support it, but it most certainly works. There are no
changes specific to this that I can find in CentOS. All I changed was
rebuilt the host kernel with 4KB pages and ARM32 support (still an
aarch64 kernel). C7 armv7hl guest is completely unmodified apart from
the /etc/rpm/platform being set explicitly.
The main point being that the original assertion that making this
work would require rpm, yum, packagekit, mock and other code changes
doesn't seem to be correct based on empirical evidence.
>> So unless there has been a lot of bit rot since F19, it seems
>> unlikely any of the rest of it would need fixing.
>
> Maybe, early Fedora on aarch64 was 4K pages during bringup but it
> became clear early on that various orgs wanted 64K pages so the
> decision was made to move.
Despite Linus' words of wisdom to the contrary over the years. :-(
>>> Some aarch64 hardware will not run 32 bit binaries at all. when we
>>> started
>>> on
>>> the path of supporting aarch64 we mad a concious decision not to
>>> support
>>> running armhfp or arm 32 bit binaries on 64 bit environments. the
>>> supported
>>> way to run 32 bit binaries is to do so in a 32 bit vm.
>>
>>
>> Unless I am missing something, even ignoring the very non-trivial
>> performance hit of running in a VM, if the hardware doesn't support
>> the 32-bit instruction set, then the VMs won't work either, so I'm
>> not sure what the point being made here is.
>
> Yes, because the instructions can be dealt with by the hypervisor
> whether through emulation, or some other mechanism.
If it's going to run in emulation you might as well run it on
some highest end possible x86 hardware, it'll be slightly less
excruciatingly slow. And last I checked, that still had issues
with availability of kernels and architectures emulated.
Gordan
_______________________________________________
arm mailing list
arm@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/arm@lists.fedoraproject.org
No comments:
Post a Comment