I have logged SR#10273247971 for this but I thought I would get peoples thoughts here as well.
Problem is with the <default> global parameter in the <bootloader> section of autoyast.
This works fine:
<bootloader> <loader_type>lilo</loader_type> <location>mbr</location> </bootloader>
Default kernel is SLES_10 as expected.
This doesnt work, during boot loader installation an error is given that there is no default value given in lilo.conf. This occurs if I put an entry in the <default> tag or not.
<bootloader> <global> <default>SLES_10</default> <gfxmenu></gfxmenu> <prompt>1</prompt> <timeout config:type="integer">5</timeout> </global> <loader_type>lilo</loader_type> <location>mbr</location> </bootloader>
ie: This also gives the same error for the default tag. It should default to SLES_10 - I should not have to specify it.
<bootloader> <global> <default></default> <gfxmenu></gfxmenu> <prompt>1</prompt> <timeout config:type="integer">5</timeout> </global> <loader_type>lilo</loader_type> <location>mbr</location> </bootloader>
And this also the same error:
<bootloader> <global> <gfxmenu></gfxmenu> <prompt>1</prompt> <timeout config:type="integer">5</timeout> </global> <loader_type>lilo</loader_type> <location>mbr</location> </bootloader>
The reason I am doing this is because I do *not* want a graphical menu so I want to specify nothing for <gfxmenu> which seems to work ok.
The text of the error during the bootloader config/installation phase is:
"Value expected for 'default' at or above line 11 in file /etc/lilo.conf."
And sure enough in /mnt/etc/lilo.conf at that point of the installation default has no value.
thanks
-- Matt Gillard UNIX Systems Engineer Coles Myer Ltd | Lvl 4 236 Bourke St | +61 3 963 51926
This email and any attachments may contain privileged and confidential information and are intended for the named addressee only. If you have received this e-mail in error, please notify the sender and delete this e-mail immediately. Any confidentiality, privilege or copyright is not waived or lost because this e-mail has been sent to you in error. It is your responsibility to check this e-mail and any attachments for viruses. No warranty is made that this material is free from computer virus or any other defect or error. Any loss/damage incurred by using this material is not the sender's responsibility. The sender's entire liability will be limited to resupplying the material.
I can confirm the same problem with OpenSuSE 10.1
2006/6/28, Matt Gillard Matt.Gillard@colesmyer.com.au:
I have logged SR#10273247971 for this but I thought I would get peoples thoughts here as well.
Problem is with the <default> global parameter in the <bootloader> section of autoyast. ie: This also gives the same error for the default tag. It should default to SLES_10 - I should not have to specify it.
<bootloader> <global> <default></default> <gfxmenu></gfxmenu> <prompt>1</prompt> <timeout config:type="integer">5</timeout> </global> <loader_type>lilo</loader_type> <location>mbr</location> </bootloader> "Value expected for 'default' at or above line 11 in file /etc/lilo.conf."
And sure enough in /mnt/etc/lilo.conf at that point of the installation default has no value.
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.
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.
I've made the same bugreport for SuSE 10.0RC1 back in september 2005 (Sep 22 on this list). Bugid in bugzilla was 119193, but it was never resolved. Looks like no one really cares about lilo a lot anymore, but everyone is supposed to use grub :-(
cu, Frank
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
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've set a timeout for error messages, but the error message about lilo has no counter, so it stays forever...
that's bad
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
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
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
On Tuesday 12 September 2006 13:56, Frank Steiner wrote:
Thanks a lot! Looks like I'm always stepping on any kind of unusual situation that produces a bug :'-(
yes, you are very talented with that. Please do 10.2 tests as soon as possible :)
We can't use http, but I will try to work around with embedding the script into the profile itself...
that should work too.
If you find a fix, let me know (now that I know how to put that stuff into the driverupdate file ;-))
patch attached. You have to recompile: /usr/share/YaST2/modules/AutoInstallRules.ycp /usr/share/YaST2/modules/AutoinstConfig.ycp /usr/share/YaST2/modules/AutoinstScripts.ycp /usr/share/YaST2/modules/ProfileLocation.ycp
On Wednesday 13 September 2006 11:21, Uwe Gansert wrote:
patch attached.
forget the patch. It will break other stuff ... *grrr* coffee!!!
Uwe Gansert wrote
On Tuesday 12 September 2006 13:56, Frank Steiner wrote:
Thanks a lot! Looks like I'm always stepping on any kind of unusual situation that produces a bug :'-(
yes, you are very talented with that. Please do 10.2 tests as soon as possible :)
Sorry, we have now a new policy that we will always use the SuSE versions that has the common code base with SLES. So my next tests will be for SuSE 11.? or whatever is the base for SLES 11 :-)
forget the patch. It will break other stuff ... *grrr* coffee!!!
:-) Don't mind, I embedded the script and it works for now!
cu, Frank
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"> <global_entry> <key>disk</key> <value>disk=/dev/sda bios=0x80</value> </global_entry> <global_entry> <key>disk</key> <value>disk=/dev/hda bios=0x81</value> </global_entry> </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
On Tuesday 12 September 2006 11:44, Frank Steiner wrote:
- 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.
can you attach the patch to https://bugzilla.novell.com/show_bug.cgi?id=119193 please? Plus some words on what it is doing. Thanx.
autoinstall@lists.opensuse.org
-
Emils -
Frank Steiner -
Matt Gillard -
Uwe Gansert