Language Selection

English French German Italian Portuguese Spanish

How-to Edit Grub

Filed under
HowTos
-s

So you've just installed your second, or third, or ninth Linux distribution and it either didn't recognize all your installs or you chose to skip that phase of the install. Of course you'd like to be able to boot all of these installs. Editing the grub.conf (or menu.lst) is an easy peasy procedure once you have an elementary understanding of the basic components.

If you are editing your Grub menu then we'll assume you already have it installed. This howto is to merely add an additional system to the existing file. This howto was inspired by this poor chap who resorted to reinstalling a whole system in order to update his Grub menu. No one should have to do that. Hopefully this will help.

Now I'm far from an expert, but having had to recently learn how to do this myself, I think I'll share what I do. The main advantage of using Grub is that editing the menu file is all that's necessary - as opposed to Lilo which requires one to rerun the Lilo program to reinstall it into the mbr.

The first thing I do is copy and paste an existing entry. No sense in retyping all of that and chances are you will probably want to use the same kernel parameters for the new install that you've used for previous. So:

  1. Copy and paste your favorite existing entry either where you think you'd like it or at the end of the list.

  2. Start the edit. The first thing one might need to consider is the title. This is easy, just change it to a meaningful name for your new install. In "Tryst's" case, he needed a new entry for PCLinuxOS 2007. So, he could have used PCLOS2007. Unlike Lilo, with Grub you can use names with spaces, so he could have used PCLOS 2007 if he chose.

  3. Now the bit more tricky part, the root. This is the component that specifies where the boot kernel is. Is it in a shared /boot partition or is it in the /boot directory of the new install?

    • First case scenario: Let's say you told the installer about your seperate /boot partition and it installed the boot kernel into it. The root component must then point to your shared /boot partition.

      The format might look scary at first, but it isn't. In the true Unix fashion, it begins its numbering with 0 (zero). The first number indicates the harddrive number. So, hda is 0, hdb is 1, hdc is 2, and so on. So, more than likely your boot partition is located on hda and in which case 0 is the number you want there. Just remember it's N - 1.

      The second number is the partition number. Again, hda1 is 0, hda2 is 1, and so on. So, say your /boot partition is located at sda5 you'd want to put a 4 there. So, your root entry might look like so:

      root (hd0,4)

    • Second scenario: You told the installer to install Grub onto the / (root) partition of the new install or you chose to skip installing Grub altogether. In this case the root component needs to point to the install partition. So, for example, say your new system is installed on hdb8, your root parameter should read:

      root (hd1,7)

  4. The next component is the kernel. This entry can contain lots of boot parameters but the most important is the correct name of the boot kernel. So, ls the /boot partition or directory to get that name.

    • If it's in a shared /boot partition you will need to just specify the name of the kernel as if in the working directory, like so:

      /vmlinuz-2.6.18.8.tex5

    • If it's on the install partition, then it will need to list the directory on that partition in which the boot kernel is found, like so:

      /boot/vmlinuz-2.6.18.8.tex5

      • Another necessary component of the kernel line is the root partition. This is in the more tradition partitioning scheme and points to the install partition. So, in our example, it should point to hdb8 like so:

        root=/dev/hdb8 (or root=/dev/sdb8)

      • Next is the resume. If you wish to use some advanced powersaving features such as suspend to disk, then you'll want a resume parameter listed. This is your swap partition where the disk image is stored. Again, the format is the more commonly used /dev/hdxX pattern. In my case, my swap is /dev/sda6, so it should look like:

        resume=/dev/sda6

      • You may also have other kernel parameters set here, such as splash=silent, vga=788, or noapic, whatever. These are system specific and usually already in place if you just copied an original working entry as in step 1.

  5. The final necessary component is the initrd. Not all boot kernels use or require an initrd, but most larger modern systems like openSUSE, Mandriva, and PCLOS do. This usually contains filesystem modules you might need to mount the system partition or the purdy boot splashes we like so much. You can tell if you need one by issuing ls -t in /boot directory of the new system or in the shared /boot partition. -t tells it to list by time, so you can see your newest files first. If one doesn't exist in the /boot directory, or you can't find one that matches the boot kernel, then you can assume you don't need one.

    If there is one listed, then you'll need to tell Grub about it. In "Tryst's" case, he does. So:

    • First case scenario: initrd /initrd-2.6.18.8.tex5.img

    • Second case: initrd /boot/initrd-2.6.18.8.tex5.img

That's it, that should get you in. If you need to, you can temporarily edit any grub entry at boot time, usually by hitting the "e" key. You will probably have to hit "e" again when the edit the entry screen appears to edit the particular component. Then you can hit "b" to boot it. You'll need to edit the grub.conf (or menu.lst) to make it permanent.

As stated this is how I do it and there is a lot more to Grub than discussed here. But hopefully this will help one edit their grub.conf or menu.lst file to boot their new Linux partitions.

PS. Windows and Unix (bsd) use entries like so:

title windows
root (hd0,0)
makeactive
chainloader +1

StumbleUpon



I use chain loader

It's good to see the subject nailed down in plain English. I found out about the chain loader method you mention from the PCLinuxOS documents for the previous version.

First, when I install a distro, I tell the installer to write the grub menu to the first sector of the root partition (i.e. the partition to which I'm installing) instead of the master boot record. The 'buntus just will not co-operate with that, so they get short shrift. I also become hypercritical of any distro which does not give me the option of using grub.

Secondly, before even beginning the installation, I add a verse like the following to menu.lst in the distro which has grub installed on the master boot record:

title KateOS_3.2
root (hd0,2)
chainloader +1

When you select that distro from the main grub menu, you then get the separate grub menu provided by the distro itself, with different options for logging in to that distro.

Advantages to using that method:
1. You can boot into the new system from the grub menu as soon as you have finished the initial installation;
2. The installer works out all the difficult technical stuff and you reduce the scope for typing errors;
3. You enable the new distro to have several options for booting, usually simple, non-fb and fail-safe.

Disadvantages:
1. There is a double choice to make and a double time lag. You can reduce the time lag on the second menu and make the distro the default choice if you wish.

This is how I eventually fixed it! (From "the poor chap")

Hey thanks for your effort, but what you wrote, for a person like me, was tooo scary. Really, I'm one of these people who find it difficult to read too much technical stuff... and so I found it difficult (and scary) to read your help. But you did inspire me to fix my GRUB immediately, and so, I did. And this is how I did it.

Firstly, taking on from your pointer, I realised that GRUB is just code. Thanks for that pointer.

Secondly, I realised that I actually needed to "cut and paste" only. Thanks for this pointer too.

However what I did, was I went to my openSUSE GRUB menu.lst and opened the file (using su) and then I copied openSUSE's boot code, which in my case was

title openSUSE 10.2
root (hd0,3)
kernel /boot/vmlinuz root=/dev/hdc4 vga=0x317 resume=/dev/hdc3 splash=silent
initrd /boot/initrd

I pasted this to the end (replacing my previous openSUSE detailed attempt). And then tested.

Viola, it worked!

Now I know that people like me are the bane of linux. Meaning, if I knew the code, I'd understand it... but instead, more and more, a generation of windows-based users are infiltrating linux and filling the space with a desire for 'easy' solutions. I try not to be one of them, but sometimes I am. However, I guess I have to go with my strengths. I don't think I will ever be friendly about understanding code (cut and paste solutions are just about all that I can do), and so I guess I want to thank you again for taking the time to address this issue... and hopefully there will be more people who will read your entry and actually UNDERSTAND what they're doing.

Cheers!

(ps. I'm going to paste this comment onto my blog along with a link to your post, because your solution actually looks and sounds really cool!)

It used to be worse

These days, BIOSes on modern motherboards work great with GRUB (and, presumably, LILO -- but, as you noted, GRUB has the advantage of not having to be reinstalled to the MBR each time its configuration file is changed). I had one computer in the mid 90s that flat would not boot using LILO, and another computer in the late 90s that would use LILO, but flat would not boot using GRUB.

There's nothing quite like a hang at boot time to induce panic, especially when you dual-boot. (Backup? What's a backup?) So afterwards, even through a succession of new computers and new motherboards, I first used loadlin, until MS-DOS went away, and then GRUB for Windows, which uses Windows' NTLDR. Finally, one day an install of openSUSE put GRUB on the MBR (even though I told it not to) and it worked just fine, so I gave in and started using "real" GRUB.

It's also really easy these days to pop in a Knoppix CD and make a backup of the MBR (with or without the partition table) and save it on a floppy.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

More in Tux Machines

Docker 1.13, Containers, and DevOps

  • Introducing Docker 1.13
    Today we’re releasing Docker 1.13 with lots of new features, improvements and fixes to help Docker users with New Year’s resolutions to build more and better container apps. Docker 1.13 builds on and improves Docker swarm mode introduced in Docker 1.12 and has lots of other fixes. Read on for Docker 1.13 highlights.
  • Docker 1.13 Officially Released, Docker for AWS and Azure Ready for Production
    Docker announced today the general availability of Docker 1.13, the third major update of the open-source application container engine for GNU/Linux, macOS, and Microsoft Windows operating systems. Docker 1.13 has been in development for the past couple of months, during which it received no less than seven RC (Release Candidate) versions that implemented numerous improvements for the new Swarm Mode introduced in Docker 1.12, a few security features, as well as a new Remote API (version 1.25) and Client.
  • Distributed Fabric: A New Architecture for Container-Based Applications
    There’s a palpable sense of excitement in the application development world around container technology. Containers bring a new level of agility and speed to app development, giving developers the ability to break large monolithic apps into small, manageable microservices that can talk to one another, be more easily tested and deployed, and operate more efficiently as a full application. However, containers also demand a new architecture for the application services managing these microservices and apps, particularly in regards to service discovery — locating and consuming the services of those microservices.
  • DevOps trends emerging for 2017 and beyond
    Finally, one of the biggest trends for 2017 will not be just a focus on engaging and implementing some of these DevOps best practices into your enterprise, but a sweeping adoption of the DevOps/agile culture. This is because one of the most important – if not the absolute most key –tenets to a successful DevOps organization is culture. The enterprises that most espouse the shared responsibility, the empowered autonomous teams, the can-do attitudes, and the continuous learning environment in which DevOps thrives will see the biggest benefits.

Kernel Space/Linux

  • Optimizing Linux for Slow Computers
    It’s interesting, to consider what constitutes a power user of an operating system. For most people in the wider world a power user is someone who knows their way around Windows and Microsoft Office a lot, and can help them get their print jobs to come out right. For those of us in our community, and in particular Linux users though it’s a more difficult thing to nail down. If you’re a LibreOffice power user like your Windows counterpart, you’ve only really scratched the surface. Even if you’ve made your Raspberry Pi do all sorts of tricks in Python from the command line, or spent a career shepherding websites onto virtual Linux machines loaded with Apache and MySQL, are you then a power user compared to the person who knows their way around the system at the lower level and has an understanding of the kernel? Probably not. It’s like climbing a mountain with false summits, there are so many layers to power usership. So while some of you readers will be au fait with your OS at its very lowest level, most of us will be somewhere intermediate. We’ll know our way around our OS in terms of the things we do with it, and while those things might be quite advanced we’ll rely on our distribution packager to take care of the vast majority of the hard work.
  • Long-Term Maintenance, or How to (Mis-)Manage Embedded Systems for 10+ Years
    In this presentation, kernel hacker Jan Lübbe will explain why apparently reasonable approaches to long-term maintenance fail and how to establish a sustainable workflow instead.
  • Linux 4.9 Is the Next Long-Term Supported Kernel Branch, Says Greg Kroah-Hartman
    Linux kernel maintainer Greg Kroah-Hartman confirmed today, January 19, 2017, in a short message, on his Google+ page, that the Linux 4.9 branch is now marked as "longterm," or as some of you know as LTS (Long-Term Support). The story behind Linux kernel 4.9 becoming the next long-term supported series dates from way before it's launch last month, on December 11, when Linus Torvalds officially announced the new branch. It all started back on August 12, 2016, when Greg Kroah-Hartman dropped a quick Google+ post to say "4.9 == next LTS kernel."
  • Maintainers Don't Scale
    First let’s look at how the kernel community works, and how a change gets merged into Linus Torvalds’ repository. Changes are submitted as patches to mailing list, then get some review and eventually get applied by a maintainer to that maintainer’s git tree. Each maintainer then sends pull request, often directly to Linus. With a few big subsystems (networking, graphics and ARM-SoC are the major ones) there’s a second or third level of sub-maintainers in. 80% of the patches get merged this way, only 20% are committed by a maintainer directly. Most maintainers are just that, a single person, and often responsible for a bunch of different areas in the kernel with corresponding different git branches and repositories. To my knowledge there are only three subsystems that have embraced group maintainership models of different kinds: TIP (x86 and core kernel), ARM-SoC and the graphics subsystem (DRM).

Graphics in Linux

  • RADV Vulkan Driver Has Geometry Shader Support For Testing
    David Airlie has published a set of 31 patches for testing that provide initial support for geometry shaders within the RADV Radeon Vulkan driver. While RadeonSI has long supported geometry shaders, it's been a bigger work item bringing it to this open-source Radeon Vulkan driver within Mesa. The patches are enough for Vulkan geometry shaders to get working on RADV, but Airlie explains that the support isn't gold: "This is a first pass at geometry shader support on radv, all the code should be here in reviewable pieces, it seems to mostly pass CTS tests but triggers some llvm 3.9 bugs around kill, and there might still be a GPU hang in here, but this should still be a good place to start reviewing."
  • libinput 1.6.0
    This release fixes the slow touchpad acceleration on touchpads with less than 1000dpi, a missing call to normalized the deltas was the source of the issue.
  • Libinput 1.6 Released With New Touchpad Acceleration
    Libinput 1.6.0 was announced a short time ago on wayland-devel.
  • Mesa 17 Gets a First Release Candidate, Final Planned for Early February 2017
    Collabora's Emil Velikov announced today, January 19, 2017, the availability of the first of many Release Candidate (RC) development versions of the upcoming and highly anticipated Mesa 17.0.0 3D Graphics Library. Mesa 17 is shaping up to be a huge milestone that should dramatically improve the performance of the bundled open-source graphics drivers for Intel, AMD Radeon, Nvidia graphics cards on a Linux-based operating system. Just the other day it enabled OpenGL 4.5 support for Intel Haswell GPUs, which is already a big achievement.

Android Leftovers

  • Donald Trump has surrendered his Android phone
    Donald Trump has given up his beloved Android phone ahead of today’s inauguration, the Associated Press reports, though it is unclear what type of device he will use in the White House. According to The New York Times, Trump is now using a more secure, encrypted handset that was approved by the Secret Service. He also has a different phone number, the Times reports, citing people close to the president-elect. Trump doesn’t use email, but he does use his Android phone to tweet. He’s also been very accessible throughout the presidential campaign and transition, taking calls from reporters, politicians, and world leaders. Malcolm Turnbull, the prime minister of Australia, called Trump to congratulate him on his electoral victory after getting his cellphone number from professional golfer Greg Norman.
  • Best affordable Android smartphones you can buy [January 2017]
    There are new smartphones hitting the market constantly, but which is the best to pick up when you’re trying to save a buck or two? We’ve seen some great launches this summer and we’re only expecting more over the coming months, but for now, let’s go over the best affordable Android smartphones you can go pick up today…
  • A list of every Samsung phone getting Android 7.0 Nougat this year
  • WatchMaker to support Gear S2 & Gear S3, 1000s of watchfaces incoming
    WatchMaker, a popular Android and Android Wear watchface platform, has some good news for our readers. They are currently in the process of expanding their supported platforms and will be targeting Tizen and its latest wearable smartwatches, the Samsung Gear S2 and Gear S3.