Softpanorama

May the source be with you, but remember the KISS principle ;-)
Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and  bastardization of classic Unix

SUSE AutoYaST

News

 Recommended Books Recommended Links Autoinst file Sample Autoinst file Setting up an installation server
Installation from ISO Image  Installation Checklist   RPM Humor Etc

Autoyast uses the same concepts as Solaris Jumpstart and its replica in Linux world -- the Red Hat Kickstart. The main problem with it (other then bugs and it is pretty buggy) is  bad, outdated documentation.  Actually it is not simply bad, it is horrible. So do not expect to succeed if you use just Novell documentation. It is just impossible. Some pages on the Internet are more helpful and dramatically increase your chances of success. See Recommended Links. Actually I see the quality of Autoyast documentation as a serious problem for SLES as this is key functionality in enterprise deployment. It is clear that Novell brass made a huge blunder not allocating enough resources to making this functionality robust and providing good documentation. 

General capacities of Autoyast are pretty standard, the only unique feature is that it is uses XML file to store settings: 

The file used for storing information about installation is called the XML control file or profile.  The profile can reside on:

To initiate installation which uses autoyast file you need to specify keyword autoyast in Grub, for example

autoyast=http://10.2.3.4/autoyast_dell.xml network=1

In case of HTTP you also need to create an HTTP server. See Setting up an installation server.

If you specified parameters correctly and networking parameters were aqured by installed from DHCP (or set in the command line) are lucky, the GRUB command line variable autoyast  causes linuxrc  to start in automated mode. 

Doing this the first time it is important to watch installer mini-OS booting messages.  For that press Esc when install started. You will see if DHCP fails or not and if installed was able to read autoyast file.

Doing this the first time it is important to watch installer mini-OS booting messages.  For that press Esc when install started. You will see if DHCP fails or not and if installed was able to read autoyast file.

Note

If just directory was specified, then linuxrc searches for a special configuration file (info file), which is a different type of file from autoyast profile. That's confusing, but this is how autoyast is architectured.  This file is useful for completely automated installs of multiple servers.

All linuxrc parameters instead of special file can be specified on the command line. In case you do not have DHCP on the segment those parameters include hostip, netmask and gateway

Keyword Value
netdevice Network device to use for network setup (for BOOTP and DHCP requests)
server Server (NFS) to contact for source directory
serverdir Directory on NFS Server
hostip When empty, client sends BOOTP request, otherwise client is configured with entered IP configuration.
netmask Netmask
gateway Gateway
nameserver Nameserver
insmod Kernel modules to load
autoyast Location of the the control file for automatic installation, i.e. autoyast=http://192.168.2.1/profiles/
install Location of the installation directory, i.e. install=nfs://192.168.2.1/CDs/
instmode Installation mode, i.e. nfs, http etc. (not needed if install  is set)
y2confirm Even with <confirm>no</confirm> in the profile, the confirm proposal comes up (available since SUSE Linux 10.1/SLES10).

Advanced Network SetupΆ

The netsetup  keyword allows advanced network configurations and enables dialogs to setup the network where required.

netsetup  can have the following values: dhcp, hostip, gateway, netmask, nameserver. nameserverN asks for N nameservers (max. 4).

For example, the following can be entered on the command line:

netsetup=-dhcp,+nameserver3

Command Line Variables for AutoYaSTΆ

The GRUB command line variable autoyast  can be used in the format described

Command line variable Description
autoyast=default Default auto-installation option.
autoyast=file://<path> Looks for control file in specified path (relative to source root directory, i.e. file:///autoinst.xml  if in the top directory of a CD-ROM and you did an installation from CD).
autoyast=device://<device>/<file> Looks for control file on a storage device (only device name needed without full path, i.e. /dev/sda1 is wrong, use only sda1 instead). Since openSUSE 11.2 (not SLES11) you can omit specifying the device and trigger AutoYaST to search all devices (autoyast=device:///my.xml).
autoyast=floppy://<path> Looks for control file on a floppy (useful when booting from CD). Since SLES10 SP1 and later the fallback is looking on USB devices.
autoyast=nfs://<server>/<path> Looks for control file on <server>
autoyast=http://[user:password@]<server>/<path> Retrieves the control file from a web server using the HTTP protocol.
autoyast=tftp://<server>/<path> Retrieve the control file via TFTP.
autoyast=ftp://[user:password@]<server>/<path> Retrieve the control file via FTP.
autoyast=usb://<path> (since SLES10 SP1) Retrieve the control file from USB devices (AutoYaST will search all connected USB devices).
autoyast=relurl://<path> (since openSUSE 11.0) Retrieve the control file from the installation source (install=....).
autoyast=label://<label>/<path> (since openSUSE 11.3, not SLES 11) Searches for control file on a device with the specified label

With all AutoYaST invocation options, excluding default, it is possible to specify the exact location of the control file:
autoyast=http://192.168.1.1/control-files/client01.xml

A sample command line to invoke the installation using AutoYaST from an NFS server follows. Enter this line at the GRUB prompt: 

install=nfs://IP_ADDRESS_OF_NFS_SERVER/NFS_PATH/CD1 autoyast=nfs://IP_ADDRESS_OF_NFS_SERVER/NFS_PATH/sample-autoyast.xml

Profile enables very granular control of the installation process. If used properly, you can do a fully automated, hands-free installation. If you happen to miss an item that the installation needs, it stops the installation at that portion and prompts you to enter what it needs. Items, such as disk partitioning, LVM and RAID, software selection, and others, can all be defined in the profile.

The configuration profile for the server is typically created during installation. At the end of the installation process you need to ensure that "Clone System for AutoYaST" was checked and completed. The file is saved to /root/autoinst.xml.  Unlike Jumpstart and Kickstart there is no way to update it automatically as you change the server but you can write scripts to do that.

Creating autoyast from existing server configuration

This is a useful feature of autoyast: selective cloning of the existing server configuration. This is where XML file shines as a configuration storage medium, as editors for XML file are easy to write and generally belong to a pretty established software domain.

Yast contains such a specialized editor for XML file which among other things allow you to create parts of an autoinst.xml file from the existing configuration of the server.

The editor is part of YaST. To invoke this editor you need to start the YaST2 with the command: 

yast2 autoyast

You will now be presented with a window that allows you to configure most of your installation options as if you were installing a new machine or performing an upgrade.  There is a possibility to close options and then edit them.

You can proceed through the menu system configuring your options for a particular system or set of similar systems that you wish to automatically install.

Alternatively, you can create class definitions which allows you to save different parts of the configuration setup and then use different classes for different sets of machines.

The use of classes is particularly good when you have a set of systems that are similar but that you would like installed in slightly different ways. For example, you could create a class definition for the hardware setup of all your client machines and create a separate class for the packages you want installed on them, whether they are server machines, test machines, workstations, etc. You can then choose which classes are used by which machines when they are installed. In our example here, all the machines would use the same hardware setup, but the workstation machines could install our workstation class of packages, test machines the test class, etc.

Once you have progressed through each configuration screen in the config setup GUI from YaST2 you are ready to save out your configuration file to disk. When you save your configuration files they will be stored locally in two different locations depending on what file you have created as follows:

Top Visited
 Switchboard
Latest
Past week
Past month

NEWS CONTENTS

Old News ;-)

[Mar 26, 2012] Network Install HOWTO SuSE Client Install

Create A Basic Config File

Once you have confirmed that you have the AutoYaST packages installed on your system, you can now start to create configuration files. For most situations the basic configuration described here will be sufficient to perform your installations.

Start the YaST2 Autoinstall configuration GUI with the command: 

yast2 autoyast

You will now be presented with a window that allows you to configure most of your installation options as if you were installing a new machine or performing an upgrade. You can proceed through the menu system configuring your options for a particular system or set of similar systems that you wish to automatically install. Alternatively, you can create class definitions which allows you to save different parts of the configuration setup and then use different classes for different sets of machines.

The use of classes is particularly good when you have a set of systems that are similar but that you would like installed in slightly different ways. For example, you could create a class definition for the hardware setup of all your client machines and create a separate class for the packages you want installed on them, whether they are server machines, test machines, workstations, etc. You can then choose which classes are used by which machines when they are installed. In our example here, all the machines would use the same hardware setup, but the workstation machines could install our workstation class of packages, test machines the test class, etc.

Once you have progressed through each configuration screen in the config setup GUI from YaST2 you are ready to save out your configuration file to disk.

NOTE: it is outside the boundaries of this document to take you through each configuration option for installation, we are just concerned with the principles of network installs here. Please consult your SuSE documentation or the SuSE Website for this information.

When you save your configuration files they will be stored locally in two different locations depending on what file you have created as follows:

Advanced Config File Setup

Before attempting advanced configuration please make sure that you have first created a valid basic configuration file as described above. It is perfectly possible to create your own configuration files from scratch but it is far easier to use the tools provided to do the job for you!

Once you have your configuration file saved, you can open it in your favourite text editor. The file is in XML format so it is particularly easy to follow and edit manually. You can use or modify any of the existing tags in your file, just so long as the tags, options, and syntax you use are legal. A full guide to the tags and their usage can be found in the AutoYaST manual, please see Appendix A of this guide for a reference.

The best use of editing the configuration file manually is probably for adding your own customised packages to the installation. Back in the SuSE Server Setup section we describe how to add your own customised packages to your install server. Here, we describe how to access those packages using the configuration file so they can be automatically installed with the rest of the system.

You should be able to locate a <software> section in your basic configuration file in your editor. You can use a sub-tag inside the software section called the <extra_packages> tag which can be used as in the following example: 

<software>
        <extra_packages>
                <package_location>
                        custom
                </package_location>
                <packages config:type="list">
                        <package>{Your package name}</package>
                        <package>{Another Package}</package>
                </packages>
        <extra_packages>
        <base>Default<base>
<software>

The package location is written as custom which describes the directory under the suse directory of you install server where you have put your custom packages, in our example this would be /install/suse/custom, but you only need to write custom here.

You can include as many package tags under the packages section as you wish. Use one package tag for each custom package you want to include in your config file and install on the client machine.

The base tag at the bottom should be left as you configured it during the basic configuration.

Save your modified configuration file from your text editor and it will then be ready to use in your installations as described below.

[Jul 01, 2011] SUSE Studio Using AutoYaST for customizing your appliance on first boot

When building appliances with SUSE Studio, I was often challenged with finding a way to configuring an appliance on first boot. The most common use cases like locale, time zone and network configuration are being offered by Studio already.

Selecting these options will make Studio include the required packages and configuration to guide the user through a YaST workflow on first boot.

But is there an easy way for further customizing your application on first boot? Yes, there is! Enter AutoYaST and it's powerful "Ask the user for values during installation" feature.

Switch to the Configuration tab, select Scripts and check the "Run AutoYaST profile on appliance's first boot" option.

Next we need to create the AutoYaST profile, which will be run on first boot. The profile format is an ASCII XML file.

Here is a simple example, that will create a simple ask dialog "Enter the user for this machine" and prompt for input. The result will be written to /tmp/answer_user. 

<?xml version="1.0"?>
<!DOCTYPE profile>
<profile xmlns="http://www.suse.com/1.0/yast2ns" xmlns:config="http://www.suse.com/1.0/configns">
  <general>
    <ask-list config:type="list"> 
      <ask>
        <question>Enter the user for this machine</question>
        <default></default>
        <help>Enter your novell userID</help>
        <title>userID</title>
        <file>/tmp/answer_user</file>
        <stage>cont</stage>
      </ask> 
    </ask-list>
  </general>
</profile>

Now let's look at a more complex profile, that uses a script to validate the users input. This technique can also be used to process the users input and e.g. change config files accordingly. 

<?xml version="1.0"?>
<!DOCTYPE profile>
<profile xmlns="http://www.suse.com/1.0/yast2ns" xmlns:config="http://www.suse.com/1.0/configns">
  <general>
    <ask-list config:type="list">
      <ask>
        <dialog config:type="integer">20</dialog>
        <element config:type="integer">20</element>
        <help><![CDATA[
              <p><b>Virtual IP address</b><br>Enter the IP address
matching the Virtual Hostname for your system.</p>
]]></help>
        <file>/tmp/ay_q_virt_ip_addr</file>
        <question>Enter (virt.) IP-Addr</question>
        <stage>cont</stage>
        <default>10.0.0.1</default>
        <script>
          <filename>chk_virt_ip.sh</filename>
          <rerun_on_error config:type="boolean">true</rerun_on_error>
          <environment config:type="boolean">true</environment>
          <source><![CDATA[
function check_ip() {
        local ip=$1 tmp phys_ip

        [ -z "$ip" ] && echo "You must provide a valid IP address!" &&
return 1
        [ "${#ip}" -lt 7 ] && echo "Is this a valid IP address? You
entered only '${#ip}' chars." && return 1
        [ -n "${ip//[0-9.]/}" ] && echo "An IP address can only
contain digits and dots ('.'). Found this: '${ip//[0-9.]/}'." &&
return 1
        tmp="${ip//[0-9]/}"
        [ "${#tmp}" -ne 3 ] && echo "An IP address can only contain 3
dots." && return 1
        [ "${phys_ip}" = "${ip}" ] && echo "The virt. IP address has
to differ from the phys. IP address ($ip)." && return 1

        return 0
}
check_ip "$VAL"
]]></source>
          <debug config:type="boolean">false</debug>
          <feedback config:type="boolean">true</feedback>
        </script>
      </ask>
    </ask-list>
  </general>
</profile>

Deploying SUSE Linux using autoyast

Whitepaper about deploying blades creating installation sources, an example autoyast file, using partitioning, LVM, YOU, Nagios, LDAP, SAN.

Automatic Installation Environment for SLES9

This lab shows how to setup an automatic SLES9 installation environment, using PXE to start the boot and install process across the network. All the setup is done without user intervention. From the booting up process, components and packages selection, to the final stages and customization.

SUSE - Uwe Gansert - autoyast - autoinstall

This is a brief overview of the changes in autoyast between SUSE Linux 10.2 and SUSE Linux 10.3 There are more fixes and features in other yast modules like the bootloader that affect the autoinstallation but are not listed here. This list only contains the changes of the autoyast itself.

Novell Doc Installation and Administration - Configuration of the Installed System

After a successful installation, YaST shows the Installation Completed dialog. In this dialog, select whether to clone your newly installed system for AutoYaST. To clone your system, select Clone This System for AutoYaST. The profile of the current system is stored in /root/autoyast.xml. Cloning is selected by default.

AutoYaST is a system for installing one or more SUSE Linux Enterprise systems automatically without user intervention. AutoYaST installations are performed using a control file with installation and configuration data. For detailed information, refer to Section 5.0, Automated Installation. Finish the installation of SUSE Linux Enterprise with Finish in the final dialog.

Cool Solutions SUSE Linux Enterprise Desktop 10 for the Masses Discover the Power of Network-Based, Hands-Free Installations

Jun 28, 2007

So you've installed SUSE Linux Enterprise Desktop 10 and have discovered the power and flexibility of the OS. The desktop comes loaded with the applications you need to be productive, like: OpenOffice.org ,Evolution and Firefox. The OS has seamlessly integrated with your existing network infrastructure and collaboration environment. Now you're ready to make the push to a wider audience in your organization, but where to begin? In this article, we'll explore in detail how to setup and configure a Network Installation Server paired with PXE Boot and AutoYaST for speedy, hands-free installations.

Autoyast How and why you may need to update your SLE installation environment & source

Linux In Novell's East Region

This is where PART I comes into play. There is an existing howto which goes into much greater detail, as well as describe howto to update device drivers. ftp://ftp.suse.com/pub/people/hvogel/Update-Media-HOWTO . I strongly encourage the reader to read the Update-Media-HOWTO. I will only focus on how to replace/update files in the installation environment itself.

1. Create the following directory structure (perhaps under /tmp):

mkdir -p update-media/linux/suse/i386-sles10/inst-sys

Note: All files below the 'inst-sys' directory will be used to update the installation environment.
The directory structure for the appropriate file locations must be preserved.

If you want to replace the mkfs files for example, add the updated mkfs files along with the appropriate directory structure under "inst-sys":

cd /tmp/update-media/linux/suse/i386-sles10/inst-sys
mkdir sbin
cp -ap ~/new-updated-files/mkfs* ./sbin/

Another example could be if you wish to update the hardware detection library:
cd /tmp/update-media/linux/suse/i386-sles10/inst-sys
mkdir -p usr/lib
cp -ap ~/new-updated-files/libhd.so.X.Y ./usr/lib/

2. Create a Driver Update configuration file (dud.config), under ./linux/suse/i386-sles10 :

vi dud.config, and add the following 2 lines:
UpdateName: Update /sbin/mkfs.ext3 to fix lvm online resize issue
UpdateID: mkfs_update_1

The driver update config file consists of lines with the format 'key: value'. Valid keys are

Please refer to the Howto at ftp://ftp.suse.com/pub/people/hvogel/Update-Media-HOWTO for details.

3. Most installation sources reside on a servers harddisk and are available from the network via http, ftp, nfs or even SMB.

I am only focusing on http for this howto. Please refer to the Howto at
ftp://ftp.suse.com/pub/people/hvogel/Update-Media-HOWTO for details on the other delivery mechanisms.

For HTTP/FTP installations you need to put a file 'driverupdate' into the root of your installation source.
(in my example, this is /data/install/SLE10install) This file is a (possibly compressed) filesystem image that contains the Update Media.

Use the following command to create a compressed filesystem called "driverupdate":

mkfs.cramfs /tmp/update-media /tmp/driverupdate

You can validate that the filesystem was created correctly (with the appropriate root directory structure starting at linux) via the following command:

cd /tmp
mount ./driverupdate /mnt -o loop
cd /mnt
ls
… you should see "linux" as the first directory
cd linux/suse/i386-sles10/inst-sys/sbin/
ls
… you should see all the updated mkfs files here. If all is good, then unmount /mnt.

4. copy the "driverupdate" file to the root of your installation source (my example /data/install/SLE10install):

cp /tmp/driverupdate /data/install/SLE10install/

5. That's it. Your ready now. Startup an installation, when the install starts, CRTL-ALT-F1 and if all is correct you should see a blurb on the screen with your UpdateName description from the dud.config file (step 2 above).

------------- PART II ----------------

Howto update your existing SLE10 installation source with new/updated RPMs

- Create Updates to installation source.

use at least version 20060418 of create_update_source.sh from the following SUSE
Homepage (http://www.suse.de/~ug). The latest autoyast2-utils RPM will contain the script as well.

1. create_update_source.sh

This script creates an "updates" tree under the SLE installation source. In the following examples the installation source is located under /data/install/SLE10install on the installation server.

Usage example:
a) Run the create_update_source.sh script to create the "updates" repository. For example:
./create_update_source.sh /data/install/SLE10install
b) copy the updated packages you wish to refresh your installation source with, for example:
cp -a myPackage-2.3.44.5-6.i586.rpm /data/install/SLE10install/updates/suse/i586

2. create_package_descr

This script updates the package database with any new packages or updated package versions
in the updates repository.

Usage example:
a) cd /data/SLE10install/updates/suse
b) create_package_descr -x setup/descr/EXTRA_PROV
c) cd setup/descr
d) ls > directory.yast

note: "create_package_descr", as well as "create_update_source.sh" is part of the autoyast2-utils.rpm
(Starting with 10.2 and SLES10-SP1 these scripts will be part of inst-source-utils.rpm)

3. After you have created the updates tree, and copied your updated RPMS, you have two options to tell autoyast about the new install updates:

Option I - create add_on_products file

a) create a file called "add_on_products" at the root of the installation source (in our example,
that is /data/install/SLE10install )

b) The "add_on_products" file will need to have an entry similar to this (starting in
column 1 of the add_on_products file):
http://192.168.66.1/suse/SLE10install/updates

OR

Option II - in the autoyast profile, add the following XML:

<add-on>
<add_on_products config:type="list">
<listentry>
<media_url>http://192.168.66.1/suse/SLE10install/updates</media_url>
<product>SuSE-Linux-Updates</product>
<product_dir>/</product_dir>
</listentry>
</add_on_products>
</add-on>

You can do Option II via the autoyast UI on SLES10/SL10.1 as well.

4. Signature Handling of updated or new packages.

YaST checks the signatures of files contained in the installation source. If a package file is not signed, during a manual installation YaST asks the user what to do. However, during an autoinstallation, the installation source will get rejected silently (and the new/updated packages will not be applied) if the autoyast file does not describe how to deal with this situation.

If you use unsigned packages (could be provided as part of a hot fix, or a in-house developed package) in your installation source with autoyast, you can turn off the checks with the following configuration in your autoyast profile.

The following elements must be between the <general><signature-handling> … </signature-handling></general> tags.
Please refer to the autoyast documentation for full details on what each of these do.

<signature-handling>
<accept_unsigned_file config:type="boolean">true</accept_unsigned_file>
<accept_file_without_checksum config:type="boolean">true</accept_file_without_checksum>
<accept_verification_failed config:type="boolean">true</accept_verification_failed>
<accept_unknown_gpg_key config:type="boolean">true</accept_unknown_gpg_key>
<import_gpg_key config:type="boolean">true</import_gpg_key>
</signature-handling>

5. Example Installation Source directory layout.

The following shows the directory structure of /data/install/SLE10install after the
create_updates_source.sh script is run, and the add_on_products file is created):

> #:/data/install/SLE10install # 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 ************** >> here is the add_on_products file
> |– 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 ************* >> here is the updates dir created via create_update_source.sh script
>
> #:/data/install/SLE10install # cat add_on_products
> http://192.168.66.1/suse/SLE10install/updates

Note: With the add_on_products file in the installation source, you don't need to specify the additional installation sources in the autoyast profile. You can however, mix the two options. So it's possible to specify one installation source in the autoyast profile and another one in the "add_on_products"-file.

Miscellaneous Side Note: How to handle the licence agreement pop-up for the SLE10 SDK, or an add_on product like Suse Linux Realtime;

- remove the license.zip file in the corresponding "media.1″ directory located under the "SDK" or
add_on product i.e "slert" (like Suse Linux Realtime for example) directory, and remove the line with the filename from the "directory.yast" file.

openSUSE 10.2 autoyast

gtuhl startup IT and software development

As part of the effort to improve our ability to manage more machines at work I decided to explore two tools to make life easier:

I generally followed the guidance offered at this novell.com page but want to walk through the specific process I went through as well as some specific gotchas and details in the hopes of helping out anybody else trying to do the same with 64bit openSUSE 10.2 on servers. By "on servers" I mean "no x windows".

Setting up the Installation Server

If you have an existing openSUSE box setting up the installation server is pretty easy. Here are the steps involved in setting the server up and linking it to the official Novell yast repostories so your new installations get updated packages.

At this point, you can setup new openSUSE machines by installing against this server. You would need to boot the machine with some sort of openSUSE installation media (the DVD, CD1, a properly setup usb key, or the minimal install CD) to get to the installation menu. From there hit F4, enter your FTP installation server and the /sources/suse-10.2-64bit/CD1 directory, press enter, and then continue with the installation. Having the installation server is really nice because you can control and manage a single, consistent set of rpms.

Setting up autoyast

Just having a central installation server is great but with autoyast you can almost completely automate installation of new openSUSE servers. This works by creating an autoyast control file at which you point new installations. The control file can include instructions for disk partitioning, installed software, services, custom config files, and directions to run extra scripts at various stages of the installation. The link at the top of this post provides a pretty good overview and the documentation here is very helpful as well. That documentation provides almost all of the information you need so where details are excluded from the following look there.

In my specific case (an autoyast file for JBoss servers) the process went like this:

Though the number of steps I just listed seems long, these autoyast files are really very quick to make. You could create any number of them for different machine roles and make them all available for new installs.

Setting up a New Server

Now that you have an installation server (FTP-based in this specific case) and all the autoyast files and other resources a new machine could need, you can setup a new machine from scratch by doing the following:

Now, when I set this up, GRUB wouldn't boot the newly installed machine. It turned out that the kernel version I was running on the reference server (and from which I generated the initial autoyast file) was different from the kernel provided by the installation server. This meant in my autoyast file the GRUB configuration portion was trying to reference a file (vmlinuz-2.6.18.2-34-default) that didn't exist. So make sure your installation server is tied to the official repositories and make sure your reference machine is fully up to date before creating the baseline autoyast file.

I used this same approach to create configurations for JBoss, e-mail, and basic openSUSE-based servers.

Network Install HOWTO SuSE Client Install

Once you have confirmed that you have the AutoYaST packages installed on your system, you can now start to create configuration files. For most situations the basic configuration described here will be sufficient to perform your installations.

Start the YaST2 Autoinstall configuration GUI with the command: 

yast2 autoyast

You will now be presented with a window that allows you to configure most of your installation options as if you were installing a new machine or performing an upgrade. You can proceed through the menu system configuring your options for a particular system or set of similar systems that you wish to automatically install. Alternatively, you can create class definitions which allows you to save different parts of the configuration setup and then use different classes for different sets of machines.

The use of classes is particularly good when you have a set of systems that are similar but that you would like installed in slightly different ways. For example, you could create a class definition for the hardware setup of all your client machines and create a separate class for the packages you want installed on them, whether they are server machines, test machines, workstations, etc. You can then choose which classes are used by which machines when they are installed. In our example here, all the machines would use the same hardware setup, but the workstation machines could install our workstation class of packages, test machines the test class, etc.

Once you have progressed through each configuration screen in the config setup GUI from YaST2 you are ready to save out your configuration file to disk. NOTE: it is outside the boundaries of this document to take you through each configuration option for installation, we are just concerned with the principles of network installs here. Please consult your SuSE documentation or the SuSE Website for this information.

Recommended Links

Google matched content

Softpanorama Recommended

Top articles

Sites

Email Groups

Discussions - novell.support.suse.linux.autoyast Google Groups

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

 You can use PayPal to to buy a cup of coffee for authors of this site

Disclaimer:

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019