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
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
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 !
#fedora-meeting-2: Fedora ARM and AArch64 Status Meeting
Meeting started by pwhalen at 16:00:06 UTC. The full logs are available
* 1) ==== Userspace Status ==== (pwhalen, 16:05:26)
* Firefox fails to build on armhfp (pwhalen, 16:06:00)
* LINK: https://koji.fedoraproject.org/koji/taskinfo?taskID=18091430
* LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1426850
* This is causing Xfce images to fail. To be proposed as an Alpha
Blocker. (pwhalen, 16:07:06)
* capnproto FTBFS with GCC7, assistance would be appreciated.
* LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1423291
* 2) ==== Kernel Status ==== (pwhalen, 16:11:10)
* kernel-4.9.13-200.fc25 (pwhalen, 16:12:17)
* LINK: https://koji.fedoraproject.org/koji/buildinfo?buildID=862754
* Enable PWRSEQ_SIMPLE module - fixes bluetooth & wifi on some boards(
BZ#1377816 ) (pwhalen, 16:12:29)
* kernel-4.11.0-0.rc0.git5.1.fc26 (pwhalen, 16:12:54)
* LINK: https://koji.fedoraproject.org/koji/buildinfo?buildID=862775
* jlinton tracking a kernel crash on Juno with 4.11. (pwhalen,
* Please test and report any issues to the list or #fedora-arm.
* 3) ==== Bootloader Status ==== (pwhalen, 16:17:41)
* uboot-tools-2017.03-0.5.rc2.fc26 (pwhalen, 16:17:54)
* LINK: https://koji.fedoraproject.org/koji/buildinfo?buildID=859397
* Changelog: Rebase OpenSSL 1.1 patches (pwhalen, 16:18:06)
* Seeing issues when pxebooting on some(all?) hardware- data abort and
reset. No BZ yet. (pwhalen, 16:19:17)
* 4) ==== Rawhide Testing ==== (pwhalen, 16:22:28)
* Testing so far(armhfp):
* Testing so far(aarch64):
* Current Bugs: (pwhalen, 16:22:57)
* selinux prevents kernel modules from loading ( BZ#1422634 ).
* Accepted Alpha Blocker. This also happened in F25, and is now fixed.
The fixed selinux-policy build failed for F26. New build expected
today. (pwhalen, 16:24:18)
* AArch64 systems fail to display the grub menu when PXE booted and
instead drop to a grub prompt (BZ#1405208) (pwhalen, 16:27:30)
* Fixed : All ARM disk image composes fail in Rawhide ( BZ#1420520 )
* Possible issue with standard partitioning on aarch64. Please test
and report issues to the mailing list/bugzilla. (pwhalen, 16:29:52)
* LINK: Full list of blockers: (pwhalen, 16:30:17)
* 5) == Open Floor == (pwhalen, 16:32:31)
Meeting ended at 16:35:10 UTC.
Action Items, by person
People Present (lines said)
* pwhalen (55)
* jlinton (11)
* zodbot (4)
* marc84 (1)
* yselkowitz (0)
* dmarlin (0)
* ahs3 (0)
* hrw (0)
* msalter (0)
* pbrobinson (0)
* jonmasters (0)
* dgilmore (0)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
On Mon, 27 Feb 2017 19:37:31 +0100, Peter Robinson <pbrobinson(a)gmail.com>
>>>> = Proposed Self Contained Change: Arm Support In FMW =
>>>> 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:
>>>> * 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
>> 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.
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.
I hope it is not a bad key, but I can switch keyboards too if needed.
How do I fix this?
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
Ziqian SUN (Zamir)
GPG : 1D86 6D4A 49CE 4BBD 72CF FCF5 D856 6E11 F2A0 525E
Want to know more about Fedora?
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?