EasyBCD loads wrong GRUB partition

sergey_o

Member
Hello,

I installed EasyBCD 2.2.0.182 on Windows 7 SP1 (fresh install of the latter, no updates yet).

I also created multiple Linux partitions.
I want Linux instances to be compartmentalized (no shared /boot), so each instance is installed in single self-contained partition hosting both ROOT and BOOT.

In addition I also created master GRUB partition.
GRUB.CFG in this partition has menu entries chainloading to target Linux instances.
Right now chainloading is performed by "configfile" statement inside each menu entry, which simply reloads "grub.cfg" file from target instance's partition within currently running GRUB (i.e. master GRUB in this case).

Later I may replace this scheme by chainloading instead to target partition's core.img file, i.e. to actual GRUB from target instance, but have not done this yet. Right now only $root and $prefix are set to target partiton and CFG file is reloaded from target partition, but in-memory GRUB executable is not replaced. All potentially needed modules are insmod'ed before the menu is displayed and thus before the transfer to new target.

I also created entry in EasyBCD pointing to master GRUB partition.

Thus it is supposed to be three-step booting process:

1) Select MASTER-GRUB entry from WINLOAD menu.
1.1) GRUB is loaded from master GRUB partition and displays menu with list of instances encoded in it's grub.cfg.

2) Make a selection of instance from displayed master grub.cfg menu.
2.1) GRUB chainloads to grub.cfg in target's instance partition (changing $root and $prefix and replacing current in-memory grub.cfg with new grub.cfg), and menu from target partition's grub.cfg is displayed.

3) Make a selection from menu of target partiton.
3.1) Linux instance boots.

This worked fine when I initally set up a system with UBUNTU32 and UBUNTU64 instances.

Then I added FEDORA64 instance and everything broke.

Instead of loading master GRUB partition, EasyBCD loads FEDORA64 partiton.

This is fairly easy to tell.

GRUB works like this:

1) WINLOAD/EasyBCD either loads (or rather is supposed to load) partition's boot block; or load "core.img" from target partition directly.

2) If partiton's boot block is used, this block has a pointer to "core.img" file in partition (core.img must reside at fixed offset within a partition, offset is encoded into boot block, stability of core.img location is achieved by chattr -i that disables file movement by OS).

3) "core.img" contains string for the prefix path, for example "(,msdos2)/boot/grub" for my master GRUB partition.
This string points the location from which GRUB reads configuration files such as grub.cfg, modules etc.
It also seeds GRUB "root" variable.

Once "core.img" is loaded one way or another, it establishes values for $prefix and $root and starts GRUB.

Again, for my master GRUB partition this string is "(,msdos2)/boot/grub" as I had verified by embedding print statements into grub-install where it invokes grub-mkimage to produce core.img.

FEDORA64 copy of GRUB uses prefix string "(,msdos8)/boot/grub2".

When EasyBCD/WINLOAD boots the entry for master partition (/dev/sda2), what actually comes is GRUB with prefix "(hd0,msdos8)/boot/grub2".

There is no way core.img booted from /dev/sda2 would have been able to figure out this path or default to it.

This clearly indicates that EasyBCD/WINLOAD boots core.img not from /dev/sda2 as it should but instead loads /dev/sda8.

Note that it is not a matter of /dev/sda2 wiped out by FEDORA64 install.
The content of /dev/sda2 is intact.
Restoring /dev/sda2 partition image from backup does not help.
Rebuilding master GRUB partition and re-creating EasyBCD entry does not help.

I feel this all strongly suggests that EasyBCD mis-selects partition for loading and loads wrong partition.

Can this be helped?

Thanks.

- Sergey

Addendum

Well, this is definitely a bug in EasyBCD, and I found a workaround.

EasyBCD has various methods for booting partition, selectable in EasyBCD UI when boot menu entry is created.

One of selections is "GRUB2" method, which causes some EasyBCD code to be executed at boot (one of "AutoNeoGrub*.mbr" files in C:\NST). This is what one is supposed to use with GRUB2 partitions, and what is apparently broken.

Another methods are "SysLinux" and "BSD" which are likely to be just aliases for the same thing -- loading boot block off the partition and transferring control to it.

Once I chose any of those two methods, master GRUB partition loads correctly and from there I am able to boot Linux instances fine too.
 
Last edited:
It's not a bug, it's completely different (and intended) behavior. You can't rely on loading the partition block when the OS you want to boot is on a different physical disk. EasyBCD will search for core.img and load the first it finds per certain coded heuristics.

I'm working on a option to override the searched drive, can't do that with stock grub2 because it relies on relative paths.
 
It's not a bug, it's completely different (and intended) behavior. You can't rely on loading the partition block when the OS you want to boot is on a different physical disk. EasyBCD will search for core.img and load the first it finds per certain coded heuristics.

I'm working on a option to override the searched drive, can't do that with stock grub2 because it relies on relative paths.

Same to me. The solution I use at moment is to copy the Grub2-Partition to SD-Card with "dd"-command, let boot the PC from SD-drive and choose there the wished Linux.

It is possible to use the UUID of grub-partition and the relative paths to (e.g.) /sde2/boot/grub/grub.cfg

Alternatively (better) if Easy-BCD list all "core.img" and user can make an entry for each Linux-OS

My grub.cfg maybe can help you to modify the app:
Code:
==============================================================================================
### Modify intentionally this file if you know what you are doing ###
### This file is created from Arny and used for Grub2-standalone ###
### BEGIN /etc/grub.d/00_header ###
set default=0
set timeout=-1
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
### GRUB_GFXMODE=800x600x24
GRUB_GFXMODE=1024x768x24
### GRUB_GFXMODE=1280x800x24
GRUB_GFXPAYLOAD_LINUX=keep
set menu_color_normal=white/black
set menu_color_highlight=black/light-gray
### END /etc/grub.d/05_debian_theme ###


### BEGIN /etc/grub.d/10_linux ###

menuentry 'Linux, Kubuntu Version 12.10 @ 64 Bit @ sde6' {
	set root=(hd4,msdos6)
	search --no-floppy --fs-uuid --set=root c5571c47-d109-4a28-913c-5231a98a5006
	linux	/vmlinuz root=UUID=c5571c47-d109-4a28-913c-5231a98a5006 ro   quiet	splash $vt_handoff
	initrd	/initrd.img
	chainloader +1
}

menuentry 'Linux, Kubuntu newer Version @ 64 Bit @ sde7' {
	set root=(hd4,msdos7)
	search --no-floppy --fs-uuid --set=root c5571c47-d109-4a28-913c-5231a98a5007
	linux	/vmlinuz root=UUID=c5571c47-d109-4a28-913c-5231a98a5007 ro   quiet	splash $vt_handoff
	initrd	/initrd.img
	chainloader +1
}

menuentry 'Linux, Mint Nadia Version 14 @ 64 Bit @ sde8' {
	set root=(hd4,msdos8)
	search --no-floppy --fs-uuid --set=root c5571c47-d109-4a28-913c-5231a98a5008
	linux	/vmlinuz root=UUID=c5571c47-d109-4a28-913c-5231a98a5008 ro   quiet	splash $vt_handoff
	initrd	/initrd.img
	chainloader +1
}

menuentry 'Linux, Mint newer Version @ 64 Bit @ sde9' {
	set root=(hd4,msdos9)
	search --no-floppy --fs-uuid --set=root c5571c47-d109-4a28-913c-5231a98a5009
	linux	/vmlinuz root=UUID=c5571c47-d109-4a28-913c-5231a98a5009 ro   quiet	splash $vt_handoff
	initrd	/initrd.img
	chainloader +1
}

menuentry 'Linux, Ultimate Edition Version 3.5 @ 64 Bit @ sde10' {
	set root=(hd4,msdos10)
	search --no-floppy --fs-uuid --set=root c5571c47-d109-4a28-913c-5231a98a500a
	linux	/vmlinuz root=UUID=c5571c47-d109-4a28-913c-5231a98a500a ro   quiet	splash $vt_handoff
	initrd	/initrd.img
	chainloader +1
}

menuentry 'System restart' {
reboot
echo 'System rebooting initiated ...'
}

menuentry 'System shutdown' {
halt
echo 'System shut down initiated ...'
}

### END /etc/grub.d/10_linux ###
 
Last edited:
Back
Top