Help 10.3 a mess After YOU Upgrade - Suse

This is a discussion on Help 10.3 a mess After YOU Upgrade - Suse ; I have a new 10.3 retail installation I also ran YOU (online upgrade including the Kernel) -= I rebooted afterwards as directed. Now - no sound (Kmix is not to be found) - no ethernet In looking at the boot ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 32

Thread: Help 10.3 a mess After YOU Upgrade

  1. Help 10.3 a mess After YOU Upgrade

    I have a new 10.3 retail installation

    I also ran YOU (online upgrade including the Kernel) -= I rebooted
    afterwards as directed.
    Now - no sound (Kmix is not to be found)
    - no ethernet

    In looking at the boot messages there are a series of FATALS at the
    end where the system is looking to load Kernal modules - BUT it is
    looking for modules with the original (old) Kernel numbers. The
    directory no longer exists - only the new /lib/modules/new kernel
    numbers.

    Whats UP?

    I can reinstall the whole thing, but what do you recommend?

    Paul
    --


  2. Re: Help 10.3 a mess After YOU Upgrade

    PaulRS wrote:
    > I have a new 10.3 retail installation
    >
    > I also ran YOU (online upgrade including the Kernel) -= I rebooted
    > afterwards as directed.
    > Now - no sound (Kmix is not to be found)
    > - no ethernet
    >
    > In looking at the boot messages there are a series of FATALS at the
    > end where the system is looking to load Kernal modules - BUT it is
    > looking for modules with the original (old) Kernel numbers. The
    > directory no longer exists - only the new /lib/modules/new kernel
    > numbers.
    >
    > Whats UP?
    >
    > I can reinstall the whole thing, but what do you recommend?
    >
    > Paul

    Dear Paul,


    Which kernel do you boot?

    Might it be that you still have the old kerenl as default boot option in
    /boot/grub/menu.lst?


    Kind regards,


    Jan Gerrit

  3. Re: Help 10.3 a mess After YOU Upgrade

    PaulRS wrote:

    > I have a new 10.3 retail installation
    >
    > I also ran YOU (online upgrade including the Kernel) -= I rebooted
    > afterwards as directed.
    > Now - no sound (Kmix is not to be found)
    > - no ethernet
    >
    > In looking at the boot messages there are a series of FATALS at the
    > end where the system is looking to load Kernal modules - BUT it is
    > looking for modules with the original (old) Kernel numbers. The
    > directory no longer exists - only the new /lib/modules/new kernel
    > numbers.
    >
    > Whats UP?
    >
    > I can reinstall the whole thing, but what do you recommend?
    >
    > Paul
    > --


    Being an old timer I would suggest that it is always a good idea when the
    kernel gets updated to open a root terminal (after Yast finishes !) and
    type:

    mkinitrd && SuSEconfig


    Press Enter and wait for it to complete. Then you can avoid the seldom
    occurring but much hated incomplete kernel upgrade. This shouldn't be
    necessary but sometimes things don't go as you hope...

    In the mean time you can boot to the CD / DVD and run the repair option to
    get back the original kernel. Then boot into your system and upgrade the
    kernel again being sure to do as I mentioned above..... mkinitrd &&
    SuSEconfig !!!






    'mkinitrd && SuSEconfig' is your friend..........

  4. Re: Help 10.3 a mess After YOU Upgrade

    On Wed, 23 Jan 2008 18:52:03 UTC, Jan Gerrit Kootstra
    wrote:

    > PaulRS wrote:
    > > I have a new 10.3 retail installation
    > >
    > > I also ran YOU (online upgrade including the Kernel) -= I rebooted
    > > afterwards as directed.
    > > Now - no sound (Kmix is not to be found)
    > > - no ethernet
    > >
    > > In looking at the boot messages there are a series of FATALS at the
    > > end where the system is looking to load Kernal modules - BUT it is
    > > looking for modules with the original (old) Kernel numbers. The
    > > directory no longer exists - only the new /lib/modules/new kernel
    > > numbers.
    > >
    > > Whats UP?
    > >
    > > I can reinstall the whole thing, but what do you recommend?
    > >
    > > Paul

    > Dear Paul,
    >
    >
    > Which kernel do you boot?
    >
    > Might it be that you still have the old kerenl as default boot option in
    > /boot/grub/menu.lst?
    >
    >
    > Kind regards,
    >
    >
    > Jan Gerrit


    I was assuming that "YOU" would set up the new kernel. The "Reboot
    after YOU" said something like modules would be built so system would
    work correctly. The directory /lib/kernel is present so I assume I am
    running the new kernel, maybe not - it is looking for the original
    (retail-CD) kernel modules and the directory with that number is gone.


    --


  5. Re: Help 10.3 a mess After YOU Upgrade

    PaulRS wrote:
    > I have a new 10.3 retail installation
    >
    > I also ran YOU (online upgrade including the Kernel) -= I rebooted
    > afterwards as directed.
    > Now - no sound (Kmix is not to be found)
    > - no ethernet
    >
    > In looking at the boot messages there are a series of FATALS at the
    > end where the system is looking to load Kernal modules - BUT it is
    > looking for modules with the original (old) Kernel numbers. The
    > directory no longer exists - only the new /lib/modules/new kernel
    > numbers.
    >
    > Whats UP?
    >
    > I can reinstall the whole thing, but what do you recommend?
    >
    > Paul


    I would wipe all partitions and start all new. You'll enjoy a new virgin
    system again.

    --
    Blattus Slafaly ? 3 7/8

  6. Re: Help 10.3 a mess After YOU Upgrade

    PaulRS wrote:

    > On Wed, 23 Jan 2008 18:52:03 UTC, Jan Gerrit Kootstra
    > wrote:
    >
    >> PaulRS wrote:
    >> > I have a new 10.3 retail installation
    >> >
    >> > I also ran YOU (online upgrade including the Kernel) -= I rebooted
    >> > afterwards as directed.
    >> > Now - no sound (Kmix is not to be found)
    >> > - no ethernet
    >> >
    >> > In looking at the boot messages there are a series of FATALS at the
    >> > end where the system is looking to load Kernal modules - BUT it is
    >> > looking for modules with the original (old) Kernel numbers. The
    >> > directory no longer exists - only the new /lib/modules/new kernel
    >> > numbers.
    >> >
    >> > Whats UP?
    >> >
    >> > I can reinstall the whole thing, but what do you recommend?
    >> >
    >> > Paul

    >> Dear Paul,
    >>
    >>
    >> Which kernel do you boot?
    >>
    >> Might it be that you still have the old kerenl as default boot option in
    >> /boot/grub/menu.lst?
    >>
    >>
    >> Kind regards,
    >>
    >>
    >> Jan Gerrit

    >
    > I was assuming that "YOU" would set up the new kernel. The "Reboot
    > after YOU" said something like modules would be built so system would
    > work correctly. The directory /lib/kernel is present so I assume I am
    > running the new kernel, maybe not - it is looking for the original
    > (retail-CD) kernel modules and the directory with that number is gone.
    >
    >
    > --


    Read what I said in my other post but also be aware that whenever you
    upgrade your kernel while shutting down you will get error messages about
    missing kernel modules because they ARE missing !! This is in reference to
    the now missing previous modules, not the newly installed ones.. Don't
    confuse this with any message you might see when booting up.

  7. Re: Help 10.3 a mess After YOU Upgrade

    On Thu, 24 Jan 2008 00:00:57 UTC, Michael Soibelman
    wrote:

    > PaulRS wrote:
    >
    > > On Wed, 23 Jan 2008 18:52:03 UTC, Jan Gerrit Kootstra
    > > wrote:
    > >
    > >> PaulRS wrote:
    > >> > I have a new 10.3 retail installation
    > >> >
    > >> > I also ran YOU (online upgrade including the Kernel) -= I rebooted
    > >> > afterwards as directed.
    > >> > Now - no sound (Kmix is not to be found)
    > >> > - no ethernet
    > >> >
    > >> > In looking at the boot messages there are a series of FATALS at the
    > >> > end where the system is looking to load Kernal modules - BUT it is
    > >> > looking for modules with the original (old) Kernel numbers. The
    > >> > directory no longer exists - only the new /lib/modules/new kernel
    > >> > numbers.
    > >> >
    > >> > Whats UP?
    > >> >
    > >> > I can reinstall the whole thing, but what do you recommend?
    > >> >
    > >> > Paul
    > >> Dear Paul,
    > >>
    > >>
    > >> Which kernel do you boot?
    > >>
    > >> Might it be that you still have the old kerenl as default boot option in
    > >> /boot/grub/menu.lst?
    > >>
    > >>
    > >> Kind regards,
    > >>
    > >>
    > >> Jan Gerrit

    > >
    > > I was assuming that "YOU" would set up the new kernel. The "Reboot
    > > after YOU" said something like modules would be built so system would
    > > work correctly. The directory /lib/kernel is present so I assume I am
    > > running the new kernel, maybe not - it is looking for the original
    > > (retail-CD) kernel modules and the directory with that number is gone.
    > >
    > >
    > > --

    >
    > Read what I said in my other post but also be aware that whenever you
    > upgrade your kernel while shutting down you will get error messages about
    > missing kernel modules because they ARE missing !! This is in reference to
    > the now missing previous modules, not the newly installed ones.. Don't
    > confuse this with any message you might see when booting up.


    My messages were in the boot log after rebooting 2-3 times. I think I
    may know what happened: I have two installations of SuSE 10.3 on the
    same HD. Grub is on the MBR. They are on different partitions
    5-swap 6-/(root) 7-/home of 1st install; 8-/(root) 9-/home of second
    install. They have different names in the Section Name menu of Grub.

    I saw that the "YOU" install also tried to modify GRUB for the proper
    Kernel # in these GRUB records - My guess is that this is where things
    screwed up. One installation was upgraded and the other was not. I
    surmise that GRUB got updated wrong. So maybe things were coming from
    two different installations???? (I originally entered the 2nd
    installation "image" info in GRUB manually, but installation 1 is the
    default and the original info supplied by YAST.)

    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. This time I
    opted not to install the upgraded kernel and everything went well -
    ALL OK.

    If I am right about what happened, I will have to figure out how to
    upgrade the Kernel with my dual installation


    I have noted your other post answer in my "Tips" notebook. Thanks
    Paul
    --


  8. Re: Help 10.3 a mess After YOU Upgrade

    PaulRS wrote:

    > On Thu, 24 Jan 2008 00:00:57 UTC, Michael Soibelman
    > wrote:
    >
    >> PaulRS wrote:
    >>
    >> > On Wed, 23 Jan 2008 18:52:03 UTC, Jan Gerrit Kootstra
    >> > wrote:
    >> >
    >> >> PaulRS wrote:
    >> >> > I have a new 10.3 retail installation
    >> >> >
    >> >> > I also ran YOU (online upgrade including the Kernel) -= I rebooted
    >> >> > afterwards as directed.
    >> >> > Now - no sound (Kmix is not to be found)
    >> >> > - no ethernet
    >> >> >
    >> >> > In looking at the boot messages there are a series of FATALS at the
    >> >> > end where the system is looking to load Kernal modules - BUT it is
    >> >> > looking for modules with the original (old) Kernel numbers. The
    >> >> > directory no longer exists - only the new /lib/modules/new kernel
    >> >> > numbers.
    >> >> >
    >> >> > Whats UP?
    >> >> >
    >> >> > I can reinstall the whole thing, but what do you recommend?
    >> >> >
    >> >> > Paul
    >> >> Dear Paul,
    >> >>
    >> >>
    >> >> Which kernel do you boot?
    >> >>
    >> >> Might it be that you still have the old kerenl as default boot option
    >> >> in /boot/grub/menu.lst?
    >> >>
    >> >>
    >> >> Kind regards,
    >> >>
    >> >>
    >> >> Jan Gerrit
    >> >
    >> > I was assuming that "YOU" would set up the new kernel. The "Reboot
    >> > after YOU" said something like modules would be built so system would
    >> > work correctly. The directory /lib/kernel is present so I assume I am
    >> > running the new kernel, maybe not - it is looking for the original
    >> > (retail-CD) kernel modules and the directory with that number is gone.
    >> >
    >> >
    >> > --

    >>
    >> Read what I said in my other post but also be aware that whenever you
    >> upgrade your kernel while shutting down you will get error messages about
    >> missing kernel modules because they ARE missing !! This is in reference
    >> to
    >> the now missing previous modules, not the newly installed ones.. Don't
    >> confuse this with any message you might see when booting up.

    >
    > My messages were in the boot log after rebooting 2-3 times. I think I
    > may know what happened: I have two installations of SuSE 10.3 on the
    > same HD. Grub is on the MBR. They are on different partitions
    > 5-swap 6-/(root) 7-/home of 1st install; 8-/(root) 9-/home of second
    > install. They have different names in the Section Name menu of Grub.
    >
    > I saw that the "YOU" install also tried to modify GRUB for the proper
    > Kernel # in these GRUB records - My guess is that this is where things
    > screwed up. One installation was upgraded and the other was not. I
    > surmise that GRUB got updated wrong. So maybe things were coming from
    > two different installations???? (I originally entered the 2nd
    > installation "image" info in GRUB manually, but installation 1 is the
    > default and the original info supplied by YAST.)
    >
    > 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. This time I
    > opted not to install the upgraded kernel and everything went well -
    > ALL OK.
    >
    > If I am right about what happened, I will have to figure out how to
    > upgrade the Kernel with my dual installation
    >
    >
    > I have noted your other post answer in my "Tips" notebook. Thanks
    > Paul
    > --

    if you go into yast2 AND system then boot loader then click on one of the
    entries then edit and see what is being loaded that should tell you what is
    going on!

    is one os able to access the partition of the other os?

  9. Re: Help 10.3 a mess After YOU Upgrade

    PaulRS wrote:

    > My messages were in the boot log after rebooting 2-3 times. *I think I
    > may know what happened: I have two installations of SuSE 10.3 on the
    > same HD. *Grub is on the MBR. *They are on different partitions
    > 5-swap 6-/(root) 7-/home of 1st install; 8-/(root) 9-/home of second
    > install. *They have different names in the Section Name menu of Grub.
    >
    > I saw that the "YOU" install also tried to modify GRUB for the proper
    > Kernel # in these GRUB records - My guess is that this is where things
    > screwed up. *One installation was upgraded and the other was not. *I
    > surmise that GRUB got updated wrong. So maybe things were coming from
    > two different installations???? *(I originally entered the 2nd
    > installation "image" info in GRUB manually, but installation 1 is the
    > default and the original info supplied by YAST.)
    >
    > 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. *This time I
    > opted not to install the upgraded kernel and everything went well -
    > ALL OK.
    >
    > If I am right about what happened, I will have to figure out how to
    > upgrade the Kernel with my dual installation
    >
    >
    > I have noted your other post answer in my "Tips" notebook. *Thanks
    > Paul


    You can use YOU and upgrade kernel, than open console as root and run, as
    suggested
    mkinitrd && SuSEconfig
    It will create initrd, if it is missing.

    I'm using multiboot system like yours.

    So far I recall there was no recent problems with updates that will leave
    system without initrd, but there is always problem if you boot 2 or more
    installations from one.

    In your case it was installation 1, partition 6.
    Now after reinstallation, it could be that installation 2 is the one that
    system boots from.

    The 'fdisk -l' (letter L, not number 1) will reveal which partition is now
    used as boot. There will be '*' in column Boot marking partition that is
    used to boot from.

    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.

    Note that after Grub takes control over booting, you can boot from any
    partition anyway.

    Your problem was that system was booting from partition 6 and script that
    should change /boot/grub/menu.lst could not find it on partition 8 (that
    was reported error) as it was on partition 6, so menu.lst was not changed.

    I would expect now installation 1 might be problem in the future, please run
    command fdisk as described above and post the result.

    --
    Regards, Rajko.
    See http://en.opensuse.org/Portal

  10. Re: Help 10.3 a mess After YOU Upgrade

    On Sat, 26 Jan 2008 09:47:00 UTC, "Rajko M."
    wrote:

    > PaulRS wrote:
    >
    > > My messages were in the boot log after rebooting 2-3 times. *I think I
    > > may know what happened: I have two installations of SuSE 10.3 on the
    > > same HD. *Grub is on the MBR. *They are on different partitions
    > > 5-swap 6-/(root) 7-/home of 1st install; 8-/(root) 9-/home of second
    > > install. *They have different names in the Section Name menu of Grub.
    > >
    > > I saw that the "YOU" install also tried to modify GRUB for the proper
    > > Kernel # in these GRUB records - My guess is that this is where things
    > > screwed up. *One installation was upgraded and the other was not. *I
    > > surmise that GRUB got updated wrong. So maybe things were coming from
    > > two different installations???? *(I originally entered the 2nd
    > > installation "image" info in GRUB manually, but installation 1 is the
    > > default and the original info supplied by YAST.)
    > >
    > > 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. *This time I
    > > opted not to install the upgraded kernel and everything went well -
    > > ALL OK.
    > >
    > > If I am right about what happened, I will have to figure out how to
    > > upgrade the Kernel with my dual installation
    > >
    > >
    > > I have noted your other post answer in my "Tips" notebook. *Thanks
    > > Paul

    >
    > You can use YOU and upgrade kernel, than open console as root and run, as
    > suggested
    > mkinitrd && SuSEconfig
    > It will create initrd, if it is missing.
    >
    > I'm using multiboot system like yours.
    >
    > So far I recall there was no recent problems with updates that will leave
    > system without initrd, but there is always problem if you boot 2 or more
    > installations from one.
    >
    > In your case it was installation 1, partition 6.
    > Now after reinstallation, it could be that installation 2 is the one that
    > system boots from.
    >
    > The 'fdisk -l' (letter L, not number 1) will reveal which partition is now
    > used as boot. There will be '*' in column Boot marking partition that is
    > used to boot from.
    >
    > 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.
    >
    > Note that after Grub takes control over booting, you can boot from any
    > partition anyway.
    >
    > Your problem was that system was booting from partition 6 and script that
    > should change /boot/grub/menu.lst could not find it on partition 8 (that
    > was reported error) as it was on partition 6, so menu.lst was not changed.
    >
    > 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





    --


  11. Re: Help 10.3 a mess After YOU Upgrade

    PaulRS wrote:

    > On Sat, 26 Jan 2008 09:47:00 UTC, "Rajko M."
    > 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.



    --
    Regards, Rajko.
    See http://en.opensuse.org/Portal

  12. Re: Help 10.3 a mess After YOU Upgrade

    On Sun, 27 Jan 2008 10:20:54 UTC, "Rajko M."
    wrote:

    > PaulRS wrote:
    >
    > > On Sat, 26 Jan 2008 09:47:00 UTC, "Rajko M."
    > > 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


    --


  13. Re: Help 10.3 a mess After YOU Upgrade

    PaulRS wrote:

    >> 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)?


    Hmm... It seems that I was not clear.

    'Default' is setting in configuration file /boot/grub/menu.lst which tells
    grub what to boot if you don't choose anything, but you can have more than
    one /boot/grub/menu.lst on computer. Actually you can have one on each
    partition.

    GRUB can't know which one you want to use. This information is hard coded in
    GRUB stage2 during GRUB installation and default is to use one on current
    root partition (last time it was /dev/sda8).

    I guess that you have now 2 files /boot/grub/menu.lst. One on /dev/sda6 and
    one on /dev/sda8. Considering that you last installed system on /dev/sda8
    than that menu.lst should be now used by grub.

    To check which one is now used, you can manually change /boot/grub/menu.lst
    on /dev/sda8 by adding some dummy entry. For instance last entry in mine
    is:
    **********
    ###Don't change this comment - YaST2 identifier: Original name: windows###
    title Windows
    rootnoverify (hd0,2)
    chainloader (hd0,0)+1
    **********

    I would add one like this:

    **********
    title Windows duplicate
    rootnoverify (hd0,2)
    chainloader (hd0,0)+1
    **********

    Adding item like this will do nothing except add new item to the list of
    bootable systems. If you use 'Windows duplicate' it will boot windows, just
    as the 'Windows' will do, so it is the safe way to check which menu.lst is
    currently used by grub.

    Now when you reboot it will show you boot screen with last 2 items listed
    in list:
    Windows
    Windows duplicate

    If that is the case than your PLAY (/dev/sda8) installation is now the one
    that is used to control boot process and you can safely update kernel on
    that installation. Problem may occur now on your MAIN (/dev/sda6)
    installation.

    If not than /boot/grub/menu.lst on /dev/sda6 is still used by GRUB and you
    have the same settings as before (but I doubt that).

    If it is /dev/sda8 used now you can change that by booting in /dev/sda6 and
    running YaST module Boot Loader. It is the same job as you did during
    installation so there should be no bad surprises, besides you actually have
    nothing to enter, just run trough. Well, I would check anyway is everything
    as I want.

    > 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.


    Kernel updates are usually important, so you should not skip them, but that
    is up to you, it is your computer.

    Skilled computer administrators review updates first to see are they
    applicable to their computers and if they are than they apply them, but I'm
    not the one, and probably neither you are (at least for Linux).

    --
    Regards, Rajko.
    See http://en.opensuse.org/Portal

  14. Re: Help 10.3 a mess After YOU Upgrade

    Rajko M. wrote:

    .....
    > If that is the case than your PLAY (/dev/sda8) installation is now the one
    > that is used to control boot process and you can safely update kernel on
    > that installation. Problem may occur now on your MAIN (/dev/sda6)
    > installation.

    ....
    It is sometimes usefull to re-read messages.
    There will be error, but not the same as you have seen.

    Now with both installations having /boot/grub/menu.lst there will be no
    errors reported. When you update kernel the mentioned post install script
    will update menu.lst. In case of /dev/sda8 it will be the real one, in case
    of /dev/sda6 it will be the one that is not in use.

    As script is updating symlinks to vmlinuz and initrd, you kernel update
    should work anyway.

    BTW, I looked in postinstall script for the last kernel, it seems OK.

    --
    Regards, Rajko.
    See http://en.opensuse.org/Portal

  15. Re: Help 10.3 a mess After YOU Upgrade

    On Mon, 28 Jan 2008 02:14:28 UTC, "Rajko M."
    wrote:

    > Rajko M. wrote:
    >
    > ....
    > > If that is the case than your PLAY (/dev/sda8) installation is now the one
    > > that is used to control boot process and you can safely update kernel on
    > > that installation. Problem may occur now on your MAIN (/dev/sda6)
    > > installation.

    > ...
    > It is sometimes usefull to re-read messages.
    > There will be error, but not the same as you have seen.
    >
    > Now with both installations having /boot/grub/menu.lst there will be no
    > errors reported. When you update kernel the mentioned post install script
    > will update menu.lst. In case of /dev/sda8 it will be the real one, in case
    > of /dev/sda6 it will be the one that is not in use.
    >
    > As script is updating symlinks to vmlinuz and initrd, you kernel update
    > should work anyway.
    >
    > BTW, I looked in postinstall script for the last kernel, it seems OK.
    >


    I had time to try your "experiment" in modifying both
    /boot/grub/menu.lst files. I discovered that the MBR Grub is sending
    to the menu.lst on the PLAY (/sda8) partition for both MAIN and PLAY.
    This would have been the last of the two receint re-installations.

    I am not sure which was last at the first install (since I have
    reinstalled both a couple of times because I did not understand what
    was happening) I THINK that just before the YOU update with the new
    kernel, that MAIN would have been the last install making the MBR
    Grub use the menu.lst on MAIN(sda6). I tried the YOU update first on
    EXP (sda8). If I understand you correctly, it would have updated
    menu.lst on EXP (sda8) NOT THE ONE IN USE on /sda6. So when I
    rebooted EXP as instructed after the update, it was reading from MAIN
    menu.lst (sda6) which was giving the old kernel numbers and old ininrd
    numbers.

    The system did load the EXP installation, but all the FATALS listed at
    the end of the boot log were looking for kernel modules with the old
    number. Does this make sense to you??

    If this is correct, then could I have gone to the REAL menu.lst in the
    other installation (sda6), modified it for the right kernel and initrd
    numbers (as updated) and all should have been well. Does this make
    sense?

    Again thanks for all you help on this. SuSE says, "Have a lot a fun"
    - not sure I am having it as yet!
    Paul



    --


  16. Re: Help 10.3 a mess After YOU Upgrade

    PaulRS wrote:

    > On Mon, 28 Jan 2008 02:14:28 UTC, "Rajko M."
    > wrote:
    >
    >> Rajko M. wrote:
    >>
    >> ....
    >> > If that is the case than your PLAY (/dev/sda8) installation is now the
    >> > one that is used to control boot process and you can safely update
    >> > kernel on that installation. Problem may occur now on your MAIN
    >> > (/dev/sda6) installation.

    >> ...
    >> It is sometimes usefull to re-read messages.
    >> There will be error, but not the same as you have seen.
    >>
    >> Now with both installations having /boot/grub/menu.lst there will be no
    >> errors reported. When you update kernel the mentioned post install script
    >> will update menu.lst. In case of /dev/sda8 it will be the real one, in
    >> case of /dev/sda6 it will be the one that is not in use.
    >>
    >> As script is updating symlinks to vmlinuz and initrd, you kernel update
    >> should work anyway.
    >>
    >> BTW, I looked in postinstall script for the last kernel, it seems OK.
    >>

    >
    > I had time to try your "experiment" in modifying both
    > /boot/grub/menu.lst files. I discovered that the MBR Grub is sending
    > to the menu.lst on the PLAY (/sda8) partition for both MAIN and PLAY.
    > This would have been the last of the two receint re-installations.


    OK. That is what I suspected. GRUB is now instructed to use manu.lst
    on /dev/sda8 so that is place that should not have problem during update.

    > I am not sure which was last at the first install (since I have
    > reinstalled both a couple of times because I did not understand what
    > was happening) I THINK that just before the YOU update with the new
    > kernel, that MAIN would have been the last install making the MBR
    > Grub use the menu.lst on MAIN(sda6). I tried the YOU update first on
    > EXP (sda8). If I understand you correctly, it would have updated
    > menu.lst on EXP (sda8) NOT THE ONE IN USE on /sda6. So when I
    > rebooted EXP as instructed after the update, it was reading from MAIN
    > menu.lst (sda6) which was giving the old kernel numbers and old ininrd
    > numbers.


    It should not if all is correct. It seems that menu.lst on /dev/sda6 was
    referring to kernel and initrd on /dev/sda8 with real file names, not
    symlinks.

    I give you a sample menu.lst below.

    > The system did load the EXP installation, but all the FATALS listed at
    > the end of the boot log were looking for kernel modules with the old
    > number. Does this make sense to you??


    Yes.

    > If this is correct, then could I have gone to the REAL menu.lst in the
    > other installation (sda6), modified it for the right kernel and initrd
    > numbers (as updated) and all should have been well. Does this make
    > sense?


    Here is menu.lst based on mine, modified with your partition numbers.
    Some entries will work with any kernel (vmlinuz) and any initrd.

    ################################################## #################
    default 0
    timeout 10
    gfxmenu (hd0,5)/boot/message

    title openSUSE 10.3 - MAIN
    root (hd0,8)
    kernel /boot/vmlinuz root=/dev/sda6 [see 1]
    initrd /boot/initrd

    title openSUSE 10.3 PLAY
    root (hd0,7)
    kernel /boot/vmlinuz root=/dev/sda8 [see 1]
    initrd /boot/initrd

    title Failsafe -- openSUSE 10.3 MAIN
    root (hd0,2)
    kernel /boot/vmlinuz root=/dev/sda6 [see 2]
    initrd /boot/initrd

    title Windows
    rootnoverify (hd0,0)
    chainloader (hd0,0)+1
    ################################################## #################

    For instance one of entries in my menu.lst is:
    title openSUSE 10.3 - (boot)
    root (hd0,2)
    kernel /boot/vmlinuz-2.6.22.12-0.1-default root=/dev/sda3
    initrd /boot/initrd-2.6.22.12-0.1-default

    What is the problem?
    Instead of pointing to symlink vmlinuz [see 3] it points to exact kernel
    file.
    While in this particular case it is not a problem, as my main menu.lst is on
    partition 3, so it will be updated, it would be problem if the same way is
    used to refer to kernel on another partition.

    After kernel update on another partition, version number in
    vmlinuz-2.6.22.12-0.1-default will be different (say 2.6.22.13-5) and GRUB
    will not find kernel. I don't know what will GRUB do when there is no
    kernel, IMHO it should report missing file and stop. Though GRUB is very
    complex boot loader and it can have fallback functionality to look for any
    kernel it can find and attempt to boot anyway, which will lead to bunch of
    errors, but it would be possible to get some running Linux and attempt
    repair.

    What exactly happened may be possible to discover looking in menu.lst
    on /dev/sda6 (that is why it would be good if you post that file). There is
    only 2 options, either menu.lst was pointing exact kernel, or symlink was
    not updated on /dev/sda8.
    BTW, it would be updated with:
    mkinitrd && SuSEconfig
    without reinstallation.

    > Again thanks for all you help on this. SuSE says, "Have a lot a fun"
    > - not sure I am having it as yet!
    > Paul


    Depends what you see as a fun. For those that like playing with system there
    is a plenty of fun ;-)


    [1] To keep line short, I skipped:
    vga=0x31a resume=/dev/sda5 splash=silent showopts

    [2] The same here:
    vga=normal showopts ide=nodma apm=off acpi=off noresume edd=off 3

    [3] This is edited listing of /boot directory to explain what is symlink.
    The removed part is replaced with [...]:
    # ll /boot
    [...]
    lrwxrwxrwx 1 [...] initrd -> initrd-2.6.22.12-0.1-default
    -rw-r--r-- 1 [...] initrd-2.6.22.12-0.1-default
    [...]
    lrwxrwxrwx 1 [...] vmlinuz -> vmlinuz-2.6.22.12-0.1-default
    -rw-r--r-- 1 [...] vmlinuz-2.6.22.12-0.1-default

    As you can see initrd and vmlinux are symlinks (letter L before permission
    part) to actual initrd and vmlinuz (those with version string). This makes
    possible to update kernel and symlink that points to it, while menu.lst
    file stay the same. That is by the way the reason why my system boots
    without problems, unless postinstall script forget to create new initrd ;-)

    --
    Regards, Rajko.
    See http://en.opensuse.org/Portal

  17. Re: Help 10.3 a mess After YOU Upgrade

    On Tue, 29 Jan 2008 02:08:03 UTC, "Rajko M."
    wrote:

    >
    > Here is menu.lst based on mine, modified with your partition numbers.
    > Some entries will work with any kernel (vmlinuz) and any initrd.
    >
    > ################################################## #################
    > default 0
    > timeout 10
    > gfxmenu (hd0,5)/boot/message
    >
    > title openSUSE 10.3 - MAIN
    > root (hd0,8)
    > kernel /boot/vmlinuz root=/dev/sda6 [see 1]
    > initrd /boot/initrd
    >
    > title openSUSE 10.3 PLAY
    > root (hd0,7)
    > kernel /boot/vmlinuz root=/dev/sda8 [see 1]
    > initrd /boot/initrd
    >
    > title Failsafe -- openSUSE 10.3 MAIN
    > root (hd0,2)
    > kernel /boot/vmlinuz root=/dev/sda6 [see 2]
    > initrd /boot/initrd
    >
    > title Windows
    > rootnoverify (hd0,0)
    > chainloader (hd0,0)+1
    > ################################################## #################
    >


    In your example I do not under the "root (hd,x)" numbers. You have
    gfxmenu as 5 (which is sda6), then Main as 8. Down in Failsafe you
    have a 2. Play seems to be OK
    Is this in error??

    The menu.lst of PLAY on my system (the REAL one) has "root (hd0,7)"
    for both the MAIN and PLAY installations. Also the menu.lst in MAIN
    has both listed as "root(hd0,5)" In both installations the "root
    /dev/sda6 / 8" are correct

    I did some reading in "info grub" and it seems this part of the
    menu.lst is also messed up

    > For instance one of entries in my menu.lst is:
    > title openSUSE 10.3 - (boot)
    > root (hd0,2)
    > kernel /boot/vmlinuz-2.6.22.12-0.1-default root=/dev/sda3
    > initrd /boot/initrd-2.6.22.12-0.1-default
    >
    > What is the problem?
    > Instead of pointing to symlink vmlinuz [see 3] it points to exact kernel
    > file.
    > While in this particular case it is not a problem, as my main menu.lst is on
    > partition 3, so it will be updated, it would be problem if the same way is
    > used to refer to kernel on another partition.
    >
    > After kernel update on another partition, version number in
    > vmlinuz-2.6.22.12-0.1-default will be different (say 2.6.22.13-5) and GRUB
    > will not find kernel. I don't know what will GRUB do when there is no
    > kernel, IMHO it should report missing file and stop. Though GRUB is very
    > complex boot loader and it can have fallback functionality to look for any
    > kernel it can find and attempt to boot anyway, which will lead to bunch of
    > errors, but it would be possible to get some running Linux and attempt
    > repair.
    >
    > What exactly happened may be possible to discover looking in menu.lst
    > on /dev/sda6 (that is why it would be good if you post that file). There is
    > only 2 options, either menu.lst was pointing exact kernel, or symlink was
    > not updated on /dev/sda8.
    > BTW, it would be updated with:
    > mkinitrd && SuSEconfig
    > without reinstallation.
    >

    I understand what you are saying in this part, but the "root (hd0,x)"
    numbers do not make sense to me in your example

    >
    > [1] To keep line short, I skipped:
    > vga=0x31a resume=/dev/sda5 splash=silent showopts
    >
    > [2] The same here:
    > vga=normal showopts ide=nodma apm=off acpi=off noresume edd=off 3
    >
    > [3] This is edited listing of /boot directory to explain what is symlink.
    > The removed part is replaced with [...]:
    > # ll /boot
    > [...]
    > lrwxrwxrwx 1 [...] initrd -> initrd-2.6.22.12-0.1-default
    > -rw-r--r-- 1 [...] initrd-2.6.22.12-0.1-default
    > [...]
    > lrwxrwxrwx 1 [...] vmlinuz -> vmlinuz-2.6.22.12-0.1-default
    > -rw-r--r-- 1 [...] vmlinuz-2.6.22.12-0.1-default
    >
    > As you can see initrd and vmlinux are symlinks (letter L before permission
    > part) to actual initrd and vmlinuz (those with version string). This makes
    > possible to update kernel and symlink that points to it, while menu.lst
    > file stay the same. That is by the way the reason why my system boots
    > without problems, unless postinstall script forget to create new initrd ;-)
    >



    --


  18. Re: Help 10.3 a mess After YOU Upgrade

    On Tue, 29 Jan 2008 02:08:03 UTC, "Rajko M."
    wrote:

    Here are copies of the two current "menu.lst"

    FIRST - MAIN (the one NOT used)

    # Modified by YaST2. Last modification on Mon Jan 28 20:36:49 PST 2008
    default 0
    timeout 8
    gfxmenu (hd0,5)/boot/message
    ##YaST - generic_mbr

    ###Don't change this comment - YaST2 identifier: Original name:
    linux###
    title MAIN openSUSE 10.3
    root (hd0,5)
    kernel /boot/vmlinuz-2.6.22.5-31-default
    root=/dev/disk/by-id/scsi-SATA_ST3250820A_9QE5QMY9-part6 vga=0x31a
    resume=/dev/sda5 splash=silent showopts
    initrd /boot/initrd-2.6.22.5-31-default

    ###Don't change this comment - YaST2 identifier: Original name:
    windows###
    title PC-DOS
    rootnoverify (hd0,5)
    chainloader (hd0,0)+1

    title PLAY openSUSE 10.3
    root (hd0,5)
    kernel /boot/vmlinuz-2.6.22.5-31-default root=/dev/sda8 vga=0x31a
    resume=dev/sda5 splash=silent showopts
    initrd /boot/initrd-2.6.22.5-31-default

    ###Don't change this comment - YaST2 identifier: Original name:
    floppy###
    title Floppy
    rootnoverify (hd0,5)
    chainloader (fd0)+1

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

    ----------------------------
    Now - PLAY (the one being used)
    ------------------------------

    # Modified by YaST2. Last modification on Wed Jan 23 19:32:57 UTC 2008
    default 0
    timeout 8
    gfxmenu (hd0,7)/boot/message

    title MAIN OpenSUSE 10.3
    root (hd0,7)
    kernel /boot/vmlinuz-2.6.22.5-31-default root=/dev/sda6 vga=0x31a
    resume=/dev/sda5 splash=silent showopts
    initrd /boot/initrd-2.6.22.5-31-default

    ###Don't change this comment - YaST2 identifier: Original name:
    windows###
    title PC-DOS
    rootnoverify (hd0,7)
    chainloader (hd0,0)+1

    ###Don't change this comment - YaST2 identifier: Original name:
    linux###
    title PLAY openSUSE 10.3
    root (hd0,7)
    kernel /boot/vmlinuz-2.6.22.5-31-default
    root=/dev/disk/by-id/scsi-SATA_ST3250820A_9QE5QMY9-part8 vga=0x31a
    resume=/dev/sda5 splash=silent showopts
    initrd /boot/initrd-2.6.22.5-31-default

    ###Don't change this comment - YaST2 identifier: Original name:
    floppy###
    title Floppy
    rootnoverify (hd0,7)
    chainloader (fd0)+1

    ###Don't change this comment - YaST2 identifier: Original name:
    failsafe###
    title Failsafe -- openSUSE 10.3
    root (hd0,7)
    kernel /boot/vmlinuz-2.6.22.5-31-default root=/dev/sda6 vga=normal
    showopts ide=nodma apm=off acpi=off noresume nosmp noapic maxcpus=0
    edd=off 3
    initrd /boot/initrd-2.6.22.5-31-default

    Hope this helps
    Paul

    --


  19. Re: Help 10.3 a mess After YOU Upgrade

    PaulRS wrote:

    > On Tue, 29 Jan 2008 02:08:03 UTC, "Rajko M."
    > wrote:
    >
    >>
    >> Here is menu.lst based on mine, modified with your partition numbers.
    >> Some entries will work with any kernel (vmlinuz) and any initrd.
    >>
    >> ################################################## #################
    >> default 0
    >> timeout 10
    >> gfxmenu (hd0,5)/boot/message
    >>
    >> title openSUSE 10.3 - MAIN
    >> root (hd0,8)
    >> kernel /boot/vmlinuz root=/dev/sda6 [see 1]
    >> initrd /boot/initrd
    >>
    >> title openSUSE 10.3 PLAY
    >> root (hd0,7)
    >> kernel /boot/vmlinuz root=/dev/sda8 [see 1]
    >> initrd /boot/initrd
    >>
    >> title Failsafe -- openSUSE 10.3 MAIN
    >> root (hd0,2)
    >> kernel /boot/vmlinuz root=/dev/sda6 [see 2]
    >> initrd /boot/initrd
    >>
    >> title Windows
    >> rootnoverify (hd0,0)
    >> chainloader (hd0,0)+1
    >> ################################################## #################
    >>

    >
    > In your example I do not under the "root (hd,x)" numbers. You have
    > gfxmenu as 5 (which is sda6), then Main as 8. Down in Failsafe you
    > have a 2. Play seems to be OK
    > Is this in error??


    Yes. I edited existing numbers and didn't changed all :-(
    I'll see now the other post.
    [...]
    --
    Regards, Rajko.
    See http://en.opensuse.org/Portal

  20. Re: Help 10.3 a mess After YOU Upgrade

    PaulRS wrote:

    > On Tue, 29 Jan 2008 02:08:03 UTC, "Rajko M."
    > wrote:
    >
    > Here are copies of the two current "menu.lst"
    >
    > FIRST - MAIN (the one NOT used)
    >
    > # Modified by YaST2. Last modification on Mon Jan 28 20:36:49 PST 2008
    > default 0
    > timeout 8
    > gfxmenu (hd0,5)/boot/message
    > ##YaST - generic_mbr
    >
    > ###Don't change this comment - YaST2 identifier: Original name:
    > linux###
    > title MAIN openSUSE 10.3
    > root (hd0,5)
    > kernel /boot/vmlinuz-2.6.22.5-31-default
    > root=/dev/disk/by-id/scsi-SATA_ST3250820A_9QE5QMY9-part6 vga=0x31a
    > resume=/dev/sda5 splash=silent showopts
    > initrd /boot/initrd-2.6.22.5-31-default
    >
    > ###Don't change this comment - YaST2 identifier: Original name:
    > windows###
    > title PC-DOS
    > rootnoverify (hd0,5)
    > chainloader (hd0,0)+1
    >
    > title PLAY openSUSE 10.3
    > root (hd0,5)
    > kernel /boot/vmlinuz-2.6.22.5-31-default root=/dev/sda8 vga=0x31a
    > resume=dev/sda5 splash=silent showopts
    > initrd /boot/initrd-2.6.22.5-31-default
    >
    > ###Don't change this comment - YaST2 identifier: Original name:
    > floppy###
    > title Floppy
    > rootnoverify (hd0,5)
    > chainloader (fd0)+1
    >
    > ###Don't change this comment - YaST2 identifier: Original name:
    > failsafe###
    > title Failsafe -- openSUSE 10.3
    > root (hd0,5)
    > kernel /boot/vmlinuz-2.6.22.5-31-default
    > root=/dev/disk/by-id/scsi-SATA_ST3250820A_9QE5QMY9-part6 vga=normal
    > showopts ide=nodma apm=off acpi=off noresume nosmp noapic maxcpus=0
    > edd=off 3
    > initrd /boot/initrd-2.6.22.5-31-default
    >
    > ----------------------------
    > Now - PLAY (the one being used)
    > ------------------------------
    >
    > # Modified by YaST2. Last modification on Wed Jan 23 19:32:57 UTC 2008
    > default 0
    > timeout 8
    > gfxmenu (hd0,7)/boot/message
    >
    > title MAIN OpenSUSE 10.3
    > root (hd0,7)
    > kernel /boot/vmlinuz-2.6.22.5-31-default root=/dev/sda6 vga=0x31a
    > resume=/dev/sda5 splash=silent showopts
    > initrd /boot/initrd-2.6.22.5-31-default
    >
    > ###Don't change this comment - YaST2 identifier: Original name:
    > windows###
    > title PC-DOS
    > rootnoverify (hd0,7)
    > chainloader (hd0,0)+1
    >
    > ###Don't change this comment - YaST2 identifier: Original name:
    > linux###
    > title PLAY openSUSE 10.3
    > root (hd0,7)
    > kernel /boot/vmlinuz-2.6.22.5-31-default
    > root=/dev/disk/by-id/scsi-SATA_ST3250820A_9QE5QMY9-part8 vga=0x31a
    > resume=/dev/sda5 splash=silent showopts
    > initrd /boot/initrd-2.6.22.5-31-default
    >
    > ###Don't change this comment - YaST2 identifier: Original name:
    > floppy###
    > title Floppy
    > rootnoverify (hd0,7)
    > chainloader (fd0)+1
    >
    > ###Don't change this comment - YaST2 identifier: Original name:
    > failsafe###
    > title Failsafe -- openSUSE 10.3
    > root (hd0,7)
    > kernel /boot/vmlinuz-2.6.22.5-31-default root=/dev/sda6 vga=normal
    > showopts ide=nodma apm=off acpi=off noresume nosmp noapic maxcpus=0
    > edd=off 3
    > initrd /boot/initrd-2.6.22.5-31-default
    >
    > Hope this helps
    > Paul


    Yes it does. It seems that I have to search for answers again.
    I have root(hd0,x) entries different, but it works fine.
    I have to see why and now is to late for any research and experiments.
    If I do wrong change it will prevent booting and than I have to use
    Knoppix Live CD to rever change, so I have to do that tomorrow.

    The only thing that I see right now is reference to file
    /boot/vmlinuz-2.6.22.5-31-default
    instead of
    /boot/vmlinuz
    and the same is for initrd-2.6.22.5-31-default.

    See do you have symlinks vmlinuz and initrd and where they point to,
    in MAIN instalation /boot directory.
    If you have them on MAIN than use only /boot/vmlinuz in PLAY menu.lst
    like this:

    title MAIN OpenSUSE 10.3
    root (hd0,7)
    kernel /boot/vmlinuz root=/dev/sda6 vga=0x31a resume=/dev/sda5 splash=silent showopts
    initrd /boot/initrd

    Don't change the entry for PLAY for now because if there is no symlinks
    it can make system unable to boot.
    I have to see will 'mkinitrd' recreate symlinks, but that also tomorrow.

    --
    Regards, Rajko.
    See http://en.opensuse.org/Portal

+ Reply to Thread
Page 1 of 2 1 2 LastLast