Why to Confirm?

"To err is human, but to really foul things up requires a computer." - Paul Ehrlich

y2confirm - the proposal screen

Sometimes it happens that something in the autoyast process does not work like you expect it to work. Like an add-on product is not added or the partitioning looks different than you expected it to look like. What to do now? How to debug the autoinstallation process? That's something I want to shed some light onto now.

If you use a fully automatic installation, it's a good start to turn on the confirmation of the proposal screen like this:

<general>
    <mode>
        <confirm config:type="boolean">true</confirm>
        ...
    </mode>
    ...
</general>

if you don't want to change your profile (for example because it's on a read only media) you can use y2confirm on the kernel parameter command line. So before the kernel and initrd are loaded, add "y2confirm" (either in your PXE config or in the boot menu of the installation DVD). That will make autoyast stop too at the proposal screen before anything has happened (except for your pre-scripts which are already executed at that time) and you can take a look at what autoyast wants to do - you can even change values and if you press the "ok" button, the autoinstallation continues with your changed values.
y2confirm also changes the starting process of the services in the second stage - you can confirm/reject every single service in the second stage then
... anyway... back to stage 1 ...
Imagine you have problems with the software selection because of a failed resolver run, you'll see a red "Software" link in the proposal screen then. Click on that and confirm the software selection then again. A popup will raise up that'll show you the resolver error message.
You can see all added respositories on the Software screen too, so you can check if your add-on section works like expected. That's how the proposal screen might help you to get closer to the root of the problem - click on everything that is red ;)

Log Files
"The logs - the answers are all in the logs" (Wietse Venema - author of postfix)

If you can not get any further interesting information from the proposal screen that helps you to track down your problem, it's time to start to dig in the dirt now. Switch to the console via "CTRL+ALT+F2" and change to the /var/log/YaST2/ directory. There are multiple log files but the y2log file is the one with the most information about the autoinstallation process but there are special log files from the software resolver too. The y2log file might scare you and you need to know what you are looking for (like an url of an add-on) to find anything useful at all and it makes no sense to read the y2log from the beginning to the end.
When you are in stage2 (after the first reboot) you'll find the y2log from the first stage file in "/var/log/YaST2/y2log-1".

Installation via SSH
If I want to repeat first stage tests without rebooting after each test, I add:

usessh=1 nosshkey sshpassword=a

to the linuxrc parameter list (the same place that I mentioned above where you have to add "y2confirm"). Yast will not start then but I can login via "ssh -X" and start it on my own by entering "yast". I can terminate yast as often as I want via"CTRL+c". Keep in mind that when you terminate yast after the partitioning is done, and you want to restart it, you have to umount and "swapoff" the used partitions. The ssh way requires network of course and you can find a list of linuxrc parameters here.

I have splitted this blog post into two parts because it got too large. Read the second part next week.

Happy bug squashing now! :) See you next week ...

au revoir, Uwe Gansert

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