Frequently Asked Questions

If you have issues during auto-installing a client it does not always mean that it is autoyast related. AutoYaST relies on many general installation components and thus, some problems might be general installation problems. During auto-installation, almost all problems perior the start of yast2 are linuxrc related. For example, if the installation source can't be found, then you have to check the kernel command line variables, (i.e. install) which are used by linuxrc to fetch the installation image (boot/root).

If yast2 starts and a problem occurs, most likely it is an autoyast issue and has to be reported as such. The control file is retrieved by yast2 and not by linuxrc as with releases perior to 8.0.

You can do that using XML XInclude. XInclude is an emerging W3C specification for building large XML documents out of multiple well-formed XML documents, independently of validation. Each piece can be a complete XML document, a fragmentary XML document, or a non-XML text document like a Java program or an e-mail message.

XInclude reference external documents to be included with include elements in the http://www.w3.org/2001/XInclude namespace. The prefix xi is customary though not required. Each xi:include element has an href attribute that contains a URL pointing to the file to include. For example, if you want to have all scripts out of the main profile, you can have them on a remote machine or make them available on the machine being installed and reference them from within the control file. Note that the profile is parsed only once at the beginning of the installation, so the scripts have to be available during initial system and autoinstallation setup.

The following is a section of a profile showing the scripts section:

                        <?xml version="1.0"?>
<!DOCTYPE profile SYSTEM "/usr/share/autoinstall/dtd/profile.dtd">
<profile xmlns="http://www.suse.com/1.0/yast2ns" 
xmlns:config="http://www.suse.com/1.0/configns" 
xmlns:xinclude="http://www.w3.org/2001/XInclude">
  <configure>
.
   <scripts>
      <chroot-scripts config:type="list">
        <script>
          <filename>chroot.sh</filename>
          <interpreter>shell</interpreter>
            <xinclude:include href="http://192.168.1.1/profiles/includes/chroot_sh.xml" />
        </script>
      </chroot-scripts>
    </scripts>
.
  </configure>
.
</profile>
                    

On the remote side, which is in this case a web server, you will have the included version in a file chroot_sh.xml which will contain the missing portion you want to include, for example:

                        
<source>
<![CDATA[#!/bin/sh

echo "This is a script"

]]>
</source>

                    

When including complex portions of the control file, you have to pay attention to adding the namespace to the included file.

Range is not supported for IPs. To make that happen with 9.0 however, you can always use you own script in the rules which you can match. For example I can use this rule to match the boardinfo of my old thinkpad:

                        
<rule>
    <custom1>
       <script>
<![CDATA[
#!/bin/sh
board=$(hwinfo --bios | grep -A 4 "Board Info" | grep Product | cut -d'"' -f 2 | sed -e "s/[<|>]//g" )
echo -n $board
]]>
       </script>
       <match>2628JXU</match>
       <match_type>exact</match_type>
    </custom1>
    <result>
       <profile>thinkpad.xml</profile>
       <continue config:type="boolean">false</continue>
    </result>
</rule>
                    

So you have to write a script that will output the latest segment of an IP and do a range checking, i,e, on 210-240.

so it will result in something like that(not tested):

                         

   <rule>
        <custom1>
            <script>
<![CDATA[
#!/bin/sh
ip=$(/sbin/ifconfig eth0  | sed -n "s/\(inet\ addr:\)\([0-9.]*\).*/\2/p" | cut -d'.' -f 4)
echo -n $ip
]]>
            </script>
            <match>210-240</match>
            <match_type>range</match_type>
        </custom1>
       <result>
            <profile>thinkpad.xml</profile>
            <continue config:type="boolean">false</continue>
        </result>
    </rule>
                    

Of course you can add other rules such as these to match the subnet and the network, etc.

Well, you can call an external script from the script themselves, however, you have to make the scripts available to the system somehow and the easiest solution is to include the scripts into the control file.

Yes, there is a limit, I am not sure what is it though (someone telling me it is 256).

To avoid this, 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.

To make YaST retrieve the control file from a directory, i.e. by naming the control file with the hex IP (for example C0A80103) and to make it default to a file named default in that directory, you have to add the trailing slash,

autoyast=http://192.168.1.1/profiles/
                        

All fixes are provided in the driverupdate image available with SP3. One has to make sure the file or the contents of the file (linux subdirectory) is available in the root of the source.

No, All fixes are already provided in the driverupdate file.

This is a known issue with SLES8 and is a general problem and not autoyast related. This is issue has been resolved with SP3. Make sure you have the driverupdate in the root of the source and boot using the kernel/initrd from SP3.

Use SLES8 SP3 kernel, initrd and driverupdate.

This is a general issue and can also be used when installing manually.

The process of creating driver updates and adding new modules is described in the Update Media Howto