The chainloading makes sense, particularly in this situation?? I noticed the OP had two different entries for windows (hd1,0) and (hd0,0) in his initial post and am wondering if he had sda disconnected during the opensuse 11 install or switched drives in BIOS.

Well, hopefully he has everything working now.

Yes, the computer is now in a 'best guess, this really should work' state...


Gives these responses:

This is odd because if I mount sdb1 as in previous posts the contents are all there and look correct (ie. files are not zero size). I've also used my openSUSE CD in some clean installations and they boot fine so the CD is OK.

I added this entry to sda/boot/grub/menu.lst:
The computer booted, gave me the menu, and selecting the above entry gives this response, an old favourite that I've seen a lot...
There is obviously something that Grub really doesn't like about a second disk and my only guess is that it's the second SATA disk as I assume as PATA disks have been around for years that someone has tried that constellation before?

Well spotted... This comes from YaST's 'merge menu.lst from different partitions' function which would be quite clever if it resulted in something that boots!

Nope... Still the same. I understand a lot more about Grub now, but still it doesn't work and this is well beyond my understanding.

Thanks for your continued support - any further ideas? I think I'll go to the openSUSE site and open a bug report....

Edit: I scanned openSUSE's bug database and found this grub installation into mbr of second disk impossible which sounds relevant, although I'm still not 100% clear about the role the MBR of each disk plays in a two disk setup where only one is required to actually 'boot' the computer, the other being required only to 'boot' the chosen OS.

OK, I took the plunge and opened a bug report: https://bugzilla.novell.com/show_bug.cgi?id=413135

umm yeah I hope you are right....just to eliminate tiny things about adding second drives.....did your bios detect it correctly?

are the connectors firmly in.

and I know they show up as sdX and not hdX but are they by any chance IDE or atapi drives?

if so, have you jumpered as cable select? instead of slave

2) thanks for the bug link....but we tried to install grub on sdb1 (root partition) and I read that bug as failing if tried for mbr of drive 2?

3) why don't you have a go and installing lilo into root partition sdb1?
You already have the chainloader for sda menu so maybe grub will boot to lilo and lilo will kick off opensuse?

I know you are more frustrated than me....but I have not liked opensuse when I tried it...when you made a system change the config scripts too bloody ages to run.

I am currently testing sidux....and altho I am not used to debian style it is looking awefully good.

You have more patience than me.....I was shocked when my trusty commands failed for you.
I felt like committing....no not really but I can not explain it. I hope it is a bug which means its an opensuse thing....but it damages grub's reputation all this headache.

thankyou very much for all the feedback responses you have given. Others may spot what I and yancek can not?

I've only just spotted th8is thread, so pardon me if I repeat things which have already been said. My desktop has two hdd's with Win2K, Suse 10.3, and Ubuntu 8.04 thus:

Notice both the 1st partitions are active. I suspect this is the root cause of HellesAngel's problem.

sda3 is the Linux swap & sdb10 is for the Win2K PageFile (a trick I learned with NT4 servers, which seems to make it faster). Suse 10.3 root is sdb1, and Ubuntu is in sdb9. Grub is on the MBR of sda, and Ubuntu was installed with Grub loaded to its partition, then I just copied the lines from it's menu.lst to the one for Suse.

I've used this same config on other boxes with various combinations and it has always worked, though on the most recent one I used chainload commands in the main OS menu.lst to point to the other Linux's. Makes it easier when you re-install them.

great answers. all you are lame at all.

Thanks for the reply - same output from my PC gives this:

Only sda3 is bootable. If there is a simple solution to this then I'm all eager! The PC is in the 'virgin install' state at the moment, ie. with a non-booting openSUSE 11.0 installation on sdb1 and fully working SuSE10.0 and Win2K on sda, so it would be easy to try anything out...

HellesAngel

Back again to ask some questions and suggestions

1) In your first post, the sdb entry has a resume for sda swap.
Can you use a live cd and show us the /etc/fstab for sdb to prove fstab is using sda's swap pls?

2) SDB....has 2 partitions agreed.....but I am wondering if sdb1 is the /boot partition?
grub find ....finds actual files so if you have no vmlinuz on sdb1 it will not work but the vmlinzu-version x will


root (hd1,0)
try
find /grub/menu.lst
find /boot/grub/menu.lst

If top line works...you have a separate /boot partition otherwise the next line should work.....and if the next one fails.....grrrrr.

3) bootable flag.....did you try to toggle the bootable flag I suggested earlier?

Thanks for the continuing help! The bug report at SUSE is grinding through the process but let's attack from every angle:

So that looks OK.

Then from grub:
Same result as before. I did some playing with fdisk:
I didn't realise all partitions could be bootable, but still not boot...

So, now I get the following on boot to openSUSE 11.0:
The entry for booting to openSUSE 11.0 came from Yast where I did a merge from the sdb grub configuration. There may be something badly merged there, but it looks fair enough.

From sda the configuration files are now:
device.map:
menu.lst:
grub.conf:
All looks fair enough, I don't know enough about the rest to know what's good or bad...

hangon Hell

run that past me again.....the last bit.

Where exactly is this grub.conf file?

Its not right....its not right.....IMHO .... yippee....could be the source of the error.

1) I assume its a /etc/grub.conf on suse 10....sda.?

2) What I am proposing....assuming you are now multi-skilled in using a live cd....is use root powers to make that file unreadable or better still move it to your /home.

redo grub.

I do not like that file.....hint hint.

I think suse has got the wrong end of the stick and is attempting to do map command on you when it...suse grub on sda....should be able to chainload suse on sdb. And that map command will explain why its not finding its menu files because it says HD0,2.....sorry for the shout.....but grub is now looking at sda partition 3....OMG what a stuff up

3) So attempt 1.....move it to /home and see if you can reboot into sda suse
then if ok......lets redo those chainloader command for grub to chainload to sdb1....with a chainloader menu for suse on sda.

must say succeeded on last line or I have failed yet again.

If succeeded change suse on sda menu.lst so you have

title sdb chainloader
root (hd1,0)
chainloader +1



I shall wait before expanding on my ideas,

Which Opensuse is the grub.conf from? I have a similar setup with two versions of suse. Here is my /etc/grub.conf from the first partition which would be equivalent to your 10.0, mine is on sdb1:


root (hd1,0)
install --stage2=/boot/grub/stage2 /boot/grub/stage1 d (hd0) /boot/grub/stage20x8000 (hd1,0)/boot/grub/menu.lst
quit

Below are the contents of opensuse 10.3 on hdb11

setup --stage2=/boot/grub/stage2 (hd1,10) (hd1,10)
quit

I expect your contents will be different but, the important part I see is that the entries you show point to the third partition on the first drive when they should be pointing to (hd1,0). This applies only if the last post of yours for "grub.conf" was from opensuse11.0. I'd suggest taking a look at the /etc/grub.conf in 10.0 and 11.0 and comparing them.

Many thanks for the suggestions - following aus9's idea I moved /etc/grub.conf on sda3 (the SUSE 10.0) out of the way. Then I'm not sure what you meant by redo grub so I tried:

But this did not re-create /etc/grub.conf on sda3.

Then:
Also still no /etc/grub.conf on sda3.

The computer is booted normally using the SUSE10.0 installation on sda3 - is it necessary to reboot using the live CD to apply these changes?

The next steps you suggested bring the following, sadly predictable results:
I'll put grub.conf back and have a look at yancek's suggestions...

Can you boot any OS now? If so can you boot a Suse? Being honest you all have lost me half way down the second page. aus9 you were probably right in suggesting he boot by chainloading. When making changes to Suse's boot order or config files I found it best to do through YaST because they have changed the name of some of the directories. But if he does not have one Suse that will boot then he will probably have to do a repair or new install.

ok sorry lets try that again.

when I asked where is this file....I assume your answer is /dev/sda3 for the one posted and /dev/sdb1 for the one not posted.

2) The one you did not move....from /dev/sdb1.....is that symbolically linked to /boot/grub/menu.lst?

What I want you to do, is to move all of these /etc/grub.conf out of their pathways or change their permissions to --- no read no write no execute.

I am thinking that the map command had stopped the manual commands I have previously failed to get working and looking at your post.....

my poor suggestion on redo grub I shall explain again.

P1) I assume you have still moved sd A /etc/grub.conf away from /etc so boot a live cd to move sdb1

if live cd does not automatically mount sdb1 with read write powers you will need to umount the read only sdb1...or if its not mounted in any way just follow the next bit
You may of course have a live cd that already mounts in read/write mode maybe at /mnt/sdb1?


Then navigate with root powers file manager to /z/etc/ and move that grub.conf please.

Then issue command
umount /z
for P3


P2) redo grub for sda within live cd

as prev discussed must give you a succeeded message.
Your last effort put a grub into your root partition of sda3 but left grub in mbr sda.

Forget the suse /etc/grub.conf please.

P3) Now the chainloader

again we need a succeeded message.

P4) Lets review

grub redone for mbr in sda links to sda3's booting files
grub for sdb1 is in root of sdb1 and will need a chainload command from sda3's menu

Since you have already done the menu

try a reboot and see if you can get into sda3 as per Larry's question
Then try to get into sdb1

The bottom line is I think the reason why my previous commands did not work for you was the fact that suse has introduced a not needed etc files and one of them caused a map command to confuse the grub command for chainloading.

P5) If any part fails....do not proceed with the next bit.....and obviously if you can not boot sda....re-use the live cd to restore the /etc file in case I am wrong?


good luck