>>> > I want to use the armhf fedora rootfs on the aarch64
>>> You can't, it's not a use case we support.
>> Why not? All arm binaries can be runnable on aarch32 mode of aarch64
> Not exactly actually, it's possible to have aarch64/ARMv8 CPUs that
> don't have the 32 bit components.
That this is not the case here, though. So the answer doesn't seem
to answer the question.
Actually it does answer the question. The question is about "32 bit
binaries on aarch64" and there are cases when they can't run.
>>> > The question is 'how can I run 'dnf'
command on armhf fedora with
>>> > aarch64 kernel?'
>>> No, the ARMv7 and aarch64 ABI aren't compatible, the only way we
>>> support ARMv7 on aarch64 is via virtualisation. We will not be
>>> supporting this or a "multilib" usecase.
>> The aarch64 kernel can execute both aarch64 and aarch32(fully compatible
>> armv7) binaries. For example, the kernel of raspberry pi 3 is aarch64 and
>> fedora arm version can't run on rpi3. Even all binaries can run on it but
>> only dnf command can't do that.
> Actually that isn't entirely true. The kernel that's currently shipped
> in raspbian for RPi3 is actually an ARMv7 kernel where the firmware
> boots the ARM cores as v7 cores. The kernel code that's running there
> is ARMv7 code not cortex-a53 code paths. That is a fairly special
> usecase and you can actually do that on Fedora ARMv7 with a Fedora
> ARMv7 kernel, not a aarch64 kernel.
Again, this doesn't answer the question and ignored the most obvious
and common case, where we have ARMv8 hardware (e.g. X-Gene) that fully
supports ARMv7 instruction set for backward compatibility, running an
aarch64 kernel with 4KB memory pages (the sensible size) and backward
compatibility option enabled (no detriment to doing so).
What about Seattle that explicitly needs a kernel with 64K pages?
You can then run an armv7hl (or armv5tel) userspace in a chroot with
no ill effects. I run a setup like this where I run hard-float and
soft-float 32-bit userspace docker containers even though the host
userspace and kernels are aarch64. I see no sane reason why this
would not be a supported configuration, since the usefulness of it
seems very obvious.
Sure, but we made a decision that our kernels would be 64K pages on
aarch64 some time ago. We need to make a decision that is not easy to
change to be compatible moving forward for a new architecture that is
evolving. Sure right at THIS VERY MOMENT the hardware that YOU'RE
using might support that configuration but there is HW that is
available right now that needs a configuration that you don't
currently have and there could well be HW soon (I don't know, and if I
did it's very likely I couldn't comment anyway) that doesn't have the
optional bits needed for aarch32.
So while it's easy to say "it works for me" sure, you can hack things
how ever you like and sit back from the edges commenting, we need to
make a decisions such as page sizes that we'll need to support for
years to come based on the information we have at the time. Other
distros have made similar decisions, others haven't, that's their
Either way if you need to build a custom kernel for a ARMv7 userspace
it's up to you and that use case is fine, it's your decision to make.
> ARM multilib is something we explicitly decided not to support
> were dealing with that. Multilib is a mess on x86, it's not a mess we
> need on ARM.
We aren't talking about multilib here, we are talking about
chroots/containers which are a very separate use case.
It might be a separate usecase but it doesn't make it less relevant
for reasons why we don't support the usecase.
But since you mentioned it, if we don't have multilib because
a mess, why is it that aarch64 Fedora still uses lib64 rather than
lib directories? I don't see how this is less of a mess than what
Because lib64 is a directory that all current 64 bit architectures
that Fedora supports uses. It's about consistency rather than