Autoyast FAQ - Frequently Asked Questions

Questions

1. Autoyast

2. SUSE Linux general

Answers - Autoyast

1.1 How do I invoke an autoinstallation?
On all SUSE Linux versions, the automatic installation gets invoked by adding autoyast=<PATH_TO_PROFILE> to the kernel parameter list. So for example adding autoyast=http://myserver/myconfig.xml will start an automatic installation where the profile with the autoyast configuration gets fetched from the webserver myserver.
Look here for details and/or read my "AutoYaST for beginners"-blogpost.

1.2 What is an autoyast profile?
That's the autyast configuration file. In the autoyast profile you have to configure how the system should look like that you want to install via autoyast. So, which Software will be installed, how is the partitioning, what is the root password and so on. Nearly everything you can configure with yast, can also be configured in an autoyast profile. The profile format is an ASCII XML file.

1.3 How do I create an autoyast profile?
You can use the graphical user interface from the yast control center (misc/autoinstallation) or you can run yast2 autoyast from the commandline or you can use your favourite Text/XML Editor.

1.4 What is smallest autoyast profile that makes sense?

SLES9 / SUSE Linux 10.1 and older

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

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

<?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>

1.5 I have an already installed system. Can I create a profile based on that system?
Yes, that's possible. On the already installed system, start "yast2 autoyast" and choose from the menu: Tools -> Create Reference Profile. That will generate an XML file based on the current system. You can use that XML file to reinstall the machine.
On the command line you can use "yast clone_system" which will create a file named autoinst.xml in the /root directory.
Be careful with those cloned profiles, especially if you want to use them for a different machine. They are more a suggestion that you should modify to your needs.

1.6 How do I do an autoinstallation with autodetection of my soundcard?

<sound>
    <autoinstall config:type="boolean">true</autoinstall>
    <configure_detected config:type="boolean">true</configure_detected>
</sound>

1.7 I want to install from CD only. Where do I put the autoyast profile?
put it to the root of the CD. Refer to it with file:///...
For some SUSE Linux versions, you have to add install=cd then too, to the kernel parameter list. For some reason yast forgets that it installs from CD when the autoyast parameter is in use.

1.8 I want to use the same profile for IDE and SCSI harddisks
Don't specify the <device> in the autoyast profile for your <drive> section. Autoyast will try to guess the device then which works well in many cases (see also my blog)

1.9 How can I test a merging process on the commandline?
if you want to merge a.xml with base.xml, do the following:

/usr/bin/xsltproc --novalid --param replace "'false'" --param dontmerge1 "'package'" --param with "'a.xml'" --output out.xml /usr/share/autoinstall/xslt/merge.xslt base.xml

1.10 Is there a way for persistent network device names?
On SLES10 you can use a chroot script to simulate that:

   <scripts>
       <chroot-scripts config:type="list">
          <script>
             <chrooted config:type="boolean">false</chrooted>
             <filename>udev_config.sh</filename>
             <interpreter>shell</interpreter>
             <source><![CDATA[
#
# simulate behaviour of /lib/udev/rename_netiface to
# create udev config files like in comment #11
#
# FIXME: might only work on i386/x86_64
#        check if "grep HWaddr" really catches all we need
#

UDEV_FILE="/mnt/etc/udev/rules.d/30-net_persistent_names.rules"
DATE=`date`

echo "# autogenerated by autoyast chroot script" > "$UDEV_FILE"
echo "# $DATE" >> "$UDEV_FILE"

for INTERFACE in $(ls /sys/class/net|grep -v lo); do
   MAC_ADDR=$(ip  addr show $INTERFACE|grep link|grep -v loop|awk '{ print $2 }' | tr '[:upper:]' '[:lower:]')
   echo -n "SUBSYSTEM==\"net\", ACTION==\"add\", SYSFS{address}==\"$MAC_ADDR\", " >> "$UDEV_FILE"
   echo "IMPORT=\"/lib/udev/rename_netiface %k $INTERFACE\"" >> "$UDEV_FILE"
done
]]>
             </source>
          </script>
       </chroot-scripts>
  </scripts>

on SLES11 you can use:

<networking>
  <net-udev config:type="list">
      <rule>
        <name>eth0</name>
        <rule>ATTR{address}</rule>
        <value>00:50:56:bb:52:3f</value>
      </rule>
  </net-udev>
...
</networking>

for linuxrc you can use udev.rule="mac=de:ad:00:00:be:ef,name=eth1" and you can pass multiple of those like udev.rule="...,name=eth0" udev.rule="...,name=eth1" udev.rule="...,name=eth2"

the bnx2(x) driver has the problem, that it takes ages (up to 60s) for him to raise up the network device. Until then, no network is available. That can disturb the automatic installation. First of all, if your installation source is on a network device, YaST can not connect that installation source. That issue was fixed for SLES10 SP2 (see bugzilla).
Still there are problems when you have init-scripts with a <location> that requires network (like HTTP, FTP,...) because after configuring the network device by autoyast, it take another 60 seconds to raise the device and the <location> is evaluated after the network configuration. As a workaround you have to add an inline post-script that waits for 60 seconds:

   <scripts>
       <post-scripts config:type="list">
          <script>
             <network_needed config:type="boolean">false</network_needed>
             <filename>wait.sh</filename>
             <interpreter>shell</interpreter>
             <source><![CDATA[
sleep 60
]]>
             </source>
          </script>
      </post-scripts>
      <init-scripts config:type="list">
          <script>
             <location>http://.....</location>
             ...
          </script>
      </init-scripts>
   </scripts>

that script will wait 60 seconds and then network should be available and the remote init-scripts can be fetched.
If you need network in your init-script too, then you have to wait again for 60 seconds or so in your init-script.

I know, that sucks but the driver is broken and the description above is just a workaround for a broken network device driver.

When cloning a system with a bridged network, the AutoYaST profile doesn't include udev rules for persistent names of network devices. This is because physical eth devices (attached into bridge) are unconfigured.
To keep their persistent names you should write that rules into profile manually (look here for details.)

1.13 Can I call zypper from scripts?

yes you can but only from AutoYaST init-scripts. Because during the post-script phase, YaST still has a lock on the RPM database

1.14 Is the order in the AutoYaST profile important?

actually the order is not important. You don't change the AutoYaST workflow by reordering the elements in the XML file. If you want to merge different XML files into one like with "rules" or "classes", it's better to have the elements in alphabetical order but that's only because of the merging process.

1.15 How can I register against my SMT server?

do it like this:

<suse_register>
  <do_registration config:type="boolean">true</do_registration>
  <reg_server>https://mysmt.mydom.de/center/regsvc</reg_server>
  <register_regularly config:type="boolean">false</register_regularly>
  <submit_hwdata config:type="boolean">true</submit_hwdata>
  <submit_optional config:type="boolean">true</submit_optional>
</suse_register>

1.16 linuxrc blocks the installation with "File not signed". I have to manually answer that

linuxrc found some unsigned file (like a driverupdate). If that's okay for you, you can suppress that message by passing insecure=1 to the linuxrc parameter list (that's where you set autoyast=... too)

1.17 the registration part works on SLES11 but not on SLES10 (or vice versa)

on SLES10 it's called:

<customer_center>
...
</customer_center>

<suse_register>
...
</suse_register>

Answers - General SUSE Linux

2.1 What is the layout of a SLES9 installation server with Service Pack?
here is the layout of a SLES9 installation server with service pack. If you recreate that by hand, it should work. You can leave out the ARCHIVES.gz, INDEX.gz and ls-lR.gz you can see in the tree. For all I known, they are not important on that level. The yast directory with it's two files is very important:

> tree -L 2
.
|-- boot -> sles9-i386/CD1/boot
|-- content -> sles9-i386/CD1/content
|-- control.xml -> sles9-i386/CD1/control.xml
|-- core9-i386
|   |-- ARCHIVES.gz
|   |-- CD1
|   |-- CD2
|   |-- CD3
|   |-- CD4
|   |-- CD5
|   |-- INDEX.gz
|   `-- ls-lR.gz
|-- driverupdate -> sles9-sp-i386/CD1/driverupdate
|-- media.1 -> sles9-i386/CD1/media.1
|-- sles9-i386
|   |-- ARCHIVES.gz
|   |-- CD1
|   |-- INDEX.gz
|   `-- ls-lR.gz
|-- sles9-sp-i386
|   |-- ARCHIVES.gz
|   |-- CD1
|   |-- CD2
|   |-- CD3
|   |-- INDEX.gz
|   `-- ls-lR.gz
`-- yast
    |-- instorder
    `-- order

> cat yast/instorder
/sles9-sp-i386/CD1 /sles9-sp-i386/CD1
/sles9-i386/CD1 /sles9-i386/CD1
/core9-i386/CD1 /core9-i386/CD1
/
> cat yast/order
/sles9-sp-i386/CD1 /sles9-sp-i386/CD1
/sles9-i386/CD1 /sles9-i386/CD1
/core9-i386/CD1 /core9-i386/CD1
/

2.2 How do I get a console during the installation and where are the Logfiles?
For a textconsole press CTRL+ALT+F2. YaST Logfiles can be found in /var/log/YaST2/. The y2log contains the most information about what autoyast is doing. You can use scp to copy the files to another machine.

2.3 Is there a length limit on the line of parameters passed to linuxrc using the boot menu (kernel command line)?
Yes, there is a limit, I am not sure what is it though (someone telling me it is 256 but it might be hardware dependant and even boot media dependant like there might be a difference between PXE and DVD booting).
To avoid trouble, use an info file with all parameters. Make sure all the URLs to the installation source and to the profile are short. Use symlinks or aliases instead of specifying the complete path. Any keyword on the command line that is beyond the allowed length will be ommited.
The length limit was changed with SLES10 SP1 to at least 512 character (hardware and boot media dependent).

2.4 How do I add own RPMs to a SLES10/SLES11 and post-openSUSE 10.1 installation source?
I'll describe two options here to do that.

YUM Repositories

mkdir -p updates/i586
cp myUpdate.rpm updates/i586/
createrepo updates

YaST Repositories

cd myOriginalSUSE_InstallSource
./create_update_source.sh .
mkdir -p ./updates/suse/i586
cp -a myPackage-2.3.44.5-6.i586.rpm ./updates/suse/i586
cd updates/suse
create_package_descr -x setup/descr/EXTRA_PROV
cd setup/descr
ls > directory.yast
# the following two steps are required since openSUSE 11.0
cd ../../..
create_sha1sums -x -n .

How to tell AutoYaST about the new repo

<add-on>
  <add_on_products config:type="list">
    <listentry>
      <media_url>http://192.168.66.1/SLES10/updates</media_url>
      <product>SuSE-Linux-Updates</product>
      <product_dir>/</product_dir>
      <name>MyUpdates</name> <!-- available since openSUSE 11.1/SLES11 (bnc#433981) -->
    </listentry>
  </add_on_products>
</add-on>

#:/space/SLES10 # tree -L 1
.
|-- ARCHIVES.gz
|-- COPYING
|-- COPYING.de
|-- COPYRIGHT
|-- COPYRIGHT.de
|-- ChangeLog
|-- INDEX.gz
|-- LICENSE.TXT
|-- NEWS
|-- README
|-- README.BETA
|-- README.BETA.DOS
|-- README.DOS
|-- add_on_products
|-- boot
|-- content
|-- control.xml
|-- directory.yast
|-- docu
|-- dosutils
|-- gpg-pubkey-0dfb3188-41ed929b.asc
|-- gpg-pubkey-1d061a62-427a396f.asc
|-- gpg-pubkey-307e3d54-44201d5d.asc
|-- gpg-pubkey-3d25d3d9-36e12d04.asc
|-- gpg-pubkey-9c800aca-40d8063e.asc
|-- ls-lR.gz
|-- media.1
|-- pubring.gpg
|-- suse
`-- updates

#:/space/SLES10 # cat add_on_products
http://192.168.66.1/SLES10/updates

If your add-on is on a device, the add_on_products file looks like this:

hd:/updates?device=/dev/sdb1 /

With that file on the installation source, you don't need to specify the additional installation sources in the autoyast profile.

You can mix those two options. So it's possible to specify one installation source in the autoyast profile and another one in the "add_on_products"-file.
Of course official add-on products like the SDK are handled in the same way. The URL in the add_on_products file might look like this then "http://192.168.66.1/SLES10/sdk/CD1"

if you add own, unsigned RPMs, you should also read the section about signature handling with autoyast and signature handling with add-ons in the documentation.

With openSUSE 11.1/SLES11 the add_on_products file is deprecated. Use add_on_products.xml instead which is a replacement for the add_on_products file mentioned above. That add_on_products.xml is not a part of your autoyast XML profile. I wrote a bit about it in my blog

2.5 How do I setup a SLES10 installation server?

mkdir -p sles10/CD{1,2,3,4}
mount -o ro,loop SLES-10-CD1.iso /mnt
cp -rv /mnt/* sles10/CD1
umount /mnt

install=http://..../sles10/CD1

cd updates
gpg --export --armor $KEY_ID > content.key
gpg -b --sign --armor content
ls -F > directory.yast

  <general>
    <signature-handling>
      <accept_unknown_gpg_key config:type="boolean">true</accept_unknown_gpg_key>
    </signature-handling>
    ...

unpackInitrd initrd
cd /tmp/work-initrd
gpg --export --armor $KEY_ID > my-key.gpg
find . | cpio -H newc -o > /tmp/initrd
gzip /tmp/initrd
mv /tmp/initrd.gz /place/for/initrd

2.7 Can I put an add-on product onto the first CD?
yes, you can do that. Copy your CD1 to the harddisk and create the add-on product like described in 2.4. If you want to use the add_on_products file, you must use cd:///updates as pointer to your add-on.
To create a new CD do:

mkisofs -R -o /tmp/CD1.iso -b boot/i386/loader/isolinux.bin \
       -c boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table .

2.8 How to create a mini boot CD?
A simple boot CD can be created like described below. You can change the file isolinux.cfg in the boot/i386/loader/ directory to add an autoyast=.... parameter.

mkdir /tmp/minicd
cp -a /srv/ftp/mounted-isos/sled10-i386/boot/i386/loader/* /tmp/minicd
cd /tmp/minicd
mkisofs -o /tmp/minicd.iso -b isolinux.bin -c boot.cat
       -no-emul-boot -boot-load-size 4 -boot-info-table
       /tmp/minicd
k3b -cdimage /tmp/minicd.iso

2.9 What is the layout of a SLES10 installation server with Service Pack?
there is no special layout. SP1 contains all packages - a remastered SLES10 if you want so.
The inst-server for SP1 and/or SP2 is created in the same way like a SLES10 one. Just copy the CDs/DVD to disk.

2.10 How do I add own RPMs to a SLES11/openSUSE 11.2 installation source?
It's like for SLES10 but in addition, read my blog.