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