Architectures/RISC-V/Installing

This page explains how to get Fedora running on either physical or virtual RISC-V hardware.

Disclaimer

riscv64 is currently not an officially supported Fedora architecture.

Most packages are built from unmodified Fedora sources, but in several cases architecture-specific patches are necessary. There is an ongoing effort to reduce (and eventually eliminate) this delta. Check out the tracker to see the current status.

Hardware support is limited to what mainline Linux provides, and that usually doesn't include the SoC's integrated GPU. Fedora RISC-V is primarily intended to be used as a headless build host / server environment for now.

Generic instructions

The following installation steps are applicable to most hardware.

If your machine is listed in the machine-specific instructions section below, make sure you check out the corresponding page first, as it might contain important information that (partially or completely) supersedes what's written here.

Requirements

Serial console access

While ssh is likely going to be the primary way you'll interact with the machine, it's useful to have serial console access as a fallback. Moreover, it is required for the initial setup.

The process of connecting the USB to serial adapter is machine-specific and can't be documented in a generic fashion.

First of all, make sure your user is in the dialup group:

$ sudo usermod -a -G dialout $(whoami)

This is necessary to access the serial console. Log out and back in for the change to take effect.

Now plug the USB to serial adapter into your computer. If you only have one such adapters connected, it should show up as /dev/ttyUSB0.

Create a configuration file for minicom, with the name you like, for example ~/.minirc.RISCV. The contents should look like this:

pu port             /dev/ttyUSB0
pu baudrate         115200
pu bits             8
pu parity           N
pu stopbits         1
pu rtscts           No

You will now be able to connect to the serial console by running:

$ minicom RISCV

For added reliability, you can use a stable device name in the configuration file. For example:

$ ls -l /dev/serial/by-id/*
/dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0 -> ../../ttyUSB0

This output indicates that you should replace /dev/ttyUSB0 with /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0 in the configuration file.

Media preparation

Downloading the disk image

Disk images can be obtained from:

• https://dl.fedoraproject.org/pub/alt/risc-v/release/41/Server/riscv64/images/

As of this writing, the most recent disk image is:

• Fedora-Server-Host-Generic-41.20250128.riscv64.raw.xz

The file you've just downloaded will be referred to as IMAGE.raw.xz below.

A matching IMAGE.raw.xz.sha256 file is also provided: this allows you to validate the integrity of your download.

Writing the disk image to the target media

The disk image is intended to work regardless of the type of media it's written to: SD cards, USB sticks, NVMe and SATA drives are all known to work. NVMe is preferred, if available on your machine, because it performs the best, but you can choose whatever is more suitable to you. SD cards, for example, are great when you want to test a disk image without affecting your existing installation.

The disk image comes compressed, so the first step after downloading it is to uncompress it:

$ unxz IMAGE.raw.xz

The compressed IMAGE.raw.xz file will be replaced by the uncompressed IMAGE.raw file. The latter is the one that can be written to the target media.

There are several tools that can be used for writing the disk image. dd is perhaps the most common option:

$ sudo dd iflag=fullblock oflag=direct status=progress bs=4M if=IMAGE.raw of=/dev/TARGET

Replace /dev/TARGET with the name of the actual target device. Please be extremely careful and ensure that you're using the correct name here: if you get it wrong, you risk destroying your current OS.

balenaEtcher is another popular option. It's a user-friendly GUI that should make it a lot harder to mess things up.

First boot

Once the disk image has been written to the target media, you can pop that into your machine and power it on.

The process of getting the firmware to boot from the media is machine-specific and can't be documented in a generic fashion. It usually helps if only one media is connected to the machine at any given time.

Assuming everything is fine, after a few seconds you should see the usual Linux boot messages scroll by on the serial console.

The boot might appear to hang after a while. Please be patient and give it some time; eventually, initial-setup should show up. This is what it will look like:

================================================================================
================================================================================

1) [ ] Language settings                 2) [x] Time settings
       (Language is not set.)                   (America/New_York timezone)
3) [x] Network configuration             4) [!] Root password
       (Connected: enp1s0)                      (Root account is disabled)
5) [!] User creation
       (No user will be created)


Please make a selection from the above ['c' to continue, 'q' to quit, 'r' to refresh]:

While all items should be functional, it is mandatory to complete either 4) [!] Root password or 5) [!] User creation. You will not be able to log into the machine at all otherwise.

Post-installation tasks

Enable the performance CPU governor

The default CPU governor is schedutils, which scales the CPU frequency dynamically. If you want to squeeze every last bit of performance out of your machine, you might want to switch to the performance CPU governor. To do so, simply run:

$ sudo grubby --update-kernel=ALL --args=cpufreq.default_governor=performance

A reboot is necessary for the change to take effect.

Disable use of tmpfs for /tmp

Fedora uses tmpfs for /tmp by default, but that might cause issues if your machine doesn't have much RAM. If you run into OOMs or other related issues, you can revert to disk-backed /tmp by running:

$ sudo systemctl mask tmp.mount

A reboot is necessary for the change to take effect.

Enable haveged

If your machine doesn't have a hardware RNG, it might take a long time to boot or accept ssh logins. A possible workaround is to configure a software RNG like so:

$ sudo dnf install -y haveged
$ sudo systemctl enable --now haveged.service

Machine-specific instructions

While the information above is generally applicable, some machines require additional or even completely different steps.

Physical hardware

• StarFive VisionFive 2
• SiFive HiFive Unmatched
• SiFive HiFive Premier P550

Virtual hardware

• QEMU