EasyBCD 2.0.0.99 NeoGrub: Cannot fint GRLDR

I'm having a similar problem with EasyBCD 2.0 build 100 and build 103. I see the following error:
Code:
Try (hd0,0): non-MS: skip
Try (hd0,1): non-MS: skip
Try (hd0,2): non-MS: skip
Try (hd0,3): NTFS5: No neogrub
Try (fd0): invalid or null
Error: Cannot find GRLDR in all devices. Press Ctrl+Alt+Del to restart.

I have the correct files on (hd0,3):
Code:
/Boot/
/BOOTMGR
/NeoGrub
/NST/NeoGrub.mbr

BOOTMGR works and I can select the NeoGrub entry. NeoGrub works if I rename it to BOOTMGR and it can list all the files on (hd0,3) fine.

The problem must be with NeoGrub.mbr. It loads and sees all the partitions but it can't find the file on (hd0,3). The AutoNeoGrub#.mbr's cannot find their ANG# files either.

Is there a debug version of NeoGrub.mbr that can show what files it thinks are on the partition? I'm thinking it must have it's own NTFS scanning code which differs from NeoGrub and may have a bug. A program that scans the NTFS partition in the same way as NeoGrub.mbr would be a good test too.
I'm pretty sure NeoGrub was working before. Something must have changed on my partition for this problem to appear.

I'm using Parallels virtualization to debug this because it's faster between boots (I can make changes to the partition without booting another OS), it can take screenshots, isolates partitions from each other, and has a virtual serial port for capturing output from Grub. I wish it could capture text instead of graphics from the screen buffer though...
 
It does have its own NTFS code. NeoGrub.mbr must not exceed a super-small file size limit in order to be loaded from real mode.


You need to cram the code that finds and loads NeoGrub into those mere bytes. We're looking into this issue.
 
Another question occurred to me. The output starts with:
Code:
Try (hd0,0): non-MS: skip
Does that mean it's not first searching the partition that the mbr was on (hd0,3)? If not, then shouldn't it?

i.e. If the mbr is for booting an iso using ANG0, it is possible that it may find an ANG0 on a different partition that boots something else.

If the mbr cannot be made to first search the partition that the mbr is on, then the file names it searches for need to be unique across all partitions and not just the partition they are on. This will be difficult if the partitions are hidden or use a different file system.

If the mbr can be made to first search the partition that the mbr is on (or already does so), then is there a reason for it to have code that searches other partitions since EasyBCD seems to always put the file on the same partition as the mbr?
 
Was this fixed in EasyBCD 2.0.1? I installed it, erased all my BCD entries then redid them and now I can successfully boot into NeoGrub.

The other reason it might be successful now is because I did some messing around with the root directory (on my Windows XP partition): I moved everything out of the root directory into a sub folder, then in Vista I moved everything back and checked the volume for errors.

(Maybe someone can explain why Vista finds it necessary to count all the files in a folder that it's moving even though the folder is only moving to another folder on the same drive...)
 
Yes, the moving could explain it.

If the files are fragmented, there's a chance they won't be loaded. Moving them in effect unfragmented the files. I'll have to test that!
 
I only moved files from one folder to the root folder - all on the same disk. If anything got defragmented, it would be only the directory list since moving a file does not move the file's data. Perhaps an erroneous file was removed or empty entries in the listing could have been filled in. I don't know anything about the NTFS file system so I can't imagine all the possible changes that could have been made by moving the files.
 
Back
Top