Has anyone had any luck getting Fedora 28 to work on the Odroid C2?
I've tried downloading the Fedora 28 Server aarch.raw.xz image which i
put onto my sd card. I then moved the Archlinux aarch64 boot parition
into boot along with the lib/modules and lib/firmware folders from
Archlinux. This has been to no avail. I'm working on building the
hardkernel kernel myself now but have never actually compiled a kernel
myself so I'm not sure what I fully need to get the Fedora rootfs to
boot with the kernel.
If anyone has some guidance or a nice writeup on getting a bootable
kernel recognized by Fedora on the Odroid C2 that would be greatly
DOn't know if this is a general F29 problem...
Skipping packages with broken dependencies:
authselect armv7hl 1.0.1-1.fc29 updates-testing 55 k
authselect-libs armv7hl 1.0.1-1.fc29 updates-testing 108 k
looking up in the messages I see:
Problem 1: cannot install the best update candidate for package
- nothing provides systemctl needed by
Problem 2: cannot install the best update candidate for package
- package bubblewrap-0.3.0-2.module_2123+73a9ef6f.armv7hl is disabled
Problem 3: cannot install the best update candidate for package
- package libnghttp2-1.33.0-1.module_2177+2526c218.armv7hl is disabled
Problem 4: cannot install the best update candidate for package
- package libpeas-1.22.0-9.module_2123+73a9ef6f.armv7hl is disabled
Problem 5: cannot install the best update candidate for package
- package libpeas-gtk-1.22.0-9.module_2123+73a9ef6f.armv7hl is disabled
Problem 6: cannot install the best update candidate for package
- package perl-HTTP-Tiny-0.076-1.module_2073+eebc5b71.noarch is disabled
Problem 7: package authselect-1.0.1-1.fc29.armv7hl requires
authselect-libs(armv7hl-32) = 1.0.1-1.fc29, but none of the providers
can be installed
- cannot install the best update candidate for package
- nothing provides systemctl needed by
I have other things to do today. Hopefully this well get fixed. Or
should I go ahead and update what will update?
With the latest uboot (2018.09) and Fedora 29-beta-Xfce
No wifi. Nothing shows when I do 'ip a'
Same uboot, but the Centos7 image:
There is the wifi interface. The Gnome install asks me if I want to
connect to any of the visible SSIDs.
How did the Centos arm team get this to work and not Fedora? :)
Really not so important RIGHT now, as my CT is for a Centos server. I am
only planning on running Fedora on Cubieboard2 which do not have their
own embedded wifi.
Just a data point for now.
I see a few months ago in the mailing list that support was brought up (in
the context of F27) and it was mentioned that improving support for
Rockchips devices in general was intended for F28.
It doesn't appear that fedora-arm-installer currently supports the Rock64
board as far as I can tell.
I'm trying to figure out how to add support by adding to
/usr/share/arm-image-installer/boards.d and socs.d, as well as solving the
lack of appropriate uboot in /usr/share/uboot for Rock64.
I flashed (and tested successfully) a community built Debian Stretch image
and by comparing it's partition layout and some information from OpenSUSE I
can guess at what some of it should be, but I'm not entirely sure how to
make the appropriate files in socs.d, boards.d, and what all is needed in
Debian Stretch image that boots :
U-boot used in the above build :
OpenSUSE info : https://en.opensuse.org/HCL:Rock64
working stretch partition layout :
# gdisk -l /dev/sdc
GPT fdisk (gdisk) version 1.0.4
Partition table scan:
BSD: not present
APM: not present
Found valid GPT with protective MBR; using GPT.
Disk /dev/sdc: 62333952 sectors, 29.7 GiB
Model: Storage Device
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): 9CFDF7D8-766C-43DE-9354-57097D428E8F
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 62333918
Partitions will be aligned on 64-sector boundaries
Total free space is 30 sectors (15.0 KiB)
Number Start (sector) End (sector) Size Code Name
1 64 8063 3.9 MiB 8300 loader1
2 8064 8191 64.0 KiB 8300 reserved1
3 8192 16383 4.0 MiB 8300 reserved2
4 16384 24575 4.0 MiB 8300 loader2
5 24576 32767 4.0 MiB 8300 atf
6 32768 262143 112.0 MiB 0700 boot
7 262144 62333918 29.6 GiB 8300 root
loader1 (partition 1) is the SPL, loader2 (partition 4) is the U-Boot. atf
(partition 5) per OpenSUSE is apparently some kind of "trust" image.
The reserved partitions (partitions 2 and 3) seem to just be all nulls.
The boot partition (partition 6) has extlinux/extlinux.conf apparently as
well as 'System Volume Information' (guessing that the origin of that
partition was built on Windows), and partition 7 is of course regular old
I'm not sure how fedora-arm-installer decides to partition things, it
wasn't obvious from socs.d/boards.d, so I'm not sure how to ensure that
when creating the soc/board scripts that the correct layout is maintained.
From glancing at the source code for fedora-arm-installer it seems like it
just extracts the image onto the media and assumes the layout based on what
was in the image, which might present a problem if the unified AArch64
image has only 3 partitions? Unless it would be expected that Fedora would
have it's own build of uboot that would ensure things didn't need all those
other partitions ?
Anyways, I'm happy to either figure this out on my own if you can point me
in the right direction or if you already have some WIP that needs a
volunteer to test it, to do be your guinea pig.
> we see the f28 installer failing with:
The Fedora 28 ship has long sailed, please test on Fedora 29 Beta RCs
and provide feedback on that:
> [ 43.222590] Internal error: Oops: 96000021 [#1] SMP
> [ 43.227456] Modules linked in:
> [ 43.230500] CPU: 87 PID: 1 Comm: swapper/0 Not tainted 4.16.3-301.fc28.aarch64 #1
> [ 43.237968] Hardware name: Cavium Inc. Saber/Saber, BIOS Cavium reference firmware version 6.4 05/30/2018
> [ 43.247521] pstate: 20400009 (nzCv daif +PAN -UAO)
> [ 43.252304] pc : test_atomic64+0x134c/0x152c
> Kernel and initrd from:
> This is due to this upstream fix from v4.17-rc7 missing:
Sure, all of the above isn't solvable now, we need to look at F-29+
Now is the time to ensure everything that is needed here for F-29 to
be there and all testing should be done there.
> Also, a workaround that uses kernel and initrd from f29 or rawhide for
> f28 installation does not work as the bootchain of the installer needs
> files from the same media. Otherwise boot fails with "Pane is dead"
> and "new value non-existent xfs filesystem is not valid as a default
> fs type", see also:
> Do you see an alternative workaround to pxe boot f28?
Use Fedora 29.
> Would it be possible to update the installer's kernel and initrd?
> Another question: Would it be possible to include early silicon (Rev
> Ax) Errata workarounds to f28, f29 and rawhide? There are 2 patches
> required, both are in this branch:
Are these patches expected to go upstream? What impact would those
patches have on other ARM platforms or even other architectures? If
they are not planned to go upstream how long would you expect Fedora
to carry them before we dropped them?
> PCI: Vulcan: AHCI PCI bar fix for Broadcom Vulcan early silicon
> ahci: thunderx2: Fix for errata that affects stop engine
> There are still some Ax systems around that wouldn't be supported
> Btw, the f29 kernel was not available for installation:
You need kernel/kernel-core/kernel-modules.
dnf --disablerepo=\* --enablerepo=f29 repoquery kernel\*