0

I just finished changing the boot order for GRUB2. I have three operating systems installed on the computer. I have Windows 8.1, Ubuntu Linux 15.04 and Mint Linux 17.2. I followed Marve's answer here: How do I change the GRUB boot order?

The thing is, it failed at first! I was booted into Ubuntu at the time I made the changes. I used the name reference like GRUB_DEFAULT='Windows 8' instead of index number, and I only worked with /etc/default/grub file. I then issued updated-grub and rebooted. I had Windows somewhere in the middle of the boot menu, Ubuntu at bottom, and Mint at the top. When the delay time ran out at the boot menu screen, Mint booted up, and not Windows.

Then I rebooted and booted back into Ubuntu to ensure my changes were still there in /etc/default/grub and they sure were. I also noticed I had a third grub~ file, along with my grub.bak backup file.

I then booted into Mint and made the same changes there, and rebooted. Sure enough, it worked! So I now have Windows selected by default at the boot menu screen and it boots up when time runs out. This is what I wanted.

But what bothers me is why I had to do this in Mint? Why did it not work in Ubuntu? Is this because I installed Mint after I installed Ubuntu? That's the only explanation I can think of. Is GRUB2 installed to more than one location? I remember that I had chosen to install the bootloader to the MBR during both system installations. Maybe it has something to do with the configuration files alone, and not the actual bootloader program? What if I had mounted the /etc to a dedicated partition? Would that make them share the configuration files? How about the /boot then?

There is another thing that bothers me with this setup, and it's the constant changing of the boot order and background colors and layout of the boot menu options for GRUB2. This seems to happen when either one of the operating systems gets an upgrade, or some major update that somehow requires updating the boot menu options. How can I avoid this? If I set the boot menu screen background to be blue, how can I prevent it from changing to purple the next morning when Ubuntu gets a new major update or upgrade?

In the linked answer above, have a look at the "troubleshooting" section. Here's an excerpt.

The Grub Customizer settings may work only from within the latest Linux/Ubuntu installation, the one that installed the Grub.

It looks like I may be onto something here. This might have to do with what I mentioned above. Is it not so? It sounds really silly that you would have to make changes only in the last installed Linux system. Be it that you use a GUI tool like GRUB Customizer or the command line tools and manual editing. Can someone more knowledgeable please shed some light on this issue?

Community
  • 1
Samir
  • 489
  • 3
  • 10
  • 22

2 Answers2

2

If you have multiple installs using grub2, only one of them can be in MBR and controls booting. That usually is the last install. And you may have issues if you installed both originally to MBR of same drive. Grub remembers where it installed and a major update of grub will reinstall it. Or either or both installs may be updating grub. I like to document how system is booting with Summary report:

https://help.ubuntu.com/community/Boot-Info

On one install you use least you can unselect all install choices. But make sure other is in MBR as default boot first.

How do I prevent one of my partitions messing with Lubuntu Grub entries?

Community
  • 1
oldfred
  • 12,100
  • I agree, but with the modification that the description of the system as running Windows 8.1 suggests that it may be an EFI-based computer, which would make the MBR irrelevant; it's the GRUB files on the ESP that are important for an EFI-based installation. – Rod Smith Aug 31 '15 at 13:41
  • With UEFI I have yet to find way. dpkg-reconfigure grub-efi-amd64 offers no choices on where to install, even if I have two drives with two efi partitions. And if I change GRUB_DISTRIBUTOR to "trusty" for example, it does create a new UEFI entry for trusty but uses the ubuntu folders grub.cfg. Or only the one grub.cfg in the /efi/ubuntu is ever used. So only solution I have is good backups of efi partition. – oldfred Aug 31 '15 at 14:37
2

GRUB is designed to take over control of the initial stages of the boot process. This works fine on a single-boot system (Ubuntu only, say) or when dual-booting one GRUB-based OS (like Ubuntu) with Windows; but when you install two GRUB-based OSes (like Ubuntu and Mint), the two GRUBs will fight for control of the boot process.

Experienced multi-booters often take one of three approaches to manage this process:

  • Give control to one distribution -- You can omit GRUB from one installation in order to give control to another. One way to do this is to tell the installer for the secondary distribution to not install GRUB. In the case of both Ubuntu and Mint, you can do this by booting the installer in its "try before installing" mode, launch a Terminal, and typing sudo ubiquity -b. The -b option tells the installer to omit GRUB. Once installed, this gets trickier. Personally, I've got a dummy grub-pc-3 package that contains nothing but a couple of empty directories. Its version number guarantees that it's "more recent" than any GRUB 2 pacakge, and so installing it causes GRUB to be removed and the system won't attempt to re-install GRUB (which may otherwise happen). This dummy-package approach is inelegant; I'm sure there's a better way to achieve the same effect, but I've never bothered researching it to figure out what it might be.
  • Give control to a custom GRUB 2 -- You can remove GRUB 2 from both your installations and then set up a GRUB 2 that's independent of either one. This can make the system as a whole more robust against problems caused by deleting the distribution associated with GRUB 2 in the future, so this method is favored by people who multi-boot many distributions and who make frequent changes to those distributions. It requires a lot of GRUB 2 expertise to set it up, though.
  • Abandon GRUB 2 in favor of something else -- This approach is like the preceding one, but instead of setting up a distribution-independent GRUB 2, you set up a distribution-independent non-GRUB boot loader. Under BIOS, possibilities include LILO, SYSLINUX, and GRUB Legacy. Under EFI, options include ELILO, SYSLINUX, rEFInd, and gummiboot/systemd-boot. All of these tools are easier to manually configure than GRUB 2, but most are harder than automatic GRUB 2 configuration (assuming automatic configuration works correctly -- as you've discovered, sometimes it doesn't!).

As with anything computer-related, understanding the tools and processes will help you control them. To that end, you should first figure out whether you're booting in BIOS/CSM/legacy mode or in EFI/UEFI mode. In Linux, this is easily done: Look for a directory called /sys/firmware/efi. If it's present, you've booted in EFI mode; if it's absent, you've probably booted in BIOS mode. If your Windows 8.1 was pre-installed, it almost certainly boots in EFI mode. BIOS-mode and EFI-mode booting are very different, so you should be sure to read up on the appropriate boot mode. (BIOS-mode booting is older, so a lot of older documentation doesn't even mention BIOS-vs.-EFI issues and just assumes BIOS-mode booting. EFI-mode documentation is usually quite explicit that it's about booting in EFI mode.)

For EFI-mode booting, I recommend you read the following references:

I don't happen to have specific recommendations for further reading on BIOS-mode booting handy.

Rod Smith
  • 44,284
  • 7
  • 63
  • 105