my experience with autoinstall (for other beginners who found the documentation very cryptic)

Here is my experience with autoinstall, including questions that I was not able to find the answers to by looking in the documentation or the suse-install mailing list archive. Description of system: I want to install SuSE 8.0 on a cluster of dual PentiumIIIs over nfs. I set up the nfs server with the installation repository by copying the dvd that came with the distribution to the hard drive of the nfs server as described in the documentation. Suse8.0 was already installed on the nfs server. I also set up the configuration repository on the nfs server using the Autoinstall module for Yast2 to create the control files. I used the bootdisk image (/disks/bootdisk) from the dvd that came with the distribution as a template to create floppies which contained an info file and the initial networking information needed to connect to the nfs server. This required that I use the modules1 and modules3 disks in addition to the bootdisk, but I figured switching disks twice is a lot easier than compiling my own kernel (I am still a beginner). Step 1: Configure nfs server to export install repository. Made sure root install directory was entered in /etc/exports on nfs server: nfsserver:# cat /etc/exports $Install_root/ $target_ip(ro) Next, exported directory on nfs server: nfsserver:# /usr/sbin/exports -rv Enabled portmap service requests from $target_ip on the nfs server (following entry was put in /etc/hosts.allow on nfs server): nfsserver:# cat /etc/hosts.allow portmap:$target_ip Made sure nfs server was active (type command on nfs server): nfsserver:# /etc/rc.d/nfsserver start At this point, nfs server should be ready. Step 2: Create floppy disks containing the info file. I first copied the bootdisk from installation repository to a separate workstation hard drive and mounted it using loop device: workstation:# scp $user@nfsserver:$Install_root/disks/bootdisk . workstation:# mount -oloop bootdisk /mnt/bootdisk List the contents of the bootdisk: workstation:# ls /mnt/bootdisk total 1428 drwxr-xr-x 2 root root 512 Dec 31 1969 . drwxr-xr-x 5 root root 128 Sep 25 16:18 .. -r-xr-xr-x 1 root root 11912 Apr 3 2002 ldlinux.sys -rwxr-xr-x 1 root root 964815 Apr 3 2002 linux -rwxr-xr-x 1 root root 523 Apr 3 2002 message -rwxr-xr-x 1 root root 399010 Oct 2 18:14 small -rwxr-xr-x 1 root root 81988 Apr 3 2002 suselogo -rwxr-xr-x 1 root root 600 Oct 2 18:16 syslinux.cfg Here, I was confused to see a file called small instead of the expected initrd. No worries, it is the initial ram disk, just with a different name to confuse us. I modified both small and syslinux.cfg, but all other files were left untouched. First, I modified small. We need to add an info file to the root directory of this ram disk. Copy the file to the local directory, decompress it, and mount it using the loop device: workstation:# cp /mnt/bootdisk/small . workstation:# zcat small > small.tmp workstation:# mount -oloop small.tmp /mnt/small Create an info file and copy it to root directory of ram disk: workstation:# cat info insmod tulip #or the necessary network driver for your target machine. workstation:# cp info /mnt/small Unmount small.tmp, compress it, and replace new compressed ram disk on bootdisk: workstation:# umount /mnt/small workstation:# gzip -9 small.tmp workstation:# cp small.tmp.gz /mnt/bootdisk/small #make sure to overwrite old small file Next, I modified syslinux.cfg, umounted the newly created bootdisk, and copied the bootdisk to floppy: workstation:# cat /mnt/bootdisk/syslinux.cfg --snip-- label linux kernel linux append initrd=initrd ramdisk_size=65536 rw netdevice=eth0 \ server=x.x.x.a serverdir=$Install_root ip=x.x.x.b \ netmask=255.255.255.0 gateway=x.x.x.c nameserver=x.x.x.d \ autoyast=nfs://x.x.x.a/$Install_root/$control_file instmode=nfs --snip-- workstation:# umount /mnt/bootdisk workstation:# dd if=bootdisk of=/dev/fd0 At this point, the floppy now has all the information it needs for your target machine to connect to the nfs server. At this point, the control file is found and the installation initiated over nfs. Problems with creating boot floppy: The documentation in Section 5.2 gave me plenty of grief. First off, it wasn't immediately clear what was meant by the command line that linuxrc uses to detect an autoinstallation. It wasn't until after lots of time-consuming trial and error that I figured out that the command line refers the "append" entry in the syslinux.cfg file (see above). Once I figure this out, I thought I'd enter as little information on this "command line" as was needed and put everything else in the info file. Bad move on my part. After trying unsuccessfully for many, many times to get the networking information to work in the info file, I finally gave up the info file and decided to enter all the information on the "command line" in syslinux.cfg (see above). Voila, it worked like a charm. So the only information I ended up putting in the info file was the "insmod tulip" line (this was recognized by linuxrc, so I knew that it actually found and parsed t! he info file). There is no example in the documentation for what the entries in the info file should look like. Should they be like this?: ip=x.x.x.a server=x.x.x.b nameserver=x.x.x.c etc. or should they look like this?: ip x.x.x.a serever x.x.x.b nameserver x.x.x.c etc. or should they look like something else? Neither one of these syntaxes worked, so it must be entered some other way. But you wouldn't know what the syntax should be, because there are no examples of what it should look like. Could someone clue me in on this, please? So, once I decided to put this networking information in syslinux.cfg, the next major frustration surfaced. At this point, I was able to connect to the nfs server, but it couldn't find the control file. First, I tried to use nfs. The entry in syslinux.cfg looked like this -- autoyast=nfs://x.x.x.a:$Install_root. Once that didn't work, I tried using -- autoyast=default. Problems here as well (see below). It wasn't until later, when I was looking through the mailing list archives that I found an email explaining that he had also spent many hours of frustration trying to get nfs to recognize the control file, only to find that the documentation had a typo: the entry in syslinux.cfg should've looked like this -- autoyast= nfs://x.x.x.a/$Install_root. The colon should be a slash. This has since been changed in the documentation, but I hope you are fortunate to have the updated documentation so you don't spend hours before resorting to the mailing list archive. The problems I had with autoyast=default. Section 5.2 explains that the default behavior of yast2 is to look for a file named autoinst.xml in the root directory of the initial ram disk on the floppy, then in the root directory of the installation repository on the nfs server, then finally on the root directory of the floppy. Well, yast2 found the autoinst.xml file in the root directory of the installation repository, but it never found it at either place on the floppy. Could someone help me out on this? Of all the options for specifying the location of the control file, placing it in the root directory of the installation repository was the least desirable to me (I didn't want 100 or more control files in the root installation directory - what a mess!!). I was very happy I wasn't left with this last option when I found the solution to the nfs issue mentioned above. Still, I spent way too much time just getting yast2 to find a control file, anywhere, just because the doc u! mentation was either incorrect or unclear. Step 3: Create the control file. I used the autoinstall module for yast2 to create control files. The graphic user interface made creating the control file very easy (thank goodness, because everything else had been difficult so far). Overall, the documentation is helpful for this step, but there were a few issues or concerns that came up. First, my concerns. These didn't cause problems, but just seemed inconsistent. When I set up the partitioning plan, yast2 specified that the swap partition was to be created as a linux native filesystem. Here is a snippet from my control file: <partition> <crypt_fs config:type="boolean" >false</crypt_fs> <crypt_key></crypt_key> <filesystem config:type="symbol" >swap</filesystem> <filesystem_id config:type="integer" >131</filesystem_id> <format config:type="boolean" >true</format> <mount>swap</mount> <size>1.0GB</size> <type>Linux native</type> </partition> I was concerned about this until I tested it and found out that the swap partition was working properly. This is an FYI. Next, I wrote a post-install script to add users to the system using useradd. One of the users has a capital letter as the first character in his username. The creation of the user account failed. Is this a limitation imposed by yast? I was able to create the user account containing capital letters in the username on the command line when I didn't go through yast. Again, this is not a major problem, just a minor inconvenience. Finally, there were three issues that are serious problems that I need help to solve. First, when specifying the location of the control file in syslinux.cfg, I had to give the explicit name of the control file rather than use the hex ip number convention. I would like to give the directory of the control file repository, then have yast figure out which control file to use based on the ip number of the target machine. I am not using DHCP, but am hard coding the ip number in the command line in syslinux.cfg. Does hex ip filename matching work only with DHCP? The documenation says that it works with nfs as well tftp. I called the name of the control file 1A2B3C4D (random hex numbers for illustration) but yast didn't recognize it for the machine with the given target ip number. I used capital hex digits like it says in the documentation. Does it require the .xml suffix? Any help would be appreciated. Second, I would like to configure my hosts.allow and hosts.deny configuration files within the autoinstall process. There was an email in the archives of the mailing list from a user who experienced the same problems that I had, but there were no posted solutions. I typed the xml directives in my control file as explained in Section 4.13, because there is no facility to add them from within yast2. When I loaded the control file back into yast2's configuration module, it changed the entries I had typed in to add /etc/hosts.allow. <config_file> was replaced by <listentry> and the <![CDATA[ directive was erased. I added the CDATA directives back in, but the whole section is completely ignored during installation. The /etc/hosts.allow and /etc/hosts.deny files are present as though I never even tried to modify them. Here is a snippet of the code: <files config:type="list" > <listentry> <file_contents><![CDATA[ sshd: x.x.x.a sshd: x.x.x.b sshd: x.x.x.c sshd: x.x.x.d sshd: x.x.x.e sshd: x.x.x.f ]]></file_contents> <file_path>/etc/hosts.allow</file_path> </listentry> <listentry> <file_contents><![CDATA[ ALL:ALL ]]></file_contents> <file_path>/etc/hosts.deny</file_path> </listentry> </files> Any suggestions on how to modify this, so that yast will actually write these configurations to /etc? Last of all, I would like to add an rpm file to the installation that is not present in the current distribution. I found an email similar to this in the mailing list archive, but the links that were given on the subject no longer existed. I would appreciate a section in the documentation on how to do this. This is what I tried to do. In the directory $Install_root/suse/setup/descr on the nfs server, there is a file, common.pkd, with entries for all the rpm packages in the installation. I added this entry to this file: ##----- gromacs ----- Filename: gromacs-3.1.4-1.i386.rpm RpmName: gromacs Series: custom InstPath: 01 /custom/ Size: 7581000 2735235 Buildtime: BuiltFrom: Flag: RpmGroup: Custom Copyright: AuthorName: Version: 3.1.4-1 Requires: libsfftw.so.2 libsrfftw.so.2 Provides: do_dssp editconf eneconv ffscan g_anaeig g_analyze g_angle g_bond g_bundle g_chi g_cluster g_clustsize g_confrms g_covar g_density g_dielectric g_dih g_dipoles g_disre g_dist g_dyndom g_enemat g_energy g_gyrate g_h2order g_hbond g_helix g_lie g_mdmat g_mindist g_morph g_msd g_nmeig g_nmens g_order g_potential g_rama g_rdf g_rms g_rmsdist g_rmsf g_rotacf g_saltbr g_sas g_sgangle g_sorient g_tcaf g_traj g_velacc genbox genconf genion genpr gmxcheck gmxdump grompp highway luck make_ndx mdrun mk_angndx ngmx pdb2gmx protonate tpbconv trjcat trjconv trjorder wheel x2top xpm2ps xrama I also created the directory, custom, in the $Install_root/suse directory. I placed the gromacs-3.1.4-1.i386.rpm file in this directory (custom). I also made sure the fftw package was installed. Also, in the custom directory, I added this file: nfsserver:# cat INDEX.english gromacs-3.1.4-1.i386.rpm: GROMACS molecular dynamics package Then, in the control file, I added an entry as directed in Section 4.6.3. Here is the snippet: <extra_packages> <package_location> custom </package_location> <packages config:type="list"> <package>gromacs</package> </packages> </extra_packages> The installation failed when it tried to install gromacs. This is the message I got: gromacs.rpm: file not found Do I need to add a flag to the entry in common.pkd? Other than that, I have no idea why it doesn't work. Any insights would be appreciated. I hope that this will be helpful to others who have also tried to use autoinstall, but ran into similar problems. Sid

* Sidney Elmer <sidnasty@stanford.edu> [Oct 09. 2002 02:36]: (....)
Problems with creating boot floppy: The documentation in Section 5.2 gave me plenty of grief. First off, it wasn't immediately clear what was meant by the command line that linuxrc uses to detect an autoinstallation. It wasn't until after lots of time-consuming trial and error that I figured out that the command line refers the "append" entry in the syslinux.cfg file (see above).
This is how it is refered to in general. For example `cat /proc/cmdline` tells you what it looks like on you system. Sorry if we were not clear enough about it.
Once I figure this out, I thought I'd enter as little information on this "command line" as was needed and put everything else in the info file. Bad move on my part. After trying unsuccessfully for many, many times to get the networking information to work in the info file, I finally gave up the info file and decided to enter all the information on the "command line" in syslinux.cfg (see above). Voila, it worked like a charm. So the only information I ended up putting in the info file was the "insmod tulip" line (this was recognized by linuxrc, so I knew that it actually found and parsed t! he info file). There is no example in the documentation for what the entries in the info file should look like. Should they be like this?:
ip=x.x.x.a server=x.x.x.b nameserver=x.x.x.c etc.
or should they look like this?:
ip x.x.x.a serever x.x.x.b nameserver x.x.x.c etc.
or should they look like something else? Neither one of these syntaxes worked, so it must be entered some other way. But you wouldn't know what the syntax should be, because there are no examples of what it should look like. Could someone clue me in on this, please?
http://www.suse.de/~nashif/autoinstall/linuxrc.html
So, once I decided to put this networking information in syslinux.cfg, the next major frustration surfaced. At this point, I was able to connect to the nfs server, but it couldn't find the control file. First, I tried to use nfs. The entry in syslinux.cfg looked like this -- autoyast=nfs://x.x.x.a:$Install_root. Once that didn't work, I tried using -- autoyast=default. Problems here as well (see below). It wasn't until later, when I was looking through the mailing list archives that I found an email explaining that he had also spent many hours of frustration trying to get nfs to recognize the control file, only to find that the documentation had a typo: the entry in syslinux.cfg should've looked like this -- autoyast= nfs://x.x.x.a/$Install_root. The colon should be a slash. This has since been changed in the documentation, but I hope you are fortunate to have the updated documentation so you don't spend hours before resorting to the mailing list archive.
The problems I had with autoyast=default. Section 5.2 explains that the default behavior of yast2 is to look for a file named autoinst.xml in the root directory of the initial ram disk on the floppy, then in the root directory of the installation repository on the nfs server, then finally on the root directory of the floppy. Well, yast2 found the autoinst.xml file in the root directory of the installation repository, but it never found it at either place on the floppy. Could someone help me out on this? Of all the options for specifying the location of the control file, placing it in the root directory of the installation repository was the least desirable to me (I didn't want 100 or more control files in the root installation directory - what a mess!!). I was very happy I wasn't left with this last option when I found the solution to the nfs issue mentioned above. Still, I spent way too much time just getting yast2 to find a control file, anywhere, just because the doc u! mentation was either incorrect or unclear.
Did you use the update packages from the FTP server?
Step 3: Create the control file. I used the autoinstall module for yast2 to create control files. The graphic user interface made creating the control file very easy (thank goodness, because everything else had been difficult so far). Overall, the documentation is helpful for this step, but there were a few issues or concerns that came up.
First, my concerns. These didn't cause problems, but just seemed inconsistent. When I set up the partitioning plan, yast2 specified that the swap partition was to be created as a linux native filesystem. Here is a snippet from my control file:
<partition> <crypt_fs config:type="boolean" >false</crypt_fs> <crypt_key></crypt_key> <filesystem config:type="symbol" >swap</filesystem> <filesystem_id config:type="integer" >131</filesystem_id> <format config:type="boolean" >true</format> <mount>swap</mount> <size>1.0GB</size> <type>Linux native</type> </partition>
I was concerned about this until I tested it and found out that the swap partition was working properly. This is an FYI.
Next, I wrote a post-install script to add users to the system using useradd. One of the users has a capital letter as the first character in his username. The creation of the user account failed. Is this a limitation imposed by yast? I was able to create the user account containing capital letters in the username on the command line when I didn't go through yast. Again, this is not a major problem, just a minor inconvenience.
Finally, there were three issues that are serious problems that I need help to solve. First, when specifying the location of the control file in syslinux.cfg, I had to give the explicit name of the control file rather than use the hex ip number convention. I would like to give the directory of the control file repository, then have yast figure out which control file to use based on the ip number of the target machine. I am not using DHCP, but am hard coding the ip number in the command line in syslinux.cfg. Does hex ip filename matching work only with DHCP?
No, it has nothing to do with DHCP.
The documenation says that it works with nfs as well tftp. I called the name of the control file 1A2B3C4D (random hex numbers for illustration) but yast didn't recognize it for the machine with the given target ip number. I used capital hex digits like it says in the documentation. Does it require the .xml suffix? Any help would be appreciated.
No xml suffix needed. just the hex string. The autoyast keyword must then point to a directory.
Second, I would like to configure my hosts.allow and hosts.deny configuration files within the autoinstall process. There was an email in the archives of the mailing list from a user who experienced the same problems that I had, but there were no posted solutions. I typed the xml directives in my control file as explained in Section 4.13, because there is no facility to add them from within yast2. When I loaded the control file back into yast2's configuration module, it changed the entries I had typed in to add /etc/hosts.allow. <config_file> was replaced by <listentry> and the <![CDATA[ directive was erased. I added the CDATA directives back in, but the whole section is completely ignored during installation. The /etc/hosts.allow and /etc/hosts.deny files are present as though I never even tried to modify them. Here is a snippet of the code:
<files config:type="list" > <listentry> <file_contents><![CDATA[
sshd: x.x.x.a sshd: x.x.x.b sshd: x.x.x.c sshd: x.x.x.d sshd: x.x.x.e sshd: x.x.x.f ]]></file_contents> <file_path>/etc/hosts.allow</file_path> </listentry> <listentry> <file_contents><![CDATA[
ALL:ALL
]]></file_contents> <file_path>/etc/hosts.deny</file_path> </listentry> </files>
Any suggestions on how to modify this, so that yast will actually write these configurations to /etc?
Ok, checking on this.
Last of all, I would like to add an rpm file to the installation that is not present in the current distribution. I found an email similar to this in the mailing list archive, but the links that were given on the subject no longer existed. I would appreciate a section in the documentation on how to do this. This is what I tried to do. In the directory $Install_root/suse/setup/descr on the nfs server, there is a file, common.pkd, with entries for all the rpm packages in the installation. I added this entry to this file:
##----- gromacs ----- Filename: gromacs-3.1.4-1.i386.rpm RpmName: gromacs Series: custom InstPath: 01 /custom/ Size: 7581000 2735235 Buildtime: BuiltFrom: Flag: RpmGroup: Custom Copyright: AuthorName: Version: 3.1.4-1 Requires: libsfftw.so.2 libsrfftw.so.2 Provides: do_dssp editconf eneconv ffscan g_anaeig g_analyze g_angle g_bond g_bundle g_chi g_cluster g_clustsize g_confrms g_covar g_density g_dielectric g_dih g_dipoles g_disre g_dist g_dyndom g_enemat g_energy g_gyrate g_h2order g_hbond g_helix g_lie g_mdmat g_mindist g_morph g_msd g_nmeig g_nmens g_order g_potential g_rama g_rdf g_rms g_rmsdist g_rmsf g_rotacf g_saltbr g_sas g_sgangle g_sorient g_tcaf g_traj g_velacc genbox genconf genion genpr gmxcheck gmxdump grompp highway luck make_ndx mdrun mk_angndx ngmx pdb2gmx protonate tpbconv trjcat trjconv trjorder wheel x2top xpm2ps xrama
I also created the directory, custom, in the $Install_root/suse directory. I placed the gromacs-3.1.4-1.i386.rpm file in this directory (custom). I also made sure the fftw package was installed. Also, in the custom directory, I added this file:
nfsserver:# cat INDEX.english gromacs-3.1.4-1.i386.rpm: GROMACS molecular dynamics package
Then, in the control file, I added an entry as directed in Section 4.6.3. Here is the snippet:
<extra_packages> <package_location> custom </package_location> <packages config:type="list"> <package>gromacs</package> </packages> </extra_packages>
The installation failed when it tried to install gromacs. This is the message I got:
gromacs.rpm: file not found
Do I need to add a flag to the entry in common.pkd? Other than that, I have no idea why it doesn't work. Any insights would be appreciated.
You dont need to add the package data to the common.pkd file if you use <extra_packages>. Using common.pkd mean that you have to handle the package as a distribution package and not extra.
I hope that this will be helpful to others who have also tried to use autoinstall, but ran into similar problems.
Thanks for the detailed report. Anas
Sid
-- To unsubscribe, e-mail: suse-autoinstall-unsubscribe@suse.com For additional commands, e-mail: suse-autoinstall-help@suse.com -- Anas Nashif <nashif@suse.com>, SuSE Linux AG Montreal (Laval), Canada

Once I figure this out, I thought I'd enter as little information on this "command line" as was needed and put everything else in the info file. Bad move on my part. After trying unsuccessfully for many, many times to get the networking information to work in the info file, I finally gave up the info file and decided to enter all the information on the "command line" in syslinux.cfg (see above). Voila, it worked like a charm. So the only information I ended up putting in the info file was the "insmod tulip" line (this was recognized by linuxrc, so I knew that it actually found and parsed t! he info file). There is no example in the documentation for what the entries in the info file should look like. Should they be like this?:
ip=x.x.x.a server=x.x.x.b nameserver=x.x.x.c etc.
or should they look like this?:
ip x.x.x.a serever x.x.x.b nameserver x.x.x.c etc.
or should they look like something else? Neither one of these syntaxes worked, so it must be entered some other way. But you wouldn't know what the syntax should be, because there are no examples of what it should look like. Could someone clue me in on this, please?
I tried entering the key/value pairs with the syntax given in this webpage, but it still didn't work. I'm just going to rely on entering all information on the command line.
documenation says that it works with nfs as well tftp. I called the name of the control file 1A2B3C4D (random hex numbers for illustration) but yast didn't recognize it for the machine with the given target ip number. I used capital hex digits like it says in the documentation. Does it require the .xml suffix? Any help would be appreciated.
No xml suffix needed. just the hex string. The autoyast keyword must then point to a directory.
Okay, this doesn't work for me, either, then.
Second, I would like to configure my hosts.allow and hosts.deny configuration files within the autoinstall process. There was an email in the archives of the mailing list from a user who experienced the same problems that I had, but there were no posted solutions. I typed the xml directives in my control file as explained in Section 4.13, because there is no facility to add them from within yast2. When I loaded the control file back into yast2's configuration module, it changed the entries I had typed in to add /etc/hosts.allow. <config_file> was replaced by <listentry> and the <![CDATA[ directive was erased. I added the CDATA directives back in, but the whole section is completely ignored during installation. The /etc/hosts.allow and /etc/hosts.deny files are present as though I never even tried to modify them. Here is a snippet of the code:
<files config:type="list" > <listentry> <file_contents><![CDATA[
sshd: x.x.x.a sshd: x.x.x.b sshd: x.x.x.c sshd: x.x.x.d sshd: x.x.x.e sshd: x.x.x.f ]]></file_contents> <file_path>/etc/hosts.allow</file_path> </listentry> <listentry> <file_contents><![CDATA[
ALL:ALL
]]></file_contents> <file_path>/etc/hosts.deny</file_path> </listentry> </files>
Any suggestions on how to modify this, so that yast will actually write these configurations to /etc?
Ok, checking on this.
Please let me know when you have more information for me. This is a feature I would really like to use.
Last of all, I would like to add an rpm file to the installation that is not present in the current distribution. I found an email similar to this in the mailing list archive, but the links that were given on the subject no longer existed. I would appreciate a section in the documentation on how to do this. This is what I tried to do. In the directory $Install_root/suse/setup/descr on the nfs server, there is a file, common.pkd, with entries for all the rpm packages in the installation. I added this entry to this file:
##----- gromacs ----- Filename: gromacs-3.1.4-1.i386.rpm RpmName: gromacs Series: custom InstPath: 01 /custom/ Size: 7581000 2735235 Buildtime: BuiltFrom: Flag: RpmGroup: Custom Copyright: AuthorName: Version: 3.1.4-1 Requires: libsfftw.so.2 libsrfftw.so.2 Provides: do_dssp editconf eneconv ffscan g_anaeig g_analyze g_angle g_bond g_bundle g_chi g_cluster g_clustsize g_confrms g_covar g_density g_dielectric g_dih g_dipoles g_disre g_dist g_dyndom g_enemat g_energy g_gyrate g_h2order g_hbond g_helix g_lie g_mdmat g_mindist g_morph g_msd g_nmeig g_nmens g_order g_potential g_rama g_rdf g_rms g_rmsdist g_rmsf g_rotacf g_saltbr g_sas g_sgangle g_sorient g_tcaf g_traj g_velacc genbox genconf genion genpr gmxcheck gmxdump grompp highway luck make_ndx mdrun mk_angndx ngmx pdb2gmx protonate tpbconv trjcat trjconv trjorder wheel x2top xpm2ps xrama
I also created the directory, custom, in the $Install_root/suse directory. I placed the gromacs-3.1.4-1.i386.rpm file in this directory (custom). I also made sure the fftw package was installed. Also, in the custom directory, I added this file:
nfsserver:# cat INDEX.english gromacs-3.1.4-1.i386.rpm: GROMACS molecular dynamics package
Then, in the control file, I added an entry as directed in Section 4.6.3. Here is the snippet:
<extra_packages> <package_location> custom </package_location> <packages config:type="list"> <package>gromacs</package> </packages> </extra_packages>
The installation failed when it tried to install gromacs. This is the message I got:
gromacs.rpm: file not found
Do I need to add a flag to the entry in common.pkd? Other than that, I have no idea why it doesn't work. Any insights would be appreciated.
You dont need to add the package data to the common.pkd file if you use <extra_packages>. Using common.pkd mean that you have to handle the package as a distribution package and not extra.
Okay, I removed the entry I put in common.pkd and modified my entry in the control file. Instead of trying to use a shortname for the rpm file, I wrote the full name of the rpm file, minus the rpm suffix, and it worked perfectly. The control file now looks like this: <extra_packages> <package_location> custom </package_location> <packages config:type="list"> <package>gromacs-3.1.4-1.i386</package> </packages> </extra_packages> Thanks for your help with everything. Sid
I hope that this will be helpful to others who have also tried to use autoinstall, but ran into similar problems.
Thanks for the detailed report. Anas
Sid
-- To unsubscribe, e-mail: suse-autoinstall-unsubscribe@suse.com For additional commands, e-mail: suse-autoinstall-help@suse.com -- Anas Nashif <nashif@suse.com>, SuSE Linux AG Montreal (Laval), Canada
-- To unsubscribe, e-mail: suse-autoinstall-unsubscribe@suse.com For additional commands, e-mail: suse-autoinstall-help@suse.com

Hi, On Wed, 9 Oct 2002, Anas Nashif wrote:
I called the name of the control file 1A2B3C4D (random hex numbers for illustration) but yast didn't recognize it for the machine with the given target ip number. I used capital hex digits like it says in the documentation. Does it require the .xml suffix? Any help would be appreciated.
No xml suffix needed. just the hex string. The autoyast keyword must then point to a directory.
I ran into the same problem: I have a boot cd for initiating the installation. The control file resides in my repository on an NFS-Server. The files are called like the HEX representation of the IP of the computer that is to be installed. It worked fine with SuSE 8.0 but it just won't work with 8.1... I installed the latest patches. Any ideas? -- Bye, Christian Schromm --------------------------------- Christian Schromm A&D SH 12 Siemens AG Tel: (+49) 9131 98-3916

On Tue, 15 Oct 2002, Christian Schromm wrote: Hi, again!
I ran into the same problem: I have a boot cd for initiating the installation. The control file resides in my repository on an NFS-Server. The files are called like the HEX representation of the IP of the computer that is to be installed.
in '/var/log/YaST2/y2log' I found a line, where the installer tried to load the wrong config file. My ip was 10.10.233.32 -> HEX 0A0AE920 But it tried to load the file A0AE920 (the first '0' is cut off). After doing a 'cp 0A0AE920 A0AE920' it worked.... -- Bye, Christian Schromm --------------------------------- Christian Schromm A&D SH 12 Siemens AG Tel: (+49) 9131 98-3916

Hi *, perhaps I'm just to blind to see, but I just don't manage to add 3rd party software (as rpm) to the package selection. My questions are: 1. Where do I have to copy the rpm, so autoinstall will find it? 2. I have to use the YaST2 GUI. What entry do I have to make? 3. Is there anything else I have to do? (recreateing the packageDB??) -- Bye, Christian Schromm --------------------------------- Christian Schromm A&D SH 12 Siemens AG Tel: (+49) 9131 98-3916

On Wed, 30 Oct 2002, Christian Schromm wrote:
perhaps I'm just to blind to see, but I just don't manage to add 3rd party software (as rpm) to the package selection.
I was to blind... now it works. -- bye, Christian Schromm --------------------------------- Christian Schromm A&D SH 12 Siemens AG Tel: (+49) 9131 98-3916
participants (3)
-
Anas Nashif
-
Christian Schromm
-
Sidney Elmer