Language Selection

English French German Italian Portuguese Spanish

How-to Edit Grub

Filed under

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:


    • 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:


      • 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:


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

    • Second case: initrd /boot/initrd-

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)
chainloader +1


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.

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.


(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

Linux 4.8.4

I'm announcing the release of the 4.8.4 kernel. And yeah, sorry about the quicker releases, I'll be away tomorrow and as they seem to have passed all of the normal testing, I figured it would be better to get them out earlier instead of later. And I like releasing stuff on this date every year... All users of the 4.8 kernel series must upgrade. The updated 4.8.y git tree can be found at: git:// linux-4.8.y and can be browsed at the normal git web browser: Read more Also: Linux 4.7.10 Linux 4.4.27

New Releases: Budgie, Solus, SalentOS, and Slackel

  • Open-Source Budgie Desktop Sees New Release
    The pet parakeet of the Linux world, Budgie has a new release available for download. in this post we lookout what's new and tell you how you can get it.
  • Solus Linux Making Performance Gains With Its BLAS Configuration
    - Those making use of the promising Solus Linux distribution will soon find their BLAS-based workloads are faster. Solus developer Peter O'Connor tweeted this week that he's found some issues with the BLAS linking on the distribution and he's made fixes for Solus. He also mentioned that he uncovered these BLAS issues by using our Phoronix Test Suite benchmarking software.
  • SalentOS “Luppìu” 1.0 released!
    With great pleasure the team announces the release of SalentOS “Luppìu” 1.0.
  • Slackel "Live kde" 4.14.21
    This release is available in both 32-bit and 64-bit architectures, while the 64-bit iso supports booting on UEFI systems. The 64-bit iso images support booting on UEFI systems. The 32-bit iso images support both i686 PAE SMP and i486, non-PAE capable systems. Iso images are isohybrid.

Security News

  • Free tool protects PCs from master boot record attacks [Ed: UEFI has repeatedly been found to be both a detriment to security and enabler of Microsoft lock-in]
    Cisco's Talos team has developed an open-source tool that can protect the master boot record of Windows computers from modification by ransomware and other malicious attacks. The tool, called MBRFilter, functions as a signed system driver and puts the disk's sector 0 into a read-only state. It is available for both 32-bit and 64-bit Windows versions and its source code has been published on GitHub. The master boot record (MBR) consists of executable code that's stored in the first sector (sector 0) of a hard disk drive and launches the operating system's boot loader. The MBR also contains information about the disk's partitions and their file systems. Since the MBR code is executed before the OS itself, it can be abused by malware programs to increase their persistence and gain a head start before antivirus programs. Malware programs that infect the MBR to hide from antivirus programs have historically been known as bootkits -- boot-level rootkits. Microsoft attempted to solve the bootkit problem by implementing cryptographic verification of the bootloader in Windows 8 and later. This feature is known as Secure Boot and is based on the Unified Extensible Firmware Interface (UEFI) -- the modern BIOS.
  • DDOS Attack On Internet Infrastructure
    I hope somebody's paying attention. There's been another big DDOS attack, this time against the infrastructure of the Internet. It began at 7:10 a.m. EDT today against Dyn, a major DNS host, and was brought under control at 9:36 a.m. According to Gizmodo, which was the first to report the story, at least 40 sites were made unreachable to users on the US East Coast. Many of the sites affected are among the most trafficed on the web, and included CNN, Twitter, PayPal, Pinterest and Reddit to name a few. The developer community was also touched, as GitHub was also made unreachable. This event comes on the heels of a record breaking 620 Gbps DDOS attack about a month ago that brought down security expert Brian Krebs' website, KrebsonSecurity. In that attack, Krebs determined the attack had been launched by botnets that primarily utilized compromised IoT devices, and was seen by some as ushering in a new era of Internet security woes.
  • This Is Why Half the Internet Shut Down Today [Update: It’s Getting Worse]
    Twitter, Spotify and Reddit, and a huge swath of other websites were down or screwed up this morning. This was happening as hackers unleashed a large distributed denial of service (DDoS) attack on the servers of Dyn, a major DNS host. It’s probably safe to assume that the two situations are related.
  • Major DNS provider Dyn hit with DDoS attack
    Attacks against DNS provider Dyn continued into Friday afternoon. Shortly before noon, the company said it began "monitoring and mitigating a DDoS attack" against its Dyn Managed DNS infrastructure. The attack may also have impacted Managed DNS advanced service "with possible delays in monitoring."
  • What We Know About Friday’s Massive East Coast Internet Outage
    Friday morning is prime time for some casual news reading, tweeting, and general Internet browsing, but you may have had some trouble accessing your usual sites and services this morning and throughout the day, from Spotify and Reddit to the New York Times and even good ol’ For that, you can thank a distributed denial of service attack (DDoS) that took down a big chunk of the Internet for most of the Eastern seaboard. This morning’s attack started around 7 am ET and was aimed at Dyn, an Internet infrastructure company headquartered in New Hampshire. That first bout was resolved after about two hours; a second attack began just before noon. Dyn reported a third wave of attacks a little after 4 pm ET. In all cases, traffic to Dyn’s Internet directory servers throughout the US—primarily on the East Coast but later on the opposite end of the country as well—was stopped by a flood of malicious requests from tens of millions of IP addresses disrupting the system. Late in the day, Dyn described the events as a “very sophisticated and complex attack.” Still ongoing, the situation is a definite reminder of the fragility of the web, and the power of the forces that aim to disrupt it.
  • Either IoT will be secure or the internet will be crippled forever
    First things first a disclaimer. I neither like nor trust the National Security Agency (NSA). I believe them to be mainly engaged in economic spying for the corporate American empire. Glenn Greenwald has clearly proven that in his book No Place to Hide. At the NSA, profit and power come first and I have no fucking clue as to how high they prioritize national security. Having said that, the NSA should hack the Internet of (insecure) Things (IoT) to death. I know Homeland Security and the FBI are investigating where the DDoS of doomsday proportions is coming from and the commentariat is already screaming RUSSIA! But it is really no secret what is enabling this clusterfuck. It’s the Mirai botnet. If you buy a “smart camera” from the Chinese company Hangzhou XiongMai Technologies and do not change the default password, it will be part of a botnet five minutes after you connect it to the internet. We were promised a future where we would have flying cars but we’re living in a future where camera’s, light-bulbs, doorbells and fridges can get you in serious trouble because your home appliances are breaking the law.
  • IoT at the Network Edge
    Fog computing, also known as fog networking, is a decentralized computing infrastructure. Computing resources and application services are distributed in logical, efficient places at any points along the connection from the data source (endpoint) to the cloud. The concept is to process data locally and then use the network for communicating with other resources for further processing and analysis. Data could be sent to a data center or a cloud service. A worthwhile reference published by Cisco is the white paper, "Fog Computing and the Internet of Things: Extend the Cloud to Where the Things Are."
  • Canonical now offers live kernel patching for Ubuntu 16.04 LTS users
    Canonical has announced its ‘Livepatch Service’ which any user can enable on their current installations to eliminate the need for rebooting their machine after installing an update for the Linux kernel. With the release of Linux 4.0, users have been able to update their kernel packages without rebooting, however, Ubuntu will be the first distribution to offer this feature for free.
  • ​The Dirty Cow Linux bug: A silly name for a serious problem
    Dirty Cow is a silly name, but it's a serious Linux kernel problem. According to the Red Hat bug report, "a race condition was found in the way the Linux kernel's memory subsystem handled the copy-on-write (COW) breakage of private read-only memory mappings. An unprivileged local user could use this flaw to gain write access to otherwise read-only memory mappings and thus increase their privileges on the system."
  • Ancient Privilege Escalation Bug Haunts Linux
  • October 21, 2016 Is Dirty COW a serious concern for Linux?
  • There is a Dirty Cow in Linux
  • Red Hat Discovers Dirty COW Archaic Linux Kernel Flaw Exploited In The Wild
  • Linux kernel bug being exploited in the wild
  • Update Linux now: Critical privilege escalation security flaw gives hackers full root access
  • Linux kernel bug: DirtyCOW “easyroot” hole and what you need to know
  • 'Most serious' Linux privilege-escalation bug ever discovered
  • New 'Dirty Cow' vulnerability threatens Linux systems
  • Serious Dirty Cow Linux Vulnerability Under Attack
  • Easy-to-exploit rooting flaw puts Linux PCs at risk
  • Linux just patched a vulnerability it's had for 9 years
  • Dirty COW Linux vulnerability has existed for nine years
  • 'Dirty Cow' Linux Vulnerability Found
  • 'Dirty Cow' Linux Vulnerability Found After Nine Years
  • FakeFile Trojan Opens Backdoors on Linux Computers, Except openSUSE
    Malware authors are taking aim at Linux computers, more precisely desktops and not servers, with a new trojan named FakeFile, currently distributed in live attacks. Russian antivirus vendor Dr.Web discovered this new trojan in October. The company's malware analysts say the trojan is spread in the form of an archived PDF, Microsoft Office, or OpenOffice file.

today's howtos