First of all, what is a “Product”? The openSUSE Wiki has the following statement on the Product Definition Article:

“A product is a defined set of packages plus extra information”

In the most simple interpretation this means a set of RPM files plus a set of metadata which contains the installation kernel, information about the installation work flow, hardware detection, languages, licenses, slide shows and the like.

Thus the most simple product imaginable is a basic set of RPM files for the system to be installed and a minimum set of metadata: an installation system consisting of kernel, initrd and the packages necessary for installation.

kiwi

The kiwi imaging system allows creation of all kinds of live media: live DVDs, CDs, USB sticks and VMware and XEN bootable images. Those images are extremely useful for systems where a regular setup of equal hosts is required. The build client farm of the openSUSE Build Service is just one popular example.

kiwi is used in several popular projects, among which you can find several project based live DVDs, terminal server, thin clients and preload images. It is also relatively easy to create a personal custom image to boot different machines from USB stick or live CD, for instance to fix crashed machines and save or recover data.

kiwi-instsource module

A weakness of the images is that it is not possible to install from them as easy and complete as it is from installable media. The reason therefore is the way in which the image is created. As explained in depth in the official kiwi documentation (available from the project web site and delivered with the kiwi-doc package) kiwi creates a so called root tree (“physical extent”) where packages are installed into. After finishing the installation an image (“logical extent”) is created from that root tree. The same root tree can be used for multiple image types (usb, iso, xen, …) and can even be tweaked manually after the physical extent is created.

This means several things. First of all, the installation process makes choices. It is not possible to have conflicting packages installed in parallel and hence there is no choice later (in case there is no other installation source available). Secondly, the system can only install on one compatible platform. Which means you can’t use a x86_64 image to boot and install an i386 machine. And only with regressions vice versa.

All those problems are solvable by using an installation source. This term refers to official online repositories (such as openSUSE:11.1), product media (boxes, downloadable iso images) and update channels.

These repositories were created by the autobuild team in the past and are created by kiwi-instsource as imaging back end in the openSUSE Build Service since openSUSE-11.1. In principle everybody can brew his or her own linux distribution that way. I presented several talks on that topic, one on FOSDEM 2008 about imaging in general, then an interim talk which was held in the Nürnberg SuSE office and is available through tube.opensuse.org, and finally about installation source creation on FOSDEM 2009.

All three talks were recorded and can be found at [1] and [2].

kiwi-instsource is a subpackage to kiwi and maintained in the openSUSE:Tools build service project [3]. Its devel project is my home project at home:helcaraxe [4].

FOSDEM Talk

Preparing and delivering this talk was really fun, thanks a lot to all attendees. I was amazed how many people attended the talk, the openSUSE DevRoom was nicknamed openSAUNA later. It is always very interesting to know possible users and contributors face to face. I met several people I knew from mailing lists before and we got some nice discussions on what is needed in the community.

Please feel free to comment on that.

One mayor feedback to me is that we have to document what needs to be done to customise installation sources. I will add some information to the openSUSE wiki at this article: Installation_Source

FOSDEM is always a great event, thanks to all the organisation around it. Unfortunately I could not attend as many talks as I intended but got at least to the ext4 talk and the syslinux talk on the main track and some of my colleagues’ talks in the openSUSE DevRoom.

Plus I discovered some very nice locations for dinner and good belgian beers thanks to the people of the X.org team.

Further Reading

[1] FOSDEM talks linked in openSUSE Wiki: FOSDEM 09, FOSDEM 08

[2] Interim talks aggregated in openSUSE Wiki

[3] Development project for kiwi in Build Service: openSUSE:Tools

[4] My home project in Build Service: home:helcaraxe

[5] My user page: User:helcaraxe

A colleague dropped by and asked me what kind of power supply were sufficient for a certain machine. I thought “ok, let’s just ask lshal|grep battery
My hope was that the hardware would not only measure the voltage of the battery but also the current drained from it.

What I found was kinda funny from an Electrical Engineer’s point of view:

So what? “voltage.current”? Voltage? Or current? Or multiplied?

After laughing a bit I thought seriously about bug report, but it isn’t a bug apparently.
I find those things funny, can’t help it. I therefore consider this an Easter Egg of HAL.

Still, if anyone knows if a laptop can tell me the current current (SCNR), let me know.

Cheers,
Jan

• BuildService Repositories
• mounted DVDs
• FTP trees

But what if you have a local Build Service building some binary only packages and you wish tp make a installable media set from, say, “SLES + binary only drivers”?
You can use the inter-BS-Connectivity feature to only build the drivers (and not the whole distribution) in your BS and then create an installation source from your main BS project.

This is possible since release of the package kiwi-instsource which extends the functionality of the config.xmlfile to allow the compilation of an installation source from scratch.
Hereby “scratch” means directories containing .rpm and .spm files. Of course some information must be provided for the metadata creation — but this is also all in the config file (with one known exception — the PDB data).

The rest is figuring out which packages must be on the installation source.
Since it is perfectly ok to have conflicting packages in instsources, there is no dependency check or package resolving in this stage. The information must come from the user.

Therefore the package list may become rather long and I already plan to implement some simplification.
These plans include:

• allowing more than one <repopackages> section
• implement outsourcing blocks in separate files using XML functionality