Hi,
thanks for all the input. So I've made some steps forward, but still a few problems I have to solve:
1) I get a message Warning: Could not set patterns: sdk_kernel,...
2) message The package resolver failed ..
Pressing 2 times RETURN and the system is getting installed.
The following parts are not correct after the installation:
Hostname is not set (just "linux")
<dhcp_hostname config:type="boolean">false</dhcp_hostname> <domain>bgc-jena.mpg.de</domain> <hostname>node25</hostname> <nameservers config:type="list">
network config was not taken from the autoyast file
<interfaces config:type="list"> <interface> <bootproto>static</bootproto> <device>eth0</device> <ipaddr>192.168.1.25</ipaddr> <name>nVidia MCP55 Ethernet</name> <netmask>255.255.255.0</netmask> <startmode>auto</startmode> <usercontrol>no</usercontrol> </interface> <interface> <bootproto>static</bootproto> <device>eth1</device> <ipaddr>10.0.3.25</ipaddr> <name>nVidia MCP55 Ethernet</name> <netmask>255.255.255.0</netmask> <startmode>auto</startmode> <usercontrol>no</usercontrol> </interface>
(both IP's are filled in into a template for each node)
postinstall script is not completly executet.
The installation source from the PXE is added to zypper, but with the proxy setting ;) (but I use nfs :)) )
I'll try to solve each point step by step. It might be a problem, that the initial autoyast file was prepared for SLES 9. A long time ago I change everything, so SLES 10 was installed. Today I compare the cloned autoyast file from SLES11SP1 with this template and replaced everything old which might be incorrect. But the errors above still occured.
Bye, Peer
Am 19.04.2012 15:15, schrieb 686f6c6d:
On Thu, Apr 19, 2012 at 08:24, Dr.Peer-Joachim Koch pkoch@bgc-jena.mpg.de wrote:
Is still got some errors about a installation source and some rpm which could not been resolved (related to the installation source). Is there any kind of log file or something like a debug mode, so I can get some more details where I made a mistake in the autoyast ? ("Error: Failed to add add-on product." - not so helpfull)
Is this by any chance a nonstandard repository with your own RPMs, that are signed with your own GPG key? In this case, you want to "grep -i gpg /var/log/YaST/*" after installation. (If this is the case, you need to tell autoyast/yast to trust the key. I can post that part of our profile next monday.) The (direct) reason for the failed package will be in /var/log/YaST/badlist if it is a dependency problem, but that often doesn't help too much in the case of transitive dependencies because you cannot see the "real" cause. If the error interrupts your installation or you have a way to stop it at the time of the error, you can also ctrl-alt-f2 to another console and tail the YaST logs in the chroot (somewhere below /mnt IIRC). This is often much easier than to scroll through 40000 lines of logs. (;
For the installation: what's faster, NFS or http+squid (same server) ?
We've always used HTTP, but we never had to use proxying.
Creating the autoyast file: I've prepared a "master node" and installed everything our user needed until everybody was happy. The I used yast to create a autoyast file and added the installation sources and all hardware dependened parts (disk network). This file I take right now for testing. Is there a better way ?
For the initial profile that is a good way to go (the alternative would be to just fire up "yast autoyast" and to add everything step-by-step). It is _very_ useful to have all the XML files in a VCS and to be able to look at the diffs (and to do so, of course). I also recommend running the profile through "yast autoyast" after a couple of changes, to save the file to a different name and then to "converge" on that version, although for some sections, this doesn't work (autoyast just removes "keep_install_network", for example, so don't blindly trust it in every decision). Also, you could do the other steps discussed here: http://lists.opensuse.org/opensuse-autoinstall/2012-03/msg00031.html
We have separate profiles for the different openSUSE versions, and once the profile for the most current version works fine, we deprecate the previous version (but keep it around just in case). Our profile is split into a base.xml file (with the stuff that every machine gets) and per-machine-type differences in single files (like hwtype1.xml, hwtype2.xml, vm.xml, ...). These are merged by rules.xml, based on stuff like the CPU type, RAM size, disk size, ... The different types of machines are booted either by PXE or with a custom boot ISO (the only custom part are the autoyast boot parameters), depending on which type of hardware they are or in which network they live. Only mandatory stuff goes into autoyast (things the machine could not function without, or that would require a lot more work in other places), the rest is done with RPMs, config management, scripts, and manual labour. (; (In the above setup, we're fine with "cleaning" the machines during reinstall, that is, throwing away everything that was changed after installation. We also have a different setup where we have host-based profiles, but that is because this is a setup with a very small number of machines, there are a lot of mandatory installation details, and we want to be able to quickly re-install these machines without losing those details.)
However, if you have a real hard-to-find bug, this multi-file setup is hard to debug. In 12.1, when I first encountered such problems (I will write about that the next week(s)), I stuffed all the contents into a single file and debugged from there, just to be sure to have a single diff history. Again, VCS is king when it comes to debugging.