I used the dvd from the boxed set to install the 64 bit version last night. I’ve been having a lot of problems with my display when I use the 64bit version but I finally got it installed and working.
After I did some updates and poked around a little, I was ready to shut down for the night. The last thing I did was use YaST to change the default option in the boot menu from the 64bit version on sda5 to the 32bit on sda2.
The next time I started up I got a kernel panic with openSUSE on sda2. The last lines from the the boot:
/bin/run-init: /sbin/init: Permission denied
Kernel panic - not syncing: Attempted to kill init!
All of the other partitions boot normally. Anyone know what went wrong here?
From whichever you are booting from, I presumed sda5. Actually, it’s important to know where the grub you are booting with was installed from plus where its loader and menu.lst files now reside. If you can boot into sda5, you can mount sda2 from there and pull the files that way.
As a starting point, since you have 3 instances of linux on the disk, we need to be clear on:
Where grub’s stage1 was last installed to. It could be in the MBR, or it could be in a boot sector on a primary partition being called from generic code in the MBR.
From which of the 3 instances is the stage1 calling its stage2 loader and menu.lst.
Everything flows from that chain. In the /etc/grub.conf you posted, it shows grub stage1 being installed in sda4 with a pointer to stage2 in sda4 - that means that when that installation was done, YaST saw either generic code in the MBR which it left untouched and sda4 was marked active, or that there was another stage1/stage2 setup which would be calling it.
Unless you manually instructed otherwise, in installing the 3 instances you installed grub 3 times and have 3 different menu.lst files. This has to be rationalized (i.e., “who’s on first?”). So, which is the “master” or “primary” instance; which menu.lst do you see at boot?
To mount another instance’s partition, e.g., to mount sda2 while in sda5: As root in a terminal do -
mount -t ext3 /dev/sda2 /mnt/sda2
###Don’t change this comment - YaST2 identifier: Original name: SUSE LINUX (/dev/sda2)###
title SUSE LINUX (/dev/sda2)
###Don’t change this comment - YaST2 identifier: Original name: openSUSE 11.1 - 220.127.116.11-9 (/dev/sda4)###
title openSUSE 11.1 - 18.104.22.168-9 (/dev/sda4)
The entry entitled SUSE LINUX is what I’m having problems with. When I boot into sda5, which is the default, there is an entry for SUSE LINUX, which is sda2. If I choose that one, it takes me to another grub screen which has just two entries- SUSE LINUX and SUSE LINUX fail safe. When I boot into SUSE LINUX, I get a kernel panic.
From the menu.lst posted here, I can’t see anything wrong. The only difference I can see between this one and menu.lst.old is the line at the top that says “YaST - generic_mbr”
All I can tell you for sure is that you either had “generic” or Windows boot code in the MBR before you began installing linux or that openSUSE in its first installation selected that method for the MBR (which requires grub stage1 to be in the boot sector of one of the “primary” partitions) and installed the generic code. Because subsequently, grub stage1 is being installed in partition boot sectors. The sda4 installation put grub stage1 in that partition’s boot sector pointing to stage2 in the same partition. The sda5 installation put grub in the sda3 boot sector pointing to sda5 for stage2. These are all examples of “chainloading”, where one boot program transfers control to another (as opposed to a single program booting all the OS’s itself; this is called “direct” booting). Note the last two stanza’s in the sda5 menu.lst; they are chainloading to a grub in sda2 and another grub in sda4 - and that is why you see additional menu’s, by the way; each chainloader transfer essentially re-initiates the process from that point which means another stage2 is being run with its respective menu.lst being used.
There are pro’s and con’s to both the chainload and direct methods, and there are even variations on each. What’s done just depends upon setup and personal preference. But, if you want multiple OS instances, it’s good to get an idea of how this all basically works or else there will be a lot of frustration.
At this point, it’s pointless to speculate on the kernel panic - could have been any number of causes. Whatever it was, you may not even see it again at all.
Re mounting partitions. If you want it to be done automatically, or you want it done on-demand but in a particular way to a particular mount point (i.e., directory), that is what /etc/fstab is for.