[FIXED] [EBCD-505] GRUB 2 wrongly using /boot/grub/ instead of /boot/grub2/

#1
Hi.

Having used EasyBCD 2.0.2 successfully a couple of years ago to set up my laptop to dual boot between Windows 7 and Gentoo Linux, I am now having a problem and am not sure if the cause is Gentoo, GRUB 2 or EasyBCD.

The laptop has the following partitions:

sda1 Windows factory restore partition
sda2 Windows C: drive
sda3 /boot
sda4 Extended partition containing:
sda5 swap
sda6 /
sda7 /home

Originally I was using GRUB 2 version 1.99-r2, and had GRUB 2 code installed in the boot sector of sda3 and GRUB 2 files installed in /boot/grub/ directory. Everything worked fine. The Windows 7 bootloader menu was displayed, I would select Linux from the menu, that would chainload the GRUB 2 menu, and on that I would select Gentoo Linux.

Just a few days ago I decided to upgrade GRUB 2 to version 2.00_beta6. Now, note that the Gentoo developers decided that GRUB 2 would use /boot/grub2/ rather than /boot/grub/. This is similar to the situation with Fedora and a number of other Linux distributions. Similarly, the GRUB 2 installation script is named grub2-install rather than grub-install, the GRUB 2 script that creates the file grub.cfg is called grub2-mkconfig rather than grub-mkconfig, and so on.

Anyway, I used the Gentoo package manager to install version 2.00_beta6 of GRUB 2 and it appeared to have installed OK. I then used the GRUB 2 installer script grub2-install to install GRUB 2 to the boot sector of sda3 and to /boot/grub2/, and that appeared to have worked correctly too. And then I used the GRUB 2 script grub2-mkconfig to generate the new /boot/grub2/grub.cfg file, and that looks fine too.

But in fact GRUB 2 version 1.99 is still being booted instead of 2.00_beta6. GRUB 2 is still using the files in /boot/grub/ rather than the files in /boot/grub2/. If I move /boot/grub/ then the laptop will not boot correctly. If I change the contents of /boot/grub/grub.cfg then the changed file is used. So the contents of /boot/grub/ are definitely being used instead of the contents of /boot/grub2/.

I have documented the problem in detail, including console outputs and contents of the MBR and partitions' boot sectors, in the following Gentoo Linux forums thread:

Gentoo Forums :: View topic - GRUB 2 wrongly using /boot/grub/ instead of /boot/grub2/

In that thread you will see that I have checked that the Gentoo GRUB 2 installation script grub2-install does actually write to the boot sector of the sda3 partition.

I also installed the latest version of Easy BCD (2.1.2) and used it, in case the BCD in Windows refers to the location of the GRUB 2 files directory in the Linux installation (although I doubt it*), but that made no difference.

* Am I correct in thinking that the BCD simply points to the boot sector of the boot partition, and only the GRUB 2 code in there points to the Linux directory which contains the GRUB 2 files, or does the BCD have information about the location of GRUB 2's core.img file too?

Anyway, I am at a loss to explain why this is happening. I just wanted to check here in case EasyBCD does control where the GRUB 2 code in the partition's boot sector looks for the GRUB 2 core.img file and other GRUB 2 files. If so, how can I make EasyBCD point to /boot/grub2/ instead of /boot/grub/?

Many thanks in advance for any help you can give.
 
Last edited:

mqudsi

Mostly Harmless
Staff member
#2
EasyBCD has two modes of operation, one which gets the GRUB info from the bootloader but does not work if Linux is on a different physical drive, and the other where it actually searches for and manually loads GRUB(2).

From your description, I'm assuming you select "GRUB2" from the drop-down. This mode searches for GRUB2 in a number of different directories. We currently search for /grub before /grub2 - and there has never been a distro to our knowledge (until you just posted this) that had both the /grub *and* the /grub2 directories.

I can play around with it some and see if there's a fix. I think simply reversing the search order (/grub2 before /grub) should do the trick..
 
#3
Thank you for your reply. Yes, I did select "GRUB2" from the drop-down in EasyBCD.

Gentoo does support having both GRUB 2 and GRUB Legacy packages installed. The GRUB Legacy files are placed in the /boot/grub/ directory and the GRUB 2 files are placed in the /boot/grub2/ directory. The command to install GRUB Legacy's files to /boot/grub/ and to install the GRUB Legacy code to the MBR (or to the boot sector of a partition) is grub-install. The command to install GRUB 2's files to /boot/grub2/ and to install the GRUB 2 code to the MBR (or to the boot sector of a partition) is grub2-install.

However, in my case I do not have both GRUB 2 and GRUB Legacy packages installed, but I do have two directories: /boot/grub/ and /boot/grub2/. The reason being that I previously had GRUB 2 version 1.99 installed, which was using the /boot/grub/ directory, and later installed GRUB 2 version 2.00_beta6 which uses the /boot/grub2/ directory.

At one point in my investigations over the last couple of days I did rename /boot/grub/ to /boot/grub-old/ to see if the grub2-install command would then create code in the boot sector of sda3 to point to the files in /boot/grub2/ instead (my post Gentoo Forums :: View topic - GRUB 2 wrongly using /boot/grub/ instead of /boot/grub2/ refers), but it didn't appear to. But I don't think I re-ran EasyBCD with only /boot/grub2/ present. If I understand you correctly, had I run EasyBCD with only the directory /boot/grub2/ present on the Linux boot partition, the GRUB 2 code in the sda3 boot sector would use /boot/grub2/i386-pc/core.img (the file created by the grub2-install command). Is my understanding correct?

Anyway, I look forward to trying any new version of EasyBCD you are able to create, to see if it makes a difference. Thank you again.

EDIT1: Perhaps I misunderstood your explanation, and you are saying that EasyBCD completely ignores the contents of the sda3 boot sector and instead sets up the BCD so that the Windows bootloder vectors directly to the core.img file in the grub sub-directory. Is that what you meant? If it is, presumably I could do an experiment now:

1. Rename /boot/grub/ to /boot/grub-old/
2. Boot into Windows and run EasyBCD to create a new BCD.
3. Reboot and select Linux from the Windows bootloader's menu.

That should cause core.img of GRUB 2 version 2.00_beta6 in /boot/grub2/i386-pc/ to be run, shouldn't it?


EDIT2: Just to answer my own question above, I tried those steps but it didn't work. I had to boot a LiveCD, rename /boot/grub-old/ to /boot/grub/ and simply reboot. Whatever I do, something insists that the file /boot/grub/core.img must be there.
 
Last edited:

mqudsi

Mostly Harmless
Staff member
#4
Your update/edit is correct. If Gentoo's configuration/build requires that /boot/grub be there, you obviously can't rename it. But in searching for /grub2 first over /grub, it won't matter because the directory will a) be there and b) not be loaded

I'll ping this thread when a new beta build with this change is made, but I will need you to test this as I have never came across this behavior before.
 
#5
Thanks very much.

I also have some interesting news: your first reply got me thinking about a workaround for my situation.

Your earlier reply was that:

a) If I were to select 'GRUB2' from the drop-down menu, EasyBCD would look for core.img in some sub-directories in /boot/ and set up the BCD to point to the first instance of the file core.img that it finds.

b) If I were to select 'GRUB Legacy' from the drop-down menu, and then specify the partition, EasyBCD would set up the BCD to point to the boot sector of the partition I specified. The assumption being that that boot sector contains GRUB Legacy code which then vectors to the GRUB Legacy Stage 2 file in the /boot/grub/ directory.

But this got me thinking. What if I were to select 'GRUB Legacy' in the EasyBCD menu in order to make EasyBCD create a BCD that points to the sda3 boot sector? If grub2-install (2.00_beta6) had indeed written code into the boot sector, and that code vectors to /boot/grub2/i386-pc/core.img, then it should be executed, shouldn't it?

So I booted into Windows, ran EasyBCD, deleted the Linux entry in the menu and clicked on the tab to create a new entry for Linux. But this time, rather than selecting 'GRUB2' from the drop-down menu, I selected 'GRUB Legacy' and specified sda3 as the partition on which GRUB is located. I saved this to the BCD and then rebooted.

This time, when I selected Linux from the Windows bootloader menu, up popped the GRUB 2 2.00_beta6 menu using the background image file that I had put in /boot/grub2/ and which is different to the background image file in /boot/grub/.

The fact the the GRUB 2 boot menu is labelled 2.00_beta6 and that the background is in /boot/grub2/ tells me that the newly created BCD does indeed point to the sda3 boot sector, and that the sda3 boot sector (created by the grub2-install script of GRUB 2 version 2.00_beta6) does appear to be executing /boot/grub2/i386-pc/core.img.

So, in summary:
1. GRUB2 2.00_beta6 is not the cause of what I experienced, EasyBCD is the cause and there is a workaround (at least there is if the partition is on the same drive as Windows).
2. My laptop is now using GRUB 2 2.00_beta6.

I think I could now safely delete /boot/grub/ without the risk of Linux being unbootable. GRUB 2 version 2.00_beta6 needs only /boot/grub2/.

I look forward to trying out a new version of EasyBCD with the fix you mentioned. Perhaps I ought to leave the /boot/grub/ directory in place until you have released the new version of EasyBCD, as that would enable me to test the new version of EasyBCD more easily.
 
Last edited:

mqudsi

Mostly Harmless
Staff member
#6
I'd appreciate if you could leave your machine in a "testable" state. Remember that you can have as many entries for the same OS in the BCD at once, so you don't even need to delete your working entry to test a future build.
 

mqudsi

Mostly Harmless
Staff member
#8
oh, and I'm going to guess if you renamed /grub it'll again not work (even with this configuration).
 
#9
You guessed wrong, I'm afraid!

$ su
Password:
# mount /boot
# cd /boot
# ls
boot grub2 kernel-genkernel-x86_64-3.3.5-gentoo splash.png tuxoniceui_initramfs_modify.sh
grub initramfs-genkernel-x86_64-3.3.5-gentoo lost+found System.map-genkernel-x86_64-3.3.5-gentoo
# mv /boot/grub /boot/grub-old
# ls
boot grub-old kernel-genkernel-x86_64-3.3.5-gentoo splash.png tuxoniceui_initramfs_modify.sh
grub2 initramfs-genkernel-x86_64-3.3.5-gentoo lost+found System.map-genkernel-x86_64-3.3.5-gentoo
# reboot

As you can see above, I renamed /boot/grub/ to /boot/grub-old/ and rebooted. As the BCD is now pointing to the boot sector of sda3, and as the code in that boot sector is GRUB 2 code pointing to /boot/grub2/i386-pc/core.img, the Windows boot manager launched the GRUB 2 version 2.00_beta6 menu in /boot/grub2/ correctly. So my workaround of selecting 'GRUB Legacy' in EasyBCD 2.1.2 and specifying the sda3 partition actually works, even though the code in the partition's boot sector is GRUB 2 code, not GRUB Legacy code. As I wrote previously, I think I could delete /boot/grub/ now, but I'll keep it to test your new version of EasyBCD with the 'GRUB2' option selected from the pull-down menu. I'll rename /boot/grub-old/ back to /boot/grub/ and keep it.

Actually, this makes me wonder: In the case of GRUB2, why did you make EasyBCD create a BCD entry pointing to the core.img file in a /boot/ subdirectory, rather than making EasyBCD create a BCD entry pointing to the boot sector of the partition (which contains the GRUB2 code pointing to the core.img file under /boot/)? I assume you have done this for a specific reason.
 

mqudsi

Mostly Harmless
Staff member
#10
It's the only way to support GRUB2 on a second disk.

I don't understand how deleting/renaming /grub makes chainloading core.img from /grub2 fail.

But now I see that your grub2 core.img is actually in a folder /boot/grub2/i386-pc/core.img - something that EasyBCD does not support. We support all variations of that path, but not the i386-pc part - I've never seen that before. I'll add that to the test build also.

Addendum

It's the only way to support GRUB2 on a second disk.

I don't understand how deleting/renaming /grub makes chainloading core.img from /grub2 fail.

But now I see that your grub2 core.img is actually in a folder /boot/grub2/i386-pc/core.img - something that EasyBCD does not support. We support all variations of that path, but not the i386-pc part - I've never seen that before. I'll add that to the test build also.

Addendum

Can you try the attached build? Giving priority to /boot/grub2 over /boot/grub and searching for the i386-pc subfolder too.
Just add a new entry with the GRUB2 option selected in the drop-down and give it a name you'll recognize (i.e. "Gentoo via EasyBCD Beta Build 179" or whatever) and see what happens when you select it at boot time?

Thanks!
 

Attachments

#11
That is the same directory structure as Fedora uses (at least Fedora 17 does, but maybe some other Linux distributions do too). In Gentoo, the subdirectory name is different according to the platform (see GRUB2 - Gentoo Wiki). For standard BIOS with MBR and x86/x86_64(amd64) CPU, the subdirectory is 'i386-pc'. For other platforms you could have subdirectory names such as e.g. ' x86_64-efi' instead. It's very complicated. But if EasyBCD caters only for x86/x86_64(amd64) and BIOS/MBR then I think the only directory path to core.img you would see in Gentoo and Fedora 17 (and perhaps some of the other Linux distributions) would be /boot/grub2/i386-pc/core.img. Below is the directory listing of /boot/grub2/ on my laptop:

ls -la /boot/grub2/
total 317
drwxr-xr-x 6 root root 1024 Jun 18 02:44 .
drwxr-xr-x 6 root root 1024 May 18 17:49 ..
drwxr-xr-x 2 root root 1024 Jun 17 22:25 fonts
-rw------- 1 root root 6914 Jun 18 02:44 grub.cfg
-rw-r--r-- 1 root root 1024 Jun 17 23:15 grubenv
drwxr-xr-x 2 root root 8192 Jun 18 02:43 i386-pc
drwxr-xr-x 2 root root 1024 Jun 17 22:25 locale
-rw-r--r-- 1 root root 302433 Jun 17 22:26 mybackground.png
drwxr-xr-x 3 root root 1024 Jun 17 22:25 themes
 

mqudsi

Mostly Harmless
Staff member
#12
Thanks. Yes, this change is new in Fedora 17 and broke EasyBCD for that as well. Fedora 16 did it the Ubuntu way. ArchLinux has also made this switch.

Can you try the beta build I posted in the previous reply?
 
#13
OK, I have now had a chance to download and try your EasyBCD 2.2 Build 179.

First I did not rename /boot/grub-old/ back to /boot/grub/, i.e. I had two directories /boot/grub-old/ and /boot/grub2/. I booted into Windows, ran EasyBCD 2.2 Build 179 and created a new entry by selecting 'GRUB2' from the drop-down menu. I then rebooted, selected the new entry in the Windows boot manager's menu and booted successfully to GRUB 2 version 2.00_beta6 (the version with its core.img and other files in /boot/grub2/).

Then I moved /boot/grub-old/ back to /boot/grub/, i.e. I have two directories /boot/grub/ and /boot/grub2/. I booted into Windows, ran EasyBCD 2.2 Build 179 and created yet another new entry by selecting 'GRUB2' from the drop-down menu. I then rebooted, selected the latest new entry in the Windows boot manager's menu and booted successfully to GRUB 2 version 2.00_beta6 (the version with its core.img and other files in /boot/grub2/).

So your new build looks good.

I will now delete /boot/grub/. It's given me enough grief!

A couple of questions:

1. Does EasyBCD Build 179 look for /boot/grub2/*/core.img or does it specifically look for /boot/grub2/i386-pc/core.img?

2. Does, or will a future version of, EasyBCD cater for non BIOS/MBR HDDs? I am beginning to see EFI, UEFI and GPT mentioned a lot. I have never had a machine with BIOS/GPT, EFI/GPT, UEFI/GPT or BIOS/hybrid-GPT-MBR but expect that newer machines have these. Will EasyBCD be able to cater for machines that use those rather than BIOS/MBR? I understand that GRUB 2 can handle those. One of the reasons I ask is because the sub-directory /boot/grub2/*/ will have a different name in each case (see Question 1 above).
 

mqudsi

Mostly Harmless
Staff member
#14
EasyBCD does not yet officially support EFI/UEFI boot loaders. I will be sure to keep the directory name in mind once we release an EFI-supporting version.

Thank you for your help testing and resolving this issue.