I attempted to edit that line via HexEdit. Either I got the partition number wrong (tried 3 different ones because I didn't realize some weren't counted), or it's not as simple as a hex hack. Just got a permanently blinking underscore. Any ideas?
Did the same thing and received the same result you did. I think this is an easy fix, shame that most people are ignoring this problem. I wonder if there are other alternatives to using OEM bios lo*ders? I'm going to have to re-install for the 2nd time today, this 40-second delay is beyond annoying.
You shouldn't have to reinstall...I just redo the crack every time and all is fine. If you just boot off of the dvd/flash drive launch the recovery console and launch the command prompt. From there type these 3 commands (assuming the drive of your install media is "D") D: cd cd boot bootsect.exe /nt60 c: If you restart it should boot like normal (you'll just have to reinstall the loader)
I got the loader and it seemed to work, but like everyone else, I get the minute of the blinking cursor. Also- if it worked, would there be the watermark down in the lower right corner?
Hi, I modified the embedded menu of the grldr file and put the line rootnoverify (hd0,2) instead of the find routine and the loading time did not change. I then decided to test the original grub4dos binary. At the grub menu I switched to commandline to test the rootnoverify command. No boot delay. System booted as soon as the command was entered So I think that it's the "acpi" function added to the grub binary that take 30-40sec to load the ACPI tables or whatever in the memory on mac based computer (Since we don't have a BIOS but an EFI). EDIT : I tried WOW7 since it's not the same mechanism. It's not grldr that loads the ACPI tables but WOW.exe but my system did not boot at all. The WOW process hangs the computer and I have to hard stop it. EDIT2 : I removed the acpi line and the boot delay is still the same without windows to be activated. I don't understand anymore what is delaying the startup process Would be great to have the current version modified so that grub displays information during boot time. That way we may be able to see what is taking time during startup PS : I have a macbookpro3,1
xenon974, Thanks for experimenting and helping to isolate the issue, and it proved my suspicions about hazar's suggestion. It's awful quiet around here lately! Maybe everyone is just waiting on the release of Snow Leopard!
The above made me think; - Take the original Grub4dos and configure it with the rootnoverify command (maybe from menu.lst) - Reverse engineer the hacked loader, or get the sourcecode - Merge that code with the original Grub4dos - Done Or: - Get the hacked loader to work with menu.lst to load the correct config What has been done on the hacked loader is that all messages from the loader are surpressed to not gain any suspicion when you boot up Win7 in public. It's aestatically for the better also. So I don't think the second option works. However, putting menu.lst in c:\boot doesn't harm anything either.
Guys to make it work on a mac just hex find --set -root /bootmgr in the grldr to rootnoverify (hd0,3) 8)
Tried that, It just sits at the boot screen without EVER loading EDIT: Tried again, how it says missing HAL.DLL (which is usually a corrupted boot.ini in XP) Ran bootsect again. Time to reinstall the loader...again. 24 Days.
I tried this too, but it didn't help. First of all, Windows is usually on the third partition (OS X is on the second partition, the first one is used for EFI), so I tried with (hd0,2). Since "rootnoverify (hd0,2)" is shorter than "find --set-root /bootmgr", I replaced the remaining bytes with 0A, which is a linefeed and simply adds a couple of empty lines (should not be a problem). With these changes, the lo*der is still working, but the 30 seconds pause does not disappear. It would be really helpful to re-enable the lo*der output, but I don't know how to do this.