From Fedora Project Wiki
(add note about rawhide boot.iso)
(46 intermediate revisions by 16 users not shown)
Line 1: Line 1:
{{autolang|base=yes}}
{{autolang|base=yes}}


= Rawhide =
Rawhide is the name given to the current development version of Fedora. It consists of a [[Repositories|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 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. Nightly live image builds are also available during the early portion of the [[Fedora Release Life Cycle]].
Rawhide is sometimes called "development" or "master" (as it's the "master" branch in package git repositories).  
 
Rawhide is sometimes called "development" or "master" (as it's the "master" branch in Package git repositories).  


== Goals ==
== Goals ==
Line 15: Line 13:
* To allow incremental changes to packages that are either too minor or major to go to stable Fedora releases.
* 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.
* To identify and fix issues with packages before they reach a stable release of Fedora.
* To allow a place where certain low-level packages (approved by FESCo), including (but not limited to) glibc and gcc, can gain real-world testing of pre-release versions.


== Using Rawhide ==
== Audience ==
 
This section discusses rawhide's target users and how to test Rawhide with Live media, within a virtual installation or on a bare metal installation.
 
=== Audience ===


Rawhide is targeted at advanced users, testers and package maintainers.  
Rawhide is targeted at advanced users, testers and package maintainers.  


As a rawhide consumer, you should:  
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 troubleshoot issues.
* 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 yum and how to downgrade packages, as well as boot time troubleshooting.
* 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.
* 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.


* Frequent reboots 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 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 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 [[Releases/Branched|Branched]] release (depending on the point in the [[Releases/{{FedoraVersion||next}}/Schedule|release cycle]]) or use regular stable Fedora releases.
 
=== Live media ===
 
After the release of the previous final release, but before the [[Releases/{{FedoraVersion||next}}|Branch event]], [http://alt.fedoraproject.org/pub/alt/nightly-composes/ nightly builds] will be composed from Rawhide. You may be able to use these automated Live images to boot and test Rawhide. These images are automatically composed and not tested by [[QA]].  


=== Virtual instances  ===
* Be willing and able to report bugs to bugzilla as you find them and help maintainers gather information to fix them.


You may wish to install and run Rawhide in a virtual machine (VM) instance. This allows you to test Rawhide when not running Linux, or avoid any impact to your day-to-day workflow.
If the above doesn't match you, you may wish to instead follow the [[Releases/Branched|Branched]] release (depending on the point in the [https://fedorapeople.org/groups/schedule/f-{{FedoraVersion||next}}/f-{{FedoraVersion||next}}-key-tasks.html release cycle]) or use regular stable Fedora releases.


See the section below on setting up a Rawhide install.
{{Rawhide_branched_install_methods|release=Rawhide}}


=== Getting a Rawhide install ===
== Discussing Rawhide ==
 
The following options are available to install a fedora rawhide instance:
 
==== Install from Live media ====
 
If Live media are being composed from Rawhide (see above), you may be able to download the Live media, copy it to local media, boot and install Rawhide.
 
This is the most fragile way to get a Rawhide install, as Live media is only produced at some points in the cycle, sometimes does not compose, and when it does, may not install correctly.
 
==== Use rawhide Boot.iso ====
 
Unless some problem occurs, a boot.iso is produced each day in the rawhide compose. It may or may not install, depending on the state of the tree and the installer. You can copy the boot.iso to media in any of the normal ways and use it to install.
 
==== Point installer to Rawhide ====
 
You can sometimes install Rawhide by using a stable install media and pointing it to the Rawhide repository for packages to install.
 
# Download the latest stable or branched install media. (netinstall or DVD install)
# Copy to local media (USB or DVD or CD)
# Boot media and go to the 'Install Source' section and manually enter:<br />https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/x86_64/os/<br />(or i386 for 32bit)
# 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.
 
==== Yum from Existing install ====
 
You may use yum to upgrade from the most recent Stable or Branched release. You will need to have such an install in place and should likely update to the newest updates before starting.
 
See [[Upgrading_Fedora_using_yum#To_rawhide|Upgrading Fedora using yum Rawhide info]]
 
This method may fail if there are upgrade path issues (newer packages in Stable or Branched than Rawhide), or broken dependencies.
 
=== Communicating  ===


There are a number of ways to communicate with other Rawhide users:  
There are a number of ways to communicate with other Rawhide users:  


==== IRC ====
=== IRC ===


Rawhide discussion is on topic and welcome in both the {{fpchat|#fedora-devel}} and {{fpchat|#fedora-qa}} IRC channels.
Rawhide discussion is on topic and welcome in both the {{fpchat|#fedora-devel}} and {{fpchat|#fedora-qa}} IRC channels.


==== Mailing Lists ====
=== Mailing Lists ===


Rawhide discussion is on topic and welcome in both the {{fplist|test}} and {{fplist|devel}} lists.
Rawhide discussion is on topic and welcome in both the {{fplist|test}} and {{fplist|devel}} lists.


==== Bugzilla ====
=== Bugzilla ===


Rawhide bugs should be reported against the Fedora Product, rawhide version and the affected component.  Please do follow [[BugsAndFeatureRequests|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 [http://bugzilla.redhat.com Bugzilla].
Rawhide bugs should be reported against the ''Fedora'' product, ''rawhide'' version and the affected component.  Please do follow [[BugsAndFeatureRequests|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 [http://bugzilla.redhat.com 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.
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.
Line 103: Line 57:
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.
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 08:15UTC. All rawhide builds in the buildsystem at that time are composed and pushed out to mirrors. Rawhide is under "development/rawhide" on the mirrors. You can find a local "development" mirror [http://mirrors.fedoraproject.org/publiclist/Fedora/development/ on the public mirror list]. Compose time varies depending on number of changes but is typically between 5 and 8 hours.  
The Rawhide repository is composed every day starting at 05:15UTC. All rawhide builds in the buildsystem at that time are included in the compose attempt. 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). If any release-blocking image fails to build as part of the compose, the compose is considered to have failed. If the compose completes successfully, the compose will be 'synced out' to the mirror system. (A system where the sync only happens if a set of automated tests run on it passes is planned, but not yet fully implemented). Rawhide is under "development/rawhide" on the mirrors. You can find a local "development" mirror [http://mirrors.fedoraproject.org/publiclist/Fedora/development/ 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 'mash' tool called from a script maintained by Fedora Release engineering: http://git.fedorahosted.org/cgit/releng/tree/scripts/buildrawhide If the base set of packages in rawhide needed to compose rawhide are broken, the daily compose may fail.  
Composes are done in a rawhide chroot using the 'pungi' tool called from [https://pagure.io/pungi-fedora/blob/master/f/nightly.sh 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 {{fplist|test}} and the {{fplist|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.  
A report for each Rawhide compose is sent to to the {{fplist|test}} and the {{fplist|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.  
Line 112: Line 66:


If needed and approved by [[Fedora_Engineering_Steering_Committee|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.  
If needed and approved by [[Fedora_Engineering_Steering_Committee|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.  
Rawhide packages are currently not signed. Work is ongoing to sign at least the majority of them.


== Questions and Answers ==
== Questions and Answers ==
Line 119: Line 71:
'''Q:''' Doesn't rawhide eat babies / kill pets / burn down houses / break constantly?  
'''Q:''' Doesn't rawhide eat babies / kill pets / burn down houses / break constantly?  


A: No. Please stop telling anyone that.  
A: No. Please stop telling everyone that.  


'''Q:''' So Rawhide is very stable and we can all use it?  
'''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, however most users should stick to Stable Fedora releases.  
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 the newer package for foo thats only available in Rawhide. Can I just yum install it?
'''Q:''' I'm using a Stable Fedora release, but I want a newer package version that's only available in Rawhide. Can I just {{command|dnf install}} it?


A: No. Mixing releases like this is a very bad idea. Your better options are:  
A: No. Mixing releases like this is a very bad idea. Better options are:  


* Obtain the src.rpm for the package you wish and try and rpmbuild --rebuild it (which may or may not work depending on dependencies)
* Ask the Fedora maintainer in a bug report to update the stable version if permitted by policy.
* Ask the Fedora maintainer in a bug report to update the stable version if permitted by policy.  
* If not, there may be a [http://copr.fedoraproject.org/ 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?  
'''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. Simply download and yum install the package.  
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" ?
'''Q:''' Is Rawhide a "rolling release" ?
Line 140: Line 93:
A: It depends on how you define that, but yes.
A: It depends on how you define that, but yes.


'''Q:''' How can I tell when the rawhide compose for the day has finished?
'''Q:''' How can I tell when the Rawhide compose for the day has finished?
 
A: Check the for the reports sent to the {{fplist|test}} and the {{fplist|devel}} lists, or watch fedmsg for the {{code|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:
 
{{command|sudo dnf config-manager --set-disabled rawhide,rawhide-modular}}
 
{{command|sudo dnf config-manager --set-enabled
fedora,fedora-modular,updates,updates-modular,updates-testing,updates-testing-modular}}
 
{{command|sudo dnf distrosync}}


A: You can see the reports it sends to the {{fplist|test}} and the {{fplist|devel}} lists. You can also watch fedmsg for the messages that rawhide compose has finished.
{{command|sudo reboot}}


'''Q:''' How do I get out of Rawhide again ? I want to continue on the branch leading to the next release.
This will work for systems most recently updated before branch, or those after branch with mixed release packages.


A: You can simply disable the rawhide repository in /etc/yum.repos.d/rawhide.repo.
'''Q:''' As a package maintainer do I have to build rawhide packages or does the nightly compose take care of that?


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, yum distro-sync will help you to get everything back on the right track.
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:''' As a package maintainer do I have to build rawhide packages or does the night compose take care of that?
'''Q:''' Are rawhide packages signed?


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.
A: They are. All of them are now signed. Make sure you have gpgcheck=1 set in your repo file to take advantage of this.


== Hints and Tips ==
== 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: 'yum downgrade' 'yum history' 'yum update --skip-broken' 'koji download-build'.
* Your package management system can be of great help in diagnosing and working around issues you find. Do read up and understand:
** {{command|dnf downgrade}}
** {{command|dnf history}}
** {{command|dnf update --skip-broken}}
** {{command|koji 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.  
* 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.  
Line 164: Line 134:
* Follow the {{fplist|test}} and the {{fplist|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.  
* Follow the {{fplist|test}} and the {{fplist|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 made with a large amount of debugging enabled. You can often gain a good deal of performance by passing "slub_debug=-" to your kernel boot line in /etc/grub2.cfg. Additionally, you can run kernels in the [[RawhideKernelNodebug|Rawhide Kernel Nodebug]] repo that have all debugging disabled.  
* 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 {{filename|/etc/default/grub}} (and re-generating your grub config, or just adding it directly). Additionally, you can run kernels in the [[RawhideKernelNodebug|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.
* 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.
Line 176: Line 146:
The name might come from [http://en.wikipedia.org/wiki/Rawhide_%28song%29 the song with the same name] that starts with "Rolling, rolling, rolling, ..."
The name might come from [http://en.wikipedia.org/wiki/Rawhide_%28song%29 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 new:
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.
[[No_Frozen_Rawhide_Proposal]] and branched process which we now follow.

Revision as of 12:42, 12 February 2021

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.
  • To allow a place where certain low-level packages (approved by FESCo), including (but not limited to) glibc and gcc, can gain real-world testing of pre-release versions.

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.

Install from nightly composes

Each day (or sometimes more than once per day) , a full 'compose' of the tree is attempted. This will usually result in the creation of all or most of the usual install, live and disk images, installer trees and so forth. Successful composes are synced to the /fedora/linux/development/ directory on the mirrors, and you can find the images there.

Each successful compose is tested by openQA and a mail summarizing the results is sent to the devel and test mailing lists, so you can check the openQA interface or the 'compose check report' emails to check whether that day's compose is installable. You may also use the nightly image finder tool maintained and hosted by a Fedora QA team member, which conveniently offers the last completed build for each image and the last that passed all tests, for openQA or Autocloud-tested images.

At least the Server and Everything network install 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.

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.

Using nightlies in the past was a fragile way to install Rawhide, but with improved compose processes since Fedora 24 and automated testing since Fedora 23, their quality has improved substantially and this will often result in the best experience.


Point installer to Rawhide

You can sometimes install Rawhide by using a stable install media and pointing it to the Rawhide repositories for packages to install. In the past this was sometimes considered a more reliable method than using a Rawhide compose, but with improvements to the compose and test process in the last few years this is rarely likely to be a good choice any longer. If you wish to try it, however, you can:

  1. Download the latest stable or branched install media (network install or offline ("DVD") installer image)
  2. Copy to local media (USB or DVD or CD)
  3. Boot media and go to the 'Installation Source' screen and manually enter: https://download.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/x86_64/os/ (or i386 for 32-bit)
  4. 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 existing stable install

You may use DNF_system_upgrade to upgrade from the most recent stable release. You will need to have such an install in place and should definitely update to the newest updates before starting. As an exception, if you are using a immutable variant like Silverblue, you may use rpm-ostree rebase to perform the upgrade, see Fedora Docs for more details.

This method may fail if there are upgrade path issues (newer packages in stable or than Rawhide), or broken dependencies.

Depending on the release schedule, it might happen that your system doesn't yet have updated GPG keys for Rawhide. Then the upgrade process might exit with an error regarding missing/unknown GPG keys (right after the download phase). If that's the case, look for updates in updates-testing:

sudo dnf update fedora-release\* fedora-repos\* fedora-gpg-keys --enablerepo=updates-testing

If that doesn't help, run the upgrade with --releasever=NN (where NN is the release number of current Rawhide) instead of --releasever=rawhide. As the last option (which really shouldn't be needed, and puts your system at risk), you can upgrade insecurely by appending --nogpgcheck.

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.

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 included in the compose attempt. 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). If any release-blocking image fails to build as part of the compose, the compose is considered to have failed. If the compose completes successfully, the compose will be 'synced out' to the mirror system. (A system where the sync only happens if a set of automated tests run on it passes is planned, but not yet fully implemented). 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:

sudo dnf config-manager --set-disabled rawhide,rawhide-modular

sudo dnf config-manager --set-enabled fedora,fedora-modular,updates,updates-modular,updates-testing,updates-testing-modular

sudo dnf distrosync

sudo reboot

This will work for systems most recently updated before branch, or those after branch with mixed release packages.

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: Are rawhide packages signed?

A: They are. All of them are now signed. Make sure you have gpgcheck=1 set in your repo file to take advantage of this.

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 downgrade
    • dnf history
    • dnf update --skip-broken
    • koji 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.