=?utf-8?q?=5Bfedora-arm=5D?=(resend) Trying to run Fedora-Minimal-31 under QEMU on Fedora 29
by Derek Atkins
(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
4 years, 3 months
Fwd: Building Fedora images for the RPi 3B+
by Elliot Alderson
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
4 years, 3 months
Question: u-boot 2020.04 on RPi4
by Steven A. Falco
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
4 years, 3 months
Re: Proposal to change ARM Release Blocking Criteria - Drop XFCE (32bit), Add Workstation(64bit)
by Kamil Paral
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?
4 years, 3 months
Re: Proposal to change ARM Release Blocking Criteria - Drop XFCE (32bit), Add Workstation(64bit)
by Peter Robinson
> > 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 ¯\_(ツ)_/¯
4 years, 3 months
Proposal to change ARM Release Blocking Criteria - Drop XFCE (32bit), Add Workstation(64bit)
by Paul Whalen
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
4 years, 3 months
networking in fedora on Odroid XU4
by Michael Whapples
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
4 years, 3 months