Rawhide is the name given to the current development version of Fedora. It consists of a package repository called "rawhide" and contains the latest build of all Fedora packages updated on a daily basis. Each day, an attempt is made to create a full set of 'deliverables' (installation images and so on), and all that compose successfully are included in the Rawhide tree for that day.
Rawhide is sometimes called "development" or "master" (as it's the "master" branch in package git repositories).
Goals
Rawhide has the following Goals:
- To allow package maintainers to integrate the newest usable versions of their packages into Fedora.
- To allow advanced users access to the newest usable packages in a rolling manner.
- To allow incremental changes to packages that are either too minor or major to go to stable Fedora releases.
- To identify and fix issues with packages before they reach a stable release of Fedora.
Audience
Rawhide is targeted at advanced users, testers and package maintainers.
As a Rawhide consumer, you should:
- Be willing to update on an almost daily basis. Rawhide gets hundreds of updates a day, and applying those updates on a regular basis allows you to more easily isolate when a bug appeared and what package(s) are responsible.
- Be willing and able to troubleshoot problems. From time to time there are problems with Rawhide packages, and you will need strong troubleshooting skills and the ability to gather information for bug reports. You need a good understanding of dnf and how to downgrade packages, as well as boot time troubleshooting.
- Have time and desire to always be able to learn new interfaces and changes. Rawhide packages stick closely to upstream projects, so interfaces and command-line options are subject to frequent changes.
- Be willing to reboot frequently to test new kernel versions and confirm functionality of the boot process. If you can't reboot often, consider using a stable release instead.
- Be willing and able to report bugs to bugzilla as you find them and help maintainers gather information to fix them.
If the above doesn't match you, you may wish to instead follow the Branched release (depending on the point in the release cycle) or use regular stable Fedora releases.
Using Rawhide
This section discusses how to use Rawhide, as a live system or permanently installed.
Using a test system
If you are not able or wanting to run Rawhide as your primary system you could instead run it:
- As a live environment only
- In a virtual machine (VM) instance
- On a secondary system
- On a multiboot system, alongside a stable release of Fedora or another operating system
This allows you to test Rawhide without any impact to your day-to-day workflow.
Deploying Rawhide using Rawhide images
The nightly 'compose' process for Rawhide means that you can usually find at least some of the normal Fedora images in the current Rawhide tree. You can look through the Rawhide tree on a mirror manually, or you can use the Fedfind tool to find images from the latest Rawhide compose:
sudo dnf install fedfind fedfind images
Fedfind has various ways to filter the results; run fedfind images --help for more information.
Each new Rawhide compose is automatically tested by openQA, which runs various installation and post-install tests on several of the images. To make sure you download a Rawhide image that at least basically works, you can browse through recent openQA results. If the latest compose is broken but another relatively recent one (in the last couple of weeks) looks like it was working, you can find it here, where the last two weeks or so of Rawhide composes are archived. You can also use fedfind to find images from recent Rawhide composes, e.g. fedfind images --compose 20160329 --respin 0. Although you may be able to find image links in openQA pages, please do not download images from openQA; it is not intended as an image download service and may cause stress on openQA itself or other parts of the Fedora network.
At least the Server and Everything boot.iso images should always be present, as composes are considered to have failed if creation of those images fails. However, at present they are not guaranteed to be working every day.
You can attempt to install Rawhide from these images; you are rather more likely to encounter problems than you would with a stable release, however, as the installer itself and all its dependencies are of course in an unstable state. Follow the normal installation procedure to install Rawhide.
For PXE installations, the relevant files can be found in the pub/fedora/linux/development/rawhide/Everything/(arch)/os/images/pxeboot directory.
Point installer to Rawhide repositories
You can sometimes install Rawhide by using a stable install medium and pointing it to the Rawhide repository for packages to install.
- Boot the most recent stable Fedora installer following the normal procedure
- Go to the INSTALLATION SOURCE screen, click the On the network: button, set the dropdown box to https://, and manually enter: download.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/(arch)/os/ (where (arch) is x86_64 or i386 as appropriate) as the address
- Finish the install as normal.
For this method to work, there should be no major changes in Rawhide that the installer is not ready for, such as packages it depends on being retired or other similar situations.
Upgrade from an existing installation
You may also try to install a non-Rawhide release of Fedora, and then upgrade to Rawhide. It is usually best to use the newest release available, and install all updates for the release itself before attempting to upgrade to Rawhide.
It is recommended to do the upgrade with DNF system upgrade. You can also do it with DNF, but as with stable release upgrades, this is not officially recommended. In either case you will probably need to add the --nogpgcheck option to the upgrade commands, because usually not every package in a Rawhide compose will be signed.
Discussing Rawhide
There are a number of ways to communicate with other Rawhide users:
IRC
Rawhide discussion is on topic and welcome in both the #fedora-devel[?] and #fedora-qa[?] IRC channels.
Mailing Lists
Rawhide discussion is on topic and welcome in both the test and devel lists.
Bugzilla
Rawhide bugs should be reported against the Fedora product, rawhide version and the affected component. Please do follow best practices when filing. Remember that IRC and mailing lists are useful to help narrow down if some behavior is a bug or where to report it, but are themselves not bug reporting channels. Always file bugs in Bugzilla.
Note that broken dependencies are mailed to maintainers for each daily Rawhide compose where a package has such broken dependencies. Therefore, it's usually not worth filing a bug for broken dependencies unless they don't appear in the daily report, or you have a fix or improvement to suggest.
Blogs
The following blogs are not official communication, but are useful to follow if you are running Rawhide.
Producing Rawhide
Package owners must build for rawhide using koji just like you would any other build; you do not go through the bodhi process and the build becomes available almost immediately.
The Rawhide repository is composed every day starting at 05:15UTC. All rawhide builds in the buildsystem at that time are composed and pushed out to mirrors. The compose process also attempts to build all the standard Fedora 'deliverables' (live and install images, ARM and Cloud disk images, Docker images and so on). Rawhide is under "development/rawhide" on the mirrors. You can find a local "development" mirror on the public mirror list. Compose time varies depending on number of changes but is typically between 5 and 8 hours.
Composes are done in a rawhide chroot using the 'pungi' tool called from a script maintained by Fedora Release engineering. If the base set of packages in Rawhide needed to compose Rawhide are broken, the daily compose may fail.
A report for each Rawhide compose is sent to to the test and the devel lists. This report contains output from the 'repodiff' tool from the previous compose as well as a broken dependency report for packages with broken dependencies. Additionally, private email is sent to maintainers with packages containing broken dependencies.
Package maintainers should read and follow the Rawhide updates policy for building any packages in Rawhide.
If needed and approved by FESCo, Mass Rebuilds are done by release-engineering in Rawhide a month or so before the next release branches from it. Typically these are done for a global change over all packages such as a new gcc release, or rpm package format.
Questions and Answers
Q: Doesn't rawhide eat babies / kill pets / burn down houses / break constantly?
A: No. Please stop telling everyone that.
Q: So Rawhide is very stable and we can all use it?
A: No. See audience above. There are things that break from time to time, but if you are able to downgrade or troubleshoot such issues aren't too severe. Most users should still stick to stable Fedora releases, but Rawhide is a viable option for enthusiasts to experiment with.
Q: I'm using a Stable Fedora release, but I want a newer package version that's only available in Rawhide. Can I just dnf install it?
A: No. Mixing releases like this is a very bad idea. Better options are:
- Ask the Fedora maintainer in a bug report to update the stable version if permitted by policy.
- If not, there may be a COPR that provides the updated version. See the COPR page for more details.
- Obtain the src.rpm for the package you wish and try and rpmbuild --rebuild it (which may or may not work depending on dependencies).
Q: I want to run the Rawhide kernel on my stable Fedora machine. Can I do that?
A: Sometimes yes. The kernel is more self contained than other Rawhide packages and you also can easily boot your older kernel if the Rawhide kernel goes wrong. Simply download and dnf install the package. However, note that Rawhide kernels often have debugging code enabled, which results in them performing noticeably worse than 'release' kernels (they will be slower and consume more memory).
Q: Is Rawhide a "rolling release" ?
A: It depends on how you define that, but yes.
Q: How can I tell when the Rawhide compose for the day has finished?
A: Check the for the reports sent to the test and the devel lists, or watch fedmsg for the org.fedoraproject.prod.pungi.compose.status.change topic.
Q: How do I get out of Rawhide again? I want to switch to the Branched release or a stable release.
A: Remove the 
fedora-repos-rawhidesu -c 'dnf config-manager --disable rawhide'), enable the 'fedora' and optionally 'updates' and 'updates-testing' repositories (su -c 'dnf config-manager --enable fedora(,updates,updates-testing)') and perhaps run su -c 'dnf --releasever=(version) distro-sync'. The farther the branch to which you want to switch is behind Rawhide, the more trouble you might have with this.
A possible problem is that you might miss the branching point, and your system has already a bunch of post-branch Rawhide packages installed. In that case, the dnf distro-sync will help you to get everything back on the right track.
Q: As a package maintainer do I have to build rawhide packages or does the nightly compose take care of that?
A: No. You must build for Rawhide using koji. The nightly compose only collects packages already built and marked with the appropriate target (rawhide) in koji.
Q: Why aren't Rawhide packages signed?
A: Rawhide signing is currently in development. At present many Rawhide packages get signed, but we still cannot guarantee that every package in any given Rawhide compose is signed. Check Release Engineering ticket 5870 for status updates.
Hints and Tips
- Your package management system can be of great help in diagnosing and working around issues you find. Do read up and understand:
dnf downgradednf historydnf update --skip-brokenkoji download-build
- You should update frequently (preferably every day). This allows you to more easily narrow down when a problem or issue appeared. If you apply a week of Rawhide updates at once you have many more packages to examine to narrow down issues.
- Reboot often (preferably whenever new kernels arrive). This allows you to test the boot up process and packages related to it, as well as newer kernels. Read and understand the Dracut troubleshooting steps.
- Follow the test and the devel lists for rawhide issues, try and at least skim them before doing your daily Rawhide updates. Look for '[rawhide]' subjects or reports of issues. Additionally if you find a problem and are not sure what to file bugs against you can open a discussion there.
- Rawhide kernels are often built with varying degrees of debugging code enabled, which will result in worse performance and increased resource usage. See KernelDebugStrategy for details on exactly what debugging code is enabled for which kernel builds. You can disable SLUB debugging for those builds for which it is enabled by passing "slub_debug=-" to your kernel command line in
/etc/default/grub(and re-generating your grub config, or just adding it directly). Additionally, you can run kernels in the Rawhide Kernel Nodebug repo that have all debugging disabled.
- If you are using a graphical desktop environment in your Rawhide install, you may wish to install several of them. This allows you to still login and troubleshoot when your primary desktop environment is not working for some reason.
- Have a rescue media handy of the current stable Fedora release for emergencies.
History
Red Hat Linux "Raw Hide" announcement: on lwn
The name might come from the song with the same name that starts with "Rolling, rolling, rolling, ..."
At one time, Rawhide would freeze before release milestones. This was changed with the No_Frozen_Rawhide_Proposal and Branched process which we now follow.