Re: Help 10.3 a mess After YOU Upgrade

On Sun, 27 Jan 2008 10:20:54 UTC, "Rajko M." <kakomo123@xxxxxxxxxxxx>
wrote:

PaulRS wrote:

On Sat, 26 Jan 2008 09:47:00 UTC, "Rajko M." <kakomo123@xxxxxxxxxxxx>
wrote:
...
Anyway, Installation 1 was still OK (not updated) and Installation 2
was the one screwed up by updating. � SO, I re-installed Installation 2
making a partimage of all before trying "YOU" again.
...
Since 10.2 openSUSE default is to install in MBR generic boot loader, not
GRUB stage1. The stage1 goes in boot sector of system root partition.
...
I would expect now installation 1 might be problem in the future, please
run command fdisk as described above and post the result.


OK - I did what you said but you will have to try and explain the
results. First, let me give you the layout of the HD

It is divided into 10 partitions
sda1=MSDOS Primary bootable from GRUB (mounted for both SUSEs)
sda3= Extended partition
sda5=SWAP
sda6=/(root) 1st SUSE install (Called MAIN in GRUB)
sda7=/home 1st SUSE install
sda8=/(root) 2nd SUSE install (Called PLAY in GRUB)
sda9=/home 2nd SUSE install
sda10=DATA (mounted for both)

NOW, when I do fdisk as suggested both installations have the * in
the boot column of sda1 the DOS partition that is formatted for
IBM-PC-DOS7 This does not make sense to me.
When installing from YAST I used the BOOT section of the YAST
preinstall (before it does anything) to set the GRUB options. I
placed the info for proper root partitions in the fill-in boxes (sda6
for MAIN and sda8 for PLAY)

The fdisk table shows the * in sda1 for both installs?????

Paul

It is OK.
You have probably GRUB stage1 (512 bytes) installed in MBR. There is no
intermediate generic boot loader, and GRUB doesn't need, nor use, active
partition flag. Besides there is no other partition than /dev/sda1 that can
have it and it is not Linux partition.

How booting works?
BIOS gives control to MBR code, in this case GRUB stage1.
GRUB stage1 gives control to stage1_5 or stage2.
GRUB stage2 loads /boot/menu.lst, a configuration file, from predefined
location, presents menu, than according to selection actually loads initrd
and kernel as defined for selected menu item. Location of menu.lst is hard
coded in stage2 during configuration with YaST Boot Loader.

Kernels are usually in directory /boot on root partition. You have right
kernel for each installation in:
/dev/sda6 directory /boot has kernel for MAIN
/dev/sda8 directory /boot has kernel for PLAY

In your previous setup predefined place for configuration file was
/dev/sda6 directory /boot/grub/menu.lst

Your previous problem was that kernel update went wrong because script that
runs after update (it is called 'postin' script and it is a part of rpm
file that YOU installed as update) could not find /boot/grub/menu.lst as it
was on the other partition and failed.

This is part where I had problems few times and had report bug on that, that
is when I learned to check what post install script did, before reboot.
Later is a lot of typing to get it right. The other option is to run
blindly
mkinitrd && SuSEconfig
it can't hurt, but as mentioned in previous post I had no problems and from
post install script prospective we have the same configuration.

I guess that something else was messed in your old menu.lst (/dev/sda6) or
update really did not run correctly for some reason.
Which problem was is hidden in your old menu.lst (the old /boot on /dev/sda8
is now gone).

If you can post it, it may help to find out what was the reason.
In the mean time I'll try to see the rpm of latest kernel update.

BTW, in Linux you can copy text from console (like 'fdisk -l' output) by
simply marking text in console, move mouse cursor to newsgroup program and
click on middle button.


Thanks so much for the info on GRUB. It is very helpful to discover
what may have happened.

The PLAY install is the one I test with before going to do the same on
MAIN. (I really hate installing new stuff on a perfectly working
system as many times things get messed up) At the time of the first
update (YOU) including the kernel, I was updating the PLAY
installation. The MAIN installation is marked in GRUB as the
"default" when the computer is turned on. Do you think that maybe
this install script for the kernel went for the "default" installation
(MAIN) instead of the one I was on (PLAY)?

Also, when I reinstalled the PLAY installation after the failure I ran
the YOU update w/o the kernel first on PLAY then on MAIN with no
problems - that is why I concluded that upgrading the Kernel caused
the problems I saw.

Thanks for your time and consideration,
Paul


--

.