Alright, well maybe not profit, but certainly fun!
I had mentioned in a previous post
about doing QA for Fedora, and having installation CD and DVD sets available prior to the general release of the distribution. All that Fedora Alpha, Beta, and Preview Release really is are just snapshots of the daily development tree of Fedora, rawhide. Sometimes, it might be useful to have a DVD, similar to what Fedora release engineering would produce, of the current rawhide. Now, I'm going to give a step-by-step of how to do this in 'mock', which is a program that you can use to manage chroot's. Mostly, it's used for building binary RPM's from source RPM's, however, it has grown functionality that make it useful for doing composes recently.
There are some things that pungi does that depend upon several things that make it very suitable to be run in a mock chroot. First, the distribution that you are composing and the distribution that you are composing on have to be the same, For instance, if you wish to compose rawhide, you have to be running rawhide (or at least have rawhide userspace). Also, the architecture that you are composing on and the arch that you are composing must be identical (you can't compose i386 on an x86_64 system, for example). Mock allows us to overcome both of these limitations (at least for compatible arches - i.e. x86_64 and i386). A mock chroot can have userspace that is very different from the host system, and so long as the arches are compatible, they can even be of a different arch (i.e. you can run i386 code on x86_64, but not the other way around, obviously).
The only thing that we have to do on the system that is going to produce the trees is to install the 'mock' rpm. This is as simple as typing 'yum install mock' at the command line. On my system, I also prefer to have the bash-completion package installed, because mock is 'completable' by that package, and the buildroot names can get kinda long sometimes (or am I just lazy?) :). After this is done, you need to make sure that the user that needs to use mock is in the 'mock' group. This is because being able to use mock is equivalent to having root on the machine in question, since mock is SUID (and has to be), You can accomplish this with 'gpasswd -a jstanley mock' for example.
The next thing that we need to do is initialize the chroot. This is very simply done by using 'mock -r (config) --init'. This brings up the question of which mock configuration to use. Mock comes with a number of pre-made configuration files. The ones that you're most likely to want to use 'fedora-rawhide-i386' or 'fedora-rawhide-x86_64'. These files live in /etc/mock, and the -r argument to mock takes them WITHOUT the trailing .cfg extension. If this is your first time running mock for this installroot, it will use yum to install the group 'buildsys-build' into the chroot. After that is done, it will tar up the root, and save it for future use. If you had used this installroot before, it would clean it (i.e. delete everything that was there), untar the root cache, and then run yum update to get items that were changed since the root cache was created.
Now we have a chroot with the desired content in it, we can install pungi. Wait a minute, this is in a chroot (and yum is not installed by default in this chroot), so how do I do that? Good thing mock has the '--install' option. So you just execute 'mock -r fedora-rawhide-x86_64 --install pungi', It won't output much at all, but it will install pungi and it's chain of dependencies. Now that we have pungi installed, we're ready to actually use it in the chroot! So let's get a shell in the chroot with 'mock -r --shell', which will give you the following output:
[jstanley@rugrat ~]$ mock -r fedora-rawhide-x86_64 --shell
INFO: mock.py version 0.9.7 starting...
State Changed: init plugins
State Changed: start
State Changed: lock buildroot
The 'mock-chroot>' is my shell prompt, reminding me that I am in the chroot. From here, we can use pungi. The reference kickstart files that release engineering uses to create the releases are included in the fedora-release package, and can be found in the /usr/share/fedora-release directory. The traditional DVD configuration, which is what you want to use, is called f9-fedora.ks (note that this just landed in the fedora-release package on Friday). One piece of housekeeping that needs to be done at this point in to remove the generated rpm database files. If you are building on your native arch, this isn't strictly necessary but still a good idea. If you are building i386 images on x86_64, not doing this is fatal.
mock-chroot> rm -f /var/lib/rpm/__db.00*
At this point, we can execute the pungi command:
mock-chroot> pungi -c /usr/share/fedora-release/f9-fedora.ks --destdir=/compose --nosplitmedia --nosource
I'll take you through what these options do:
-c - what kickstart file do you want to use to use for this compose
--destdir= - where should the compose happen. It's important to note that this is different from where on the non-chroot'ed filesystem you'll find it - remember that we're operating in a chroot here.
--nosplitmedia - I do not wish to generate split (CD-sized) media for this compose
--nosource - I don't want to gather source code for this compose. Note that you MUST NOT use this option if you plan on distributing the resulting discs. Note that by eliminaiting this option alone, source ISO's will not be created, that's an additional step that I'll mention below.
When you enter this command, pungi will go about four phases of operation:
- Gather the RPM's and SRPM's as required
- Create a yum repo out of those
- Run the anaconda 'buildinstall' tool to generate installation images, etc
- Create ISO's
Using a local mirror and a reasonably fast computer, this will take about 30 minutes. Note that every RPM that would be included on the DVD is downloaded, so having a local mirror REALLY helps here. Not a show-stopper if you don't have one, but it will take longer than 30 minutes :). One word of warning, though - when the compose gets to the point of running buildinstall, it will look like it's hung - this is the longest part of the compose. So if you see something like this and nothing more on your screen, it will finish:
Pungi.Pungi:INFO: Running /usr/lib/anaconda-runtime/buildinstall --product Fedora --version 20080503 --release "Fedora 20080503" --bugurl http://bugzilla.redhat.com /compose/20080503/x86_64/os
OK, so eventually, you'll see the following (among other things):
Pungi.Pungi:INFO: Running /usr/bin/sha1sum Fedora-20080503-x86_64-DVD.iso
Pungi.Pungi:INFO: Running /usr/bin/sha1sum Fedora-20080503-x86_64-netinst.iso
Pungi.Pungi:INFO: CreateIsos is done.
At this point, the DVD and netinst.iso have been created, and are inside of our chroot. To get at the chroot from the non-chroot'ed OS, it's located in /var/lib/mock/fedora-development-$YOURARCH/root - so everything that you did is located there. You can find the completed ISO's in /var/lib/mock/fedora-development-x86_64/root/compose/20080503/x86_64/iso for example.
I said earler that source ISO's are not created by default as part of the Create ISO's stage. In order to create the ISO's, you need to run pungi again against the same tree. Here's the syntax for doing that:
mock-chroot> pungi -c /usr/share/fedora-release/f9-fedora.ks --destdir=/compose --sourceisos --nosplitmedia
Again, eliminate the --nosplitmedia option if you want CD-sized ISO's created as well.