Hi,
I want to upgrade a couple of HPC nodes. All working in a private subnet. To get access to some additional repositories I need a proxy config. But when I add the proxy and proxyport statement at the pxe server for the (test) node, the autoyast file is not found. Without the proxy statements the autoyast file is found, but many packages are not found ;(
I've tested the proxy using wget and everything is working from the cli. Any idea what's wrong or howto debug ?
LABEL install KERNEL kernel APPEND initrd=initrd showopts install=nfs://192.168.1.100/Net/Groups/Services/LNX_FTP/INSTALL/sles11SP1/x86_64/ autoyast=http://192.168.1.100/sysinst/autoyast/node25 textmode=1 netdevice=eth0 dhcp=1 proxy=192.168.1.100 proxyport=3128
-> no autoyast found
APPEND initrd=initrd showopts install=nfs://192.168.1.100/Net/Groups/Services/LNX_FTP/INSTALL/sles11SP1/x86_64/ autoyast=http://192.168.1.100/sysinst/autoyast/node25 textmode=1 netdevice=eth0 dhcp=1
-> autoyast found, no external sources ...
On 18.04.2012 16:42, Dr.Peer-Joachim Koch wrote:
LABEL install KERNEL kernel APPEND initrd=initrd showopts install=nfs://192.168.1.100/Net/Groups/Services/LNX_FTP/INSTALL/sles11SP1/x86_64/ autoyast=http://192.168.1.100/sysinst/autoyast/node25 textmode=1 netdevice=eth0 dhcp=1 proxy=192.168.1.100 proxyport=3128
-> no autoyast found
can you try this? proxy=192.168.1.100:3128 instead of proxyport? proxyport is no longer supported but I'm not sure if it works with SP1 or not
Workaround suggestion: In case that for the installation the OS repository is sufficient i would suggest to add additional packages during the stage 2 install or even via a init script.
Hth Hajo
-----Original Message----- From: Dr.Peer-Joachim Koch [mailto:pkoch@bgc-jena.mpg.de] Sent: Wednesday, April 18, 2012 4:43 PM To: opensuse-autoinstall@opensuse.org Subject: [opensuse-autoinstall] autoyast pxe + proxy = error
Hi,
I want to upgrade a couple of HPC nodes. All working in a private subnet. To get access to some additional repositories I need a proxy config. But when I add the proxy and proxyport statement at the pxe server for the (test) node, the autoyast file is not found. Without the proxy statements the autoyast file is found, but many packages are not found ;(
I've tested the proxy using wget and everything is working from the cli. Any idea what's wrong or howto debug ?
LABEL install KERNEL kernel APPEND initrd=initrd showopts install=nfs://192.168.1.100/Net/Groups/Services/LNX_FTP/INSTALL/sles11SP1/x86_64/ autoyast=http://192.168.1.100/sysinst/autoyast/node25 textmode=1 netdevice=eth0 dhcp=1 proxy=192.168.1.100 proxyport=3128
-> no autoyast found
APPEND initrd=initrd showopts install=nfs://192.168.1.100/Net/Groups/Services/LNX_FTP/INSTALL/sles11SP1/x86_64/ autoyast=http://192.168.1.100/sysinst/autoyast/node25 textmode=1 netdevice=eth0 dhcp=1
-> autoyast found, no external sources ...
-- Thanks and bye, Peer _________________________________________________________ Max-Planck-Institut fuer Biogeochemie Dr. Peer-Joachim Koch Hans-Knöll Str.10 Telefon: ++49 3641 57-6705 D-07745 Jena Telefax: ++49 3641 57-7705
Hi, Am 18.04.2012 16:59, schrieb Uwe Gansert:
On 18.04.2012 16:42, Dr.Peer-Joachim Koch wrote:
LABEL install KERNEL kernel APPEND initrd=initrd showopts install=nfs://192.168.1.100/Net/Groups/Services/LNX_FTP/INSTALL/sles11SP1/x86_64/
autoyast=http://192.168.1.100/sysinst/autoyast/node25 textmode=1 netdevice=eth0 dhcp=1 proxy=192.168.1.100 proxyport=3128
-> no autoyast found
can you try this? proxy=192.168.1.100:3128 instead of proxyport? proxyport is no longer supported but I'm not sure if it works with SP1 or not
that's it! This error is gone :)
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)
Some addional questions: Autoyast is changing always alittle bit. Is there a reference document in every distro (SLES 11 X, opensuse 12.x,...) giving a overview about the syntax of the used autoyast ? Maybe this could help to solve most of my questions.
For the installation: what's faster, NFS or http+squid (same server) ?
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 ?
Is there a way to convert/use all zypper installation sources into the autoyast ?
For the installation: what's faster, NFS or http+squid (same server) ?
I prefer HTTP since its requires less "resources" ( Ports on the network , configurations on the (nfs) server )
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.
We are using small xml files to create a final node.xml
Example: ( Project TCE) ... Minimum: tce_base.xml.SLES11SP1 Partition: tce_lvm.xml.SLES11SP1 Network: tce_nw-eth.xml.SLES11SP1 ( No NIS,NFS ) User&Group: ... ...
These files will be merged to a node.xml like host1000.xml and copied to the target autoyast installation directory ( ../autoinstall/classes/host1000.xml ) BEFORE the installation starts
This allows us to test additional requirements ( Like LDAP) without messing around with a whole autoyast xml file.
In our current environment we use also for each suse distribution dedicated xml files. ( We have to support SLES 9 SP4 ,SLES 10 SPx SLES 11 SPx OpenSuse 11.x ,12.x ) and about 10 different projects.
Thus with this approach we can reuse and easily fix our xml files on/for new suse versions or projects.
Is there a better way ?
If your way is sufficient for you - it might be the best way for you.
Is there a way to convert/use all zypper installation sources into the autoyast ?
You can add all installation sources into the add_on_product section. See the example
<?xml version="1.0"?> <!-- $Id: tce_addon.xml.SLES11SP1,v 1.2 2011/08/25 15:55:59 hjehlers Exp $ --> <!DOCTYPE profile> <profile xmlns="http://www.suse.com/1.0/yast2ns" xmlns:config="http://www.suse.com/1.0/configns">
<add-on> <add_on_products config:type="list"> <listentry> <media_url><![CDATA[http://10.1.1.1/export/suse/sles11sp1/sdk/@OSTYPE@]]></media_url> <product>SLES 11 SP1 SDK</product> <product_dir>/</product_dir> <name>SDK</name> </listentry> </add_on_products> </add-on>
</profile>
Hth Hajo
On 19.04.2012 08:24, Dr.Peer-Joachim Koch 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)
Yeah, that's not helpful but it's not because I'm evil and don't want to tell the exact error or so. At that point in the code, I don't know what went wrong. I don't get the exact error that libzypp hit in my autoyast code. I have it on my todo to climb deeper into the code and pass the exact error up but to the autoyast layer but for the moment you can only look at the /var/log/YaST2/y2log to see what libzypp says.
Some addional questions: Autoyast is changing always alittle bit. Is there a reference document in every distro (SLES 11 X, opensuse 12.x,...) giving a overview about the syntax of the used autoyast ? Maybe this could help to solve most of my questions.
autoyast should not change in a way that makes it incompatible. When a feature gets incompatible I usually keep compatibility code to support the old syntax - sometimes for years. If there is something I can't catch with code, you can always find it in my changelogs on http://www.suse.de/~ug Those changes are marked with [compat] New features and keys in the XML are marked with [func] In the documentation I mention it when a key gets deprecated and should not be used anymore.
Is there a way to convert/use all zypper installation sources into the autoyast ?
via cloning? Unfortunately not yet (TODO again). How to add them manually, Hans-Joachim already explained in his mail
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.
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.
Hi,
so I could solve now all of my problems. Somehow yast-ncurces was missing in the packages list and therefore everything what is normaly done after the first boot missed. Thanks for all the help!
One last question: How can I redirect the console ? For the old system (SLES10SP2)
APPEND initrd=initrd.sles-10SP2-x86_64 console=tty0 console=ttyS0,115200n8 ...
was working. Not for SLES11SP1.
Hi,
so in the last days I've updated nearly 40 machines. Different setup and some minor changes for some nodes took some time. After all I have to say - it's working great. But using external sources seems to slow down everything and causes sometimes trouble. Currently some nodes stopping the installation, because a check sum error is reported etc. pp. (yesterday, the same worked perfect!) or packages are not found....
I'm currently thing about downloading all files from the different sources and create from this rpm folder my own repository. Has anybody done this before ? Beside the disk space (not a problem here) - is there anything speaking against it ?
Just as a background info: We are using a GFS (StorNEXT) which is only supported for RH and SLES. So we have to use the SLES with a software state which is supported. The software state is used on all other nodes (not part of the GFS, but part of the cluster) as well. Normaly the HPC cluster is only updated in major steps (SLES 10SP2->SLES11SP1). In the meantime defect notes are replaced and get the same software state as the allready running system.
On 26.04.2012 11:40, Dr.Peer-Joachim Koch wrote:
sorry for the late response
I'm currently thing about downloading all files from the different sources and create from this rpm folder my own repository. Has anybody done this before ?
that's a very common scenario
Beside the disk space (not a problem here) - is there anything speaking against it ?
not really. People usually use the SMT to do a local mirror of SLES11 updates. http://www.novell.com/de-de/linux/smt/faq.html Download: http://bit.ly/JqR3bH
openSUSE updates can simply be mirrored locally
Hi list,
I have a problem when installing a machine via pxe with two network cards. Doesn't matter if both cards are connected or the first or the second card the naming of the devices always changes.
eth0 in stage 1 becomes eth1 in stage two (before static network configuration takes place) and vice versa. When the machine is comming up into stage two it claims that no configuration is found for eth1 and tries to connect via the other interface but that one is not connected to the installation source.
If changing the cables than the process is going vice versa. In stage one network source will be accessed via eth1 which becomes eth0 in second stage. But no configuration found for eth0.
Is there anything known about that behaviour. Can I workarround that?
I already tried with netdevice parameter but that didn't help.
Thanks, Jochen
autoinstall@lists.opensuse.org
-
686f6c6d -
Dr.Peer-Joachim Koch -
Hans-Joachim Ehlers -
Jochen Schaefer -
Uwe Gansert