Announcement

Collapse
No announcement yet.

HOW TO: GRUB Methods - Toolkit

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

    #16
    Re: HOW TO: GRUB Methods - Toolkit

    Putting Linux OSes on your flash drive . . .

    If you find yourself here, looking for tips on how to put bootable Linux operating systems on your USB Flash Drive (UFD), you’ll find that in another Kubuntu How-To here, at:

    How To Make GRUB Thumb Drive
    http://kubuntuforums.net/forums/inde...opic=3081748.0

    Scroll down, and you’ll see some examples, including Puppy and how to simplify your UFD build.
    You’ll need to use some of the GRUB methods of Post #1 above, but it’s all very easy

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

    Comment


      #17
      Re: HOW TO: GRUB Methods - Toolkit

      Just made a new post to the following:

      How To: Make GRUB Thumb Drive
      http://kubuntuforums.net/forums/inde...95461#msg95461

      New this morning:
      Reply #10, 10-23-07
      Update: Building a useful flash drive (UFD) -- with tutorial improvements for new Kubuntu users
      Project: To put Super Grub Disk (SGD), GParted, and Puppy Linux on a flash drive.

      It's a re-do of previous work, combining the 3 installations, but specifically expanded for new people. I also put GParted on its own partition. And the new post demonstrates using a separate partition for GRUB. In about 3200 words, it's a fairly complete how-to on building these UFD pups, with special tutorial Notes for new users (e.g., how to check the Md5, logistics of using GParted, CLI vs GUI, sudo, accessing files on a downloaded iso, using Ark, K3b, etc.). I did this project on a 512 MB Memorex flash drive, and still have 250 MB leftover after allowing generous room for the installations. This was my first flash drive. I was laying around here with old stuff on it, and I think this is a good use for it--with room left for other rescue, utility, or just fun Linux stuff.
      An intellectual says a simple thing in a hard way. An artist says a hard thing in a simple way. Charles Bukowski

      Comment


        #18
        Re: HOW TO: GRUB Methods - Toolkit

        Use GRUB to Chainload LILO

        How-To:
        If you have GRUB set up as your bootloader, and you have an operating system on hard drive x, partition y, and suppose that operating system has the LILO bootloader installed to its root partition (where the operating system files are), then to boot the operating system using GRUB by chainloading, include the following boot stanza in your main GRUB menu.lst:

        title An Operating System with LILO installed in its root partition
        root (hdx,y)
        chainloader +1

        That’s it. Done. Done the same way we chainload anything, e.g., how Windows is chainloaded from GRUB. It is how we would use GRUB to chainload other operating systems, e.g., Slackware, that have LILO installed to them.

        To make this a bit more interesting and informative for anyone wanting to learn/play with GRUB . . .
        = = = = = = = = = =

        In an existing setup that uses GRUB as the bootloader, we’ll demonstrate the following sequence:

        -- Install Kubuntu 7.10, selecting LILO to be installed to the operating system root partition
        -- Chainload the newly installed Kubuntu 7.10 using GRUB
        -- Remove LILO (just for fun)
        -- Install GRUB from scratch and build /boot/grub and menu.lst—all in the Kubuntu 7.10 partition
        -- And how to rescue yourself while doing this (hint: direct booting using TAB completion)

        = = = = = = = = = =
        Example

        Assume we have two internal hard drives sda and sdb set up as follows.
        sda1 = (hd0,0) = Windows XP; sdb = the Linux hard drive
        sdb1 = (hd1,0) = dedicated GRUB partition; contains only the main GRUB files and the controlling menu.lst; it boots all the Linux operating systems on the second hard drive sdb, and it boot Windows on the first hard drive..
        sdb6 = (hd1,5) = the newly installed instance of Kubuntu 7.10. that has LILO installed to it—the one we are working with in this How-to. Beforehand, I used GParted live CD to make this partition and format it ext3.

        Here we go.

        ----- Install Kubuntu 7.10 to (hd1,5) and select LILO as the bootloader

        Use the Alternate installer (not the regular live Desktop CD installer). Select the Manual method of installation/partitioning, When you come to Install GRUB (toward the end), select Go Back (using the TAB key, then Enter). From the Ubuntu Installer Main Menu, select "Install the LILO boot loader on a hard disk";
        LILO installation target: /dev/sdb6, where sdb6 is the "new Ubuntu partition"; (i.e., where the newly installed Kubuntu 7.10 is). "Make that partition active?"; select No. (No need; you can always change that later using GParted Live CD). Done with the install. Eject installer CD. Re-start.
        *** Important: Note that we did *not* put LILO in any Master Boot Record! Only in the root partition sdb6.


        ----- Testing the chainloader at re-boot

        My regular GRUB boot menu came up (and yours will, too!). Press the "c" key before the timeout expires. That gives you a GRUB prompt, grub>.
        I know that sdb6 (in Linux notation) = (hd1,5) (in GRUB notation) on my 2-hard drive system; that's where I put the new Kubuntu 7.10 and the LILO bootloader. If you are not sure, at the grub>, type geometry (hd0) and <Enter>, then grub> geometry (hd1) and <Enter>, etc. until you find out where your new partition is.
        So, to test the chainloading, type these commands at the grub>, each followed by Enter:
        grub> root (hd1,5)
        grub> chainloader +1
        grub> boot
        Up comes the newly installed Kubuntu, courtesy of LILO 22.8. Log in, and continue . . .


        ----- Chainload Kubuntu using GRUB. Edit your main GRUB menu.lst.
        You need to make the chainload permanent so you can always get into Kubuntu 7.10.

        Access the mounted partition where your main GRUB menu is (sdb1, for me).
        Access there the file /boot/grub/menu.lst, as root, and add the following boot stanza for your newly installed Kubuntu 7.10:

        title Kubuntu 7.10 sdb6 LILO installed to root partition
        root (hd1,5)
        chainloader +1 # to boot LILO by chainloading from GRUB

        (No need for boot in a menu.lst, as it is implied.) File > Save, File > Quit. Re-start to test it.

        Get more LILO stuff and have some more fun: In Kubuntu, K > System > Adept Manager
        Enter lilo (search), and you can choose to install lilo-config (KDE frontend for configuring LILO) and lilo-doc (documentation for LILO).


        ----- To remove LILO:
        In the new Kubuntu 7.10, K > System > Adept Manager, Search: lilo, Request Removal, Apply.


        ----- Install GRUB from scratch and build /boot/grub and menu.lst

        --- To get GRUB, you already have it! It's there somewhere. (If not, you can use Adept Manager to search grub, Request Install, Apply.) I found mine in /usr/lib/grub/i386-pc (called the GRUB "image directory").

        --- Build your /boot/grub directory and contents, including GRUB files and the menu.lst.

        Now, if you open the file manager K > System > Dolphin, and Root > boot, you will not see the usual /grub directory. You have to create it * as root *. Then, from /usr/lib/grub/i386-pc, copy 3 files: stage1, stage2, and stage_1.5 (which for ext3 filesystem is e2fs_stage_1.5; there's a different stage_1.5 for each file system), and paste them into your newly created and empty /boot/grub.
        You also need to make a menu.lst. ***If you do not do this now, your chainload will not work to get you into the new Kubuntu! So make up a menu.lst. Do this by copy/paste some other menu.lst and modify it for your new Kubuntu, or just make a text file for now called menu.lst that looks like this:

        # My temporary menu.lst for /boot/grub/menu.lst on sdb6 = (hd1,5) = Kubuntu 7.10 partition
        # I promise to make this look better later
        default = 0
        timout = 15
        #
        title Kubuntu on sdb6
        root (hd1,5)
        kernel /boot/vmlinuz-2.6.22-14-generic root=UUID=XXXXXXX
        initrd /boot/initrd.img-2.6.22-14-generic

        (And File > Save As a text file in the /boot/grub directory.)

        Where do those details come from?
        Answers (while you are in the new Kubuntu 7.10):

        Get the kernel & initrd details by looking in /boot, and get the UUID for the Kubuntu partition from /etc/fstab or from the command blkid from Konsole.

        *** Later, by copying another good and regular menu.lst, you can fix this menu.lst so it is complete with groot=(hd1,5) and the Kubuntu boot stanza placed between the line ### BEGIN AUTOMAGIC KERNELS LIST and the line ### END AUTOMAGIC KERNELS LIST, and so on.


        --- Install GRUB in the Kubuntu root partition. Open Konsole, type sudo grub, then do the following:
        grub> root (hd1,5)
        grub> setup (hd1,5)
        grub> quit

        This makes it possible to chainload Kubuntu 7.10 on (hd1,5) using your main GRUB menu.lst (on sdb1 in our example here).

        --- Re-boot to test the chainload. The chainloader we set up in our main menu.lst to boot LILO will now work to boot GRUB installed to (hd1,5). That's it. Your done.


        ----- Loose ends.

        -- You may want to edit your kernel statement to include some kernel options. Ask other people what theirs looks like and look at your previous menu.lst's for Kubuntu on your system.
        -- Clean up the menu.lst in your new Kubuntu partition as explained above.
        -- Edit your main GRUB menu.lst (the one you see when you first boot up; in this example, it is /boot/grub/menu.lst in sdb1): Delete the reference we made (above) to LILO, and include something like:
        title Kubuntu 7.10 sdb6
        root (hd1,5)
        chainloader +1

        Options:
        Instead of the line chainloader +1, you can use
        configfile /boot/grub/menu.lst

        Or, if you wish, make the boot entry using root, the kernel statement, and the inird statement, exactly as we did above for the menu.lst on sdb6 in Kubuntu 7.10.


        ***** Problems & The Solution
        ----- How to rescue yourself while doing this


        If you leave yourself where you can not boot into your new Kubuntu (e.g., if you forgot your menu.lst in /boot/grub on your new Kubuntu 7.10 partition), then do the following::
        Re-boot.
        If you omitted a menu.lst in the new partition's /boot/grub directory, you'll drop to a GRUB prompt, grub>.
        Or, do so yourself when you get your usual, main GRUB menu, by pressing the "c" key, get a grub>.
        Then boot directly into your new Kubuntu using TAB-completion (in this example, on (hd1,5)):

        grub> root (hd1,5)
        grub> kernel /boot/vmlinuz<press the TAB key now, then select a kernel>
        grub> kernel /boot/vmlinuz-2.6.22-14-generic
        grub> kernel /boot/vmlinuz-2.6.22-14-generic root=/dev/sdb6
        grub> initrd /boot/initrd<press the TAB key now, then select an initrd>
        grub> initrd /boot/initrd.img-2.6.22-14-generic
        grub> boot

        and that will get you into Kubuntu 7.10 on (hd1,5).

        Important notes about this direct-boot rescue:

        -- You may use the TAB completion more than once on the same line until you get all the information you need.
        -- Your filesystem, root=/dev/sdb6:
        In the kernel line, TAB completion will NOT get you the root=/dev/sdb6; you must memorize that you need it (or check the GRUB manual or past printouts of your menu.lst's or a How-To cheat-sheet).
        And, since you probably do not know the UUID, you can not use the form root=UUID=SomeBigNumber. For now, you may simply use root=/dev/sdb6. *** However, note that during the boot-up, you may get complaints about the filesystem. For now, just hit Control-D (maybe Enter, then Control-D, maybe more than once!) to continue booting past that error. Later, you should edit the fstab's everywhere to include a valid entry for your new Kubuntu 7.10 on sdb6.

        = = = = = = = = = =
        References: You already know them if you’ve been following this How-To thread.

        Your own reference: It’s good practice to print out some of your system setup details, like the key parts of your key menu.lst’s, and /etc/fstab, and How-To cheat-sheets, just in case you have to manually rescue yourself as we showed here, and as I did when I forgot to put a menu.lst on sdb6 in /boot/grub
        An intellectual says a simple thing in a hard way. An artist says a hard thing in a simple way. Charles Bukowski

        Comment


          #19
          Re: HOW TO: GRUB Methods - Toolkit

          Another gui to edit grub:


          kubicle told in the
          Topic: Interesting new packades in Hardy
          http://kubuntuforums.net/forums/inde...opic=3089325.0
          qgrubeditor
          graphical editor for GRUB boot manager settings
          A tool to view and edit the menu.lst file of the GRUB boot manager. It offers
          many features and it is the perfect solution for those who want to change the
          way GRUB works, without messing with the menu.lst file.
          QGRUBEditor
          http://www.qt-apps.org/content/show....?content=60391

          There is a Ubuntu download (Debian Package (2.5.0)).

          QGRUBEditor depends on:
          gzip (gunzip)

          grub

          imagemagick

          libqt4-core (>=4.3.0)

          libqt4-gui (>=4.3.0)

          libqt4-dev (>=4.3.0)
          => working in the Kubuntu Gutsy Gibbon (7.10).


          Update
          From QGRUBEditor
          http://www.qt-apps.org/content/show....?content=60391
          QGRUBEditor's development was discontinued and a new application has been created: KGRUBEditor(http://www.kde-apps.org/content/show.php?content=75442). It contains exactly the same features and a lot more plus the fact that it is written in the KDE4 libraries. Please take a look at it.
          Attached Files
          Before you edit, BACKUP !

          Why there are dead links ?
          1. Thread: Please explain how to access old kubuntu forum posts
          2. Thread: Lost Information

          Comment


            #20
            Re: HOW TO: GRUB Methods - Toolkit

            Thanks for the info/update. Now and then, people ask about such GUI. Some of us old farts by now might have problems switching to frontend GUI, so used to scrapping around in the Edit-as-Root and CLI mazes, feeling it is more real and tangible. GRUB 2, when ready, is supposed to sport some GUI. I haven’t found much yet on GRUB 2 that the average, casual user like myself can use if he/she just wants a basic test run,; and no documentation that I have run into, just a bit of WIKI, and a lot of technical, work-in-progress stuff on the mail list.
            An intellectual says a simple thing in a hard way. An artist says a hard thing in a simple way. Charles Bukowski

            Comment


              #21
              Re: HOW TO: GRUB Methods - Toolkit

              Device.map – a misunderstood, notorious, often irrelevant critter . . .
              We are talking about the file /boot/grub/device.map.

              (See Reply #9 above for the start of this subject.) More here now . . .

              Summary For most users and most cases, the device.map is irrelevant. Avoid messing with it; avoid using the grub shell. Instead, use the command line interface of the “native” GRUB, the GRUB you see (along with its menu.lst and its grub> prompt) when you boot your PC. (Leave the grub-install commands for people who know what they are doing in the grub shell invoked from Kubuntu.)

              ***The native GRUB you see when you boot your PC does not even look at device.map -- it gets your drives correct each time!***


              -- The “native” grub gets it right every time. When you boot from a drive (any drive), if you get a GRUB prompt from the GRUB on that drive, the GRUB you see this way (and its boot menu, menu.lst) is called the native GRUB. It’s the only one you really need to worry about and the only one you need to know how to use and live with. The native GRUB always gets your drive correct at boot time. If you want to know how GRUB sees the drives, simply get a GRUB prompt from the native GRUB and use the geometry command.

              ***** When you boot your PC, GRUB does not even look at your device.map. *****

              --GRUB commands for your native GRUB command line
              On a positive note, if you wish to learn some GRUB and use it, simply focus on the commands at the GRUB command line interface and menu.lst, mainly these commands:
              root, rootnoverify, setup, quit, geometry, find, kernel, initrd, chainloader, map, boot, configfile, halt, reboot, help, cat, and (in the menu.lst) default and timeout.
              (See the first post of this thread.)

              No need to mess with the grub-install commands of the so-called grub shell, which is explained next . . .


              -- What is the grub shell?

              When you are in Kubuntu, and you open Konsole, and you type at the prompt the command “grub,” you are invoking the grub shell that runs in Linux. This is the subject of Chapter 15 of the GRUB manual.

              In particular, /boot/grub/device.map is for and used by this grub shell. Your Linux OS is not always very good at guessing the correspondence between Linux devices and BIOS drives and the BIOS drive order. Editing device.map is your way of setting it straight so you may safely use the commands while you are in this grub shell. If you have just one hard drive, there is no need at all for the device.map.

              In plain English: For most of us, don’t mess with your device.map.

              More to the point, the GRUB you see when starting your PC does * not * even consult the device.map. That GRUB always gets the BIOS drives right.

              And a corollary of that is: To do your work on GRUB when you have problems, you only need to get a GRUB prompt, grub>, at the command line interface of your native GRUB. No need to mess with the grub shell and all the grub-install commands you see people using—leave that for people who know what they are doing.


              GRUB manual (pdf): http://www.gnu.org/software/grub/manual/grub.html
              GRUB, GNU GRUB Manual 0.97 at: http://www.gnu.org/software/grub/manual/

              = = = = = = = = = =
              Technical Note:
              Experiments where we messed up device.map to prove that it has no effect on the native GRUB that boots the PC. (See link cited below.)

              In a recent set of experiments, three of us GRUB guys, each independently and intentionally messed up our device.map’s and found, as I had originally suspected and proposed, that doing so has no ill effect on your PC’s ability to boot normally and correctly, because the native GRUB that boots your PC doesn’t even look at the device.map.

              -- This command rules: device (hdx) /dev/sdy
              My comment from the thread: “If you are working in Linux at the command line, using the grub shell (as in Section 15 of the GNU GRUB manual), then device.map is used by the grub program, and device.map, therefore, becomes important. But even then, you can use the command: “device (hdx) /dev/sdy” to specify the map to use or to override device.map.”

              -- Updates and device.map:
              Comment by meierfra that gels with and nicely summarizes our experiments”
              “… update-grub uses "device,map" to determine "groot" -- But only if menu.lst does not already have a "# groot" statement.”

              ---> The implication is that, to keep life simple, if you have more than one drive, and if you make changes to your system, and if you have a lot of kernel updates, then it’s probably good practice to make sure now and then that your device map is correct, just so there’s no weird stuff at update time.

              -- /boot partitions that contain the kernel files:
              In particular, if you set up a separate /boot partition at (hdx,y), then your groot=(hdx,y). (This does NOT apply to a dedicated GRUB partition that contains only the GRUB files /grub; it applies to a true /boot partition that contains the kernel & initrd of your OS.)

              -- Summary of one set of experiments (by meierfra)—
              An excellent summary of WHEN device.map becomes relevant. Quote (meierfra):
              1) Device.map is only used when you run "grub-install", "grub --device.map=path_to_device.map" or "update-grub" (and in the latter case only if you do not have a "#groot" statement in your menu.lst")
              2) This is the situation where you need to edit the device.map and use "grub --device.map=path_to_device.map"
              When you use:
              root (hdx,y)
              setup (hdw)
              ***But only if all of the following conditions are met:***
              a) x is different from w
              b) grub is guessing the boot order of (hdx) wrongly.
              c) One does not want or is not able to change the boot order of (hdx)
              d) One is not able to get to the "grub command line" at boot-up. (At boot-up, grub always uses the correct order)
              [End quote]


              http://ubuntuforums.org/showthread.php?t=442945
              (Be patient; read beyond the OP problem into pages 2- and sort through it to get comments by MQMike, Herman, and Meierfra; the above summarizes the key counclusions we made in that thread.)


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

              Comment


                #22
                Re: HOW TO: GRUB Methods - Toolkit

                Dual-boot Windows and Kubuntu: Special Situations
                This covers two special situations:
                ----- How to avoid installing GRUB to the Master Boot Record of your Windows XP drive
                ----- Two drives, a Windows drive and a Kubuntu drive, GRUB is in the Windows MBR, but sometimes you must remove the Kubuntu drive and Windows won’t boot when you do

                Changed
                This topic has been deleted here.
                It has been re-written/improved and included under SECTION 6 Windows topics of the original post.

                For the Table of Contents of the GRUB toolkit, see the original post (above).
                An intellectual says a simple thing in a hard way. An artist says a hard thing in a simple way. Charles Bukowski

                Comment


                  #23
                  Re: HOW TO: GRUB Methods - Toolkit

                  GRUB Boot -- Rescue Methods

                  NOTE:
                  A brief, summary of these methods has been re-written and included under the Table of Contents in the original post. It appears in Reply #1SECTION 10
                  Rescuing Your System, Emergencies, Fixing Boot problems
                  SGD, Emergency boot methods, Working from a Live Kubuntu CD
                  Options, strategies for accessing menu.lst and re-installing GRUB


                  – How to Boot Into Your Operating System in an Emergency (and some tips on fixing the problem)

                  *** See also the next post, Reply #23:
                  *** GRUB Errors -- common errors and what causes them and how to fix them, Reply #23

                  For helpers on the forum:
                  This tell you how to help people. For one thing, you can refer them here as a first step.

                  If you need help:
                  This tell you how to be helped! For one thing, try to read through this. The helpers are going to ask about your disk drives and partitions, your boot menu (menu.lst), and perhaps your fstab. So you need to run the commands “sudo fdisk –lu,” “grub> geometry (hdx),” maybe use GParted, copy your /boot/grub/menu.lst and perhaps your /etc/fstab files (and, perhaps, check your UUIDs).


                  Summary: You have 5 tools

                  1 Use a Live Kubuntu/Linux CD to fix the problem, then boot into your operating system.*
                  2 Use Super Grub Disk to boot into your operating system, then fix the problem.
                  3 Manually boot into your operating system at a GRUB prompt, then fix the problem.
                  4 Use the edit function on a broken boot menu to boot into Kubuntu, then fix the problem.
                  (*5 Similar to 1, if you have two or more Linux operating systems and can boot into one of them, do so and fix the problem.)

                  >>> If you do not get a GRUB prompt or see a boot menu, you must use either the Live Kubuntu CD (to fix it) or Super Grub Disk (to boot into Kubuntu and fix it).
                  >>> If you see a GRUB prompt or the boot menu, then all 5 choices are available to you.

                  An “emergency” is when you turn on your PC, or re-boot, and BIOS doesn’t get you into your operating system. Your “boot” is broken! This usually occurs after you install a new distro, or after you change something—a drive or a partition, or after a change to the boot menu. This How-to tells you How to Boot Into Your Operating System in an Emergency. It expands on the methods described in the first post of this thread.

                  ----- How GRUB works -- Two key things in the GRUB setup:
                  -- The boot menu (or GRUB configuration file, /boot/grub/menu.lst)
                  -- The GRUB installation to a MBR (or, in advanced cases, to a partition)

                  ----- The decision tree
                  We’ll go through this from the top down, as a flowchart.
                  Of special interest are the methods for manually booting Kubuntu from a GRUB prompt (scroll to Case 2 below).

                  ----- There are two cases (after your PC comes on, and goes through the Power-On-Self-Test)

                  Case 1: You do not see a boot menu or a GRUB prompt, grub>. You may get an error message, or Loading Stage …

                  Case 2: All you see is the GRUB prompt, grub>; or you see a boot menu, but when you try to select an entry to boot, it doesn’t work and it gives you an error message.

                  = = = = = = = = = =

                  Case 1: No boot menu. No GRUB prompt.

                  If you have Super Grub Disk, use Solution 1A.
                  If not, use Solution 1B.

                  ----- Solution 1A: Use Super Grub Disk to boot into Kubuntu and then fix things from there.

                  In Kubuntu, proceed as follows:

                  Goal: To check the boot menu against the location of your operating systems on your drives.

                  --- Check your disk drives using fdisk -lu, geometry, and GParted Live CD:

                  Open K > System > Konsole. Type:
                  sudo fdisk -lu
                  Study the output. Determine what drive your operating system(s) is on.
                  In Linux, "a" is your first drive, "b" is the second, etc. Partitions are numbered 1, 2, 3, ... In GRUB, counting starts from zero, and (hdx,y) indicates hard drive x, x= 0, 1, 2, ..., and partition y, y =0, 1, 2, ... Normally, sda1 = (hd0,0), sda2 = (hd0,1), etc.; sdb1 = (hd1,0); sdb2 = (hd1,1), etc. Linux may also use hda1, hda2, hdb1, ... Example: The 3rd partition on the 2nd drive is (normally) sdb3 = (hd1,2) (or, it may be hdb3 in Linux).

                  grub> geometry
                  If you have any doubt about what operating system is on what drive, us the geometry command to explore your drives as follows. At Konsole, type
                  sudo grub
                  to get a GRUB prompt, grub>, then:
                  grub> geometry (hd0)
                  grub> geometry (hd1)
                  etc.

                  GParted
                  Another good method to explore your drives is to use GParted Live CD. Or, you can use GParted if it's installed in Kubuntu (K > System > Gnome Partition Editor).

                  *** Very important: Do your best to figure out where your operating systems are located in both Linux notation and GRUB notation.


                  --- Check your boot menu (/boot/grub/menu.lst)

                  Open menu.lst as root and save a backup copy.

                  (Here's how: Open Konqueror (file manager). In the location window at the top, type /boot, click on the grub folder to open it, right-click on menu.lst, Actions > Edit as root, and menu.lst will open in a text editor (e.g., KWrite). The file menu.lst must be edited with root privileges. Save a backup copy of menu.lst: File > Save As, select Home folder, and name it menu.lst_backup.)

                  Study menu.lst.: Check for device names, UUIDs, syntax/spelling, Windows issues,

                  Find your operating system(s) in the menu.lst (they are introduced by the word "title"), study it, noting especially two things:
                  the statements root (hdx,y);
                  and the kernel lines, where it shows root=/dev/sdax or root=UUID=a-big-Number-&Letters.

                  For example, here's a boot entry for Kubuntu:

                  title Kubuntu on sdb5--Ubuntu, kernel 2.6.20-16-generic
                  root (hd1,4)
                  kernel /boot/vmlinuz-2.6.20-16-generic root=UUID=4ead32ce-5c61-49c3-babb-f0e17831afd4 ro quiet splash
                  initrd /boot/initrd.img-2.6.20-16-generic

                  Or, it might say
                  kernel /boot/vmlinuz-2.6.20-16-generic root=/dev/sdb5 ro quiet splash

                  This boot entry says that Kubuntu is on (hd1,4) (the second hard drive hd1, the 5th partition "Partition 4"; remember, counting in GRUB starts from zero, so it is 0, 1, 2, 3, 4 = partition 5). You must make sure this is all correct and lines up with what you learned from fdisk -lu and from geometry (and perhaps from GParted).
                  The root= in the kernel line must correspond to the statement root (hd1,4). If it says, for example, root=/dev/sdb3, then something is (probably) wrong (in advanced cases where you use a separate /boot partition for the kernel, things get a bit more involved, but then you wouldn't need my help here beyond what I've already said).

                  UUIDs
                  If the kernel line uses something like, root=UUID=4ead32ce-5c61-49c3-babb-f0e17831afd, then you must make sure the UUID matches up with the partition (hd1,4). Your UUIDs are listed in your Kubuntu filesystem table, /etc/fstab. Check it.
                  You can also generate your UUIDs using one of the following commands at Konsole:
                  UUIDs, listing:
                  From Live CD or hard drive: ls /dev/disk/by-uuid/ -alh
                  From hard drive: blkid

                  (A UUID is a Unique Universal Identifier; each of your drives has associated with it a (generated) identifier that is called a UUID. Use Google, Wikipedia, etc., to learn more.)

                  Summary so far
                  You have checked your boot menu, /boot/grub/menu.lst against your list of drives and partitions and your UUIDs (as applicable).

                  Windows:
                  Do all this for Windows, too, in menu.lst:
                  title Microsoft Windows XP
                  root (hd0,0)
                  makeactive
                  chainloader +1

                  Make sure, in this example, that Windows really is on (hd0,0) (=sda1 or hda1). If Windows is not on the first drive, you must modify its boot entry as follows (see Reply #12 above), assuming it is on (hdx,0), x > 1:

                  title Microsoft Windows XP
                  root (hdx,0)
                  map (hdx) (hd0)
                  map (hd0) (hdx)
                  makeactive
                  chainloader +1

                  Vista: If it is Vista, you must use rootnoverify (hd0,0) instead of root. Also, Vista uses two partitions--one is a special recovery partition and one is for the main Vista operating system; make sure the rootnoverify statement points at the Vista operating system.

                  Syntax and spelling
                  Check menu.lst for any obvious errors in spelling or syntax. There should be a space after each of these commands: root, kernel, initrd, chainloader. No spaces in root=UUID=4ead32ce-5c61-49c3-babb-f0e17831afd. A space between generic and root. In kernel and initrd, note the leading slash in front of boot: /boot. Note the opening and closing parentheses in (hd0,0). Don't worry about title: you can say anything after the word title; it's what you see in the boot menu when you boot your PC. Note the leading slash before dev in root=/dev/sdb5.

                  Editing menu.lst
                  You have opened menu.lst with root privileges (Action > Edit as root). Make your changes to menu.lst, typing carefully!, then File > Save and File > Quit.

                  --- Re-boot to test it.

                  If it doesn't work even though menu.lst looks correct, then, try re-installing GRUB . . .

                  --- Re-install GRUB
                  Install (or re-install) GRUB from your "main" Kubuntu to the Master Boot Record of your first hard drive (the first drive to boot, as set up in BIOS).

                  Again, open Konsole, type
                  sudo grub
                  to get a GRUB prompt, grub>, and type
                  grub> find /boot/grub/stage1
                  which will tell you where GRUB files are located on your drives, in the notation (hdx,y). Again, you will use fdisk -lu and geometry to explore your drives. Select the (hdx,y) that corresponds to your "main" Kubuntu that you use all the time, and do the following:

                  grub> root (hdx,y)
                  grub > setup (hd0)
                  grub > quit
                  exit

                  and re-boot to test it.

                  The setup command
                  This assumes you are installing GRUB to the Master Boot Record of the first (in BIOS) hard drive, hd0. If you are installing GRUB to some other MBR, indicate that in the setup command. Example: You may want to re-install GRUB to the MBR of an external USB hard drive, or to a flash drive; if that device is seen as sdc = hd2, then you would use setup (hd2). (Again, note the space after root, and after setup.)

                  Then what?
                  If that works, OK. If not, then you must dig deeper, but first, re-check everything you've done here thus far.

                  Another "test" is to use Super Grub Disk to boot your operating system. If it can, then that's good news--run SGD again and see what you can learn from how it sees your drives and operating systems (e.g., use the "Advanced" option).

                  Final tip: Re-type it! If everything looks OK, and especially if you have a simple, basic system, I have seen cases fixed by simply re-typing the exact same entries in menu.lst. I have seen it happen after text is copied from OOo Writer into menu.lst. After re-typing the boot entry, everything worked fine.


                  ----- Solution 1B: (Super Grub Disk is not available) Use the Live Kubuntu CD to try to fix things in your Kubuntu on your hard drive.

                  Solution 1B is identical to Solution 1A *except* you MAY have to open /boot/grub/menu.lst using Konsole (by mounting it, then using some commands).

                  Start up the Live Kubuntu CD.
                  (Here's how: Turn on the PC, let it do something, like boot into Windows or into another operating system, or freeze up. Open the CD tray, insert the Live Kubuntu CD, then re-start your PC--if necessary, press the Re-set button on the PC case, referred to as doing a "hard re-set." Assuming your BIOS is set to boot from CD first, that's what will happen. If not, when your PC goes through the Power-On-Self-Test, enter BIOS setup and set BIOS to boot from the CD drive.)

                  Open K > System > Konsole

                  Proceed as in Solution 1A until you get to menu.lst. That is,

                  At Konsole, use sudo fdisk -lu, sudo grub, and geometry to explore your drives.
                  (If you need to use GParted, do that, too. You can use the Live GParted CD, or you can install GParted in the Live Kubuntu session using K > System > Adept Manager; then GParted is installed to your RAM only--it is not permanently installed.)

                  Then to open your menu.lst, use Konsole as in this example:

                  Example Suppose the menu.lst you need to look at is in Kubuntu on sdb3 (=(hd1,2)).
                  Open Konsole (from the Live CD), and do as follows:

                  sudo mkdir /media/sdb3 # make directory called /media/sdb3
                  sudo mount /dev/sdb3 /media/sdb3 # mount device sdb3 on directory /media/sdb3
                  cd /media/sdb3 # change to this directory
                  kdesu kate /boot/grub/menu.lst # in text editor Kate, open menu.lst, as root
                  # Then study & edit menu.lst, and when you are done, File - Save, then File - Quit
                  sudo umount /media/sdb3 # unmount the directory; note the spelling of umount
                  exit

                  Note: kdesu: if it doesn't work, try kdesudo in Kubuntu 7.10 and later).
                  Note: Backup! It's best and safe to make a backup of menu.lst before editing it as follows:

                  At Konsole, make the backup to a file called menu.lst_MyBackup:
                  cp /boot/grub/menu.lst /boot/grub/menu.lst_MyBackup
                  To restore (if you have a problem and need to!), reverse it:
                  sudo cp/boot/grub/menu.lst_MyBackup /boot/grub/menu.lst
                  (You need sudo to modify /boot/grub/menu.lst.)

                  Another way to open menu.lst:
                  If you are lucky, or know how to do it, the Live Kubuntu CD may automatically mount the partition (in “Storage”) containing your "main" menu.lst that you need to check. If so, you can open menu.lst from Konqueror as in Solution 1A.

                  Now, after checking/editing menu.lst in this way, proceed exactly as in Solution 1A. That is,

                  --- Re-boot to test it.
                  If it doesn't work even though menu.lst looks correct, then, try re-installing GRUB.
                  --- Re-install GRUB.
                  If that works, OK. If not, then you must dig deeper, but first, re-check everything you've done thus far.
                  --- Another "test" is to use Super Grub Disk to boot your operating system. If it can, then that's good news--run SGD again and see what you can learn from how it sees your drives and operating systems (e.g., use the "Advanced" option).
                  --- Final tip: If everything looks OK, and especially if you have a simple, basic system, try re-typing the exact same entries in menu.lst.


                  = = = = = = = = = =

                  Case 2:
                  All you see is the GRUB prompt, grub>; or you see a boot menu, but when you try to select an entry to boot, it doesn’t work and it gives you an error message.

                  Solution:

                  Three choices:
                  --- Use a Live CD to fix it: Same as Solution 1B.
                  --- Use SGD to boot into Kubuntu and fix it: Same as Solution 1A.
                  --- Use the grub> to manually boot into Kubuntu and fix it: Same as Solution 1A.
                  --- Use the edit function to fix the broken boot menu, boot, then fix it. Same as Solution 1A.

                  Here, we will show how to boot into Kubuntu manually from the GRUB prompt or by using the edit function on a broken boot menu.

                  ----- Manually boot into Kubuntu from the GRUB prompt, grub>.
                  Two methods discussed here: configfile and direct kernel booting.

                  --- grub> configfile (hdx,y)/boot/grub/menu.lst

                  I like this one. It's easy and (almost) always works.

                  You may see (i.e., "be dropped to") the GRUB prompt, grub>.
                  Or, if you try a boot entry in the boot menu, and it fails to work, press the ESC key to get the boot menu back, then press the "c" key to get a grub>.

                  At the grub>, type

                  grub> configfile (hdx,y)/boot/grub/menu.lst

                  where (hdx,y) is the location (hard drive and partition) of the Kubuntu operating system you are trying to boot.

                  The statement says, "Take me to (hdx,y) and show me the boot menu there."

                  You can also do this as:
                  root (hdx,y)
                  configfile /boot/grub/menu.lst

                  When you see the menu.lst come up, select the entry for your Kubuntu (usually the top, or first, entry).

                  --- Finding (hdx,y)

                  Use geometry (same as in Solution 1A). You can also look for the GRUB files as follows:
                  grub> find /boot/grub/stage1
                  or,
                  grub> find /boot/grub/menu.lst

                  --- Tab-completion in GRUB commands.

                  You can use Tab-completion on the geometry command to see a list of your drives:
                  grub> geometry (hd<Press the Tab key now>
                  (which means: type geometry, space, left parentheses ( , type hd, now press the Tab key.) You'll get a list hd0, hd1, hd2, ... of all the detected drives on your system.
                  Then, investigate a drive by typing geometry (hd0) or geometry (hd1), etc., at the grub>.

                  --- Getting help: at the grub>, type help; or simply press the Tab key; you'll get a list of GRUB commands.

                  --- Direct kernel booting at the grub>

                  (hdx,y): use geometry or find
                  First, find the partition (hdx,y) where you think your Kubuntu root files and kernel are. Use the methods discussed above to do that (geometry, or find /boot/grub/stage1, or find /boot/grub/menu.lst).

                  Example: Suppose you want to boot Kubuntu on (hd1,4). Use Tab-completion to try to get the kernel booted directly.
                  Type:
                  grub> root (hd1,4)
                  then, you need a kernel:
                  grub> kernel /<Press Tab key>
                  That gives you some choices, from which you remember that the kernel is in /boot, so choose boot (and type boot):
                  grub> kernel /boot<Press Tab key>
                  You'll get a /
                  grub> kernel /boot/<Press Tab key>
                  and you get a list of choices, from which you remember that a Kubuntu kernel is called vmlinuz, so, again, type:
                  grub> kernel /boot/vmlinuz<Press Tab key>
                  and you get more choices! Keep playing with this until you get a full kernel, such as:
                  grub> kernel /boot/vmlinuz-2.6.20-16-generic
                  but before you press Enter you must pass the root device to the kernel! (hd1,4) is the same as sdb5, and don't forget to name it as a device:
                  grub> kernel /boot/vmlinuz-2.6.20-16-generic root=/dev/sdb5
                  Do the same thing to get the initrd file:
                  grub> initrd /boot/initrd.img-2.6.20-16-generic
                  Then, finally,
                  grub> boot

                  and off you go! You'll boot into that operating system using that kernel & initrd.

                  With Tab-completion, you keep trying, little-by-little, until you get where you want to be.


                  ----- Boot into Kubuntu using the edit function on a broken boot menu

                  You see a boot menu, but it doesn't work.

                  Suppose you select "Kubuntu on sdb5" from the boot menu, and you know Kubuntu is there and sdb5 = (hd1,4). But, you get an error, perhaps Error 15 File Not Found.
                  Press ESC key to get the menu back.
                  Highlight "Kubuntu on sdb5."
                  Press "e" key to edit.
                  Ha! There you see a line
                  root (hd1,3)
                  which you know should be
                  root (hd1,4).
                  Highlight root (hd1,3), press "e" key to edit, change it using arrow keys, backspace, delete, etc., press Enter to accept the final version, then press "b" to boot, and if you are right, it'll boot into Kubuntu on sdb5.


                  Notes: Using the edit function on the boot menu.

                  --- The full instructions are listed at the bottom of the boot menu. They are easy to follow. You can't harm anything by trying. Worst case, you'll have to re-boot by pressing the Re-set button on your PC. You can also, at any time, type reboot at a grub prompt to reboot:
                  grub> reboot
                  or
                  grub> halt
                  to turn the PC off.

                  --- You may want to press the Number Lock key (Num Lock) to use the number keypad (and arrows and del key); or just use the "big" arrow keys (<-- and -->) and the backspace key for delete.

                  --- Finding (hdx,y): Again, if you don't know what root (hdx,y) should be, use the methods discussed above to look for it: geometry (hd0) (geometry (hd1), etc.), find /boot/grub/stage1, find /boot/grub/menu.lst

                  --- The edits you make are temporary! They do NOT change the boot menu /boot/grub/menu.lst permanently. To do that, you must boot into Kubuntu and do so in Konqueror (or at Konsole), as root, as we have demonstrated above.


                  References

                  See the first and second posts at the start of this thread-Topic.

                  *** See also the next post, Reply #23:
                  *** GRUB Errors -- common errors and what causes them and how to fix them, Reply #23


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

                  Comment


                    #24
                    Re: HOW TO: GRUB Methods - Toolkit

                    GRUB Errors -- common errors and what causes them and how to fix them

                    Includes:
                    --- Errors 1, 5, 11, 13, 15, 17, 18, 19, 21, 22, 25, 27
                    --- YOUR SYSTEM FREEZES AT THE KUBUNTU SCREEN showing a frozen blue progress bar (which may not show any progress!).
                    --- YOU GET A GRUB PROMPT, grub> when your PC boots--You do not get a boot menu.
                    --- Grub loading . . . or Grub Stage 1.5 . . . and the screen Freezes there.
                    --- "Kernel panic . . . Not syncing . . . VFS unable to mount root file system..."
                    --- "Starting up . . . "
                    --- Notes about your GRUB files; the /boot and the image directories: GRUB is just a bunch of files!
                    +=+ Excludes: Error 18. See Herman's bigpond (Reference at the end).

                    About the tips given here . . .
                    . . . These examples are taken from real cases I've seen on the forums, common GRUB errors that people encounter. I tested every situation here on my system. This is not meant to be a complete guide. From time to time, I may add to this post as I see other examples come up.

                    Good News -- In preparing the first draft of this guide, I intentionally inflicted all these errors on my system--more than 34 errors in 90 minutes. I recovered, my system recovered, and you and your system will also recover from GRUB-boot errors! They are fixable.

                    = = = = = = = = = =
                    As a reminder . . . Troubleshooting procedure:
                    >> Consult the first post of this thread for basic GRUB techniques.
                    >> Consult Reply #1 of this thread for editing the GRUB configuration file (/boot/grub/menu.lst).
                    >> Consult Reply #22 above ( GRUB Boot--Rescue Methods: how to boot into your Kubuntu in an emergency).
                    >> See References (at the end).
                    = = = = = = = = = =
                    These typical boot entries (in/boot/grub/menu.lst) are used in the examples to illustrate various GRUB errors:

                    title Kubuntu 7.10 sdb5 -- Boot by kernel
                    root (hd1,4)
                    kernel /boot/vmlinuz-2.6.22-14-generic root=UUID=cbd79e1b-6095-49ca-9b42-4cfca49b899c ro quiet splash
                    initrd /boot/initrd.img-2.6.22-14-generic

                    title Microsoft Windows XP Home Edition
                    root (hd0,0)
                    chainloader +1

                    title Kubuntu 7.10 sdb5 -- Boot by configfile
                    root (hd1,4)
                    configfile /boot/grub/menu.lst
                    = = = = = = = = = =

                    ----- 1: GRUB Error 1 : Filename must be either an absolute filename or blocklist
                    This error is returned if a file name is requested which doesn't fit the syntax/rules listed in the Filesystem (see the GRUB Manual 0.97).

                    -- Examples
                    Consider these two statements taken from the above examples:
                    kernel /boot/vmlinuz-2.6.22-14-generic root=UUID=cbd79e1b-6095-49ca-9b42-4cfca49b899c ro quiet splash
                    and
                    configfile /boot/grub/menu.lst

                    If you remove the leading slash before /boot in either of these two examples, you will get Error 1.
                    The leading slash is needed to make /boot/vmlinuz-2.6.22-14-generic or /boot/grub/menu.lst a valid, absolute filename.


                    ----- 5: GRUB Error 5 : Partition table invalid or corrupt
                    This error is returned if the sanity checks on the integrity of the partition table fail. This is a bad sign.

                    Solution:
                    Hopefully, the problem just occurred and it's not too late to attempt to fix the MBR partition table.
                    Do so using TestDisk (or other disk editors/rescues). (I have had success with TestDisk.)
                    See References (at the end of this post).

                    http://www.cgsecurity.org/wiki/TestDisk


                    ----- 11: GRUB Error 11: Unrecognized device string
                    This error is returned if a device string was expected, and the string encountered didn't fit the syntax/rules listed in the Filesystem.

                    Example:
                    In the statement "root (hd1,4)," suppose it appeared as
                    root (hd1,4
                    (i.e., no right parenthesis). Then you'd get GRUB error 11. The root command requires a device string telling what hard drive and partition it is referring to. But "(hd1,4" is an improper device string--it doesn't fit the syntax/rules because it is missing the ending parenthesis.


                    ----- 13: GRUB Error 13: Invalid or unsupported executable format
                    This error is returned if the kernel image being loaded is not recognized as Multiboot or one of the supported native formats (Linux zImage or bzImage, FreeBSD, or NetBSD).

                    -- Example:

                    title Microsoft Windows XP Home Edition
                    root (hd0,0)
                    chainloader +1

                    I changed (hd0,0) to (hd0,1). The partition (hd0,1) exists on my disk, and it holds GRUB files, but the GRUB on (hd0,1) is not installed to that partition or to any MBR. Thus, my "main" GRUB was not able to recognize it as a bootable (or executable) format. But the real problem is that Windows did not boot as expected! So, in this case, the solution is to change (hd0,1) to what it should be, (hd0,0).

                    -- Example:
                    Suppose you have a boot entry that looks like this:
                    title GRUB files and a menu.lst on sda2 = (hd0,1)
                    root (hd0,1)
                    chainloader +1

                    But when you select it from the boot menu, you get GRUB Error 13: Invalid or unsupported executable format. That (probably) means that GRUB (on (hd0,1)) is not installed to that partition or to any MBR. It is not in a bootable format and so cannot be chainloaded by GRUB.
                    SOLUTION:
                    If you wanted this to work (and not get this error), you would have to install/re-install GRUB to the partition (hd0,1) using the GRUB files in (hd0,1). For example, you could install the GRUB files on (hd0,1) to the boot sector of partition (hd0,1) as follows:
                    grub> root (hd0,1)
                    grub> setup (hd0,1)
                    grub> quit
                    Then, when you re-boot, and select the entry "GRUB files and a menu.lst on sda2 = (hd0,1)," GRUB would chainload to (hd0,1), and you would get the menu.lst from (hd0,1), from which you could then make a (second) choice of an operating system to boot.


                    ----- 15: GRUB Error 15: File not found
                    This error is returned if the specified file name cannot be found, but everything else (like the disk/partition info) is OK.

                    This is perhaps the most commonly encountered error. It occurs when you tell GRUB to access a file and GRUB can't find the file.
                    -- Examples. Error 15 will occur in each of the following examples:

                    >> Consider: kernel /boot/vmlinuz-2.6.22-14-generic root=UUID=cbd79e1b-6095-49ca-9b42-4cfca49b899c ro quiet splash

                    If you edited this and made a typo by typing vmlinux instead of vmlinuz, you'd get error 15.
                    If you typed 2.6.22-14 as 2.6.22.14, you'd get error 15.
                    If you typed 2.6.22-14 as 2.60.22-14, you'd get error 15 (it's supposed to be .6, not .60).
                    If you omit the space between "generic" and "root" in "vmlinuz-2.6.22-14-generic root=UUID=," you will get error 15 (i.e., "vmlinuz-2.6.22-14-genericroot=UUID=" is improper).
                    If you type "boot" as "bot," as in kernel /bot/vmlinuz-2.6.22-14-generic, you will get error 15.
                    If you somehow introduce an extra / and space at the front, like in "/ /boot/vmlinuz-2.6.22-14-generic," you will get error 15.

                    In the statement "configfile /boot/grub/menu.lst," suppose you type this as "configfile /boot/grub/menulst," (i.e., you omit the dot), then you'd get error 15.

                    >> You must have the correct root (hdx,y). Consider our example again:
                    title Boot by kernel--Kubuntu 7.10 sdb5
                    root (hd1,4)
                    kernel /boot/vmlinuz-2.6.22-14-generic root=UUID=cbd79e1b-6095-49ca-9b42-4cfca49b899c ro quiet splash
                    initrd /boot/initrd.img-2.6.22-14-generic

                    If somehow, say by making a typo, it reads
                    root (hd1,5)
                    and suppose the partition (hd1,5) exists. But suppose that (hd1,5) does not contain any such kernel & initrd files (or it contains kernel & initrd files, but not the ones referenced in this boot entry). Then you will get error 15: File Not Found (because GRUB cannot find the kernel & initrd files listed here).

                    Another case for Error 15: Broken initrd file:
                    Both files listed in the kernel and initrd statements must actually be present in the /boot directory! In the above example, those two files are vmlinuz-2.6.22-14-generic and initrd.img-2.6.22-14-generic.
                    Especially after a major kernel update, it may happen that the files are changed somehow. It usually happens with the initrd file. For example, when you look in the /boot directory, you may not find the initrd generic file but only a backup file called, for example, initrd.img-2.6.22-14-generic.bak. In this case, here's a fix that may work:
                    > Using the Live Kubuntu CD, open Konsole and Open Konqueror as root by typing kdesu konqueror, access /boot, then rename the bak file to initrd.img-2.6.22-14-generic (right-click on the bak file then Rename then remove the extension .bak). Re-boot to test it.
                    > That solution often works. In the future, when getting another major kernel & initrd update, you may again have a problem booting; e.g., either Error 15 or a kernel panic. (It may happen because by simply removing the .bak extension, things might not all quite fit together, or hook-up, the way they should.) One possible fix for that, and also a fix you might try instead of simply renaming the initrd file (above, by removing .bak), is the following:

                    Suppose, as an example, that the broken Kubuntu is in partition sda2.
                    From the Live CD, chroot into the sda2 partition (see how-to note below).
                    Issue the following command:
                    sudo update-initramfs -u -v
                    and let it run and put things together & right for your initrd.

                    Chroot -- How-to
                    To chroot into sda2 from the Live Kubuntu CD at Konsole:
                    sudo mkdir /media/fixthings
                    sudo mount /dev/sda2 /media/fixthings
                    sudo chroot /media/fixthings
                    (Now you are “in” sda2 as root and can work from there as if you were actually booted into it.)


                    ----- 17: GRUB Error 17: Cannot mount selected partition
                    This error is returned if the partition requested exists, but the filesystem type cannot be recognized by GRUB.
                    Take our example:
                    title Boot by configfile--Kubuntu 7.10 sdb5
                    root (hd1,4)
                    configfile /boot/grub/menu.lst

                    Now suppose instead of root (hd1,4) it reads root (hd0,0), and suppose Windows XP is on (hd0,0). So you are sending GRUB to (hd0,0) to use a GRUB configfile command. It won't work! You'll get error 17 every time. (Windows does not support such a command.)

                    ----- 18: GRUB Error 18: See Reply #25 by Martijn van Es for Error 18.
                    (where he also references Herman's page on it at bigpond)

                    ----- 19: GRUB Error 19: Linux kernel must be loaded before initrd
                    This error is returned if the initrd command is used before loading a Linux kernel.
                    Just what it says! Also, I got this error when I simply deleted the kernel line.


                    ----- 21: GRUB Error 21: Selected disk does not exist
                    This error is returned if the device part of a device- or full file name refers to a disk or BIOS device that is not present or not recognized by the BIOS in the system.
                    In your (hdx,y)'s, examine the hdx's to see if they are correct.
                    Consider again the example:
                    title Boot by kernel--Kubuntu 7.10 sdb5
                    root (hd1,4)

                    I changed this to root (hd3,4) and got error 21 (because drive hd3 does not exit on my system).

                    Error 21 may also be caused by other things.
                    > Check your typing—(manually) type the hard drive device reference hdx again.
                    > Check to see if BIOS is correctly setup to detect your hard drives.
                    > Hardware: Each hard drive is connected to the power supply by a power cable and to the motherboard by a data cable. Check that all cables are securely attached. SATA data cables, especially, are prone to coming loose.
                    > You might try re-installing GRUB (using root & setup commands at a GRUB prompt).

                    ----- 22: GRUB Error 22: No such partition
                    This error is returned if a partition is requested in the device part of a device- or full file name which isn't on the selected disk.
                    In your (hdx,y)'s, examine the y's to see if they are correct.
                    Again:
                    title Boot by kernel--Kubuntu 7.10 sdb5
                    root (hd1,4)

                    I changed this to root (hd1,7) and got error 22 (because partition 8 ("7") does not exist on my drive).
                    Then, I changed root (hd1,4) to root (hd3,7) and got error 22 ("No such partition"; in this case, neither disk hd3 nor partition "7" exists on my system).


                    ---- 25: GRUB Error 25 : Disk read error
                    "This error is returned if there is a disk read error when trying to probe or read data from a particular disk."

                    Hardware:
                    Make sure for each SATA drive that the data cable (the thin one) is firmly attached to the drive and to the SATA port on the motherboard. (These new SATA cables are prone to popping loose.) Make sure the power cable is attached (from the power supply to the hard drive). If the error involves an IDE drive, check the cable attachment--are they secured? --do you have master and slave set correctly on the cable? jumpered correctly?

                    BIOS:
                    Check BIOS setup to see that BIOS recognizes both drives, that LBA is enabled, that the hard drives are set to "Auto," that the Boot Order list looks right.


                    ----- You get a re-boot (your PC reboots), or you get Error 27:
                    ----- 27: GRUB Error 27: Unrecognized command
                    This error is returned if an unrecognized command is entered on the command-line or in a boot sequence section of a configuration file and that entry is selected.

                    If you make an error in typing a GRUB command, two things may happen:
                    You get error 27; or
                    Your PC re-boots when you select the boot entry containing the bad command.
                    This is usually caused by a misspelling, by wrong punctuation, or by omitting a space.

                    In versions of Kubuntu previous to 7.10 (Gutsy), I often noticed the error 27.
                    In my Gutsy experiments, my PC would simply reboot when I selected a boot entry having a bad command name in it.

                    Examples of this error are:
                    typing root as roo;
                    typing root (hd1,4) without the space after root, as: root(hdx,y);
                    typing root (hd1,4) as rootx (hd1,4);
                    typing chainloader +1 without the space after chainloader: chainloader+1;
                    typing configfile as confgfile (it's missing the first "i");
                    typing configfile as xconfigfile;


                    ----- YOUR SYSTEM FREEZES AT THE KUBUNTU SCREEN showing a frozen blue progress bar (which may not show any progress!).
                    In my experiments, this was caused by something wrong in the "root=" part of the kernel statement. Take our example:
                    kernel /boot/vmlinuz-2.6.22-14-generic root=UUID=cbd79e1b-6095-49ca-9b42-4cfca49b899c ro quiet splash

                    Examples I got this bad result when I did ANY of the following:

                    delete the "=" sign in "root=", and the system freezes;

                    use an incorrect UUID, and the system freezes;

                    in Gutsy 7.10, when I use "root=/dev/sdb5" instead of "root=UUID= cbd79e1b-6095-49ca-9b42-4cfca49b899c", the system freezes;

                    if your version allows you to use the form "root=/dev/sdb5", but you omit the leading slash (before dev as in: "root=dev/sdb5", the system will freeze (or you'll get some error);


                    ----- YOU GET A GRUB PROMPT, grub> when your PC boots--You do not get a boot menu.

                    This means that although GRUB is installed to your Master Boot Record, GRUB can't find the menu.lst. The menu.lst (/boot/grub/menu.lst) may be in the wrong location, or you misspelled menu.lst. The boot menu, menu.lst, should be located in /boot/grub of your Kubuntu.

                    Examples I got this error when I did any of the following:

                    Remove the menu.lst from the /boot/grub directory of the "main" Kubuntu partition, and you'll be dropped to the grub> (with no boot menu);

                    Or, in this boot entry:
                    title Boot by configfile--Kubuntu 7.10 sdb5
                    root (hd1,4)
                    configfile /boot/grub/menu.lst

                    Instead of /boot/grub/menu.lst, goof up the name of menu.lst, such as /boot/grub/xyzmenu.lst, and you'll be dropped to the grub> (with no boot menu);


                    ----- Grub loading . . . or Grub Stage 1.5 . . . and the screen Freezes there.
                    Chances are good that GRUB is installed to the Master Boot record of your drive, but something is wrong with Stages_1.5 and/or Stage_2 of GRUB. Check your root (hdx,y) statement--Is it correct?
                    You may have to re-install GRUB (see the Troubleshooting procedure listed at the beginning of this post) using the GRUB commands root (hdx,y), setup (hdz), quit.


                    ----- "Kernel panic . . . Not syncing . . . VFS unable to mount root file system..."
                    ----- "Starting up . . . "
                    You will get this error when something is wrong with the initrd statement or the second part of the kernel statement (starting with "root="). If you delete the initrd statement, you'll get this message.
                    This could also be caused by using the wrong root (hdx,y) statement that precedes the kernel statement.
                    These problems may also cause the message "Starting up . . ." and it freezes there.

                    SOLUTION: Basically, you must check everything! Start with the root (hdx,y) -- is it the right partition? Then examine the details of your kernel and initrd statements.

                    ----- Kernel panic . . . and especially where Init (initrd, initramfs) is mentioned:
                    Try the fix mentioned under Error 15:
                    chroot into the broken Kubuntu partition
                    sudo update-initramfs -u -v

                    = = = = = = = = = =

                    Your GRUB files: They are just a bunch of files (and they won't bite you!).

                    Note 1 /boot/grub
                    GRUB expects to find its files in the directory /boot/grub.
                    The GRUB files, including menu.lst, are, therefore in the /grub subdirectory.
                    Your kernel and initrd files are in /boot, at the top-level (not in the /grub subdirectory). Go have a look now! (Your kernel is a vmlinuz file; initrd is an initrd file; as indicated in the kernel & initrd statements of your menu.lst.)

                    Note 2 GRUB image files: /usr/lib/grub/i386-pc
                    Normally, and, for example, in Gutsy 7.10, during the installation of Kubuntu, the "original" GRUB files are placed in a special directory called the image directory, and it is called
                    /usr/lib/grub/i386-pc
                    Go have a look now!

                    GRUB image directory--Applications
                    --- Let's say that somehow all your GRUB files in /boot/grub get deleted or damaged.
                    Then you may simply access the image directory, copy all the GRUB files, and paste them into /boot/grub, and proceed to re-install grub or do whatever you need to do. If the /grub directory got deleted, too, then simply access /boot and create a new directory called grub there; then copy the image files into the newly created /boot/grub directory.
                    --- Need some GRUB files to build a bootable flash drive? Copy them either from /boot/grub or from the image directory.

                    = = = = = = = = = =
                    References

                    See the Troubleshooting procedure listed at the start of this post.

                    See the Troubleshooting Section of Herman's GRUB page at:
                    http://users.bigpond.net.au/hermanzo..._Some_Possible

                    GRUB, GNU GRUB Manual 0.97 at: http://www.gnu.org/software/grub/manual/
                    See Chapter 14: Error messages reported by GRUB

                    TestBook
                    http://www.cgsecurity.org/wiki/TestDisk
                    An intellectual says a simple thing in a hard way. An artist says a hard thing in a simple way. Charles Bukowski

                    Comment


                      #25
                      Re: HOW TO: GRUB Methods - Toolkit

                      Nice GRUB GUI for those who may opt for it (Both links are of the same tool, just different routes):

                      http://kubuntuforums.net/forums/inde...seen#msg107781


                      QGRUBEditor

                      Comment


                        #26
                        Re: HOW TO: GRUB Methods - Toolkit

                        I find this thread very usefull in my quest to set up a dual boot system. I did miss something in all the tutorial that might save a lot of time for other attempting to set up a dual boot system.
                        If your computer is a few years old (like around 2002 or earlier) and you use a big HD (>100GB) to install you will run into grub error 18.
                        This error means that your BIOS cannot find where your system is located because it the files are installed outside the readable range of the BIOS.

                        The best setup for your HD would be:
                        -sda1 500 MB ext(2/3) primary partition where you will put all boot files for all linux installs on your system
                        -sda2 XXXGB for your Windows partition (Primary)
                        -sda3 XXXGB for your Linux partition (Primary)
                        -sda4 XXXGB extended for your swap and other partitions.

                        First you use GParted or any other tool to create and format tha 500MB sda1 partition.
                        Then just install Windows and in the installer create a new partition. That will be sda2.
                        Then install your linux disto on a new partition and create the partition for the swap.

                        At this point grub will present you an error when you try to boot (probably error 17) because your /boot/grub dir is way outside the readable range on your hard drive.
                        From this point follow the excelent how to in making a boot partition that you can find on http://users.bigpond.net.au/hermanzo...boot_partition

                        Basically you will install GRUB in the first 500 MB of your HD and also move all the linux kernel files there. Then you mount the partition in the /boot/grub of your linux installation. Everything that happens with that linux installation will actually be done in the first 500 MB of your HD and therefore can be found by your BIOS.

                        And then Windows.... since windows is installed directly after your boot partition (MB 501 and forward) Windows can be found by your hardware without any aditional tricks.

                        Maybe this will help someone and maybe someone who can write proper English can rewrite this peice so it becomes more usable Goodnight!

                        Comment


                          #27
                          Re: HOW TO: GRUB Methods - Toolkit

                          Martijn van Es, Good! Excellent, just as you've written it. Very nice and helpful details.

                          I modified my post on errors (Reply #23 above) to include Error 18 and a reference to your post here. Also good that you caught Herman's page on #18 and linked to it for people. That's one of the few times that making a true, separate /boot partition (with kernels and all) is really useful. When that is done, one must also modify the groot=(hdx,y) line in menu.lst to point to the place where those kernels are (for updating).

                          Thanks again for your post
                          --Mike
                          An intellectual says a simple thing in a hard way. An artist says a hard thing in a simple way. Charles Bukowski

                          Comment


                            #28
                            Re: HOW TO: GRUB Methods - Toolkit

                            I ran into an interesting different way to add an existing OS to the menu.lst recently when a friend asked me to install Mandriva to evaluate it. Mandriva found my existing Kubuntu install and included it in the menu.lst, and I let it go ahead and install grub to MBR on hd0,0. In the past when I have done this with a new distro, it would not use chainloader, but instead, it would include the direct link to the other OS in a menu entry. The problem with this is, if you have a kernel update in the other OS, you would have to manually edit the menu.lst file to reflect the update. When I first booted up, with the Mandriva supplied version of Grub, and selected to boot the Kubuntu OS, the next thing that happend was, my Kubuntu Grub appeared. So I took a look at the Mandriva menu.lst to see how they did that, assuming they used chainloader, but such was not the case. Instead, the entry to boot Kubuntu was:

                            title Ubuntu 8.04.1
                            root (hd0,3)
                            configfile /boot/grub/menu.lst


                            Wonder why they didn't use chainloader?

                            Comment


                              #29
                              Re: HOW TO: GRUB Methods - Toolkit

                              Originally posted by Detonate
                              Wonder why they didn't use chainloader?
                              I think (yeah, that get's me into trouble at times ) that using configfile is a cleaner approach and "just works."

                              Added: Reviewing Configfile Boot. Boot Ubuntu and most Linux systems by their configuration file (Herman's Illustrated Dual Boot Site) it may be that Mandriva's installation determined that you only had Linux OS's installed, all running Grub as their bootloaders. Using Grub's chainloader wouldn't be required in this case.
                              GRUB's 'chainloader' command is special because it hands over the job of booting to another boot loader.
                              It can be another GRUB, installed in an operating system, or it can be LiLo, Syslinux, or even Windows NTLDR.
                              This method requires that your have a bootloader GRUB, LiLo, NTLDR, or Syslinux installed to the first sector of your partition. Windows calls the first sector of it's partition a 'boot sector', and it cannot be booted without it (easily).
                              Linux doesn't need to use it's first sector for booting. There's no boot loader installed there by default, but the option is open to install a Linux boot loader, GRUB or LiLo, there if you want to.
                              Windows no longer obstructs my view.
                              Using Kubuntu Linux since March 23, 2007.
                              "It is a capital mistake to theorize before one has data." - Sherlock Holmes

                              Comment


                                #30
                                Re: HOW TO: GRUB Methods - Toolkit

                                Hey Detonate, the answer to your question is ...

                                Of course, you can use chainloader from a Mandriva menu.lst to boot Kubuntu (or many Linux distros). However, you must first install GRUB to the boot sector--sector 1--of the Kubuntu root partition, and you would do that simply by

                                (from a Live CD or a Linux distro)
                                sudo grub
                                grub> root (hdx,y)
                                grub > setup (hdx,y)
                                grub> quit
                                $exit
                                re-boot to test it (of course, it will work!)

                                ... where (hdx,y) is the partition of the Kubuntu root filesystem (= (hd0,3), I believe, according to what you posted).

                                Thus, Mandriva's GRUB (installed to the MBR of the first-boot drive in BIOS) will access Mandriva menu.lst, see the chainloader command for booting Kubuntu, and pass control to the bootloader in the Kubuntu boot sector (sector 1 of (hdx,y)), which, since we just installed GRUB to it, will be GRUB. That second instance of GRUB (in (hdx,y)) will then boot Kubuntu.


                                Try it. Play with it. You won't break anything.

                                Keep the configfile boot menu entry for Kubuntu, and call it, e.g.,
                                title Kubuntu by configfile
                                root (hd0,3)
                                configfile /boot/grub/menu.lst


                                Set up GRUB (as explained above) and make a second menu.lst entry for Kubuntu, calling it, e.g.,

                                title Kubuntu by chainloading
                                root (hd0,3)
                                chainloader +1

                                It'll work.
                                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