From simon.loewenthal@klunky.co.uk Tue Sep 1 15:17:07 2009 From: Simon Loewenthal/NL/Tele2 To: autoinstall@lists.opensuse.org Subject: [opensuse-autoinstall] Deriving hostname for .xml file from PXE client & setting values in /etc/sysctl.conf Date: Tue, 01 Sep 2009 17:18:00 +0200 Message-ID: <4A9D3B28.4060909@klunky.co.uk> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2588181879610871399==" --===============2588181879610871399== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Dear all, Question 1: I am trying to construct a generic autoinst.xml file for several clients. The template I am using is the one generated from one server, an HP Blade, found in /root/autoinst.xml. I intend to use this from within a file called this, (the MAC address is made up) # cat /tftpboot/pxelinux.cfg/00-00-00-00-00-00-01 default SLES11 # install SLES11 - Dummy entry for generic profile label SLES11 kernel vmlinuz append initrd=initrd ramdisk_size=65536 install=nfs://10.205.8.145/export/sles11-dvd1-i586 hostip=10.205.8.123/24 autoyast=nfs://10.205.8.145/export/generica-sles11_i586-autoinst.xml netdevice=eth0 textmode=1 insmod=bnx2 The autogenerated file contains host specific entries like, 10.254.66.90 newHPserver newHPserver 127.0.0.1 localhost 127.0.0.2 newHPserver.it.lan newHPserver I would like to have this xml inherit the hostname, IP address from the client that called it. Question 2: In most cases these servers will run Oracle. Therefore I would like to some how add values for shmmni shmmax and so on for Oracle. I expect to have a separate .xml file somewhere that would set these values. What is the way to so this? I thought that I could use some xml like this but I don;'t know if this is the preferred way in the SUSE world? How would I instruct autoyast to call this file? Regards, S. -- Simon Loewenthal/Tele2 GSM: +31 6 2000 5427 [ -d . ] || echo "Oh!" ******** IMPORTANT NOTICE ******** This e-mail (including any attachments) may contain information that is confidential or otherwise protected from disclosure and it is intended only for the addressees. If you are not the intended recipient, please note that any copying, distribution or other use of information contained in this e-mail (and its attachments) is not allowed. If you have received this e-mail in error, kindly notify us immediately by telephone or e-mail and delete the message (including any attachments) from your system. Please note that e-mail messages may contain computer viruses or other defects, may not be accurately replicated on other systems, or may be subject of unauthorized interception or other interference without the knowledge of sender or recipient. Tele2 only send and receive e-mails on the basis that Tele2 is not responsible for any such computer viruses, corruption or other interference or any consequences thereof. -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-autoinstall+help(a)opensuse.org --===============2588181879610871399==-- From mmarion@qualcomm.com Tue Sep 1 17:59:48 2009 From: Mike Marion To: autoinstall@lists.opensuse.org Subject: Re: [opensuse-autoinstall] Deriving hostname for .xml file from PXE client & setting values in /etc/sysctl.conf Date: Tue, 01 Sep 2009 11:00:58 -0700 Message-ID: <20090901180057.GA4518@sunapee.qualcomm.com> In-Reply-To: <4A9D3B28.4060909@klunky.co.uk> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2479457338798775788==" --===============2479457338798775788== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Tue, Sep 01, 2009 at 08:18:00AM -0700, Simon Loewenthal/NL/Tele2 wrote: > I would like to have this xml inherit the hostname, IP address from the > client that called it. You can basically re-write the entire profile in the pre-install scripts if you want, and could do what you're looking to do (and a lot more) there. Just output a /tmp/profile/modified.xml file and it'll be re-read after the pre-install scripts are run. I do several things using comment tags that are replaced by a pre-install script that replaces them based on common names.. e.g. compute_single.xml: SWAP_DEFAULTS scripts.xml: NET_DEFAULTS scripts.xml: NIS_DEFAULTS scripts.xml: NTP_DEFAULTS scripts.xml: CLK_DEFAULT scripts.xml: ADDON_DEFAULTS scripts.xml: ROOTWORD_DEFAULT scripts.xml: TZ_DEFAULT The script looks for any VALUE_DEFAULTS then in a case statement runs the right subroutine to replace the comment tags with xml for the profile.. the above do things like dynamically set the swap space (different admins in our offices wanted to be able to set different amounts of swap), outputs the entire section (which is what you're mostly looking for), NIS info (mostly deprecated), etc. These were originally put in place to allow a shared set of identical files with one configuration file per site read in to put in site specific values without super complicated rules.xml setups, which have their own short-comings. > > > How would I instruct autoyast to call this file? You can also do this type of thing in either the chroot or post-install scripts. The ways to do pre/chroot/post scripts are pretty well documented in the autoyast docs. -- Mike Marion-Unix SysAdmin/Staff IT Engineer-http://www.qualcomm.com "Only wimps use tape backup: _real_ men just upload their important stuff on ftp, and let the rest of the world mirror it ;)" (Linus Torvalds, about his failing hard drive on linux.cs.helsinki.fi) -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-autoinstall+help(a)opensuse.org --===============2479457338798775788==-- From ug@suse.de Wed Sep 2 08:51:14 2009 From: Uwe Gansert To: autoinstall@lists.opensuse.org Subject: Re: [opensuse-autoinstall] An error occurred during initrd creation. Date: Wed, 02 Sep 2009 10:52:33 +0200 Message-ID: <200909021052.33816.ug@suse.de> In-Reply-To: <4A70E847.2040702@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1818631421854928516==" --===============1818631421854928516== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit on Thursday 30 July 2009 limited.address wrote: > Using 11.2 M4 for repository > Using "smallest autoyast profile that makes sense" > Using 11.2 M4 files to build boot disk > > "An error occurred during initrd creation." > > What do I do now? I finally got the time to look into that on 11.2 you can workaround that error by adding yast2-bootloader to your package list. you'll run into another error in the second stage unless you add yast2-slp too. Both should be fixed with milestone 7. -- ciao, Uwe Gansert Uwe Gansert SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Business: http://www.suse.de/~ug -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-autoinstall+help(a)opensuse.org --===============1818631421854928516==-- From Thomas.Zimolong@bmi.bund.de Wed Sep 2 16:30:12 2009 From: Thomas.Zimolong@bmi.bund.de To: autoinstall@lists.opensuse.org Subject: [opensuse-autoinstall] SLES10 SP2 how to integrate dud and autoyast? Date: Wed, 02 Sep 2009 18:30:54 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0267815049174255639==" --===============0267815049174255639== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hello All! In short: I need to integrate an HP-delivered DUD in my network-based autoyast-configuration with loopback mounted installation sources. Here's the whole story (sorry for the lengthy description): I have an existing environment with a PXE-server and an autoyast install server. I have to install some HP blades (460c G6) with a FLEX10 emulated NIC that needs a newer version of kernel module bnx2x than provided by the SLES10SP2 initrd. Concerning the initrd, I replaced the initrd on the PXE-server with the one provided by HP according to : << http://h18006.www1.hp.com/products/servers/management/rdp/knowledgebase/00000 197.html>> The installation is started from pxelinux.cfg/default with the following lines: --snip label auto10sp2_x86_64 menu label SLES10 SP2 (64 Bit) Automatische Installation kernel sles10sp2_x86_64/linux append initrd=sles10sp2_x86_64/initrd ramdisk_size=131072 vga=791 splash=0 install=http://myserver.mydomain/inst_srv/SLES10_x86_64/SUSE-SLES-10-Service- Pack-Version-2/DVD1 textmode=1 lang=de_DE autoyast=http://myserver.mydomain/inst_srv/autoyast/sles10sp2_x86_64-default/ --snap So far everything works fine, the first stage of the autoyast installation runs without problems. Now I have to tell autoyast to use the HP-provided Driver Update Disk to install the module to the installed system. HP delivers a file that is to be renamed to "driverupdate" and to be placed in the installation source. The installation source consists of loopback mounts of the SLES10-DVDs. The Problem is, that autoyast seems to look for the file "driverupdate" which is the root of DVD1. Since this is an ISO9660 I can't place the file there. When I copy the whole DVD to the filesystem of the install server an put the driverupdate there, the installation works, but since disk space is an issue on my install server, this is not a long term solution. Now I was playing around with some ways to change the path to driverupdate. 1) I tried to hand over some command line options to the kernel, like "dud=http://myserver...." Or "driverupdate=http://myserver....", like described in << http://en.opensuse.org/Linuxrc#p_dud>> but none of them worked. Then I found << http://www.suse.de/~ug/autoyast_doc/info_file_format.html>> stating no "dud" or "driverupdate" parameter. Hm,...? 2) I tried to put the info file section in my autoyast profile like in 7.3.3 of << http://www.suse.de/~ug/autoyast_doc/invoking_autoinst.html#id339566>> but that also didn't work: --snip --snap As far as I understood, linuxrc looks for the info file but if this fails it looks for additional parameters on the kernel commandline. Could it be that "dud" or "driverupdate" isn't supported in SLES10SP2? Do I have to look for a bug in the HP initrd? I looked inside the initrd, but can't seem to find any file named "info". Any hints or experiences with that topic? Greetz Thomas -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-autoinstall+help(a)opensuse.org --===============0267815049174255639==-- From manfred@die-hollsteins.de Wed Sep 2 16:52:28 2009 From: Manfred Hollstein To: autoinstall@lists.opensuse.org Subject: Re: [opensuse-autoinstall] SLES10 SP2 how to integrate dud and autoyast? Date: Wed, 02 Sep 2009 18:53:43 +0200 Message-ID: <20090902165342.GB7516@saturn.hollstein.homelinux.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4187378893889026024==" --===============4187378893889026024== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hi there, On Wed, 02 Sep 2009, 18:30:54 +0200, Thomas.Zimolong(a)bmi.bund.de wrote: > [...] The > Problem is, that autoyast seems to look for the file "driverupdate" which is > the root of DVD1. Since this is an ISO9660 I can't place the file there. > When I copy the whole DVD to the filesystem of the install server an put the > driverupdate there, the installation works, but since disk space is an issue > on my install server, this is not a long term solution. Why don't you just "lndir" the whole loopback-mounted ISO to some directory accessible by your installation server and create the "driverupdate" there? HTH, cheers. l8er manfred -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-autoinstall+help(a)opensuse.org --===============4187378893889026024==-- From jakinne@gmail.com Wed Sep 2 20:15:42 2009 From: Justin Kinney To: autoinstall@lists.opensuse.org Subject: [opensuse-autoinstall] createrepo breaks installation server Date: Wed, 02 Sep 2009 15:16:38 -0500 Message-ID: <535b27a10909021316n407497c2ye189957a4bf7d465@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4387689994388011343==" --===============4387689994388011343== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hello, I've got a sles 10 sp2 installation server accessed by clients via http which has been working fine. I recently used createrepo to build the repomd.xml and other files necessary to use this source as a repo for packages by zypper clients. This too seems to have worked for providing package dependencies for clients that were not originally installed on the host. My problem is that now, whenever I try to build a new host, I get a message similar to "cannot find pattern: base". The installation continues, but based on the package counts being installed, there are many missing packages. The system later fails while trying to install grub. Removing the repodata folder from the installation sources fixes this. How can I use the same repository to both offer installation sources and later be used as a zypper repo? Thanks, Justin -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-autoinstall+help(a)opensuse.org --===============4387689994388011343==-- From Thomas.Zimolong@bmi.bund.de Thu Sep 3 08:20:14 2009 From: Thomas.Zimolong@bmi.bund.de To: autoinstall@lists.opensuse.org Subject: AW: [opensuse-autoinstall] SLES10 SP2 how to integrate dud andautoyast? Date: Thu, 03 Sep 2009 10:21:01 +0200 Message-ID: In-Reply-To: <20090902165342.GB7516@saturn.hollstein.homelinux.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4373684519354878603==" --===============4373684519354878603== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > Why don't you just "lndir" the whole loopback-mounted ISO to some > directory accessible by your installation server and create the > "driverupdate" there? > > HTH, cheers. > > l8er > manfred Hi! Thanks for your advice! Just tested this workaround and it did the job. At least this saves me the disk space. Sometimes one gets so stuck that the obvious is left aside unnoticed. Nevertheless, I think there must be an actual solution using the means of linuxrc and autoyast. So, @all, if anyone has further advice on this it would be appreciated!!! Many thanks again to Manfred! Greetings from Berlin, Thomas -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-autoinstall+help(a)opensuse.org --===============4373684519354878603==-- From ug@suse.de Thu Sep 3 08:41:17 2009 From: Uwe Gansert To: autoinstall@lists.opensuse.org Subject: Re: [opensuse-autoinstall] SLES10 SP2 how to integrate dud and autoyast? Date: Thu, 03 Sep 2009 10:42:39 +0200 Message-ID: <200909031042.39447.ug@suse.de> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4065279014244918682==" --===============4065279014244918682== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit on Wednesday 02 September 2009 Thomas.Zimolong(a)bmi.bund.de wrote: > 1) I tried to hand over some command line options to the kernel, like > "dud=http://myserver...." Or "driverupdate=http://myserver....", like > described in << http://en.opensuse.org/Linuxrc#p_dud>> but none of them > worked. Then I found << that does not work on SLES10. It works for SLES11 though > http://www.suse.de/~ug/autoyast_doc/info_file_format.html>> stating no > "dud" or "driverupdate" parameter. Hm,...? the driverupdate is actually not part of autoyast. It's used for autoyast installations sometimes to fix a bug in autoyast itself but it's not an autoyast mechanism. This links http://en.opensuse.org/Linuxrc is the right one > As far as I understood, linuxrc looks for the info file but if this fails > it looks for additional parameters on the kernel commandline. Could it be > that "dud" or "driverupdate" isn't supported in SLES10SP2? that's right. driverupdates on remote sources is not supported in SLES10 So Manfred's solution is the only one I have in mind too. Besides putting it on a floppy disk which is kind of archaic since there are hardly any of those left in modern machines. -- ciao, Uwe Gansert Uwe Gansert SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Business: http://www.suse.de/~ug -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-autoinstall+help(a)opensuse.org --===============4065279014244918682==-- From Thomas.Zimolong@bmi.bund.de Thu Sep 3 08:54:15 2009 From: Thomas.Zimolong@bmi.bund.de To: autoinstall@lists.opensuse.org Subject: AW: [opensuse-autoinstall] SLES10 SP2 how to integrate dud and autoyast? Date: Thu, 03 Sep 2009 10:53:49 +0200 Message-ID: In-Reply-To: <200909031042.39447.ug@suse.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1597365304755408629==" --===============1597365304755408629== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hi! > that does not work on SLES10. It works for SLES11 though ... > that's right. driverupdates on remote sources is not supported in SLES10 > So Manfred's solution is the only one I have in mind too. Besides putting it > on a floppy disk which is kind of archaic since there are hardly any of those > left in modern machines. Ah, ok, so I know, there's no need to think about it anymore. We will check this again on our way to SLES11. Thanks again for the fast and helpful answers! By, Thomas -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-autoinstall+help(a)opensuse.org --===============1597365304755408629==-- From ug@suse.de Thu Sep 3 13:15:53 2009 From: Uwe Gansert To: autoinstall@lists.opensuse.org Subject: Re: [opensuse-autoinstall] createrepo breaks installation server Date: Thu, 03 Sep 2009 15:17:15 +0200 Message-ID: <200909031517.15693.ug@suse.de> In-Reply-To: <535b27a10909021316n407497c2ye189957a4bf7d465@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6847195326728815763==" --===============6847195326728815763== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit on Wednesday 02 September 2009 Justin Kinney wrote: > I recently used createrepo to build the repomd.xml and other files > necessary to use this source as a repo for packages by zypper clients. > > This too seems to have worked for providing package dependencies for > clients that were not originally installed on the host. > > My problem is that now, whenever I try to build a new host, I get a > message similar to "cannot find pattern: base". The installation you want to install from a repository with repomd.xml? That does not work. That repository format does not support patterns AFAIK. Why don't you use "create_update_source.sh" from my homepage instead? That should work > How can I use the same repository to both offer installation sources > and later be used as a zypper repo? create_update_source.sh should work -- ciao, Uwe Gansert Uwe Gansert SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Business: http://www.suse.de/~ug -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-autoinstall+help(a)opensuse.org --===============6847195326728815763==-- From it-support@asta.tu-darmstadt.de Fri Sep 4 08:24:50 2009 From: Ivan De Masi To: autoinstall@lists.opensuse.org Subject: [opensuse-autoinstall] OT: Centralized patch management for OpenSuse 11.x Date: Fri, 04 Sep 2009 10:26:09 +0200 Message-ID: <4AA0CF21.2060000@asta.tu-darmstadt.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7078528738449067875==" --===============7078528738449067875== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hello, someone may start to laugh now for my (OT) question, but I can't find a satisfying solution :-/ How do you manage patches, updates, etc. for your running opensuse clients (not enterprise linux, just the "regular" opensuse distribution)? Is there a way like known from M$-World (WSUS)? As I know "Zend Management Server" is not open source (and not supported any more?!). Or can the complete management only be handled with self written scripts? Thanks! Regards, Ivan -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-autoinstall+help(a)opensuse.org --===============7078528738449067875==-- From kmachalkova@suse.cz Fri Sep 4 11:49:55 2009 From: Katarina Machalkova To: autoinstall@lists.opensuse.org Subject: Re: [opensuse-autoinstall] OT: Centralized patch management for OpenSuse 11.x Date: Fri, 04 Sep 2009 13:51:17 +0200 Message-ID: <200909041351.20129.kmachalkova@suse.cz> In-Reply-To: <4AA0CF21.2060000@asta.tu-darmstadt.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5717824682684785000==" --===============5717824682684785000== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hi, > someone may start to laugh now for my (OT) question, but I can't find a > satisfying solution :-/ > > How do you manage patches, updates, etc. for your running opensuse > clients (not enterprise linux, just the "regular" opensuse distribution)? Erm, I'm not sure if I understand correctly what you're asking about, but guessing from keyword "centralized" in $subject, I'd say that you're looking for something like this: http://www.novell.com/linux/smt/ http://www.novell.com/linux/smt/faq.html Unfortunately, even though SMT is GPLed, it is targeted at enterprise product(s), and afaik, we don't have any openSUSE equivalent of it. hB. -- \\\\\ Katarina Machalkova \\\\\\\__o YaST developer __\\\\\\\'/_ & hedgehog painter -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-autoinstall+help(a)opensuse.org --===============5717824682684785000==-- From simon.loewenthal@klunky.co.uk Fri Sep 4 12:23:24 2009 From: Simon Loewenthal/NL/Tele2 To: autoinstall@lists.opensuse.org Subject: Re: [opensuse-autoinstall] Deriving hostname for .xml file from PXE client & setting values in /etc/sysctl.conf Date: Fri, 04 Sep 2009 14:24:28 +0200 Message-ID: <4AA106FC.7020504@klunky.co.uk> In-Reply-To: <20090901180057.GA4518@sunapee.qualcomm.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5553283474022024296==" --===============5553283474022024296== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Dear all, I set-up the server, and it passes out the DHCP lease as shown below. However, when the client tries to contact the TFTP server it attempts to do so on 0.0.0.0 instead of t2nl-app205.versatel.com. Below are the files and part of a tcpdump from the session detailing some of the TFTP communication. Somethin I have missed but what it is I do not know. Does anyone else know? Best regards, S. 14:02:42.960262 IP t2nl-app205.versatel.com.32799 > 10.205.8.254.acp-port: UDP, length 1460 14:02:42.960815 IP 10.205.8.254.acp-port > t2nl-app205.versatel.com.32799: UDP, length 4 14:02:42.960836 IP t2nl-app205.versatel.com.32799 > 10.205.8.254.acp-port: UDP, length 48 14:02:42.961127 IP 10.205.8.254.acp-port > t2nl-app205.versatel.com.32799: UDP, length 4 14:02:43.006899 IP 10.205.8.254.57089 > *0.0.0.0*.tftp: 63 RRQ "pxelinux.cfg/01-00-23-7d-a8-0a-54" octet tsize 0 blksize 1440 14:02:43.713904 IP 10.205.8.254.57089 > *0.0.0.0*.tftp: 63 RRQ "pxelinux.cfg/01-00-23-7d-a8-0a-54" octet tsize 0 blksize 1440 14:02:45.197284 IP 10.205.8.254.57089 > *0.0.0.0*.tftp: 63 RRQ "pxelinux.cfg/01-00-23-7d-a8-0a-54" octet tsize 0 blksize 1440 14:02:47.948824 arp who-has 10.205.8.254 tell t2nl-app205.versatel.com 14:02:47.949072 arp reply 10.205.8.254 is-at 00:23:7d:a8:0a:54 (oui Unknown) 14:02:48.118658 IP 10.205.8.254.57089 > 0.0.0.0.tftp: 63 RRQ "pxelinux.cfg/01-00-23-7d-a8-0a-54" octet tsize 0 blksize 1440 14:02:53.947311 IP 10.205.8.254.57089 > 0.0.0.0.tftp: 63 RRQ "pxelinux.cfg/01-00-23-7d-a8-0a-54" octet tsize 0 blksize 1440 14:03:05.594568 IP 10.205.8.254.57089 > 0.0.0.0.tftp: 63 RRQ "pxelinux.cfg/01-00-23-7d-a8-0a-54" octet tsize 0 blksize 1440 14:03:28.879831 IP 10.205.8.254.57090 > 0.0.0.0.tftp: 51 RRQ "pxelinux.cfg/0ACD08FE" octet tsize 0 blksize 1440 14:03:29.620095 IP 10.205.8.254.57090 > 0.0.0.0.tftp: 51 RRQ "pxelinux.cfg/0ACD08FE" octet tsize 0 blksize 1440 # cat /etc/xinetd.d/tftp # default: off # description: tftp service is provided primarily for booting or when a \ # router need an upgrade. Most sites run this only on machines acting as # "boot servers". service tftp { socket_type = dgram protocol = udp wait = yes user = root server = /usr/sbin/in.tftpd server_args = -s /tftpboot disable = no } # find /tftpboot/ -ls 185858 4 drwxr-xr-x 5 root root 4096 Sep 3 17:23 /tftpboot/ 185859 16 -rw-r--r-- 1 root root 13148 Dec 23 2008 /tftpboot/pxelinux.0 185860 4 drwxr-xr-x 2 root root 4096 Sep 3 17:15 /tftpboot/pxelinux.cfg 185868 4 -rw-r--r-- 1 root root 291 Sep 3 16:34 /tftpboot/pxelinux.cfg/01-00-1b-78-76-36-02 185872 0 lrwxrwxrwx 1 root root 20 Sep 3 15:41 /tftpboot/pxelinux.cfg/0ACD08FE -> 01-00-23-7d-a8-0a-54 185873 4 -rw-r--r-- 1 root root 438 Sep 3 16:34 /tftpboot/pxelinux.cfg/default 185875 4 -rw-r--r-- 1 root root 333 Sep 3 17:15 /tftpboot/pxelinux.cfg/01-00-23-7d-a8-0a-54 185861 136 -rw-r--r-- 1 root root 135168 Dec 24 2008 /tftpboot/message 185863 0 lrwxrwxrwx 1 root root 23 Dec 24 2008 /tftpboot/initrd -> initrd-2.4.21-32.EL.img 185865 0 lrwxrwxrwx 1 root root 20 Dec 24 2008 /tftpboot/vmlinuz -> vmlinuz-2.4.21-32.EL 185864 4 drwxr-xr-x 2 root root 4096 Sep 3 13:39 /tftpboot/sles11_i586 185867 2404 -r--r--r-- 1 root root 2455600 Aug 31 17:07 /tftpboot/sles11_i586/linux 185870 20852 -r--r--r-- 1 root root 21319984 Aug 31 17:07 /tftpboot/sles11_i586/initrd 185862 1228 -rw-r--r-- 1 root root 1252573 Dec 24 2008 /tftpboot/vmlinuz-2.4.21-32.EL 185866 520 -rw-r--r-- 1 root root 528338 Dec 24 2008 /tftpboot/initrd-2.4.21-32.EL.img 185871 4 drwxr-xr-x 2 root root 4096 Sep 3 13:40 /tftpboot/sles11_x86 185869 4 -rw-r--r-- 1 root root 333 Sep 3 17:23 /tftpboot/01-00-23-7d-a8-0a-54 # cat /tftpboot/pxelinux.cfg/01-00-23-7d-a8-0a-54 default SLES11 # install SLES11 - Dummy entry for generic profile label SLES11 kernel /sles11_i586/linux append initrd=initrd ramdisk_size=65536 install=nfs://10.205.8.145/export/sles11-dvd1-i586 hostip=10.205.8.254/24 autoyast=nfs://10.205.8.145/export/generica-sles11_i586-autoinst.xml netdevice=eth0 textmode=1 insmod=bnx2 -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-autoinstall+help(a)opensuse.org --===============5553283474022024296==-- From oliver.schweikert@horiba.com Tue Sep 8 11:05:07 2009 From: Oliver Schweikert To: autoinstall@lists.opensuse.org Subject: [opensuse-autoinstall] Installation (SLES10-SP2) destroys USB Flash Drive Date: Tue, 08 Sep 2009 13:06:27 +0200 Message-ID: <4AA63AB3.6090909@horiba.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7823765587226408324==" --===============7823765587226408324== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Hello all, I read the autoyast profiles for installation from an USB flash drive. This worked so far with many different drives, but now i have a problem with a 8GB drive (Imation Nano Pro, with password protection). The first time, yast can successfully read the profile and starts the installation. The second time, after abort, the same drive cannot be accessed anymore. I made 2 test with 2 different computers: One drive has now invalid vendor, product name, etc, the second one seems to have valid metadata. But both fail to report anything by sfdisk or fdisk. I tried both types of URL: usb:///... and device://sdb1/... Has anyone an idea what yast (or another part of installation process) is doing, that could mess up the firmware? Maybe a USB/SCSI command, that is unusual to a USB drive? Best Regards, Oliver This are the kernel messages when plugging in a working drive: usb 4-2: new high speed USB device using ehci_hcd and address 6 usb 4-2: new device found, idVendor=0718, idProduct=043b usb 4-2: new device strings: Mfr=1, Product=2, SerialNumber=3 usb 4-2: Product: Nano Pro usb 4-2: Manufacturer: Imation usb 4-2: SerialNumber: 078C171929B4 usb 4-2: configuration #1 chosen from 1 choice scsi8 : SCSI emulation for USB Mass Storage devices usb-storage: device found at 6 usb-storage: waiting for device to settle before scanning scsi 8:0:0:0: Direct-Access Imation Nano Pro PMAP PQ: 0 ANSI: 0 CCS sd 8:0:0:0: [sdb] 15646720 512-byte hardware sectors (8011 MB) sd 8:0:0:0: [sdb] Write Protect is off sd 8:0:0:0: [sdb] Mode Sense: 23 00 00 00 sd 8:0:0:0: [sdb] Assuming drive cache: write through sd 8:0:0:0: [sdb] 15646720 512-byte hardware sectors (8011 MB) sd 8:0:0:0: [sdb] Write Protect is off sd 8:0:0:0: [sdb] Mode Sense: 23 00 00 00 sd 8:0:0:0: [sdb] Assuming drive cache: write through sdb: sdb1 sd 8:0:0:0: [sdb] Attached SCSI removable disk sd 8:0:0:0: Attached scsi generic sg2 type 0 usb-storage: device scan complete and this are the ones of the same drive after installation: usb 4-2: new high speed USB device using ehci_hcd and address 10 usb 4-2: new device found, idVendor=0718, idProduct=043b usb 4-2: new device strings: Mfr=1, Product=2, SerialNumber=3 usb 4-2: Product: Nano Pro usb 4-2: Manufacturer: Imation usb 4-2: SerialNumber: 078C171929B4 usb 4-2: configuration #1 chosen from 1 choice scsi12 : SCSI emulation for USB Mass Storage devices usb-storage: device found at 10 usb-storage: waiting for device to settle before scanning scsi 12:0:0:0: Direct-Access Imation Nano Pro PMAP PQ: 0 ANSI: 0 CCS sd 12:0:0:0: [sdb] Attached SCSI removable disk sd 12:0:0:0: Attached scsi generic sg2 type 0 usb-storage: device scan complete This is the output of the broken drive with the screwed up metadata. It is the same product as the other one! usb 4-2: new high speed USB device using ehci_hcd and address 11 usb 4-2: new device found, idVendor=13fe, idProduct=1d00 usb 4-2: new device strings: Mfr=1, Product=2, SerialNumber=0 usb 4-2: Product: USB DISK 30X usb 4-2: Manufacturer: usb 4-2: configuration #1 chosen from 1 choice scsi13 : SCSI emulation for USB Mass Storage devices usb-storage: device found at 11 usb-storage: waiting for device to settle before scanning scsi 13:0:0:0: Direct-Access USB DISK 30X 1.00 PQ: 0 ANSI: 0 CCS sd 13:0:0:0: [sdb] Attached SCSI removable disk sd 13:0:0:0: Attached scsi generic sg2 type 0 usb-storage: device scan complete -- Oliver Schweikert Software Development HORIBA Europe Automation Division GmbH Zabergäustr. 3 73765 Neuhausen (Germany) Tel: +49 7158-933-413 Fax: +49 7158-933-613 Email: oliver.schweikert(a)horiba.com Geschäftsführer: Thomas E. Ehmann, Yuichi Muroga, Takashi Nagano Amtsgericht Stuttgart, HRB 213200 -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-autoinstall+help(a)opensuse.org --===============7823765587226408324==-- From guenther.haas@gmx.de Wed Sep 9 15:14:04 2009 From: Guenther Haas To: autoinstall@lists.opensuse.org Subject: [opensuse-autoinstall] openSUSE11.2-Milestone6 / rules / xsltproc missing!? Date: Wed, 09 Sep 2009 17:15:29 +0200 Message-ID: <4AA7C691.6000305@gmx.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4894615557138611106==" --===============4894615557138611106== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hi all! Today I spent some time testing our 11.1 autoinstallation with pxe boot, autoyast and rules with openSUSE-11.2-Milestone6 (from the DVD, 32 and 64 bit). After some minor problems and changes (mounting of our own scripts doesn't work because of missing portmap and nonworking(?) rpc.statd except I use the mount option "nolock"), the installations stops with the following error message and problem in the step "Processing Profiles and Rules": "sh: /usr/bin/xsltproc: No such file or directory" Clicking "OK" several times the next message says "A profile for this machine counld not be found or retrieved Check that you entered the correct location...". And in the logfile 'y2log" I find the following information > ... > > 2009-09-09 12:43:05 <1> sirius(3901) [YCP] AutoInstallRules.ycp:679 > Working on file: classes/netcard/primergy_rx300.xml > 2009-09-09 12:43:05 <1> sirius(3901) [YCP] AutoInstallRules.ycp:711 > Merge command: /usr/bin/xsltproc --novalid --param replace "'false'" > --param with > "'/tmp/YaST2-03901-2AVCCM/rules/classes/netcard/primergy_rx300.xml'" > --output /tmp/YaST2-03901-2AVCCM/result.xml > /usr/share/autoinstall/xslt/merge.xslt > /tmp/YaST2-03901-2AVCCM/base_profile.xml > 2009-09-09 12:43:05 <3> sirius(3901) [bash] > ShellCommand.cc(shellcommand):78 sh: /usr/bin/xsltproc: No such file > or directory > 2009-09-09 12:43:05 <1> sirius(3901) [YCP] AutoInstallRules.ycp:713 > Merge result: $["exit":127, "stderr":"sh: /usr/bin/xsltproc: No such > file or directory\n", "stdout":""] > 2009-09-09 12:43:05 <3> sirius(3901) [YCP] AutoInstallRules.ycp:716 > Merge Failed > 2009-09-09 12:43:05 <1> sirius(3901) [ui] > YPushButton.cc(setFunctionKey):183 Guessing button role YOKButton for > YPushButton "OK" at 0x8c8d6dc from function key F10 > 2009-09-09 12:43:05 <1> sirius(3901) [ui-shortcuts] > YShortcutManager.cc(checkShortcuts):127 No valid shortcut for YLogView > "Error" at 0x8af621c And really, "/usr/bin/xsltproc" is not available at this point of the installation. No package "libxslt-....rpm" is installed (in the initrd?). So the merging of xml files, e.g. described in the following way > ... > > That requires that yast has started at least once and autoyast has > fetched the XML profile. > If you don't have problems with the rules scripts, but with the > merging, you can merge the XML files like AutoYaST would do it to view > the result: > /usr/bin/xsltproc --novalid --param replace "'false'" \ > --param dontmerge1 "'package'" \ > --param with "'a.xml'" --output out.xml \ > /usr/share/autoinstall/xslt/merge.xslt base.xml > > ... > in the article "Why to Confirm? (Part 2)" at http://ugansert.blogspot.com/2009/02/why-to-confirm-part-2.html doesn't work. Has anybody tested something similar and maybe can confirm that observation? Best regards, -- Guenther Haas, Uni Ulm, Institut TAIT, guenther.haas(a)gmx.de --===============4894615557138611106== Content-Type: application/x-pkcs7-signature Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIME-Version: 1.0 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJQTCCAvsw ggJkoAMCAQICEEZMcGnbt3vM6IJQFKeujoowDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgxOTEzMTcyNVoXDTEwMDgxOTEzMTcy NVowXzENMAsGA1UEBBMESGFhczERMA8GA1UEKhMIR3VlbnRoZXIxFjAUBgNVBAMTDUd1ZW50aGVy IEhhYXMxIzAhBgkqhkiG9w0BCQEWFGd1ZW50aGVyLmhhYXNAZ214LmRlMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAu515Wk0l4fkBGeWFQ7O73ZLyKR4bpT+w1v4akhd0neMzyiLlVAEJ PnjasUd/EG6CuzvUf6TMSsIS5kWbKdSDIIbc4Tt+6DC2G5Pt1XfBrvWYHhFJZkVqHSnDb0tARN4H GD2O1jNL9Tjx+rwd4HCpxR1zYTVSHrSP80FJx1GpqMpYTo3US3APOsY2eu+fq9nOw3RlyaBaUd+0 ijD7HovwINPuO2H2LvcyER4XhXKw6g0WlLwCGJ7uF/ROwAUzuFyBv0zF4DSPb/ct+e/n00ozwVZq ChfjJdWFiW8rPIwTeUjRApBVvD40HPYYIHqVA73EKpes0bnrKRtN8MGglrVK6QIDAQABozEwLzAf BgNVHREEGDAWgRRndWVudGhlci5oYWFzQGdteC5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEB BQUAA4GBAIMuYcgiy5nTs7KzjoIDqrhpxBVpjp3+hOt6QkN4RCXkkkQJm0sAb+zBz8mfaE5cXfVa XAHvh7igVDnXo1QSF6RF00MKBnbPKG3TR/CPBdBlJ4rrqHkCKjJXeqd8HX183CtAnp46bVdYtahe VFDNss677/KazspGUM/t9bSsN0SnMIIC+zCCAmSgAwIBAgIQRkxwadu3e8zoglAUp66OijANBgkq hkiG9w0BAQUFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0 eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcN MDkwODE5MTMxNzI1WhcNMTAwODE5MTMxNzI1WjBfMQ0wCwYDVQQEEwRIYWFzMREwDwYDVQQqEwhH dWVudGhlcjEWMBQGA1UEAxMNR3VlbnRoZXIgSGFhczEjMCEGCSqGSIb3DQEJARYUZ3VlbnRoZXIu aGFhc0BnbXguZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7nXlaTSXh+QEZ5YVD s7vdkvIpHhulP7DW/hqSF3Sd4zPKIuVUAQk+eNqxR38QboK7O9R/pMxKwhLmRZsp1IMghtzhO37o MLYbk+3Vd8Gu9ZgeEUlmRWodKcNvS0BE3gcYPY7WM0v1OPH6vB3gcKnFHXNhNVIetI/zQUnHUamo ylhOjdRLcA86xjZ675+r2c7DdGXJoFpR37SKMPsei/Ag0+47YfYu9zIRHheFcrDqDRaUvAIYnu4X 9E7ABTO4XIG/TMXgNI9v9y357+fTSjPBVmoKF+Ml1YWJbys8jBN5SNECkFW8PjQc9hggepUDvcQq l6zRuespG03wwaCWtUrpAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGd1ZW50aGVyLmhhYXNAZ214LmRl MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAgy5hyCLLmdOzsrOOggOquGnEFWmOnf6E 63pCQ3hEJeSSRAmbSwBv7MHPyZ9oTlxd9VpcAe+HuKBUOdejVBIXpEXTQwoGds8obdNH8I8F0GUn iuuoeQIqMld6p3wdfXzcK0CenjptV1i1qF5UUM2yzrvv8prOykZQz+31tKw3RKcwggM/MIICqKAD AgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYD VQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0 ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVz VftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Va qj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20Txh BEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0 hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNV HQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqG SIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCT cDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo0 5RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTEl MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEZMcGnbt3vM6IJQFKeujoowCQYFKw4DAhoFAKCC AcMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwOTA5MTUxNTI5 WjAjBgkqhkiG9w0BCQQxFgQUjwCrxdj8Lnekf79hrVzMQ5aLoDMwUgYJKoZIhvcNAQkPMUUwQzAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBJc3N1aW5nIENBAhBGTHBp27d7zOiCUBSnro6KMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkG A1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBGTHBp27d7zOiCUBSnro6KMA0G CSqGSIb3DQEBAQUABIIBAE6ycjAKsz4t5qW+yjIpZS8a/Gjkf/yT94QbSXMXSFP2/wDv7IBte+q3 gxKUz84lZROuR+LqZVzT5i+hIJsKO2GBQtwQ/g3RP40jI3ek6a3KHBBBfjwVYTOvsyjtW99pBRei 4EILPDjKdtD54VPRkqo/YYpLNexXC2pexyuY+0/X+VeqvZXabHiE/t8KSDrfDCaGpZmGkuzipXwA Gy02Aq8iqJAYsaNJb+c8AzBinrNdRAs6XlKlcei2dr/q/KJEgtZvwiDApCE0kHKwKpfjPFbNK4FL 1Zh0cusqi88ulmYLgjrKC5xhQ/Z+Ud1XRzaGLbh877uvJU1Xb1bPq4nX+UoAAAAAAAA= --===============4894615557138611106==-- From ataschner@novell.com Thu Sep 10 07:15:28 2009 From: Andreas Taschner To: autoinstall@lists.opensuse.org Subject: [opensuse-autoinstall] "SHA1 sum wrong" after modifying control.xom Date: Thu, 10 Sep 2009 08:16:56 +0100 Message-ID: <4AA8C408020000D0000369EF@vpn.id2.novell.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2373140997869400917==" --===============2373140997869400917== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi I have created a YaST client module that snaps into the AutoYaST workflow for= running displaying the progress of custom scripts (http://www.novell.com/com= munities/node/8961/) and a part of this game is to modify /control.x= ml. While this works fine for SLES 10, SLES 11 is more careful. First it gave me an error like this : /control.xml : SHA1 sum wrong. If you really trust your repository, you may continue in an insecure mode. (OK/Back) Hmm ... OK fair enough - naively I entered a new SHA1 sum in /conten= t hoping that would be it. :( Now I get a less friendly popup saying : /content: Invalid signature Aborting installation I see there is a content.key file, but since I don't know the password to it,= it guess it is useless to try to generate a new content.asc. Is there any way around this, or do we not want customer's to port their cust= omizations to SLE 11 ? Thanks. Best regards Andreas Taschner --=20 To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-autoinstall+help(a)opensuse.org --===============2373140997869400917==-- From simon.loewenthal@klunky.co.uk Thu Sep 10 10:27:38 2009 From: Simon Loewenthal/NL/Tele2 To: autoinstall@lists.opensuse.org Subject: [opensuse-autoinstall] OT: SLES/Suse mailing list sought for storage related discussion Date: Thu, 10 Sep 2009 12:27:48 +0200 Message-ID: <4AA8D4A4.7050509@klunky.co.uk> In-Reply-To: <4AA8C408020000D0000369EF@vpn.id2.novell.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6331955242541302048==" --===============6331955242541302048== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Off topic I know but: Is there an SLES or OpenSUSE mailing list that deals with LVM/LUNs and powerpath/multipathing subjects? I would rather stay away from opensuse(a)opensuse.org because I end up with a lot of Email that would probably suited to a list orientated to Suse desktop environments. -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-autoinstall+help(a)opensuse.org --===============6331955242541302048==-- From kmachalkova@suse.cz Thu Sep 10 12:56:04 2009 From: Katarina Machalkova To: autoinstall@lists.opensuse.org Subject: Re: [opensuse-autoinstall] "SHA1 sum wrong" after modifying control.xom Date: Thu, 10 Sep 2009 14:57:39 +0200 Message-ID: <200909101457.41535.kmachalkova@suse.cz> In-Reply-To: <4AA8C408020000D0000369EF@vpn.id2.novell.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7958186279247274333==" --===============7958186279247274333== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, > I have created a YaST client module that snaps into the AutoYaST workflow <-- snip --> > While this works fine for SLES 10, SLES 11 is more careful. > First it gave me an error like this : > /control.xml : SHA1 sum wrong. > If you really trust your repository, you may continue in an insecure > mode. (OK/Back) The easy and fast way around - boot with 'insecure=3D1' option appended to yo= ur=20 BL parameters. This tells Linuxrc (http://en.opensuse.org/Linuxrc) not to=20 check SHA1 sums of every file it downloads, so it won't complain anymore.=20 > I see there is a content.key file, but since I don't know the password to > it, it guess it is useless to try to generate a new content.asc. > Is there any way around this, or do we not want customer's to port their > customizations to SLE 11 ? In general, if you modify a control file, you have to sign again the whole=20 repository with a key available to you, that is, compute again all the=20 checksums, replace content.key, content.asc ... erm ... you don't want to do = that :) it is rather cumbersome. Looking at the initial description, inserting a new step into workflow (more = generally, modifying an installation workflow) is a good candidate for=20 creating an add-on media, be it only very simplistic one. And this can also b= e=20 signed, so you are on a safe side: =20 Here is a how-to for signing add-ons, maybe some parts of it will be helpful = to you: http://ugansert.blogspot.com/2009/01/opensuse-111-sles11-and-add-ons.html hB. --=20 \\\\\ Katarina Machalkova =20 \\\\\\\__o YaST developer __\\\\\\\'/_ & hedgehog painter --=20 To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-autoinstall+help(a)opensuse.org --===============7958186279247274333==-- From ataschner@novell.com Thu Sep 10 13:56:23 2009 From: Andreas Taschner To: autoinstall@lists.opensuse.org Subject: Re: [opensuse-autoinstall] "SHA1 sum wrong" after modifying control.xml Date: Thu, 10 Sep 2009 14:57:51 +0100 Message-ID: <4AA921FF020000D000036B7F@vpn.id2.novell.com> In-Reply-To: <200909101457.41535.kmachalkova@suse.cz> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8568302642144550181==" --===============8568302642144550181== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Katarina >>> On 9/10/2009 at 14:57, Katarina Machalkova wrote:= =20 >=20 > The easy and fast way around - boot with 'insecure=3D1' option appended to = your=20 > BL parameters. This tells Linuxrc (http://en.opensuse.org/Linuxrc) not to=20 > check SHA1 sums of every file it downloads, so it won't complain anymore.=20 Thank you very much for your reply and suggestions. insecure=3D1 works fine for me although Uwe Gansert's blog was also very inte= resting reading. Will keep that approach in mind for very security-conscious = customers (with too much time on their hands). //Andreas --=20 To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-autoinstall+help(a)opensuse.org --===============8568302642144550181==-- From ml-admin@opensuse.org Fri Sep 11 07:30:30 2009 From: ml-admin@opensuse.org To: autoinstall@lists.opensuse.org Subject: [opensuse-autoinstall] Power Outage Date: Fri, 11 Sep 2009 07:30:08 +0000 Message-ID: <4aa9fc80.W3otS102KcKljyuE%ml-admin@opensuse.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1947091952032765557==" --===============1947091952032765557== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Broadcast message from ml-admin(a)opensuse.org (/dev/pts/0) at 07:30 GMT ... The system is going down for halt NOW! -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-autoinstall+help(a)opensuse.org --===============1947091952032765557==-- From Bill.Stephens@pbsg.com Sun Sep 13 19:30:17 2009 From: "Stephens, Bill {PBSG}" To: autoinstall@lists.opensuse.org Subject: [opensuse-autoinstall] add_on_products.xml not working in sles11 Date: Sun, 13 Sep 2009 14:31:48 -0500 Message-ID: In-Reply-To: <200908121044.06329.ug@suse.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0937767184646743848==" --===============0937767184646743848== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I've been stumped on this one for days now and can't figure out what I'm doin= g wrong. I've signed the add_on_products.xml, I can point to the updates dir= ectory in the autoyast file and it works fine. The add_on_products.xml file = does not add on the updates if I use that though. Here's the add_on_products= .xml file: sles11 updates nfs://devlinux.pbsg.pvt/usr/sle11/sles11/x86_64/DVD/updates<= /url> / false true And here's the add-on section in the autoyast file: nfs://devlinux.pbsg.pvt/usr/sle11/sles11/x86_64/DVD/update= s updates / --=20 To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-autoinstall+help(a)opensuse.org --===============0937767184646743848==-- From werner.hack@uni-ulm.de Mon Sep 14 14:56:45 2009 From: Werner Hack To: autoinstall@lists.opensuse.org Subject: [opensuse-autoinstall] Problems with rules in openSUSE 11.2 (milestone7) Date: Mon, 14 Sep 2009 16:56:39 +0200 Message-ID: <4AAE59A7.3090708@uni-ulm.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3423322153270169278==" --===============3423322153270169278== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hello, I tried to install openSUSE 11.2 (milestone7) via autoyast for testing purpose. I am using the rules feature to create a profile dynamically. I have no problems within former openSUSE releases. But in openSUSE 11.2 it fails. 'xsltproc' is missing here (for merging the profiles) ! Is this problem already known? autoyast is not working yet. Is there a bugfix available or even a workaround to solve this problem? This will be great. At the moment I can not test autoinstallation in release 11.2. Regards, Werner Hack -- --===============3423322153270169278== Content-Type: application/x-pkcs7-signature Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIME-Version: 1.0 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJQTCCAvsw ggJkoAMCAQICEDBPuVjBSVgYZiuFZloRzeUwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDMxMTE0MDE0NVoXDTEwMDMxMTE0MDE0 NVowXTENMAsGA1UEBBMESGFjazEPMA0GA1UEKhMGV2VybmVyMRQwEgYDVQQDEwtXZXJuZXIgSGFj azElMCMGCSqGSIb3DQEJARYWd2VybmVyLmhhY2tAdW5pLXVsbS5kZTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAOIzccsQv+vR4cKIbPYqmzNbqlCWV+pd7Kb2F4AVL7McIW3/TCqM1D4I UcOhxaFNBjMjIP+xnuMJ2Z6cHtOPIcF1HurhnBqRrvVWUoG/0dg69StYWbfsaCM1r1zgXIWuoPz4 yNh4+qErVmLE+dIX3VGNyaDGtkr0Eu4fbfxA0HS/5tf8dkUHR6QyhJ3eOer7kzQY9PnPGN3huhGu RoKE6AeYVG1MllZgYIuxE2hF5QLQwV85e7CUI6lN7cpu9fsW6JzhKxxFyGnNdMs92j48TrN8i/mT NKXEWybC6sPi7yQ2YWkKC2nmT6jjVz4VYgoxEOgNXA8rOS2Q3nZVuRS5S4UCAwEAAaMzMDEwIQYD VR0RBBowGIEWd2VybmVyLmhhY2tAdW5pLXVsbS5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEB BQUAA4GBACIOsrIXcFRroa66aHCfGRrXDTC8QNyhfqYYah2PbkNdm+3k5PztRzTT6R/hD5yY297e 7Njg7DB/u4e92UXEXtyol7DzxqzFBHjZvufRWe3IMM1A6mz+oclgwvBfWbTsigJPBZpqLrtYyIAu aAw0/ygQ05nsc2eAdJQY7gVmzu2lMIIC+zCCAmSgAwIBAgIQME+5WMFJWBhmK4VmWhHN5TANBgkq hkiG9w0BAQUFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0 eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcN MDkwMzExMTQwMTQ1WhcNMTAwMzExMTQwMTQ1WjBdMQ0wCwYDVQQEEwRIYWNrMQ8wDQYDVQQqEwZX ZXJuZXIxFDASBgNVBAMTC1dlcm5lciBIYWNrMSUwIwYJKoZIhvcNAQkBFhZ3ZXJuZXIuaGFja0B1 bmktdWxtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4jNxyxC/69Hhwohs9iqb M1uqUJZX6l3spvYXgBUvsxwhbf9MKozUPghRw6HFoU0GMyMg/7Ge4wnZnpwe048hwXUe6uGcGpGu 9VZSgb/R2Dr1K1hZt+xoIzWvXOBcha6g/PjI2Hj6oStWYsT50hfdUY3JoMa2SvQS7h9t/EDQdL/m 1/x2RQdHpDKEnd456vuTNBj0+c8Y3eG6Ea5GgoToB5hUbUyWVmBgi7ETaEXlAtDBXzl7sJQjqU3t ym71+xbonOErHEXIac10yz3aPjxOs3yL+ZM0pcRbJsLqw+LvJDZhaQoLaeZPqONXPhViCjEQ6A1c Dys5LZDedlW5FLlLhQIDAQABozMwMTAhBgNVHREEGjAYgRZ3ZXJuZXIuaGFja0B1bmktdWxtLmRl MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAIg6yshdwVGuhrrpocJ8ZGtcNMLxA3KF+ phhqHY9uQ12b7eTk/O1HNNPpH+EPnJjb3t7s2ODsMH+7h73ZRcRe3KiXsPPGrMUEeNm+59FZ7cgw zUDqbP6hyWDC8F9ZtOyKAk8Fmmouu1jIgC5oDDT/KBDTmexzZ4B0lBjuBWbO7aUwggM/MIICqKAD AgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYD VQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0 ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVz VftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Va qj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20Txh BEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0 hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNV HQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqG SIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCT cDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo0 5RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTEl MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEDBPuVjBSVgYZiuFZloRzeUwCQYFKw4DAhoFAKCC AcMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwOTE0MTQ1NjM5 WjAjBgkqhkiG9w0BCQQxFgQUEbW1B630WTAGzLbSBP9uodZOviUwUgYJKoZIhvcNAQkPMUUwQzAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBJc3N1aW5nIENBAhAwT7lYwUlYGGYrhWZaEc3lMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkG A1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAwT7lYwUlYGGYrhWZaEc3lMA0G CSqGSIb3DQEBAQUABIIBAGsjx/dbs1+D5OzuAvrLbajm5PZhku26G7Xo/Ulgc3iDVakWsQk/yJQu 6lUe6KHOIFma1/KvKFtFHVbFYwPBzjDD7DzYcGA7j9B7LzhYykCk/pykVfVHGvLw0P/LsDEV3h8S 5dBCaI5QnP0oBLVm6FZ2dmuVGzzhC56lqt4MB+MxbxoxCTM26LZNv41ispjcvQmVtLfRSKDuMo9S 4rrvpvpNJaTuqS2Meq3/fHbyFrnsnG+dkSd5WVcHJlLB0JvY+6gRUluWStRHkuM/l5GGBF5zRrT4 e39/eOK6y85OdFD+wPvcFtU8KpmdC+gyNilW00rjCAJ1jWfADE95p3NsnHsAAAAAAAA= --===============3423322153270169278==-- From kmachalkova@suse.cz Mon Sep 14 15:30:05 2009 From: Katarina Machalkova To: autoinstall@lists.opensuse.org Subject: Re: [opensuse-autoinstall] Problems with rules in openSUSE 11.2 (milestone7) Date: Mon, 14 Sep 2009 17:29:59 +0200 Message-ID: <200909141730.03385.kmachalkova@suse.cz> In-Reply-To: <4AAE59A7.3090708@uni-ulm.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5227227766781490661==" --===============5227227766781490661== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, > I tried to install openSUSE 11.2 (milestone7) via autoyast for testing > purpose. > I am using the rules feature to create a profile dynamically. > 'xsltproc' is missing here (for merging the profiles) ! This is actually the second report on this list, the first one is here:=20 http://lists.opensuse.org/opensuse-autoinstall/2009-09/msg00014.html I've just verified it - xsltproc used to be in inst-sys up to openSUSE 11.1=20 (SLEx 11) but it is not there anymore in 11.2. I can't find any obvious reaso= n=20 for it in the changelog. Suggest to file a bug. > Is there a bugfix available or even a workaround to solve this problem? You might try to download libxslt (the package you need) from M7 repository, = place it on local http/ftp server and pass the URL to the installed as the=20 driver update, like this: dud=3Dftp://local.ftp.server/pub/11.2/libxslt-x.y-z.rpm This should add xsltproc to inst-sys ... might work, but I have actually=20 never tested adding packages like this (just replacing the existing ones) ;) Hope that helps hB. --=20 \\\\\ Katarina Machalkova =20 \\\\\\\__o YaST developer __\\\\\\\'/_ & hedgehog painter --=20 To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-autoinstall+help(a)opensuse.org --===============5227227766781490661==-- From david.werner@iws.uni-stuttgart.de Tue Sep 15 14:41:22 2009 From: David Werner To: autoinstall@lists.opensuse.org Subject: [opensuse-autoinstall] Problem with URLs containing a password with openSUSE 11.2 (milestone7) Date: Tue, 15 Sep 2009 16:41:16 +0200 Message-ID: <20090915144116.GA27097@arup.iws.uni-stuttgart.de> In-Reply-To: <200909141730.03385.kmachalkova@suse.cz> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0236151966137806866==" --===============0236151966137806866== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello,=20 today I made a first try with preversion of openSUSE 11.2 (milestone 7). Basically I used the same configuration as with 11.2. As we access our repositories at times from outside we have weak access limitation by basic httpd authentication (password cleartext) sch= eme. It seems to me that repository URLs as of style=20 http://user:password(a)host/path_to_repository/=20 do not work anymore. I use them as command-line-parameter "install=3D" for ke= rnel and in=20 -section (for the non-oss part) of autoyast file. I'm going to use later similiar URL also for command-line-parameter "autoyast= =3D" if possible. I had to relax the conditions on http-server to start installation. Looking at y2.log it seems that it parses user and password correctly out. as one sees them there as parameters. My version was the DVD release for x86_64 architecture. Do you need more details? Greetings David --=20 To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-autoinstall+help(a)opensuse.org --===============0236151966137806866==-- From kmachalkova@suse.cz Tue Sep 15 15:31:18 2009 From: Katarina Machalkova To: autoinstall@lists.opensuse.org Subject: Re: [opensuse-autoinstall] Problem with URLs containing a password with openSUSE 11.2 (milestone7) Date: Tue, 15 Sep 2009 17:31:14 +0200 Message-ID: <200909151731.17556.kmachalkova@suse.cz> In-Reply-To: <20090915144116.GA27097@arup.iws.uni-stuttgart.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8811311433834227057==" --===============8811311433834227057== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hi, > As we access our repositories at times from outside we have > weak access limitation by basic httpd authentication (password cleartext) > scheme. It seems to me that repository URLs as of style > > http://user:password(a)host/path_to_repository/ > > do not work anymore. I use them as command-line-parameter "install=" for Could it be this bug? http://bugzilla.novell.com/show_bug.cgi?id=537300 (it's about samba repo, but seems that all schemes ceased to work as soon as username/password is involved) hB. -- \\\\\ Katarina Machalkova \\\\\\\__o YaST developer __\\\\\\\'/_ & hedgehog painter -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-autoinstall+help(a)opensuse.org --===============8811311433834227057==-- From guenther.haas@gmx.de Tue Sep 15 15:34:03 2009 From: Guenther Haas To: autoinstall@lists.opensuse.org Subject: Re: [opensuse-autoinstall] Problems with rules in openSUSE 11.2 (milestone7) Date: Tue, 15 Sep 2009 17:33:56 +0200 Message-ID: <4AAFB3E4.1030707@gmx.de> In-Reply-To: <200909141730.03385.kmachalkova@suse.cz> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5579252535022091044==" --===============5579252535022091044== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Katarina Machalkova wrote: >> 'xsltproc' is missing here (for merging the profiles) ! ... > You might try to download libxslt (the package you need) from M7 repository= ,=20 > place it on local http/ftp server and pass the URL to the installed as the = > driver update, like this: > > dud=3Dftp://local.ftp.server/pub/11.2/libxslt-x.y-z.rpm > > This should add xsltproc to inst-sys ... might work, but I have actually=20 > never tested adding packages like this (just replacing the existing ones) ;) > Hope that helps For me that seems to work. Many thanks for the hint/workaround! Regards, --=20 Guenther Haas, Uni Ulm, Institut TAIT, guenther.haas(a)gmx.de --===============5579252535022091044== Content-Type: application/x-pkcs7-signature Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIME-Version: 1.0 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJQTCCAvsw ggJkoAMCAQICEEZMcGnbt3vM6IJQFKeujoowDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgxOTEzMTcyNVoXDTEwMDgxOTEzMTcy NVowXzENMAsGA1UEBBMESGFhczERMA8GA1UEKhMIR3VlbnRoZXIxFjAUBgNVBAMTDUd1ZW50aGVy IEhhYXMxIzAhBgkqhkiG9w0BCQEWFGd1ZW50aGVyLmhhYXNAZ214LmRlMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAu515Wk0l4fkBGeWFQ7O73ZLyKR4bpT+w1v4akhd0neMzyiLlVAEJ PnjasUd/EG6CuzvUf6TMSsIS5kWbKdSDIIbc4Tt+6DC2G5Pt1XfBrvWYHhFJZkVqHSnDb0tARN4H GD2O1jNL9Tjx+rwd4HCpxR1zYTVSHrSP80FJx1GpqMpYTo3US3APOsY2eu+fq9nOw3RlyaBaUd+0 ijD7HovwINPuO2H2LvcyER4XhXKw6g0WlLwCGJ7uF/ROwAUzuFyBv0zF4DSPb/ct+e/n00ozwVZq ChfjJdWFiW8rPIwTeUjRApBVvD40HPYYIHqVA73EKpes0bnrKRtN8MGglrVK6QIDAQABozEwLzAf BgNVHREEGDAWgRRndWVudGhlci5oYWFzQGdteC5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEB BQUAA4GBAIMuYcgiy5nTs7KzjoIDqrhpxBVpjp3+hOt6QkN4RCXkkkQJm0sAb+zBz8mfaE5cXfVa XAHvh7igVDnXo1QSF6RF00MKBnbPKG3TR/CPBdBlJ4rrqHkCKjJXeqd8HX183CtAnp46bVdYtahe VFDNss677/KazspGUM/t9bSsN0SnMIIC+zCCAmSgAwIBAgIQRkxwadu3e8zoglAUp66OijANBgkq hkiG9w0BAQUFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0 eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcN MDkwODE5MTMxNzI1WhcNMTAwODE5MTMxNzI1WjBfMQ0wCwYDVQQEEwRIYWFzMREwDwYDVQQqEwhH dWVudGhlcjEWMBQGA1UEAxMNR3VlbnRoZXIgSGFhczEjMCEGCSqGSIb3DQEJARYUZ3VlbnRoZXIu aGFhc0BnbXguZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7nXlaTSXh+QEZ5YVD s7vdkvIpHhulP7DW/hqSF3Sd4zPKIuVUAQk+eNqxR38QboK7O9R/pMxKwhLmRZsp1IMghtzhO37o MLYbk+3Vd8Gu9ZgeEUlmRWodKcNvS0BE3gcYPY7WM0v1OPH6vB3gcKnFHXNhNVIetI/zQUnHUamo ylhOjdRLcA86xjZ675+r2c7DdGXJoFpR37SKMPsei/Ag0+47YfYu9zIRHheFcrDqDRaUvAIYnu4X 9E7ABTO4XIG/TMXgNI9v9y357+fTSjPBVmoKF+Ml1YWJbys8jBN5SNECkFW8PjQc9hggepUDvcQq l6zRuespG03wwaCWtUrpAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGd1ZW50aGVyLmhhYXNAZ214LmRl MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAgy5hyCLLmdOzsrOOggOquGnEFWmOnf6E 63pCQ3hEJeSSRAmbSwBv7MHPyZ9oTlxd9VpcAe+HuKBUOdejVBIXpEXTQwoGds8obdNH8I8F0GUn iuuoeQIqMld6p3wdfXzcK0CenjptV1i1qF5UUM2yzrvv8prOykZQz+31tKw3RKcwggM/MIICqKAD AgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYD VQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0 ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVz VftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Va qj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20Txh BEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0 hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNV HQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqG SIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCT cDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo0 5RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTEl MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEZMcGnbt3vM6IJQFKeujoowCQYFKw4DAhoFAKCC AcMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwOTE1MTUzMzU2 WjAjBgkqhkiG9w0BCQQxFgQUHAmdQGXBRZUn9iYQ4c3cJDtqlvUwUgYJKoZIhvcNAQkPMUUwQzAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBJc3N1aW5nIENBAhBGTHBp27d7zOiCUBSnro6KMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkG A1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBGTHBp27d7zOiCUBSnro6KMA0G CSqGSIb3DQEBAQUABIIBAINvViJu7YWaM2Mcp1uM2QxWgVOtn9LK9OHXStEox/UNW4kGj9k+Fxo9 td1O1IR9kCj2YhzYzXwn0w3hHRYcriBW0e3qmQUsYaLhwaxzGYIVh3fLE0pUxWN3o98KMeA7q+PI xinc5aZgwZz/j0MHj8KU+i7bvixqNBByJpVjRx4t9GeU8Tcs6bA00i5igxLC+zsN11XH0ZRDenQO U4q2+Ba2cqVeeVnNQgfRBxSFxF5juljcuqSbswHimB9uzRhlpef8jLEInCIGBrMGXmAI/FpS2B4O qbxBrPX86pTliVHXz5+EmWw5L9u4rnsDet/7TFzTJPWvDNc2ATGEob5VAkMAAAAAAAA= --===============5579252535022091044==-- From tomasl@cs.umu.se Thu Sep 24 18:30:20 2009 From: Tomas Rosenthal To: autoinstall@lists.opensuse.org Subject: Re: [opensuse-autoinstall] Wrong disk-id with hw raid Date: Thu, 24 Sep 2009 20:30:30 +0200 Message-ID: In-Reply-To: <200907151706.00708.ug@suse.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0204013333323027742==" --===============0204013333323027742== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hi again. We solved it, but in another less beautiful way. We tried some combinations but didn't get it to work the way you suggested. Instead, we mounted the root in boot/x86_64/ and added a script called inst_setup in sbin and re-created the root. That did the trick. Regards, Tomas On Wed, 15 Jul 2009, Uwe Gansert wrote: > on Sunday 12 July 2009 Tomas Rosenthal wrote: > >> But now when invoked from linuxrc, I'm calling the script so early that >> the initrd filesystem is not loaded, or something. It doesn't find basic >> commands such as grep, sed, head etc. >> >> What am I doing wrong? My linuxrc.config looks like this: > > *argh* you are right. The exec is executed too early :-/ sorry. > > We can try something different. You have to change the initrd anyway, so > create a directory like this: > /linux/suse/x86_64-sles11/install/ > and copy this shell script with the name update.pre into it: > > #! /bin/sh > /my_raid_setup.sh > > or copy your raid_setup to /linux/suse/x86_64-sles11/install/update.pre > That should run later. > > -- > ciao, Uwe Gansert > -- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-autoinstall+help(a)opensuse.org --===============0204013333323027742==--