Bug 394319

More information:

This is the content of the /boot/grub/menu.lst of the 10.3 partition:

# Modified by YaST2. Last modification on Thu Feb 28 14:04:04 MST 2008
default 0
timeout 8
gfxmenu (hd0,1)/boot/message
##YaST - activate

###Don't change this comment - YaST2 identifier: Original name: linux###
title openSUSE 10.3 - 2.6.22.17-0.1
    root (hd0,1)
    kernel /boot/vmlinuz-2.6.22.17-0.1-bigsmp root=/dev/disk/by-id/scsi-SATA_ST9200420ASG_5SH013HL-part2 vga=0x346 resume=/dev/sda1 splash=silent showopts
    initrd /boot/initrd-2.6.22.17-0.1-bigsmp

###Don't change this comment - YaST2 identifier: Original name: failsafe###
title Failsafe -- openSUSE 10.3 - 2.6.22.17-0.1
    root (hd0,1)
    kernel /boot/vmlinuz-2.6.22.17-0.1-bigsmp root=/dev/disk/by-id/scsi-SATA_ST9200420ASG_5SH013HL-part2 vga=normal showopts ide=nodma apm=off acpi=off noresume nosmp noapic maxcpus=0 edd=off 3
    initrd /boot/initrd-2.6.22.17-0.1-bigsmp



And these are the contents of the file in the oS11 partition:

# Modified by YaST2. Last modification on Sat May 24 01:50:48 UTC 2008
default 0
timeout 8
##YaST - generic_mbr
gfxmenu (hd0,3)/boot/message
##YaST - activate

###Don't change this comment - YaST2 identifier: Original name: linux###
title openSUSE 11.0 - 2.6.25.3-2
    root (hd0,3)
    kernel /boot/vmlinuz-2.6.25.3-2-default root=/dev/disk/by-id/scsi-SATA_ST9200420ASG_5SH013HL-part4 resume=/dev/sda1 splash=silent showopts vga=0x314
    initrd /boot/initrd-2.6.25.3-2-default

###Don't change this comment - YaST2 identifier: Original name: failsafe###
title Failsafe -- openSUSE 11.0 - 2.6.25.3-2
    root (hd0,3)
    kernel /boot/vmlinuz-2.6.25.3-2-default root=/dev/disk/by-id/scsi-SATA_ST9200420ASG_5SH013HL-part4 showopts ide=nodma apm=off acpi=off noresume edd=off x11failsafe vga=0x314
    initrd /boot/initrd-2.6.25.3-2-default

###Don't change this comment - YaST2 identifier: Original name:  openSUSE 10.3 - 2.6.22.17-0.1 (/dev/sda2)###
title openSUSE 10.3 - 2.6.22.17-0.1 (/dev/sda2)
    rootnoverify (hd0,3)
    chainloader (hd0,1)+1

I've copied the normal 10.3 entry in my oS10.3 grub file into the new oS11.0b3 grub file (replacing the failing one) and it has been fixed.

However, I leave this bug open in order to know if the oS installation should have been done this automatically.

The bug is valid, what you did is one possible workaround, which will work as long as you don't upgrade your 10.3 kernel.

The problem is in the 

rootnoverify (hd0,3)

line, which refers to the system in /dev/sda4 instead of /dev/sda2.

Alex, this is issue in perl-Botloader, please, have a look.

forgot to reassign...

Andres, could you, please, attach the installation logs (/var/log/YaST2 directory)? Also, where did you install the 10.3 bootloader? To the bootsector, or MBR? (/etc/grub.conf from the 10.3 install has the answer)

Created attachment 218060 [details]
The grub.conf from 10.3 (sda2)

Thanks, this confirms that 10.3 bootloader was installed into /dev/sda2.

Created attachment 218184 [details]
Yast2 logs (whole dir)

(In reply to comment #3 from Jiri Srain)
> The problem is in the 
> 
> rootnoverify (hd0,3)
> 
> line, which refers to the system in /dev/sda4 instead of /dev/sda2.
> 

Jiri, are you sure? I've recovered the item I had in the menu.lst and corrected this line to read "hd0,1" instead of "hd0,3", and it doesn't work either.

What does it report then? If it does not work, the only explanation I have is that the boot sector does not contain any valid boot data and you booted 10.3 directly via MBR (and then it is obvious that it cannot boot).

Let me have a look at the logs.

The log refers to /dev/sda2 as the target of chainloader:

"chainloader":"/dev/sda2"

which is passed to perl-Bootloader.

The only explanation I have to the system not booting even after this change is something strange in the 10.3 system which I cannot explain.

However, this doesn't change the fact that refering to /dev/sda4 is written incorrectly to the configuration file even though /dev/sda2 is passed to perl-Bootloader.

*** Bug 395782 has been marked as a duplicate of this bug. ***

(In reply to comment #10 from Jiri Srain)
> What does it report then?

It reports:

rootnoverify(hd0,1)
chainloader(hd0,1)+1

What should solve your problem is the following:

rootnoverify (hd0,1)
chainloader +1

There mustn't be a partition specified in the chainloader line. I'll try to fix this generally for openSUSE 11.0 if possible.

The same issue is still in RC1. First during installation in the menu the system/installation did not see my 10.3 partition /dev/sda8.
This is the entry for 10.3 in /boot/grub/menu.lst after using the bootloader module of yast.
----------
###Don't change this comment - YaST2 identifier: Original name:  openSUSE 10.3 (/dev/sda8)###
title  openSUSE 10.3 (/dev/sda8)
    root (hd0,7)
----------
If I change this in:
    rootnoverify (hd0,7)
    chainloader +1
----------
This does not work either.
The windows entry has:
    rootnoverify (hd0,7)
    chainloader (hd0,0)+1
or on the 10.3 partition
    rootnoverify (hd0,2)
    chainloader (hd0,0)+1
so I tried:
    rootnoverify (hd0,7)
    chainloader (hd0,7)+1
this did not work either.

Ok, I wasn't aware that your openSUSE 10.3 is on /dev/sda8 and so on an extended partition. Therefore chainloading such (extended) partitions doesn't work, one has to use something like the following:

title  openSUSE 10.3 (/dev/sda8)
    root (hd0,7)
    configfile /boot/grub/menu.lst

This issue should be fixed in next build finally.

Reassigning to new maintainer of perl-Bootloader.

alexander - is it already in svn?

Nope, unfortunately it isn't. I had to concentrate on other tasks.

fixed in svn as Alexander suggest in comment #14. For problem with extended partition please open another bug.

0.4.70 released, if problem still happen please reopen with actual logs

*** Bug 439212 has been marked as a duplicate of this bug. ***

*** Bug 439606 has been marked as a duplicate of this bug. ***

Created attachment 248596 [details]
YaST2 log directory

It is the YaST2 log directory.

I have the problem, but I don't know if I have the version where it is resolved (haven't found a way to see which version I'm running). I do have recently updated my software by going into Zen and selected "upgrade if newer version is available".

I've attached the YaST2 log directory after I went into YaST2, selected boot loader, "Suggest new configuration" and deleted one I didn't want to have listed.

I have no idea how to use bugzilla so I've probably screwed a bit up here and there

(In reply to comment #25 from Torstein Winterseth)
> I have the problem, but I don't know if I have the version where it is resolved
> (haven't found a way to see which version I'm running). I do have recently
> updated my software by going into Zen and selected "upgrade if newer version is
> available".
> 
> I've attached the YaST2 log directory after I went into YaST2, selected boot
> loader, "Suggest new configuration" and deleted one I didn't want to have
> listed.
> 
> I have no idea how to use bugzilla so I've probably screwed a bit up here and
> there
> 

Version which resolve this is in Opensuse 11.1 testing release (I think from beta2). If you have old configuration that is broken, we keep it, but you can change it by for example change tittle (change something and it is rewrite).
So do you have 11.1 testing release and after new proposal it is bad?

I am still running OpenSUSE 11.0 so I guess I still have the bugged version. I don't want to upgrade to an unstable version on this machine so I can't check if it's resolved on my computer.

(In reply to comment #27 from Torstein Winterseth)
> I am still running OpenSUSE 11.0 so I guess I still have the bugged version. I
> don't want to upgrade to an unstable version on this machine so I can't check
> if it's resolved on my computer.
> 

OK, so I close this as fixed.