arm February 2020

arm@lists.fedoraproject.org

17 participants
19 discussions

=?utf-8?q?=5Bfedora-arm=5D?=(resend) Trying to run Fedora-Minimal-31 under QEMU on Fedora 29
by Derek Atkins 11 Feb '20

11 Feb '20

(sorry if you get this twice -- I wasn't subscribed with this address so I think my message was held for moderation or just blocked) Hi, I've got an x86_64 F29 desktop and I'm trying to run Fedora-Minimal-31 ARM on QEMU. I was following the instructions in the various F25/26/27 "run on QEMU" pages and I've been able to get the system to boot under virt-manager, but once it gets to "Reached Basic System" in the virt-manager console, it stops and never reaches the first-boot setting. I never get asked to set a password. I never get a login screen. I just found a reference to an older web page about QEMU and ARM: https://fedoraproject.org/wiki/Architectures/ARM/HowToQemu but this page was last touched in 2016. Any assistance would be grand. Thanks! -derek -- Derek Atkins 617-623-3745 derek(a)ihtfp.com www.ihtfp.com Computer and Internet Security Consultant

3 6

Fwd: Building Fedora images for the RPi 3B+
by Elliot Alderson 10 Feb '20

10 Feb '20

Hi, I've been trying to build some custom aarch64 Fedora30 images. I tried using imagefactory, but I ran into problems with that since I am virtualizing my build server and there no support yet for aarch64 nested virtualization. I am now trying to use livemedia-creator with the --no-virt option and getting the following error while beginning the installation: 2020-02-10 18:24:17,327: 1) [x] Language settings 2) [x] Time settings 2020-02-10 18:24:17,328: (English (United States)) (America/New_York timezone) 2020-02-10 18:24:17,329: 3) [x] Installation source 4)[x] Software selection 2020-02-10 18:24:17,329: (https://mirrors.fedoraproject.o (Custom software selected) 2020-02-10 18:24:17,330: rg/mirrorlist?repo=rawhide&arch= 2020-02-10 18:24:17,330: $basearch) 2020-02-10 18:24:17,331: 5) [!] Installation Destination 2020-02-10 18:24:17,331: (Kickstart insufficient) The kickstart I am using is almost exactly the result from using ksflatten on fedora-arm-minimal.ks from https://pagure.io/fedora-kickstarts. I have just added a user account, root password, and activated the network. I am using the following command to attempt to create the image: livemedia-creator --make-disk --ks $1 --image-only --no-virt --resultdir /home/rpi/build/image --releasever 30 --image-name Fedora30BuildTEST Any advice on fixing this issue? Or maybe this is not the approach I should be using? Thank you, Elliot

1 0

[Fedocal] Reminder meeting : Fedora ARM & AArch64 status meeting
by pwhalen＠redhat.com 09 Feb '20

09 Feb '20

Dear all, You are kindly invited to the meeting: Fedora ARM & AArch64 status meeting on 2020-02-11 from 15:00:00 to 16:00:00 UTC At fedora-meeting-2(a)irc.freenode.net The meeting will be about: Fedora ARM & AArch64 weekly status meeting. More information available at: [https://fedoraproject.org/wiki/Architectures/ARM](https://fedoraproject.org… Source: https://apps.fedoraproject.org/calendar/meeting/9431/

1 0

Question: u-boot 2020.04 on RPi4
by Steven A. Falco 06 Feb '20

06 Feb '20

I noticed that there was a new u-boot image for the RPi4: uboot-images-armv8-2020.04-0.2.rc1.fc32.noarch.rpm so I gave it a try. With that u-boot image, once Linux booted, ethernet was not functional. It appeared to come up, but it couldn't do dhcp to get an address. I tried applying an address manually, but that didn't work either. I reverted to the uboot-images-armv8-2020.01-1.fc32.noarch.rpm version and ethernet worked properly. I then tried rebuilding u-boot 2020.04-0.2.rc1 from source, but without the "Ethernet-support-for-Raspberry-Pi-4.patch" file and ethernet worked. Has anyone else observed this behavior? Steve

1 0

Re: Proposal to change ARM Release Blocking Criteria - Drop XFCE (32bit), Add Workstation(64bit)
by Kamil Paral 05 Feb '20

05 Feb '20

On Tue, Feb 4, 2020 at 7:26 PM Ben Cotton <bcotton(a)redhat.com> wrote: > On Mon, Feb 3, 2020 at 4:22 PM Paul Whalen <pwhalen(a)redhat.com> wrote: > > > > Proposed changes to the Desktop release criteria for ARM and AArch64 in > Fedora 32: > > * drop Xfce on 32-bit ARM from release blocking desktops > > * add Workstation on AArch64 to release blocking desktops > > > Program Management is okay with this proposal, but ideally I'd like to > see it go through the self-contained change process. Any chance you'd > be okay with holding this until F33? In either case, FESCo will need > to approve it, but it has my support. > Because there's no development to do, it's just a change in the blocking deliverables list, I think we can do it right away. Peter, Paul, can you please file a FESCo ticket?

2 1

Re: Proposal to change ARM Release Blocking Criteria - Drop XFCE (32bit), Add Workstation(64bit)
by Peter Robinson 05 Feb '20

05 Feb '20

> > Proposed changes to the Desktop release criteria for ARM and AArch64 in Fedora 32: > > * drop Xfce on 32-bit ARM from release blocking desktops > > * add Workstation on AArch64 to release blocking desktops > > > Program Management is okay with this proposal, but ideally I'd like to > see it go through the self-contained change process. Any chance you'd > be okay with holding this until F33? In either case, FESCo will need > to approve it, but it has my support. If QA is fine to continue to do all the QA on the current bits sure, in terms of engineering etc the feature is complete (and actually was going back a number of releases), this is really just a QA/process change. Personally I'd like to get it done now and move on with life but it's mostly not going to affect me much either way so ¯\_(ツ)_/¯

2 1

Proposal to change ARM Release Blocking Criteria - Drop XFCE (32bit), Add Workstation(64bit)
by Paul Whalen 04 Feb '20

04 Feb '20

As discussed in the Fedora QA meeting today, below are the proposed changes to release blocking desktops on ARM. == Summary == Proposed changes to the Desktop release criteria for ARM and AArch64 in Fedora 32: * drop Xfce on 32-bit ARM from release blocking desktops * add Workstation on AArch64 to release blocking desktops == Detailed Description == In Fedora 32 we will have a couple new additions to release blocking deliverables including IoT and CoreOS. In order to reduce the overall test coverage and release blocking desktops we propose no longer blocking on the 32-Bit ARM Xfce Desktop spin, and adding Workstation on AArch64 as a release blocking desktop. Release blocking image changes: Drop: Spins/armhfp/images/Fedora-Xfce-armhfp-_RELEASE_MILESTONE_-sda.raw.xz Add: Workstation/aarch64/images/Fedora-Workstation-aarch64-_RELEASE_MILESTONE_-sda.raw.xz Testing will still be completed on the 32-Bit ARM Xfce spin to ensure it continues to work, but any issues found will not block the overall release. For a full list of the current release blocking deliverables, visit the wiki[1]. If you have any questions or concerns, please respond for further discussion. Regards, Paul [1] - https://fedoraproject.org/wiki/Releases/32/ReleaseBlocking

3 2

networking in fedora on Odroid XU4
by Michael Whapples 04 Feb '20

04 Feb '20

I have installed fedora 31 on my Odroid XU4 following instructions at https://blog.pcfe.net/hugo/posts/2019-01-27-fedora-29-on-odroid-hc2/. Mostly it seems to work, at least for what I want (IE. as a headless server). There is one problem which I am having. The built in network controller works most of the time. However I have found if I do a reboot using shutdown -r now then the network card is not found by linux (eg. output of lsusb does not show it and it is not in output from ifconfig). If I should shutdown using shutdown -h now and then power on by using the power button, the network controller is detected and networking works normally. Some google searches suggest that people with the same model of realtek network card, but in an external form, have had problems with their network card because of power management features in Linux. If I check /sys/bus/usb/devices/6-1/power/control then the value is "on" which I believe means no power management/suspend. So seems like this may not be the issue. Does anyone have any suggestions on what may be wrong? Might this be a kernel bug and if so where would be best to report it? Thanks in advance for any help. Michael

2 2

[Fedocal] Reminder meeting : Fedora ARM & AArch64 status meeting
by pwhalen＠redhat.com 02 Feb '20

02 Feb '20

Dear all, You are kindly invited to the meeting: Fedora ARM & AArch64 status meeting on 2020-02-04 from 15:00:00 to 16:00:00 UTC At fedora-meeting-2(a)irc.freenode.net The meeting will be about: Fedora ARM & AArch64 weekly status meeting. More information available at: [https://fedoraproject.org/wiki/Architectures/ARM](https://fedoraproject.org… Source: https://apps.fedoraproject.org/calendar/meeting/9431/

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

arm February 2020