From Fedora Project Wiki

Rawhide 是 Fedora 开发版本的代号。这个版本包含了一个叫做 "rawhide" 的源并且包含所有每天最新构建的 Fedora 软件包。Nightly builds are also available during the early portion of the Fedora Release Life Cycle.

Rawhide 适用人群

Rawhide 版本适合那些喜欢更新并且能够自行解决问题的用户。否则请勿安装。

Rawhide 用户基本要求:

  • 愿意每日更新。Rawhide 每天都有上百更新,经常更新会更容易解决问题。
  • 愿意动手解决问题。Rawhide 的内容不少都存在问题,您需要有良好的解决问题素质和娴熟的报告问题能力。比如学会用 yum 来降级软件包和解决启动失败就是这之中的一部分。
  • 有时间和需求来学习新的功能和变化。因为 Rawhide 的软件包与上游联系密切,菜单、命令及选项都可能随时变化。
  • 经常重启来测试心得内核并确认启动功能是否正常。如果您不能做到,请换用其它更稳定的发行版。

您应该从 每日实时构建版下载页面 尝试 Rawhide 或者 Branched (取决于 发行周期) 而无需安装。如果您不想这么做,也可以找剩余空间来安装,或做双系统安装,以及虚拟机体验等等。

每日实时构建版

After the release of the previous final release, but before the Branch event, nightly builds will be composed of Rawhide packages. These are built automatically without manual tweaking or testing, so they will sometimes be beyond the size of a single CD, and sometimes may not work at all. If there is a bug in the generation toolchain, the images may not be built on a given night; in this case, the most recent image will remain available. Using these nightly builds is an ideal way to test Rawhide if you have no spare machine or partition available, or simply do not have the time to maintain a Rawhide installation. It's a very safe way to test, since it will make no changes to your installed system. You can also install Rawhide to your hard drive from the Live desktop if the Live image is working well for you. During the rest of the release cycle, daily builds will contain Branched content, and you must use a repository to install Rawhide - though you can build a custom spin using livecd-tools if you need to test a Live distribution.

访问 FedoraLiveCD 以了解更多。

安装 Rawhide

Rawhide 不可被直接安装。不过有这么几种方式可以让您体验:

使用包含 Rawhide 的镜像源

Rawhide 在 "development/rawhide" 目录下。您可以在 这里找到您附近包含 "development" 目录的镜像。 继续阅读以了解如何安装。

如何不影响已安装的系统

有几种测试 Rawhide 的方式:

  1. 用 CD, DVD 或 USB 驱动器来测试。
    • 有关刻录 CD 或 DVD,请见 刻录指南
    • 有关写入至 USB 驱动器,请见 How to create and use Live USB
    • 如果您使用启用永久储存的 LiveUSB,您可以使用下文描述的 "yum update" 方法来获取最新的 Rawhide RPM (除了内核)。注意您也可能需要安装 'fedora-release-rawhide' 包并启用 rawhide 源。不过,下载每日实时构建版是最好的选择。
  2. 使用虚拟机。请见 Testing/qemu
  3. 安装到独立的分区中。

通过 Anaconda 安装 Rawhide

Anaconda 是 Fedora 的安装器。它可被直接启动,无需运行 Live 环境。

通过 BFO (boot.fedoraproject.org)

您可以使用从 BFO 获取的安装文件,通过 yum distro-sync 完成预安装。BFO 镜像文件是一个让您进入安装环境的非常小的文件。

  1. 下载 BFO 启动介质: http://boot.fedoraproject.org/download
  2. 启动,选择 Installation 或 Pre-Release。选择您想使用的最新的安装器。
  3. 运行最小化安装。
  4. 预安装,通过 yum distro-sync:
# yum install fedora-release-rawhide
# yum --releasever=rawhide distro-sync

使用标准 ISO

您可以使用每个正式发布版本的 Anaconda 安装器进行安装,目前最新版本是 Fedora 41。通过这种方式,您将会使用一个稍微旧一些但是不会有安装问题的安装程序完成您的 Rawhide 安装。

选项 1 - 使用已下载好的一份拷贝
如果您手头已经有一个可自启动的 CD、DVD、USB,或者是包含 *-DVD.iso 或 *-disc1.iso 的磁盘驱动器,那么就可以使用它来完成您的 Rawhide 安装。不过如果您没有上述的任何一项,那么不推荐您通过该方式安装。因为您想安装 Rawhide 而不是正式版。请看 这里 了解如何下载拷贝。请不要使用 Live 镜像,因为它无法完成安装。
选项 2 - 下载最小化安装程序
如果您需要制作一个可自启动的 CD、DVD、USB,或者是硬驱动器,最好的方法就是下在最小化的 boot.iso 安装程序并通过网络获取安装需要的 RPM。这跟 *-netinst.iso(例如 Fedora-Fedora 41-i386-netinst.iso)一样。
获取方法:
* 前往 http://download.fedoraproject.org/ - 您会被自动跳转到离您最近的镜像。
* 进入 releases/41/Fedora 目录。
* Choose the directory for your architecture (i386, x86_64, or ppc - help available), then find os/images/boot.iso and download it.
* Create a bootable CD, DVD, USB media, or hard drive partition following the instructions here using your newly downloaded boot.iso file. You can use the livecd-iso-to-disk method described there even though boot.iso is not a Live image, and it should also work on hard drive partitions, not just USB media.
选项 3 - 没有启动介质的纯网络安装
完整安装指南见此
执行上述3个选项后需要做的事情
启动安装程序,然后按照屏幕提示继续。软件包组选择。反选所有 Fedora 41 的软件源,手动添加 rawhide 源。从 这里 获取可用的 rawhide 源。
选项 4 - 安装时无网络环境
如果是这样,您需要从 Rawhide 镜像源 下载 Rawhide (development) 目录,并使用 安装指南中指出的硬驱动器方式安装。如果您认为麻烦可以选择本页列出的其它方式。

通过 Live 安装器安装

时间决定一切
此方法只在 Fedora 41 发布后和 Fedora 42 发布分支版本前有效。请访问 Fedora 42 发行计划 了解准确时间。一旦被分支,请查看 被分支 页面的介绍。
Presence and viability of nightly images not guaranteed
The nightly images are built by a script with little human intervention. As generating an entire bootable and installable Fedora image is a fairly complex operation which requires a rather large subset of packages to be present, functional, and interoperable, they will quite often fail to install correctly, fail to boot, or fail to compose at all: you cannot rely on a recent image being available, or any given image actually providing a usable installation. This is quite normal.
  1. Download a daily Live image (.iso) from http://alt.fedoraproject.org/pub/alt/nightly-composes/
  2. Follow the steps at How to create and use Live USB or How to create and use a Live CD to prepare and boot from the image you select.
  3. Log in and double click the Install to Hard Drive icon on the desktop.
  4. Follow the on-screen instructions to complete the installation.

Yum update from a stable release or pre-release

As an alternative to a direct installation of Rawhide, you can install an existing stable release or pre-release and try to upgrade to Rawhide using yum. When a pre-release is available, Rawhide corresponds to the following release: when Fedora 41 Alpha is available, the Rawhide repositories contains what will become Fedora 42. As with any method of installing Rawhide, success is not guaranteed. If you cannot get a direct installation to work, the yum method may work; on the other hand, if you cannot get a yum upgrade to work, try the direct installation method (above) instead.

It is generally best to start from the most recent release available, even if this is a pre-release: only use a stable release if no pre-release of the following version is yet available, or you cannot get the pre-release to install.

If a test release or "pre-release" (Alpha or Beta) is currently available, you can download it here. Otherwise, you can download the latest stable release here.

You may run into dependency problems which could take time and manual effort to resolve: if the upgrade refuses to proceed, look carefully at the errors yum reports and consider appropriate action (often, you need to remove a few problematic packages to let the rest of the system update). Remember that Rawhide installations in general may need to be wiped and re-installed from scratch at any time.

You can upgrade to the rawhide repository one of two ways. The most reliable is to use the command line method from a console; this avoids the case where an update causes the X server to crash or restart, killing the yum process in mid-upgrade as a consequence. The results of this case are usually sub-optimal.

图形界面

以 GNOME 桌面和 gnome-packagekit 为例 - 其他桌面请自行找类似程序:

  1. 添加/删除程序 (gpk-application),安装 fedora-release-rawhide
  2. 下一步,使用 软件设置 (gpk-prefs) 修改软件源
    • 启用 Fedora - Rawhide
  3. 最后使用软件更新开始更新 (gpk-update-viewer)

命令行

首先请使用 yum-config-manager --disable 来禁用所有非 'fedora-rawhide' 源,然后:
# yum --releasever=rawhide install fedora-release-rawhide
# yum --releasever=rawhide distro-sync

某些情况下可能需要您手工禁用 gpg 签名检查功能。加上选项 --nogpgcheck 即可。

如果您启用了某些第三方源,上述操作可能会失败,这是由于在这些源中没有 'Rawhide' 分支。这种情况下,请您手动禁用它们。

如果您无法安装 fedora-release-rawhide,您可以直接下在 RPM 安装,包位于:development/rawhide/<arch>/os/Packages/ (例如:wget http://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/i386/os/Packages/f/fedora-release-42-0.2.noarch.rpm)

测试 Rawhide

所有 Rawhide 的测试者需要做几件事。首先请阅读 test 邮件列表,所有 Rawhide 讨论都在这里。You'll find discussion of significant changes and warnings of severe breakage here. Reading test-list daily is key to staying on top of Rawhide. Secondly, report all the bugs you find in Rawhide to Bugzilla. Remember to file bugs according to these best practices. Please remember that bugs should always be filed in Bugzilla. Reporting bugs on the mailing list or IRC is not sufficient, as these reports rapidly become lost in history. Only on Bugzilla will they always be accessible to other testers and to the developers.

Beyond that, here is some general advice which may be of use in using Rawhide:

  • Approach the test release as a valuable chance to learn more about your system. There is a good chance you will run into some bugs in subsystems or components that you are unfamiliar with as part of the testing process. Use this an opportunity to learn more about that particular subsystem and become familiar with its documentation. Even documentation has bugs, by following up and trying to learn from the documentation you might be able to help clean up badly worded or out of date documentation as well. The more you learn, the more effective you will be in the future if you participate in the development process again. Be as proactive as you can about reading about how things work and you will have a much more valuable experience overall.
  • When using yum, take the time to review the list of package actions before you proceed. Don't disable the review step.
  • Become familiar with the /var/log/rpmpkgs and /var/log/yum.log log files.
  • Get a notebook and make notes about system configuration changes you make. Many problems can be traced to simple configuration errors, but can appear as package update bugs. When working with other testers to confirm the problem, make notes as to the other changes you have made since the last update/reboot can be invaluable in tracing the problem down accurately.
  • Keep at least one older kernel that you are confident works as expected.
  • Reboot daily, to test to see if any of your updates have affected startup. Its much more difficult to track down a boot up problem that was caused by an old update if you are updating daily but have not rebooted.
  • Become familiar with useful grub features for troubleshooting boot up failures.
  • Don't force or nodeps any package to work around dependency problems. Instead, report them as bugs or to test-list. If no-one reports these problems, they will never get fixed, and will persist into stable releases.
  • Because the development tree is not guaranteed to be internally consistent every day, you will frequently see yum update fail with errors. Don't Panic, most dependency problems will be fixed by the developers in one or two days - sometimes simply by requesting more package rebuilds. If you see a dependency problem with yum update on your system for several days in a row, and see no discussion of it on test-list, see below to decide how you should report it or if a report is necessary.
  • If there is one error (such as a package depending on an old library) holding you back from a full Rawhide update, you can use yum update --skip-broken to update all other packages. However, make sure the error has been reported to the maintainer of the offending package.
  • You might need to disable GPG checking in /etc/yum.conf or the fedora-devel repository in /etc/yum.repos.d if packages are incorrectly signed.
  • Take advantage of downloading packages from koji and using 'yum downgrade' to help isolate package updates that caused issues and work around them until they are fixed.

何时报告更新问题

A daily build report of the development tree sent to the test and the devel every morning as part of the automated push of packages out to the publicly accessible trees. The daily report contains information about new, removed and updated packages. It also contains a summary of known dependency problems for each arch for which the development tree is built. If you experience any problems updating against the development tree the first thing you should review is the last two or three build reports. If you are seeing a dependency problem summarized in the latest build report, you can be sure the developers are aware of the problem. Package maintainers receive daily emails when their packages are on this list.

Note that the broken dependency list, which is part of the daily rawhide reports, only provides the first layer of dependencies and not the entire list, this saves build time. Unlisted packages might also be affected, but fixed when one or more of the listed packages are rebuilt.

If, however, the problem lingers longer than a few days on your system, and the problem package is not listed in the daily report, that could be an indication that you have run into a situational bug that not everyone is seeing. This is when you can spring into action as a tester and make a difference. But, before you file a new bug report there is a short recipe you can follow to avoid filing unnecessarily. Please remember that test releases exist primarily to help the developers identify problems so they can be fixed in time for release. Unfortunately, reactionary bug filing of duplicate or well known issues can take developer time away from actually fixing issues.

  1. Read test and devel: Go back into your archives or the web archives for fedora-test-list and read over the threads for the last 48 hours and see if there has been any discussion about the specific update errors you have been seeing. Generally, these sorts of errors are seen by most everyone with similar hardware, so there's a very good chance that other testers are already discussing it. Please don't post a new post to test until after you have reviewed the last 48 hours worth of posts. Having multiple discussions about the same issue is a drain on other testers and developers.
  2. Search Bugzilla: Search to see if there are any reports about the update issue you have seen.
  3. Drop a note into fedora-test-list: Please start a new thread only after you have attempted to find a previous discussion of this problem in the test-list or in bugzilla. Other testers can help you confirm the problem. If they can't confirm it they can help you determine if its a configuration problem or user error on your part. The test-list is a great way to obtain assistance from other more experienced testers, but please do what you can to use the archives responsibly to avoid duplication of information and discussion.
  4. File a new bug report: If the exact nature of the dependency problem during updating is lingering for several days, or if the problem seems specialized to your situation and it doesn't appear that the developer is aware of this problem, file a new bug. If you are unsure how to file, experienced testers in fedora-test-list can make suggestions. Please don't assume its a yum bug. Most dependency issues are packaging bugs in one of the packages detailed in the error messages.

什么是 "降临 Rawhide"?

Rawhide 每天自动从最新的软件包中生成。头一天构建的软件通常第二天会出现在 rawhide 源中。原理上构建过程会完成于美国东部时间午夜 0400/0500 UTC。

什么叫做 Rawhide "push"?

一个 Rawhide push 简单来讲就是一个每天会自动生成的 Rawhide 定制版。如果偶然这个 push 坏了,系统会生成更多的 push。

如何报告发现的 Rawhide 问题?

通过 test 邮件列表或 #fedora-qa[?] IRC 频道。如果是 bug,请报告至 Bugzilla,注意对应版本为 rawhide。

如何获知 Rawhide 的变动?

每天所有变动都会通过邮件发送至 testdevel 邮件列表,主题叫做 'rawhide report: <date> changes'。 这些报告会包含被添加/被移除/被更新(附带更新日志)的软件包,还会伴随一个问题损坏依赖关系列表。

一些有用的资源: