More Timeouts for AutoYaST

Run, Lola, Run!
a famous german movie

Today I want to introduce you some new timeouts you can configure in AutoYaST.
On openSUSE 11,2 you can use timeouts in two new places.

• The feedback popups of your scripts can timeout now if you want


• The ask-dialogs can timeout now too

So even with feedback and ask-questions, you can now have a non-stop installation.
How does it work? Lets start with the feedback dialogs:

<script>
 <source>
<![CDATA[
echo "this feedback will timeout"
]]>
 </source>
 <feedback config:type="boolean">true</feedback>
 <feedback_type>message</feedback_type>
 <debug config:type="boolean">false</debug>
</script>
...
<report>
  <messages>
    <log config:type="boolean">false</log>
    <show config:type="boolean">true</show>
    <timeout config:type="integer">5</timeout>
  </messages>
</report>

This is an ordinary AutoYaST script which makes use of the feedback mechanism and there is nothing special with it except for the new feedback_type. This type can be "message", "warning" or "error" and if you are experienced with AutoYaST, you might notice that these are the same values that you can configure timeouts for in the <report> section.
Your scripts will timeout like you configure it in the report section if you specify a feedback_type for them.
Without that feedback_type, the old behaviour of a blocking popup is used.

On ask dialogs it works a bit different:

<ask>
  <title>Password: root</title>
  <path>users,0,user_password</path>
  <question>Password for root</question>
  <password config:type="boolean">true</password>
  <default>lousypassword</default>
  <timeout config:type="integer">20</timeout>
</ask>

You can configure the timeout in seconds for each dialog and if the user does not answer the dialog in time, it will continue with the assumption that the default value is wanted.
Without that <timeout ...>, the old behaviour of a blocking ask-dialog is used.

Run, AutoYaST, Run!

au revoir, Uwe

One string to rule them all ...

... one string to find them
Lord of the Rings (almost)

On openSUSE 11.2 I did a little change with the handling of how AutoYaST looks for the profile on devices. Currently you have to do it this way:

autoyast=device://sde2/mydir/myprofile.xml

to find the profile on /dev/sde2 in the path /mydir/myprofile.xml.
On openSUSE 11.2 you can use one string to find a profile on every device AutoYaST can find. So with:

autoyast=device:///mydir/myprofile.xml

AutoYaST will look for the profile on every device it can mount and will stop looking when the profile is found. Take care that you use three slashes if you want to use that feature. The old syntax with naming the device still works of course.
Actually that can even make the autoyast=usb://myprofile.xml superfluously because USB devices are found and mounted too with the new feature. I'll still keep the old USB syntax for a while but I might change the code underneath the veil to use the new "devices://" code.

Ciao! - Uwe

Two AutoYaST Features by One Char

and the star char is - The Slash!

Feature 1:
On openSUSE 11.2, if you add a "/" at the end of a filename in the <files> section, AutoYaST will create a directory:

<files config:type="list">
  <config_file>
    <file_path>/myData/</file_path>
    <file_permissions>644</file_permissions>
  </config_file>
...
</files>

Maybe nothing which makes the crowd go wild but might be useful from time to time and saves you from writing a script just for that.

Feature 2:
That's a bit more impressive than the first. If you use a "/" at the beginning of a <package> or <pattern>, you tell AutoYaST to interpret it as a regular expression like this:

<software>
  <patterns config:type="list">
    <pattern>/.*_server</pattern>
  </patterns>
  <packages config:type="list">
    <pattern>/kde4.*</pattern>·
  </packages>
</software>

Beware of using <package>/.*</package> because that will select every package and some of them conflict.

happy slashing ;) - Uwe

AutoYaST and LVM striping

A less known fact of the AutoYaST LVM configuration is, that it can do striping too. The reason for that being less known might be, that I just documented it a few weeks ago, even though that feature was available since ages.
If you now say "I want that!!! What is it good for?" you can read this article. In a nutshell, with striping you spread the harddisk IO across multiple physical devices which increases the IO performance but also the risk of data loss, so never use that without a RAID system below.

How to use that in AutoYaST? Just configure the number of physical devices and the blocksize in KB like this:

<drive>
 <device>/dev/data_vg</device>
 <is_lvm_vg config:type="boolean">true</is_lvm_vg>
 <type config:type="symbol">CT_LVM</type>
 <partitions config:type="list">
  <partition>
   <filesystem config:type="symbol">ext3</filesystem>
   <lv_name>my_data_lv</lv_name>
   <mount>/data</mount>
   <stripes config:type="integer">2</stripes>
   <stripesize config:type="integer">4</stripesize>
   <size>10G</size>
  </partition>
 </partitions>
 <pesize>4M</pesize>
 <use>all</use>
</drive>

That's the same like you would do without striping, except for those two keys:

<stripes config:type="integer">2</stripes>

which is the number of physical devices you use. And:

<stripesize config:type="integer">4</stripesize>

which is the size of a block in KB. So after writing 4kb the physical device will be switched.
That's all you need to activate striping on a logical volume.


happy striping - Uwe

Keep what you got

Let's say the docs present a simplified view of reality...
Larry Wall

Recently I got a bugreport against SLES11 by a customer who uses an undocumented a secret feature of AutoYaST that is quite fancy. It's hidden in the <networking> section and that option can not be configured with the UI. It's called:

<keep_install_network config:type="boolean">false</keep_install_network>

unfortunately that feature is broken on openSUSE 11.1 and SLES11 (that's why there was a bugreport) but will be fixed for openSUSE 11.2 and maybe on SP1 for SLES11.
What does it do? Well, actually you can take it literally. A networking section like this ...

<networking>
  <keep_install_network config:type="boolean">true</keep_install_network>
</networking>

... will keep the network configuration that was created by linuxrc by doing an installation of the system over a network. linuxrc will raise the network then to connect the installation source and with that boolean set to true in the XML file, AutoYaST will copy that network configuration into the installed system. So if the network configuration during the installation is the same you want in the running system, you don't have to configure it in the XML file. Just set that boolean to true and you'll keep your installation network in the running system.

Thanx to Bubli and Michal for supporting me with that bug.

au revoir - Uwe

A new kind of Script

I love flying. I've been to almost as many places as my luggage.
Bob Hope

Since openSUSE 11.2 (not in SLES11) you can use a new kind of script called "postpartitioning-script". That script runs between the pre-scripts and the chroot-scripts after the partitioning is done by autoyast and the system is mounted to /mnt. The fstab is written too but nothing is installed yet, so the system is quite empty currently (and can not be called "system" actually at that stage).
You can mount something into the system for example that was not specified in the XML file but is required during the installation.
The script definition in the XML file is very similar to the other scripts:

<postpartitioning-scripts config:type="list">
    <script>
        <filename>postpart.sh</filename>
        <interpreter>shell</interpreter>
        <debug config:type="boolean">false</debug>
        <feedback config:type="boolean">true</feedback>
        <source><![CDATA[
touch /mnt/a_test
echo Hi
]]>
        </source>
    </script>
</postpartitioning-scripts>

have a nice weekend, Uwe

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