Just a note to say that I installed the Fedora KDE arm image on my RPi 3
from the link below using a Kingston class 10 SD card and it is running
extremely slow.
https://muug.ca/mirror/fedora/linux/releases/25/Spins/armhfp/images/Fedor...
After the second boot, I opened a console and did a 'dnf update'. With a
fast ethernet connection, it has taken nearly 12 hours to complete. It is
currently in the 'top' shows nothing CPU usage to be 2.3% for the top
process and nothing much for anthing else. The dnf process occasionally
pops up in the top list, using less than 1% of the cpu, though about 18% of
memory.
Is there a zombie thread running somewhere ?
I'll investigate further once the update process is complete.
BTW: kudos for bringing Fedora to the RPi platform. I'm so happy not to be
building custom kernels and to be running the same distribution I use on my
other computers. Keep up the good work !

On Mon, 27 Feb 2017 19:37:31 +0100, Peter Robinson <pbrobinson(a)gmail.com>
wrote:
>>>> = Proposed Self Contained Change: Arm Support In FMW =
>>>> https://fedoraproject.org/wiki/Changes/ArmSupportInFmw
>>>>
>>>> Change owner(s):
>>>> * Martin Bříza <mbriza AT redhat DOT com>
>>>>
>>>> Fedora Media Writer will gain the ability to write ARM images to SD
>>>> cards and other portable media.
>>>>
>>>>
>>>> == Detailed Description ==
>>>> With ARM (ARMv7A) being one of the primary architectures of Fedora, we
>>>> should support writing the images to bootable media for devices with
>>>> this architecture.
>>>>
>>>> This means Fedora Media Writer will have to list the ARM images, offer
>>>> their download and be able to unpack them reliably (as they're shipped
>>>> LZMA-compressed - .xz). Memory card support should be improved,
>>>> especially in terms of reading drive information - many SD card
>>>> drivers report wrong names, sizes and media presence.
>>>>
>>>> This will come along with many more features in FMW, such as
>>>> fullscreen screenshot preview, automatic FMW update check on Windows
>>>> and Mac, better reliability and performance improvements.
>>>>
>>>>
>>>>
>>>> == Scope ==
>>>> * Proposal owners:
>>>> Implementation of this Change
>>>>
>>>> * Other developers:
>>>> N/A (not a System Wide Change)
>>>>
>>>> * Release engineering:
>>>> N/A
>>>
>>>
>>>> * List of deliverables:
>>>> N/A (not a System Wide Change)
>>>
>>>
>>>> * Policies and guidelines:
>>>> N/A (not a System Wide Change)
>>>>
>>>> * Trademark approval:
>>>> N/A (not needed for this Change)
>>>
>>>
>>> So this is another case where the 'system-wide' / 'self-contained'
>>> split doesn't really work. This doesn't affect the functioning of
>>> anyone's existing installed system, but it clearly has implications for
>>> the wider project: if this becomes the 'official' delivery mechanism
>>> for ARM users, that'll require changes to the download pages. And while
>>> the Change page says " How To Test - N/A (not a System Wide Change)",
>>> clearly this *will* need testing, especially before we make it the
>>> primary delivery mechanism.
>>
>>
>> Yeah, you're right.
>> I'm intending this as a smaller change that will just make this
>> functionality available. However, I don't mean to push this as a
>> primary way
>> how to ship Fedora ARM images - there are some specifics that the tool
>> won't
>> handle before F26 (and maybe ever), like resizing the partitions after
>> writing it and maybe some hardware-specific cases.
>> Regarding the test cases, these will be necessary, yes. I'm going to add
>> them as an optional part of the FMW verification matrix.
>
> It would be nice if you also engaged with myself or the ARM SIG in
> general too from both an implementation details PoV and a QA.
>
> Peter
Resending this to the ARM list too.
From the implementation standpoint, this change is basically just about
listing Fedora ARMv7 images in the list of available Fedora variants and
also adding LZMA on-the-fly decompression for the raw images provided by
fedora download mirrors.
Please let me know if there are other features you'd like to have
implemented. Please also note FMW is a multiplatform tool so adding things
like partition layout changes on Windows (especially) and Mac would be a
pretty challenging task for now - these would probably have to resort to
be Linux-exclusive for some time.

My old Asus 900 got broken (I slipped on ice and it and its carry pouch
saved me from injury, but broke the screen). It was running F21 (never
got around to upgrading).
Got a 'new' Asus 900. Left mouse button does not work, but I will
switch mouse buttons later. I DID switch drives (and memory), and my
F21/Xfce system comes right back up. Except.
No Fn key, so no home or end or pgup or etc button.
lsmod|grep eee
shows eeepc_laptop
I hope it is not a bad key, but I can switch keyboards too if needed.
How do I fix this?
thanks

Hi,
So recently I tried armhfp of Rawhide-20170120.
Things did not go smooth. First I tried Workstation, but GNOME did not
show up. I thought it is simply because BeagleBone Black is not strong
enough so I tried LXDE instead. However still no lucky after a long wait
(more than 20 minutes).
During the LXDE image boot, I find a lot of
"alloc_contig_range: [94bfc, 94c00) PFNs busy"
I just updated uboot, so it should not be things related with uboot.
Is this a known bug? If needed I can file a bug to track this.
I uploaded part my boot log (on serial console) here
https://zsun.fedorapeople.org/pub/bugs/Fedora-LXDE-armhfp-Rawhide-2017012...
--
Ziqian SUN (Zamir)
zsun(a)fedoraproject.org
GPG : 1D86 6D4A 49CE 4BBD 72CF FCF5 D856 6E11 F2A0 525E
Want to know more about Fedora?
Visit https://fedoraproject.org/wiki/

Hello,
I'm running Fedora 25 arm on a RPi3. I'm mainly using this particular RPi for ham stuff. Previous versions of Fedora for RPi had the ax25.ko module available, but it appears to be missing from the 'modules-extra' kernel package in the official F25 arm build. The module IS available in the x86-64 build.
Is there a reason the ax25 module is not available in the arm build? Is there any chance it will be added soon?
...Jeff