The Kickstarter page for VisionFive 2 mentions that 4 images would be available for the VisionFive 2 SBC.
So the only thing that is missing without any updates whatsoever (right now) is the Fedora image for the VisionFive 2. Is there any status to this? Any ETA?
No risc-v package build system instance for Fedora
Are you sure?
Just try openEuler
I need Feodra because I have a few use cases which are best met by Fedora, out of the box.
https://dl.fedoraproject.org/pub/alt/risc-v/repo/fedora/
There are fc29 & fc37 （33 is empty directory）in Offical site.
There’s not a bootable image because we’re waiting on stuff to get upstream. We have an IRC channel #fedora-riscv on Libera.
There are ways to run(aka systemd-nspawn) Fedora 38 from within Debian. Essentially the sdcard still holds Debian Image-69, and the nvme holds a partition holding the contents for Fedora 38’s risc-v image originally intended for the hifive unmatched, but still works for VF2. The trick was to use the Debian Image-69’s “/boot” and only Fedora38’s “/”
it’s discussed here:
Recently, somebody actually helped me to add a new entry in my extlinux.conf to launch directly into the nvme’s fedora 38 “/”, but you still need the debian image-69 /boot. I don’t need to systemd-nspawn into Fedora 38 anymore.
It’s a bit of finagling, but it certainly helps to get closer to getting Fedora onto the VF2 for sure.
One could create an image right now that uses debian image-69’s boot and the nvme’s fedora 38 “/” to provide something, but that’s not the ideal. It’s just a workaround until everything lands in the usual place it’s supposed to land.
I’m grateful podman runs well in Debian Image-69. I would not have succeeded in doing anything to get this far without it.
Oddly enough I can’t get podman to install on the Fedora 38 nvme running on VF2 itself which was stopping me from continuing my efforts to ultimately create a fedora silverblue 38 image for the vf2. I’m new to that whole original process but there are others in discussion and have better understaning about all that. I’m trying to keep up LOL.
Fedora 38 packages for riscv is still a WIP in itself. The repos group list shows lists, but the packages without the groups haven’t been entirely built so may not be installed/empty installs. At least that was my experience when I last tried last week.
I noticed that but didn’t look into that specific way of getting the Fedora image working because I do not have an NVMe drive at the moment.
Hence, I am asking for an image 
I could look into creating an image but I don’t know how the SD Card partitions are laid out… Like, why do some start with a 2MB offset, etc.
At a guess 2MiB (0x20_0000) is where the 32KiB ZSBL (zerostage bootloader ROM) in the JH7110 checks to read the SPL (second stage loader) on an SD card / eMMC during a normal boot flow.
I had saved the PDFs to understand them one by one but forgot to save the boot flow PDF and that’s why I was confused.
Thank you @mzs! 
You can boot fedora from sdcard too. I chose nvme because… well… I had one.
The debian-69 image comes with three partitions where the third one is the root filesystem. One normally expands that to fill the whole sdcard but instead of doing that you can create a fourth partition mmcblk1p4 that would hold the fedora root fs. Just sub that partition for the nvme partition in the other thread and you should be ok.
I just skipped through it because an NVMe drive was mentioned and I don’t have one at the moment. Now, taking a closer look at it, I realize what was done.
But my primary concern is that with a Fedora image, SELinux, among other Kernel configuration, is a given. Though I don’t directly interact with SELinux, most of the networking and Podman stuff that I do does need SELinux in some way or other.
It’s not Fedora that I need, but the things that come with Fedora out of the box that makes me want it, if you know what I mean 
Guess I will have to wait sometime until Linux 6.4 to get a Fedora image from the upstream devs
Debian69’s kernel is not enabled “security label” .
This will cause some rpm install fail.
the fedora images listed were intended for the HiFive Unmatched Board.
They could be used for inspiration for sure. The binaries mostly run, but not the bootup/desktop parts of course because those need to be configured particularly with the VF2 graphic device drivers and VF2 bootup configs.
fc33 was done to work with vf1 I believe, which is a good reference point.
The new build ways for fedora use appliance-tools and livecd-tools along with mock. I haven’t figured out everything about it, but I can nudge you to a place
http://fedora.riscv.rocks/koji/tasks?order=-completion_time&owner=davidlt&state=all&view=flat&method=createAppliance
where others that want to help configure and build more recent fedora images for VF2 could take a look.
http://fedora.riscv.rocks/kojifiles/work/tasks/6900/1466900/fedora-riscv64-developer-f39.ks
http://fedora.riscv.rocks/kojifiles/work/tasks/6900/1466900/koji-image-f39-build-1466900.ks
This is the output of the create-appliance using mock, but I still have no idea how they launched it all.
http://fedora.riscv.rocks/kojifiles/work/tasks/6900/1466900/mock_output.log
Here’s a new risc64 fedora 39 image for HiFive Unmatched:
http://fedora.riscv.rocks/kojifiles/work/tasks/6900/1466900/Fedora-Developer-39-20230927.n.0-sda.raw.xz
Like I mentioned before, this image could be tweaked to be run on VF2 if we change the boot/graphics driver specific configurations. I did succeed in doing an nspawn using a similar fc37 image from the same koji build server which ran but not with the gui/graphics of course, but still it was impressive to see all those hifive binaries run on the vf2.
On a tangent, I managed to run archlinux cwt18 image and install podman related
In archlinux:
pacman -Syy
pacman -S cockpit cockpit-machines cockpit-podman cockpit-storaged podman nomad-driver-podman cockpit-pcp pcp-pdma-podman podman-compose podman-dnsname podman-docker
mkdir -p /home/user/backToHost
podman run --privileged --net host -i -t -v /home/user/backToHost:/backToHost docker.io/imbearchild/fedora-rv64 /bin/bash
dnf install appliance-tools livecd-tools
ctrl+p ctrl+q
podman commit 01b348336969 f38-aplnctlslvcdtls
podman ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
98d23e33a35e docker.io/imbearchild/fedora-rv64:latest /bin/bash 17 minutes ago Up 17 minutes jolly_mestorf
podman images
REPOSITORY TAG IMAGE ID CREATED SIZE
localhost/f38-aplnctlslvcdtls latest 06edcf98bea6 5 minutes ago 590 MB
docker.io/imbearchild/fedora-rv64 latest fedc80455f67 4 months ago 231 MB
podman attach 06edcf98bea6
# appliance-creator -n ThinCrust -c /usr/share/appliance-tools/aos-rawhide.ks --cache /var/tmp/act/
# found this in the koji mock output log file but I don't see fedora-riscv64-developer-f39.ks being used anywhere when it should
/usr/bin/appliance-creator -c /chroot_tmpdir/koji-image-f39-build-1466900.ks -d -v --logfile /chroot_tmpdir/appliance.log --cache /chroot_tmpdir/koji-appliance -o app-output --format raw --name Fedora-Developer-39-20230927.n.0 --version 39 --release 20230927.n.0
xzcat ./Fedora-Developer-39-20230927.n.0-sda.raw.xz | sudo dd bs=4M conv=fsync of=/dev/sda
Notice that docker.io/imbearchild/fedora-rv64:latest
I believe it was inspired from this image:
http://fedora.riscv.rocks/kojifiles/work/tasks/5889/1465889/Fedora-Developer-38-20230825.n.0-sda.raw.xz
The last image for fc38 built on koji.
I also noticed these koji images do not provide a checksum file to ensure its file integrity after a download. I believe they should.
I would recommend they use b3sum, it is faster by far than sha256sum and sha512sum tools and just as reliable.
All this work is described here and presented by David Abdurachmanov
Fedora/RHEL/CentOS/Alma/Rocky are use “koji” to build rpms & system.
You can think koji is a font-end of mock. It ask mock witch src.rpm is will be built & storage mock’s output.
mock is a buildtool. You can think it is a “script” which create a new rootfs to provide build depend & chroot in the rootfs to run rpmbuild command to build rpms.
If compiler set “-march=riscv64gc” , then unmatched/vf2 all can run.
Oh, Yes. It is seems fedora/debian and other riscv64 distribution are all with the riscv64gc .
I remember the “riscv64gc” is a common standard in linux community.
(riscv64gc is seems replace with RVA20 , and next standard is RVA22. RAV22 seems will not support VF2.)
Thank you for reaching out. It’s easy to mention the following:
I found a place where how to install and setup koji.
https://docs.pagure.org/koji/server_howto/
using koji to build images
https://docs.pagure.org/koji/image_build/
BUT to actually install and configure the pre-requisites takes time. I’m working on it within a podman session running fedora 38 on the archlinux VF2. I’ll give you progress as I go.
dnf install httpd mod_ssl postgresql-server mod_wsgi mock setarch rpm-build createrepo
real 18m49.323s
user 1m52.060s
sys 2m36.480s
podman ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
bfbb52c1269f localhost/f38-aplnctlslvcdtls:latest /bin/bash 21 minutes ago Up 21 minutes loving_stonebraker
time podman commit bfbb52c1269f f38-koji-prereqs
real 1m59.746s
user 1m41.737s
sys 0m26.820s
In my suggestion, koji install to a x86 machine, vf2 install as “a worker”.
If you only build a few of rpms, mock is enough.
koji’s doc is confuse… 