(update to match current kickstart) |
m (markup) |
||
Line 64: | Line 64: | ||
It happens quite often that you need to include some bleeding-edge packages that have already been built in [[Koji]], but they haven't been pushed to any of the repositories (''fedora'', ''updates'' or ''updates-testing'') yet, or they haven't hit your mirror yet. | It happens quite often that you need to include some bleeding-edge packages that have already been built in [[Koji]], but they haven't been pushed to any of the repositories (''fedora'', ''updates'' or ''updates-testing'') yet, or they haven't hit your mirror yet. | ||
If the packages are already available on the [http://dl.fedoraproject.org/pub/fedora/linux/ master mirror], but not yet on your local mirror, you can overwrite the <code>repo</code> definitions to force using the master mirror: | * '''If the packages are already available on the [http://dl.fedoraproject.org/pub/fedora/linux/ master mirror], but not yet on your local mirror''', you can overwrite the <code>repo</code> definitions to force using the master mirror: | ||
{{#tag:pre| | {{#tag:pre| | ||
repo --name=fedora --baseurl=http://dl.fedoraproject.org/pub/fedora/linux/development/$releasever/$basearch/os/ | repo --name=fedora --baseurl=http://dl.fedoraproject.org/pub/fedora/linux/development/$releasever/$basearch/os/ | ||
Line 72: | Line 72: | ||
Please use this only when necessary. Don't stress our master mirror needlessly. | Please use this only when necessary. Don't stress our master mirror needlessly. | ||
If your package builds are not available even on the master mirror, just in Koji, you need to download them, create a custom repository and use it in your kickstart file. Example: | * '''If your package builds are not available even on the master mirror, just in Koji''', you need to download them, create a custom repository and use it in your kickstart file. Example: | ||
<ol> | <ol> | ||
<li>Download the packages: | <li>Download the packages: |
Revision as of 08:36, 3 May 2013
Creating a Test Day Live Image
The following steps outline how to create a Fedora live image based on current Fedora Branched packages for use during Test Days. This is mainly intended for Fedora QA team and teams that host a Test Day. Of course these teams can also use a nightly compose image, but special Test Day images bring additional benefits - a welcome screen with an easy access to test day channels (web, chat), smaller size and customizability.
How to build a Test Day Live image:
- Install
livecd-tools
from the same or higher release that you intend to build the image for. If you want to build a Fedora 42 live image, you need to install the.fc42
package or later. Usually you can install it and run it on an older release (Fedora 41) just fine. If that doesn't work, you will need to install Fedora 42 first:yum install livecd-tools --releasever=42
- Download the kickstart script used by Fedora 42 by using the
f42
git branch:yum install git git clone 'git://git.fedorahosted.org/spin-kickstarts.git' -b f42
or if you have done it in the past, just update it:
cd spin-kickstarts; git checkout f42; git pull; cd ..
The Test Day kickstart is located at
spin-kickstarts/custom/qa-test-day.ks
. - OPTIONAL: If you need some changes related to your Test Day (some packages pre-installed or some default configuration adjusted), either modify
qa-test-day.ks
(it is well documented) or create a new kickstart file, includeqa-test-day.ks
and put in your changes. This is an example of my-test-day.ks:%include spin-kickstarts/custom/qa-test-day.ks # Point repositories to a local mirror repo --name=fedora --baseurl=file:/mnt/globalsync/fedora/linux/development/$releasever/$basearch/os/ repo --name=updates --baseurl=file:/mnt/globalsync/fedora/linux/updates/$releasever/$basearch/ # Enable updates-testing (from the Internet) repo --name=updates-testing --mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=updates-testing-f$releasever&arch=$basearch %packages # List of packages to be added or removed - dependencies are handled packageYouWant wildcardedPackagesYouWant* @GroupYouWant -packageYouDontWant (unless something else requires it) %end %post # Put any shell commands here, they will be executed in a chrooted environment %end
More kickstart documentation is available at Anaconda/Kickstart.
- Create the live image:
livecd-creator -c spin-kickstarts/custom/qa-test-day.ks --releasever 42 --cache /var/cache/live -f testday-YYYY-MM-DD
(of course replace spin-kickstarts/custom/qa-test-day.ks with my-test-day.ks if you have created your custom kickstart file)
Further tips
Using unreleased or custom packages
It happens quite often that you need to include some bleeding-edge packages that have already been built in Koji, but they haven't been pushed to any of the repositories (fedora, updates or updates-testing) yet, or they haven't hit your mirror yet.
- If the packages are already available on the master mirror, but not yet on your local mirror, you can overwrite the
repo
definitions to force using the master mirror:
repo --name=fedora --baseurl=http://dl.fedoraproject.org/pub/fedora/linux/development/$releasever/$basearch/os/ repo --name=updates --baseurl=http://dl.fedoraproject.org/pub/fedora/linux/updates/$releasever/$basearch/ repo --name=updates-testing --baseurl=http://dl.fedoraproject.org/pub/fedora/linux/updates/testing/$releasever/$basearch/
Please use this only when necessary. Don't stress our master mirror needlessly.
- If your package builds are not available even on the master mirror, just in Koji, you need to download them, create a custom repository and use it in your kickstart file. Example:
- Download the packages:
koji download-build NVR
- Create a repository from the contents of the current directory:
createrepo -v .
- Share the repository over HTTP, FTP or NFS. One of the easiest way is:
python -m SimpleHTTPServer
Now your repository is available at http://localhost:8000. - Include the repository in your kickstart:
repo --name=test-day --baseurl=http://server/path
- If the packages are included by default, their new versions will be picked up automatically. Otherwise you need to list them:
%packages package1 package2 %end
Using a non-debug kernel
In Rawhide and in Fedora 42 before Beta the debug kernels are used by default. That lowers the system performance considerably. If you need performance rather than kernel debug information, you can manually add a production (non-debug) kernel to the Live image.
The information how to distinguish a production and a debug kernel is outlined in KernelDebugStrategy. The easiest way is to search Koji for a list of kernels built for your Fedora release and pick the latest one that contains kernel-debug RPM (the presence of this RPM indicates this is a production kernel, i.e. the debug information are separated). If this kernel is available in one of the repositories, you can simple put kernel NVR into the %packages
section, like this:
%packages kernel-3.9.0-0.rc7.git3.1.fc42 %end
Very often, however, a production kernel will not be a part of any repository and you'll need to download it manually from Koji and put it into a custom repository first.