On Wednesday 28 June 2006 17:09, Emils wrote:

I can confirm the same problem with OpenSuSE 10.1

I know. I have reproduced that by myself in the meantime and made a bugreport. Sorry guys, you have to use a chroot-script to workaround that. -- ciao, Uwe Gansert Uwe Gansert, Server Technologies Team SUSE LINUX Products GmbH, Maxfeldstrasse 5, D-90409 Nuernberg, Germany e-mail: uwe.gansert@suse.de Fax: +49-(0)911-74053-476, Web: http://www.suse.de/~ug

Uwe Gansert wrote

On Wednesday 28 June 2006 17:09, Emils wrote:

...

I can confirm the same problem with OpenSuSE 10.1

I know. I have reproduced that by myself in the meantime and made a bugreport. Sorry guys, you have to use a chroot-script to workaround that.

How is that supposed to work? When using a script with chrooted=false, the wrong lilo.conf does not yet exist. But with chrooted=true the script would run after installing lilo, so it won't run at all because the installation stops with the error message about lilo. So unattended install does not work :-( I've set a timeout for error messages, but the error message about lilo has no counter, so it stays forever... Can I do sth. to make the installation go on so that the chroot script after lilo installation is reached automatically? 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. *

Ok, two things about this bug: 1) Looks like the whole creation of global parameters is messed up. I've this part in my profile: <global config:type="list"> <key>disk</key> <value>disk=/dev/sda bios=0x80</value> <key>disk</key> <value>disk=/dev/hda bios=0x81</value> </global> but no disk entry shows up in lilo.conf and my system does not boot, it tries from hda, although the installation goes to sda. lilo.conf contains "boot=/dev/sda" but without the disk entries this doesn't work. Actually, I guess I can fix this with a "chrooted=yes" chroot-script. 2) I wrote a fix for the missing default label, for BootLILO.ycp, but should work the same way in BootELILO.ycp, because there is the same if clause for autoinst mode. The patch is based on SuSE 10.1 files. It checks if the value for "default" is empty, and if so, adds the name from the first section. I don't know if there are side effects, but at least it works for me here, so you can try it if you want. I used it this way (adjust to your needs): - installed yast2-bootloader.src.rpm - called "rpmbuild -ba SPECS/yast2-bootloader.spec", so that I had the compiled stuff in BUILD/yast2-bootloader-2.13.56 - entered BUILD/yast2-bootloader-2.13.56/src/modules/ and applied the patch to BootLILO.ycp - called "make" which recompiled BootLILO.ybc und BootLoader.ybc. Now put those two files into a driverupdate: This depends very much on your system. I had a driverupdate file from Uwe's fix-script from ftp://ftp.suse.com/pub/people/ug/autoyast/ After calling the script, I mounted the driverupdate file and copied all the stuff to some tmp dir and copied BootLILO.ybc und BootLoader.ybc to tmp/mydriverupdate/linux/suse/i386-10.1/y2update/modules/ Make sure the subdir matches your arch, i386 here. If you use the SLES10 installed, the subdir will be called i386-sles10/ I recreated the driverupdate file as cpio file with cd ~/tmp/mydriverupdate find linux | cpio -H newc -o > /rpm-export/i586/10.1/SuSE/driverupdate Reinstall with this new driverupdate file, and the default option will be fixed in lilo.conf. No warranty :-) If your system starts burning, it's not my fault ;-) 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. *

Uwe Gansert wrote

On Tuesday 12 September 2006 10:34, Frank Steiner wrote:

...

How is that supposed to work? When using a script with chrooted=false, the wrong lilo.conf does not yet exist. But with chrooted=true the script would run after installing lilo, so it won't run at all because the installation stops with the error message about lilo. So unattended install does not work :-(

I don't have the overview of the bug at the moment. Can't you let yast install the default bootloader (no <bootloader> section at all or at least one that does not trigger the popup) and overwrite it in a chroot script?

I guess I could because I think the problem just pops up if you set any global parameter in the profile. Otherwise, BootLILO.ycp will call "CreateGlobals" and that works fine. Anyway, due to the disk lines I need in lilo.conf for booting from SCSI, I have to run a chroot script anyways. But... this fails :-((( I'm using two chroot scripts: <scripts> <chroot-scripts config:type="list" > <script> <interpreter>shell</interpreter> <location>nfs://141.84.1.3/rpm-export/autoyast/10.1/scripts/prepare_post.script</location> <chrooted config:type="boolean">false</chrooted> </script> <script> <interpreter>shell</interpreter> <location>nfs://141.84.1.3/rpm-export/autoyast/10.1/scripts/wait.script</location> <chrooted config:type="boolean">true</chrooted> </script> </chroot-scripts> </scripts> The first one runs and I see that it is copied to /mnt/var/adm/autoinstall/scripts/ or sth. Then, after installing lilo (now working with the patch), AY tries to copy the second script. y2log says " cp some_nfs_location/wait.scrip /var/adm/autoinstall/scripts/chroot-scripts and then "copy failed, file system is read only" or sth. similar. Actually, there is ineed a mount /dev/loop0 on /mounts/inst-sys type cramfs (ro) and /var/adm/autoinstall is a link to /mounts/inst-sys. Looks like the script is not copied from within the chrooted environment and therefore it fails. So I'm still stuck with that server because I can't insert the disk lines into lilo.conf :-((( 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. *

Uwe Gansert wrote

On Tuesday 12 September 2006 12:24, Frank Steiner wrote:

...

Looks like the script is not copied from within the chrooted environment and therefore it fails.

I can reproduce this but only with <location>nfs://... With http for example it's working fine here. Looks like a bug with nfs location used in chrooted=true scripts. I need to take a closer look

Thanks a lot! Looks like I'm always stepping on any kind of unusual situation that produces a bug :'-( We can't use http, but I will try to work around with embedding the script into the profile itself... If you find a fix, let me know (now that I know how to put that stuff into the driverupdate file ;-)) 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. *

On Wednesday 13 September 2006 11:21, Uwe Gansert wrote:

patch attached.

forget the patch. It will break other stuff ... *grrr* coffee!!! -- ciao, Uwe Gansert Uwe Gansert, Server Technologies Team SUSE LINUX Products GmbH, Maxfeldstrasse 5, D-90409 Nuernberg, Germany Business: http://www.suse.de/~ug now playing The Retrosic - Dragonfire