imag(in)e AutoYaST

"Come to the edge.
We might fall.
Come to the edge.
It’s too high!
COME TO THE EDGE!
And they came,
and he pushed,
and they flew."
Christopher LOGUE

Since openSUSE 11.1 you can use the deploy_image element to use the pre-defined images of openSUSE. I have written an article about that a few weeks ago already. It's very easy to use and can speed up your installation remarkable but it's a bit inflexible.
Today I want to show you an experimental feature of AutoYaST that is available since a few releases and is a lot more flexible and a lot faster too. I did an installation of a kde4 system and measured the time from the proposal screen until the reboot happened and here are the numbers:

kde4 system with RPMs only	1051 RPMs	19 minutes
kde4 system with pre defined images	1051 RPMs	13 minutes
kde4 system with a kiwi image	1031 RPMs	3,5 minutes

All systems were about 2,8GB in size.

What you have to do for that is to create an image that AutoYaST dumps on the harddisk instead of installing RPMs. You specify it like
this in the AutoYaST XML file:

<software>
  <image>
    <script_location>http://10.10.0.162/image.sh</script_location>
    <run_kickoff config:type="boolean">true</run_kickoff>
  </image>
</software>

The kickoff is needed to configure the bootloader.

You can't configure any packages or patterns anymore, because all software has to be in your image. Here comes the image.sh I have used for my test:

#!/bin/sh
# if you don't want to deal with the fstab,
# you can also remove that file from your image
# so the one created by autoyast is not overwritten
# by your image extraction
mv /mnt/etc/fstab /tmp/
wget -O - http://10.10.0.162/kiwi_image.tgz 2>/dev/null| tar xfz - -C /mnt
mv /tmp/fstab /mnt/etc

as you can see, the script AutoYaST will run fetches an image from a HTTP server and pipes it into tar, which will extract it into the /mnt directory. The /mnt directory is the directory where your freshly partitioned and formated system is mounted to during the installation.
So the last question to answer is, how to create such an image? Well, the way you create an image is up to you because AutoYaST can do all kind of things in the script but in my case, I have used kiwi. Install the following packages:

kiwi-desc-usbboot
kiwi-desc-vmxboot
kiwi-pxeboot-prebuild
kiwi-instsource
kiwi-pxeboot
kiwi-tools
kiwi-desc-xenboot
kiwi-doc
kiwi-config-openSUSE-11.1
kiwi-desc-isoboot
kiwi
kiwi-instsource-plugins-openSUSE-11-1
kiwi-desc-oemboot
kiwi-desc-netboot

not all of them are needed but it can't hurt to install them all. Then do (as root):

cp -a /usr/share/doc/packages/kiwi/examples/suse-11.1/suse-oem-preload .

and edit the XML file in that directory. All I did was changing the location of my installation source, removed the example user (I let autoyast configure the users) and changed the patterns to install to "kde4". Then call:

kiwi --prepare ./suse-oem-preload --root /space/kiwi_image

This will take a while and kiwi will install the complete system into that directory. When it's done, all you have to do is to tar that directory into the kiwi_image.tgz tarball and put it on your webserver. Of course you can do all kind of changes to that before you tar it (like removing /etc/fstab, which is created by AutoYaST anyway)

Try it out, create yourself a nice image ;)
Keep in mind that this is still an experimental feature but a nice one to play with :)
Feedback is appreciated.

ahoj Uwe

The minimum profile

"All The Small Things" - Blink 182

On SLES9 the smallest AutoYaST profile had to contain a partitioning and a software section (well, and a user section with a root user if you wanted to login). On SLES10 the software section was no longer required because AutoYaST has chosen a very small system to install (only the base pattern) if no software section was there.
Now, on openSUSE 11.1/SLES11 not even the partitioning section is required anymore. If you don't provide the partitioning information, AutoYaST will ask the storage code of YaST2 what it would suggest in a manual installation to the user and that suggestion is used by AutoYaST too then. Those suggestions are often quite conservative and YaST tries to keep other Linux/Windows partitions intact.

So on openSUSE 11.1 / SLES11 the smallest profile looks like this:

<?xml version="1.0"?>
<!DOCTYPE profile>
<profile xmlns="http://www.suse.com/1.0/yast2ns" xmlns:config="http://www.suse.com/1.0/configns">
    <users config:type="list">
        <user>
            <encrypted config:type="boolean">false</encrypted>
            <user_password>myrootpassword</user_password>
            <username>root</username>
        </user>
    </users>
</profile>

well, actually it looks like this:

<?xml version="1.0"?>
<!DOCTYPE profile>
<profile xmlns="http://www.suse.com/1.0/yast2ns" xmlns:config="http://www.suse.com/1.0/configns">
</profile>

but you can not login then.

You might say, "that's nice but where is the sense in a totally unconfigured system?" and you are right. There is not so much use in it. All I wanted to show with this article is, that you can try out AutoYaST without configuring a full blown XML file. Now you can start to fill that XML file with flesh step by step, section by section. Put it on an USB stick for example and add autoyast=usb:///my.xml to the boot menu of an openSUSE 11.1/SLES11 DVD and that's it. You just fired up an autoinstallation.

bye bye, Uwe

P.S.: don't forget to buy the latest Diary of Dreams album that is released today ;)

openSUSE 11.1 / SLES11 and add-ons

Today I want to take you on a little journey into the world of add-on repositories on openSUSE 11.1 and SLES11.
If you want to add an extra repository to your autoinstallation process, like a repository containing all updates or some self created RPMs, you have two options to do so. You can specify it in your autoyast XML file like this:

<add-on>
 <add_on_products config:type="list">
   <listentry>
     <media_url>http://192.168.66.1/11.1_install/updates</media_url>
     <product>SuSE-Linux-Updates</product>
     <product_dir>/</product_dir>
     <name>MyUpdates</name>
   </listentry>
 </add_on_products>
</add-on>

"Buddy, that's nothing new" you might say and you are right, because it's possible that way since SLES10 / openSUSE 10.1 and it's the easiest way to add an add-on.
The other option is something that has changed now and is a bit more complex but you don't have to specify the add-on in your autoyast XML file then.
In the past you could add a file called "add_on_products" to the root of the installation source. The format of that file was pretty simple - too simple for such a complex world maybe because it has changed to a way more complex XML format now. Look:

<?xml version="1.0"?>
<add_on_products xmlns="http://www.suse.com/1.0/yast2ns"
   xmlns:config="http://www.suse.com/1.0/configns">
   <product_items config:type="list">
       <product_item>
           <name>11.1 updates</name>
           <url>http://10.10.0.162/11.1_install/DVD1/updates</url>
           <path>/</path>
           <ask_user config:type="boolean">false</ask_user>
           <selected config:type="boolean">true</selected>
       </product_item>
       <!-- Another product item -->
       <product_item />
   </product_items>
</add_on_products>

The complete format description can be found here.
When you created that file, it's not as easy like just adding it to the root of the installation source to make things fly, because in SLES11 and openSUSE 11.1 every file on the installation source needs a checksum in the "content" or the "SHA1SUMS" file and those files have to be signed. Update for SLES11 SP1 and openSUSE 11.2: the checksum for add_on_products.xml and the add_on_products file is optional now. So if you use openSUSE 11.2 or newer or SLES11 SP1, you can skip the following steps!
I'll guide you through the process of using and signing an add_on_products.xml file now.

Step one is to create the XML file like described above and to copy it to the root of your installation source with the name "add_on_products.xml". Then you have to calculate the sha1sum of that file and store it in a file called SHA1SUMS like this:

sha1sum add_on_products.xml > SHA1SUMS

The file should look like this then (with a different sum of course)

taylor:/space/11.1_install/DVD1 # cat SHA1SUMS
a3813f6a5d64459b3727389bcf632c2038abc627  add_on_products.xml

okay, that was easy right? Now the SHA1SUMS file needs to be signed by your gpg key. I assume you already have a gpg key but if not, you can easily create one like described here. When you have your gpg key, you can sign the file by the following command with your private gpg key:

gpg -b --sign --armor SHA1SUMS

a file SHA1SUMS.asc will be created which contains the signature for the SHA1SUMS file. That means, if you change the SHA1SUMS file from now on, you have to recreate the SHA1SUMS.asc file too.
The installer needs to know your public gpg key now, so it can check the signature of that file. You need to add your public gpg key to the initrd AND you have to store it in a file called SHA1SUMS.key (yes, two places - I'd call that a bug). First of all you need to export your public gpg key like this:

cd /inst/source/openSUSE-11.1/DVD1/
gpg --export --armor $KEYID > SHA1SUMS.key
ls > directory.yast
cp SHA1SUMS.key my-key.gpg

$KEYID has to be replaced by your keyid. Mine is "30FC5F6B" for example and you can see all keys in your keyring by "gpg --list-public-keys". Your key will be in that list too and the id is in a line starting with "pub".

pub   1024D/30FC5F6B 2001-06-13
uid                  Uwe Gansert <ug@suse.de>
sub   1024g/55DBC73E 2001-06-13

now you have to add that key to the initrd in /boot/i386/loader/initrd on the DVD or on your tftp server for PXE booting. Add the key like this:

mv initrd initrd.gz
gunzip initrd.gz
find my-key.gpg | cpio -o -A -F initrd -H newc
gzip initrd
mv initrd.gz initrd

You can take a breath now because you are nearly done :-). You can remove my-key.gpg if you want. The SHA1SUMS file is signed and the key is known to the installation system in the initrd and by the SHA1SUMS.key file. You can verify the content of the initrd by "cpio -it <>
gpg -b --sign --armor content

ATTENTION: don't accidentally overwrite the content.asc file in the root of your 11.1/SLES11 installation source or the conent.key file will not match anymore with the signature.

Congratulation! You made it!


bye, Uwe Gansert

remote files during autoinstallation

With AutoYaST you could always store complete files in the XML profile to save them somewhere into the installed system later. With openSUSE 11.1 and SLES11 you can specify the location of those file to a remote source like an HTTP server for example, so there is no need to store the files directly in the XML profile anymore.

  <files config:type="list">
    <file>
      <file_path>/bla</file_path>
      <file_location>http://10.10.0.162/file_test.txt</file_location>
    </file>
  </files>

The section is evaluated after the network configuration is done so start_immediately should be set to true for the needed network interface, which is the default anyway if it's not specified. Protocols are the same like for the AutoYaST profile (http(s), ftp, nfs, tftp, ...)
Here you can read more about the files section in AutoYaST.

post-patterns in AutoYaST

with openSUSE 11.1 and SLES 11 you can install patterns in stage 2 and not only in stage 1. For packages that was already possible since quite a while via
<post-packages config:type="list">
and now this configuration option got a sibling called ... surprise surprise ...
<post-patterns config:type="list">
here is the documentation.

YaUIc in AutoYaST 11.1/SLES11

"Yet another UI change" in the AutoYaST UI. After using the last UI change for a few hours, we came to the conclusion that there is some room for improvement and so we did a redesign again and now it looks a bit like the Mac OS Finder tableview which is another step forward for the usability of the AutoYaST UI.
I'm quite confident that we'll keep it that way this time ;-)

some AutoYaST UI changes

in openSUSE 11.1 and SLES11, there are some changes in the AutoYaST UI. First of all, the tree on the left was dropped to be more YaST control center like and all summaries of one section are collected on one page now. That means you save at least one click when jumping between modules ;)
The usage of the UI has changed a bit by this, like some buttons were replaced by Combobox Widgets.
Thanx to Martin Schmidkunz for the suggestion on how the UI should look like from a usability point of view and thanx to Sven Schober (a student in my team) for implementing it.



Another important change has happened in the validation dialog which shows the name of the section in the AutoYaST profile that has failed the validation now.
With jing installed you were always able to see which part of the profile is broken but now even with only xmllint installed you can at least see wich section failed.
Thanx to Sven Schober again for implementing this.

EVMS support dropped in SLES11

I'm back from my vacation in france and while checking my TODOs, I read that EVMS support was dropped for SLES11. That means today I dropped EVMS support from AutoYaST as well. AutoYaST will no longer be able to deal with EVMS during cloning or installing in SLES11. For SLES10 and the service packs of SLES10 it's still supported.
If you want to read more about EVMS in SLES11, look here.