January 2008 - openSUSE Autoinstall - openSUSE Mailing Lists

[opensuse-autoinstall] Installing SLED on top of SLES
by Frank Steiner 25 Jan '08

25 Jan '08

Hi, a little HOWTO for people who are interested in this :-) What I do is installing SLES and SLED on top of a SuSE 10.1 installation. Installing SLED on SLES (or vice versa) will work the same way. Why doing that? We need hosts that have the huge software repository that you find in a (open)SuSE system but can run longer than 2 years. So my idea was to install SLES and SLED over the SuSE system so that I replace almost all packages with their SLES/D pendants and can use the SLES/D security updates for a while. This works because SuSE 10.1, SLES10 and SLED10 have a common code base. There are a few packages that are in SuSE and not in SLES/D, very useful ones like sshfs or wipe. Of course you can install SLES+D and add those few packages from SuSE if you need them. Or you install SLES+D on top of SuSE. I describe what I did for installing SLES+D on top of SuSE 10.1. The decision you must take is what should be your main system. In my case, suse-release.rpm is installed, marking the system as a SuSE system in /etc/SuSE-release. If you start with SLES and install SLED on top, you will have sles-release.rpm, thus a SLES system + SLED packets. If you start with SLED, you have a SLED system + SLES rpms and sled-release.rpm. Usually that should not be very important. What I did (very short description because I expect that people who want to do that know about autoyast, pxe etc.): - made a local NFS repository for SuSE 10.1 - setup AY installation for SuSE 10.1 from that repository. Due to some bugs in the 10.1 installer I use the SLES10 installer, i.e. "linux" and "initrd" from the SLES10 loader/ subdir for PXE. Note that it is not possible to use the SLES10-SP1 installed for installing SuSE 10.1, but for combining SLES SP1 and SLED SP1. - setup an updates/ directory below the SuSE sources with the create_update_source.sh script from autoyast2-utils. - rsync all RPMs from SLED-SP1, SLES-SP1 and SDK-SP1 into that updates/ dir. I.e., rsync -avP <somepath>/{SLED10,SLES10,SDK10}-SP1/suse/ <somepath>/10.1/SuSE/updates/suse/ You can indeed rsync the i586 and x86_64 versions of SLES/D into the same updates/suse/ dir. If you install SLED on SLES you don't need that because they have seperate i586 and x86_64 versions anyway. - in updates/suse/ call the /usr/bin/create_package_descr script like create_package_descr -l english -l german -x `pwd`/setup/descr/EXTRA_PROV or whatever languages you need. The script is part of autoyast2-utils, too. - make the updates/ dir known by adding sth. like nfs://<yourserver>/<yourpath>/10.1/SuSE/updates to the file <yourpath>/10.1/SuSE/add_on_products When you start AY now, it will just take the RPMs at SuSE/updates/suse/ as additional RPM repository, not knowing about SLES and SLED. To the best of my knowledge this is the only way to solve the conflict between SuSE, SLES and SLED. Any other method (adding the whole SLES directory as addon product e.g.) will result in a conflict at least between suse-release.rpm, sles-release.rpm and sled-release.rpm. Now you can chose your packages in AY or add your own selection (if based on SuSE) or pattern (if based on SLES) in updates/suse/setup/descr/. Check the AY mailing list or AY homepage for further details. One problem I stepped on: We are using lilo and with the new package set there was some problem when AY tries to write the lilo.conf after installing all packages. Maybe because I use the SLES10 installer to install packages from SLES SP1. Some AY libraries seem to be incompatible there. I guess the problem wouldn't occur when you just install SLED on SLES. For my setup I just removed "limal-bootloader-*" from the updates/suse/ dir and it worked again. Now what about updates: I guess this will be a problem using the SuSE tools because you system will identify as SuSE or SLES e.g., but you will need updates for e.g. SLED, too. I never used the SuSE update mechanism, so I can't tell. We have been using autorpm here for years. This is a perl script that works on arbitrary directories (or ftp servers) and just scans all RPMs in there, resolves dependencies and takes the latest versions of all packages. There are many options for autorpm like upgrading only installed packages or install all found packages, select accept or reject patterns and so on. If you want to use that, you can find the latest patched version at http://www.bio.ifi.lmu.de/~steiner/files/autorpm-test-3.3.3-1.noarch.rpm because autorpm is no longer maintained by Kirk. Anyway, any program that can work on a bunch of directories containing RPMs without caring about the product you have installed (SuSE, SLES, SLED) should do the job. So we always mirror all updates for SuSE (with mirror/wget), SLES and SLES (with yup) to our local nfs server and let autorpm work on all three update directories. Even when SuSE 10.1 doesn't get security updates anymore you must include the SuSE 10.1 updates for the first update after the installation. If you install SLED on SLES you don't care about this of course ;-) I'm sure you can also rsync the updated RPMs from SuSE/SLES/SLED into the SuSE/updates/suse/ repository so that AY works always on all the latest updates. I just didn't do that to have a stable repository for installation to make sure it always runs the same way. There are other ways to achieve the same result, like adding repositories to your either SLED or SLES installation, however, if you need a full SLES+SLED set on some of your hosts, I guess this is the easiest way. cu, Frank -- Dipl.-Inform. Frank Steiner Web: http://www.bio.ifi.lmu.de/~steiner/ Lehrstuhl f. Bioinformatik Mail: http://www.bio.ifi.lmu.de/~steiner/m/ LMU, Amalienstr. 17 Phone: +49 89 2180-4049 80333 Muenchen, Germany Fax: +49 89 2180-99-4049 * Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. * -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-autoinstall+help(a)opensuse.org

2 2

[opensuse-autoinstall] Pre-init scripts step hangs
by Pepe Barbe 23 Jan '08

23 Jan '08

Hi, I am trying to create an Autoyast profile that will run a pre-init script to define the size for several partitions given the size of / dev/sda. I have debugged the script and seems to be fine syntactically, but whenever the install process hits the pre-init script part, it just hangs there. When I run it in debug mode, the window popping up shows all the results correctly, but once I hit 'close' it comes up again, and again, and again ... etc. Seems to be on some sort of loop, but I have no clue what the problem could be. I've checked /tmp/profile/modified.xml and it is just as I was expecting so it is running and doing things as expected. Any ideas on what the problem could be? Thanks, Pepe -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-autoinstall+help(a)opensuse.org

2 1

[opensuse-autoinstall] AutoYast SLES9 SP3 problem with hostname via DHCP
by chrroe＠uni.de 21 Jan '08

21 Jan '08

Hello, I am facing a problem that I cannot solve myself and hope for your expert help. Description: When installing a machine with SLES9 with AutoYast the via DHCP forwarded hostname is not fully recognized. Environment: 1. DHCP-Server under SLES9 SP3 2. DNS via Active Directory under Windows 2003 Server 3. PXE and Installationsserver for Autoyast under SLES9 SP3 4. various Destination Machines (3. und 4. under VMware ESX 3) Procedure: In my environment every Machine is assigned a fixed IP-Adress and the corresponding host name via DHCP (this is the assignment for the time being and should not be changed). The installation of new Linux machines via AutoYast works basically fine so far. The installations are triggert with PXE-Boot over the Network. For the basic installation I have created various XML Files for AutoYast. eth_default_dhcp.xml: -------------------------------------------------------------------------------- <?xml version="1.0"?> <!DOCTYPE profile SYSTEM "/usr/share/autoinstall/dtd/profile.dtd"> <profile xmlns="http://www.suse.com/1.0/yast2ns" xmlns:config="http://www.suse.com/1.0/configns"> <configure> <networking> <dns> <dhcp_hostname config:type="boolean">true</dhcp_hostname> <dhcp_resolv config:type="boolean">true</dhcp_resolv> <domain>domain.test</domain> <nameservers config:type="list"> <nameserver>192.169.40.25</nameserver> </nameservers> <searchlist config:type="list"> <search>domain.test</search> </searchlist> </dns> <interfaces config:type="list"> <interface> <bootproto>dhcp</bootproto> <device>eth0</device> <startmode>onboot</startmode> </interface> </interfaces> <routing> <ip_forward config:type="boolean">false</ip_forward> <routes config:type="list"> <route> <destination>default</destination> <device>eth0</device> <gateway>192.168.40.1</gateway> <netmask>255.255.255.0</netmask> </route> <route> <destination>192.168.40.0</destination> <device>eth0</device> <gateway>default</gateway> <netmask>255.255.255.0</netmask> </route> <route> <destination>192.168.41.0</destination> <device>eth0</device> <gateway>default</gateway> <netmask>255.255.255.0</netmask> </route> </routes> </routing> </networking> </configure> </profile> -------------------------------------------------------------------------------- The problem is, that in the first part of the AutoYast installation (when the RPMs are installed) the new machine knows its IP adress but not the Computer Name. Only after the reboot when the second part of the installtion starts, the hostname is set correctly. I have identified 3 RPMs so far which need the hostname in the first part of the installation (aaa_base, postfix and a custom made one). For testing, I addded the hostname to <hostname>testhost</hostname> and set <dhcp_hostname config:type="boolean">true</dhcp_hostname> to false, and then the hostname was "ok" also in the first step of the installation, and all RPMs are installed as expected. Is this a bug in AutoYast ? Does anybody have a hint on how I should try to publish the hostname by DHCP "in time" ? Thanks in advance, Christoph ---- Hol Dir jetzt Deine coole @uni.de E-Mail Adresse. Der einzigartige Webservice und auch noch kostenlos. -- www.uni.de -- -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-autoinstall+help(a)opensuse.org

4 3

[opensuse-autoinstall] addon repositories vs. create_package_descr
by Frank Steiner 21 Jan '08

21 Jan '08

Hi, I've put the SuSE 10.1 sources into a directory SuSE/, created a SuSE/updates directory with the create_update_source.sh script and put some of my own RPMs into it. Works fine, AY finds and installs them. Now guess that I want to add all RPMs from SLED10 to my SuSE sources so that AY installs SLED10 packages when they are newer as SuSE (let's not discuss if this makes sense for now :-)). I tried a) define SLED10 as addon product. Unsolvable dependencies, e.g. suse-release.rpm vs. sled-release.rpm etc. b) in SuSE/updates/suse/ call /usr/bin/create_package_descr -l english -l german -d . \ -d /whereever/SLED10/suse/ and pass only SuSE/updates/ as addon source to AY. -> "packages" file contains all SLED10 packages, AY manages to solve dependencies, but segfaults when starting to install. I guess it cannot access the /whereever/SLED10/suse/ directory because it doesn't know where it is. c) bind-mount the SLED10/suse/ directory at SuSE/updates/suse/sled10/ -> create_packages_descr doesn't find them because it searches with maxdepth 2. d) like b) but call the script with "-d . -d sles10 -d sled10". AY finds all packages, even starts installing, but says it will install only 3.5GB instead of the 9.5GB it usually would (without the additional sles10/sled10 packages) and fails at many packages during the installation process. Looks like it would only install from the updates/ dir, ignoring the normal SuSE/ path. So, is there any way to achieve what I want? Just add a bunch of RPMs with newer releases from a product like SLED10 without copying all those RPMs into the update/ dir? And what's the correct way to work with the -d parameter? Can it work only for subdirs of the updates/suse/ dir? cu, Frank -- Dipl.-Inform. Frank Steiner Web: http://www.bio.ifi.lmu.de/~steiner/ Lehrstuhl f. Bioinformatik Mail: http://www.bio.ifi.lmu.de/~steiner/m/ LMU, Amalienstr. 17 Phone: +49 89 2180-4049 80333 Muenchen, Germany Fax: +49 89 2180-99-4049 * Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. * -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-autoinstall+help(a)opensuse.org

1 0

Re: [opensuse-autoinstall] AutoYast SLES9 SP3 problem with hostname via DHCP
by chrroe＠uni.de 18 Jan '08

18 Jan '08

Hello Uwe! Can you please say something to the described problem in this thread? Is it possible to figure out the provided DHCP-Hostname during AutoYast stage 1? Or at least during stage 2 when more shell commands are availible? What would be the most practicable way? How else can I solve my problems? Thanks in advance ... Dank im Voraus ... Bye Christoph ---- Hol Dir jetzt Deine coole @uni.de E-Mail Adresse. Der einzigartige Webservice und auch noch kostenlos. -- www.uni.de -- -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-autoinstall+help(a)opensuse.org

1 0

Wtrlt: Antw: Re: Antw: Re: [opensuse-autoinstall] signing add_on_products
by Jochen Schaefer 18 Jan '08

18 Jan '08

Forward this mail again, cause it does not reach the list Sorry

2 2

[opensuse-autoinstall] signing add_on_products
by Jochen Schaefer 16 Jan '08

16 Jan '08

Hi list, I'm looking for some hints how to sign my add_on_product to avoid messages during installations. I know the faq of Uwe Gansert and I followed the described steps but still have some problems: This not an automated installation - I'm not using an autoyast.xml file I did following steps: create-addonpackage.sh placed an add_on_products file to the SLES10-SP1 CD1-root created SHA1 checksums for all files contained in suse/setup/descr of my addon_product and created the appropriate entries in content file gpg --export --armor <my $KEY_ID> > content.key gpg -b --sign --armor content ls > directory.yast unpackInitrd initrd cd /tmp/work-initrd gpg --export --armor <my $KEY_ID> > my-key.gpg find . | cpio -H newc -o > /tmp/initrd gzip /tmp/initrd mv /tmp/initrd.gz /place/for/initrd moved the initrd to SLES10-SP1/boot/i386/loader/initrd However when I install SLES10-SP1-i386 it finds my addon_product but complains about an unknown key and ask if I want to import that key. >From faq I understood that this steps will be automatically done. Did I miss something? I understood that when placing my-key.gpg on top of SLES10-SP1-CD1 it will automatically imported. Can I use an arbitrary name for my gpg-key or should it be named to "my-key.gpg"? Thanks Jochen -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-autoinstall+help(a)opensuse.org

2 1

[opensuse-autoinstall] basic SLES10SP1 autoyast unattended install problems
by John SJ Anderson 03 Jan '08

03 Jan '08

Sorry for what may be a stupid and/or FAQ -- Google isn't being my friend and the list archive search function is disabled at the moment. I'm trying to set up a SLES10SP1 AutoYast server. I've got the CD images copied onto disk, and I can boot a target server and have it use the install server and the configuration file and everything works. The only problem is that I can't seem to get it to do a completely automated install -- it pauses at the 'Installation Settings' screen and I have to hit 'Accept' to get it to go on. I'm using the "simplest possible config" from the FAQ page: <?xml version="1.0"?> <!DOCTYPE profile SYSTEM "/usr/share/autoinstall/dtd/profile.dtd"> <profile xmlns="http://www.suse.com/1.0/yast2ns" xmlns:config="http://www.suse.com/1.0/configns"> <partitioning config:type="list"> <drive> <use>all</use> </drive> </partitioning> <users config:type="list"> <user> <encrypted config:type="boolean">false</encrypted> <user_password>yeahright</user_password> <username>root</username> </user> </users> </profile> I'm reasonably sure that everything else is good to go, as I said, because if I do hit 'return' on the Accept button the install runs and finishes. I have applied the 'sles10sp1_root_fix_v0.4' fix; the driverupdate file is in the CD1 directory and I see messages about it being applied. Further details: Dell 1750 (32bit Xeon, Tigon3 NIC), booting off the CD1, specifying text mode install via F3, specifying NFS install via F4, giving further boot param 'autoyast=nfs://$SERVER_IP/install/generic.xml', which is where that file above lives. I was not having this problem with SLES9SP3 but our partitioning configs are much more elaborate that the simple example config. I guess I'll try using the partitioning section from one of those configs next and see if that resolves the problem. Thanks for any suggestions/pointers. john. -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-autoinstall+help(a)opensuse.org

2 3

[opensuse-autoinstall] nfs_server: cannot update idmap.conf
by Lars Stavholm 03 Jan '08

03 Jan '08

Hi list, We're using SuSE 10.3 retail autoyast, and with some recent advice from Uwe, it works like a charm, except for one minor detail: When reaching the System Configuration stage, specifically the Configuring nfs_server step, we get a pop-up saying "Unable to write to idmapd.conf". A quick check under the hood at that point reveals that the /etc/idmapd.conf file is indeed present and has some content. The permissions on the file allows root to write to it. /etc/idmapd.conf seems to be part of the nfs-client package, which seems to be installed alright. It's a minor annoyance, but still, the installation is now not really unattended, since we have to be there to click OK on the pop-up to let the installation continue. Any advice appreciated. R /Lars -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-autoinstall+help(a)opensuse.org

4 4