Announcement

Collapse
No announcement yet.

Intelligent way to upgrade GRUBmenu file

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Intelligent way to upgrade GRUBmenu file

    Got the upgrade available message this morning. Did so. Created poblems because the installation s/w did the dumb thing in modifying the GRUB menu file. I have posted the problem on another thread and copy the solution here in hopes that the people responsible for the upgrade s/w may read what happened.

    I have 3 physical discs:

    sda contains the GRUB booter, Windows XP and Fedora 8. GRUB reads the Fedora 8 menu file for booting

    sdb contains Windows Vista

    sdc contains Kubuntu.

    During the upgrade, the Kubuntu upgrade s/w did NOT do as I expected. In updating the GRUB menu, it did the brain dead, simple thing and looked in /boot/grub on sdc. It's home physical disc.

    What I EXPECTED the upgrade s/w to do was to look at the GRUB boot partition, find where GRUB looked for the menu, find that menu and make the necessary changes. IT DIDN'T.

    So when the reboot went through, GRUB did it's logical thing and looked for the menu file that it was instructed to look for and then tried to boot Kubuntu 7.10.

    Of course that led to all kinds of real problems.

    Finally dawned on me that the Kubuntu upgrade s/w did the brain dead, simple installation thing. Booted Fedora 8, and loaded the GRUB menu file on sda into Kate and then loaded the menu file that Kubuntu modified on sdc. Copied the modifications into the sda menu file, commented out the 7.10 kernals. saved the new menu file on sda.

    Rebooted

    2.6.24 kernal booted into Kubuntu 8.04.

    Is there some way to send something to the Kubuntu people responsible for the upgrade s/w and ask them to please do the intelligent thing when looking for the GRUB files and look where GRUB looks and NOT expect that their hard wired view of the world to be the only one?

    People used to do that over 20 years back with PC-DOS.

    They finally learned NOT to do that.

    Seems that the Kunbutu people are repeating history all over again.

    #2
    Re: Intelligent way to upgrade GRUBmenu file

    I believe the groot= statement in the controlling menu.lst will fix that for you. One of mine looks like this (in the menu.lst):

    ## default grub root device
    ## e.g. groot=(hd0,0)
    # groot=(hd1,1)

    where, in the example given, (hd1,1) is the location of the main, controlling GRUB menu (and correspondingly, the GRUB files used to set up the controlling MBR (sda in your case). Your GRUB root looks like the Fedora 8 partition:
    # groot=(hdx,y)
    where (hdx,y) is your Fedora 8 partition.

    That, I believe, is the theory.


    Looks like you know your way around GRUB, though, which is cool and useful.
    An intellectual says a simple thing in a hard way. An artist says a hard thing in a simple way. Charles Bukowski

    Comment


      #3
      Re: Intelligent way to upgrade GRUBmenu file

      Yeah - I learned over 20 years ago kicking around PC-DOS with assembler that you NEVER assume that files are where you think they should be - it is guaranteed that they will not be. Every system is different even if you think you set it up.

      Never, never, never hard code file locations.

      Always, always, always look where the application looks.

      In this case the upgrade software people need to stop hard coding a file location and inspect the GRUB partition for where GRUB is instructed to look.

      THAT is the only sure way to find the same file that GRUB will find. Putting instructions into certain files works, SOMETIMES, but only if the user knows or remembers to do what you think the user will do. 99.99999% of the time the user doesn't.

      If I hadn't suddenly realized what had happened, I had already downloaded the 8.04 Live CD and was getting prepared to do another install and then have to refind all of the pertinent s/w and finally learn what s/w I hadn't remembered and then find that, etc., etc., etc.

      Now average user does the same thing. Has no idea what GRUB is, where it it is, what it does, etc., That user will have to re-install, then re-install Fedora 8, then re-install hundreds of mega-bytes of apps.

      Why because the upgrade s/w writers haven't learned from history and did the LAZY thing. Then Kubuntu gets a black-eye and the average user says that it is easier to just stick with M$. Now M$ hasn't learned any better, but their PR machine has.

      So. always follow the same rules the app follows not your own rules.

      Comment


        #4
        Re: Intelligent way to upgrade GRUBmenu file

        In the general case, the devs would have no clue where to tell their installer/updater to look for the controlling GRUB menu.

        In the special case of most users who have just one menu.lst and one Linux on their machine, then the groot= configuration statement is automatically setup for the user (invisibly during the installation of their Kubuntu). So, there's no problems for most people.

        In the general case, where there are many Linux instances on the machine's drives and many menu.lst files, then you can use the groot= configuration statement in the main controlling menu.lst to instruct the updaters where to look (the updaters are programmed to look there). I fit the general case, like you, and have several Linux instances and many menu.lst's all over the place, even in places I forgot about. So the groot= config statement is important to use. Ditto for folks who use a separate /boot partition(GRUB files + kernel files) or a separate partition dedicated only to GRUB files, where their main controlling GRUB files (and menu.lst) are.



        An intellectual says a simple thing in a hard way. An artist says a hard thing in a simple way. Charles Bukowski

        Comment

        Working...
        X