Jump to content


  • Content Count

  • Joined

  • Last visited

About Laqk

  • Rank
    InsanelyMac Protégé

Recent Profile Visitors

3,450 profile views
  1. Laqk

    [pre-release] macOS High Sierra

    No, I changed nothing except the BiosVersion, and now BiosReleaseDate to match. I've just clean reinstalled Sierra and so far so good. No problem with iCloud. Now to try High Sierra.
  2. Laqk

    [pre-release] macOS High Sierra

    For those of you having the icloud password reset problem, I may have an explanation. I too started having this problem when I started testing high sierra. I don't have TFA enabled, and the problem started happening randomly on both high sierra (all beta versions) and sierra (10.2.5) on fresh installs. Had to reset my icloud password almost a dozen times so far. Tought the only thing I had changed was clover version (now using 4097) but didn't think that was the problem. Suddenly, I remembered that I had updated my BiosVersion key in the SMBios section of my config.plist to allow use of APFS. But when I checked my config.plist for consistency, I realized that I had not updated the BiosReleaseDate key of the SMBIOS section, and that that key still displayed the release date of the previous value of BiosVersion. In other words, my SMBios section had the following values in it: <key>BiosReleaseDate</key> <string>11/30/2016</string> <key>BiosVersion</key> <string>MBP133.88Z.0226.B24.1704292117</string> I have now corrected my config.plist to contain the following: <key>BiosReleaseDate</key> <string>04/29/2017</string> <key>BiosVersion</key> <string>MBP133.88Z.0226.B24.1704292117</string> and will now do further testing. If this was indeed the source of the problem, it highlights the critical importance of having an absolutely consistent configuration for having a properly working hackintosh.
  3. @srs5694 I had just logged in to post a follow-up when I saw your replies. Thank you for taking the time to investigate my problem. I had already managed to solve it by doing essentialy what you advise. I used an older version of Ubuntu as a live cd (maverick) which has the proper version of the libicu library, and that allowed me to use the linux version of GPT fdisk, which worked flawlessly. So as you suspected, this is definately a problem with the Windows version of GPT fdisk. But I'm sure you'll be able to sort this out very soon. Thank you for your work with GPT fdisk, which, as far as I can tell, is the only tool out there to do MBR -> GPT lossless conversions.
  4. @srs5694: Since you developped GPT fdisk, maybe you can tell me what's happening here. The problem is this: Everytime I use GPT fdisk to convert a MBR disk to GPT, the resulting disk triggers a BSOD (believe it or not) on my Windows 7 x64 when connected. However, when I mount the same disk, on the same hardware, using an Ubuntu live cd and examine it with disk utility, it seems to be reported as a completely normal and healthy GPT-partitionned disk. The disk in question is a healthy 80 GB western digital disk. I connect it to my laptop using and external enclosure connected through an eSata connection. For the conversion, I use the latest version of GDISK for Windows. I've tried creating the original MBR partition within Windows, and also with gparted on a linux live cd. Both method give me the same result. I've also tried a variety of original MBR configurations (one single partition taking up the entire disk, two or more partitions of varying sizes, formatted in a variety of formats, with or without free space left on the disk, etc), everything I try gives me the same result: The moment I connect the drive, Windows blue screens. If I try to boot Windows with the drive already connected, Windows freezes during bootup. The only thing I haven't tried is using a linux version of GPT fdisk, because the .deb on sourceforge requires libicu 42, and the live cd I use has libicu 44, and I can't for the life of me figure out how to install a previous version of this library. I seem to have a talent for stumbling on the most obscure bugs in applications...
  5. In order to install Windows 7 x64 in true UEFI mode, the install DVD needs to have the proper el-torito record. This is the case with genuine Microsoft DVDs, or DVDs created by burning a genuine Microsoft ISO image. DVDs created with customized Windows 7 installs from applications like rt7lite will not work because they don't create the proper el-torito header. There is a way to manually create an ISO image containing the proper el-torito records using the oscdimg.exe tool from either OPK or WAIK. In fact, that's the tool Microsoft use the create their own DVD images. That's what I used to create my own custom install Windows 7 x64 DVD and it worked very well, allowing me to install Windows 7 x64 in UEFI mode on a GPT-partitionned HDD.
  6. Works perfectly now, thank you ! Don't be too hard on yourself, It's just the "But I made only one minor and obvious modification, what could possibly go wrong ?" syndrome. I was plagued with it extensively in my programming days. By the way, did you know that if you removed the check on the hiddensectors value (either in the code or by removing -DWITH_VALIDATION in the makefile), you can use your bootduet on an unpartitionned usb "superfloppy" (by placing it directly on sector 0) and it works splendidly ? Much simpler that way. And as a small token of my appreciation, I've solved your EFI Windows 7 USB stick issue. Do the following: 1. Format your USB stick using the FAT32 format (an unpartitionned "superfloppy" works fine); 2. Install Bootduet on it; 3. Copy EFILDR20 to the root; 4. Copy the entire content of the Windows 7 x64 install DVD to the USB stick; 5. In folder EFI, create a folder named BOOT; 6. In that folder, copy the BOOTX64.EFI file that I included in this post. And voila ! A perfectly functional EFI Windows 7 installation USB stick. I tested it and it works. I read your previous post and the problem was that the BOOTX64.EFI file included in the EFISYS.BIN and EFISYS_NOPROMPT.BIN don't work. They're only for the el-torito partition of a bootable DVD. The one I included in my post comes directly from the EFI system partition of an already installed and working Windows 7 x64 installation on an EFI GPT disk. Enjoy ! And thanks again for your help. bootx64.zip
  7. Thanks for your reply Keshav. But I'm not sure I understand what you mean when you say that gpt.com doesn't pass partition info properly. If I read bootduet's source code correctly, all that it needs is the BIOS drive number of the boot drive, and the LBA of the boot sector of the EFI partition, and the "hd" versions of bootduet seem to read both of these directly from to boot sector itself (and I've made sure this information is present and accurate in the boot sector of the EFI partition). So it shouldn't need any information from gpt.com. As for syslinux, I'll look into it. Besides syslinux and grub2, is there any other gpt-aware boot loader ? @migle: I think I found a discrepency in your bootduet source code. In the comment, you say: * 0x006000 - 0x007000 Room for several FAT sectors (4k) (FAT12) ... * 0x007e00 - 0x008000 Room for one FAT sector (FAT32 and FAT16) Yet, in the code, the following: #if FAT == 32 || FAT == 16 .equ FatOffset, 0x6000 # Offset address for the FAT buffer #else .equ FatOffset, 0x7e00 # Offset address for the FAT buffer #endif seems to do the exact opposite. Is it a mistake in the comments ?
  8. You guys are lucky to be able to boot your Windows in EFI mode from your hard drive. I've been trying for days now without success. Migle's bootduet just doesn't work for me. First, let me say I used Keshav's package to build an MBR DUET USB stick, and it works perfectly. I've used it to install Windows 7 x64 several times now on my GPT formatted hard disk. But so far I've failed in setting it up so it can boot without the USB stick. Whatever I try I get the same result: I get the message "GPT Started!" on screen, then a blinking cursor in the upper left corner of the screen, then nothing. The problem is not with gpt.com, I confirmed that it does load and execute the boot sector of the EFI system partition by making the boot sector invalid on purpose (I compiled bootduet with -DWITH_VALIDATION and wrote zeros for the hidden sectors value) and I did get the "Bad" message, so I know the boot sector load and at least starts to execute. But when I compile bootduet with the -DDEBUG option I don't even get any number display on the screen, and I know that EFILDR20 is not only not loaded, it's not even searched for because even when the EFI system partition is completely empty, I don't get any "Missing EFILDR20" message. I've created my GPT disk in several ways (let Windows create it itself during setup starting from a completely blank and unformated disk, created the GPT partition in Mac OS X, created it in Linux using gparted, and in this last case, letting windows create the EFI system partition itself, or creating it manually before windows setup using gparted and gnome disk manager). I tried a FAT32 EFI system partition using bd32hd.bin, and also a FAT16 one using bd16hd.bin, to no avail. Whatever I do I get the same result: the boot sector loads and starts executing, but somehow crashes along the way, doesn't even get to the debug code (when -DDEBUG is specified) and doesn't even try to load EFILDR (no "missing EFILDRXX" message when the file is not even on the disk). In desperation, I began to suspect that maybe there was something wrong with my internal hard drive, so I took an 8 GiB USB stick and used gparted and gnome disk manager to format it in GPT, create two FAT32 4 GiB partition, and set the first one as an EFI system partition. Then I tried installing gpt.com on the master boot record and bootduet on the boot sector and tried booting with this USB stick, and got exactly the same result as always: "GPT Started!" message, and then the dreaded blinking cursor, then nothing. I've tried every test, every configuration I could think of, but now I'm completely out of ideas. Maybe one of you guys could steer me in a new diection of investigation, or else I guess I'll just have to accept the fact that I'll have no choice but booting my machine with a USB stick...
  9. Laqk

    Sleep issues with GA-EP45-UD3P

    I also had the wake right after sleep problem. What solved it from me was to create a section for the sound device in the DSDT, it wasn't there by default. A simple: Device (HDEF) { Name (_ADR, 0x000B0000) } should be enough. Make sure your actual sound device is at address B0000, and put the real address if it's different. Also, if you don't want AppleHDA.kext to load and try to drive the device (for example if you're using VoodooHDA instead), then name the device something other than HDEF. Hope this helps.
  10. Like many here I've been plagued by this dreaded error message that prevented some or all of my USB ports from working correctly. The problem was intermittent on Leopard, but now since I started using Snow, it happened in about 19 out of every 20 reboots. Some members of this board much more knowledgeable than I am have traced the problem to an IRQ conflict between the HPET and the USB ports. A number of solutions have been offered, but the only one that worked for me was using an alternate IOPCIFamily.kext made by Slice. This worked perfectly fine, however I couldn't resolve myself to consider this as a permanent solution, simply because I want my hack to be has much "vanilla" as possible, therefore avoiding all the problems caused by system updates. Let me point out that my machine is an HP Pavilion DV5-1157ca (which overall isn't too bad as a hackintosh), but the fix explained therein may also apply to other types of board, albeit with some adjustments. A little investigating using IORegistryExplorer allowed me to figure out that my UHCI and EHCI ports that were most often disabled required use of IRQs 0x14 and 0x15. The HPET, however, requires four interrupts, even though only two are specified in the DSDT. Device (HPET) { Name (_HID, EisaId ("PNP0103")) Name (BUF0, ResourceTemplate () { IRQNoFlags () {0} IRQNoFlags () {8} Memory32Fixed (ReadOnly, 0xFED00000, // Address Base 0x00000400, // Address Length _Y10) }) ... Note that even though the DSDT specifies interrupts 0 and 8, IORegistryExplorer shows that the HPET always seems to use interrupts 2 and 8. However, that didn't seem to conflict with other devices also using one of those two interrupts. However, in addition to these interrupts, the HPET always seemed to use two others. Sometimes these were 0x0B and 0x17, which didn't cause any problem with my USB ports. The problem is that sometimes, the HPET was hijacking IRQ 0x14 or 0x15, sometimes both, and it seems to use these interrupts exclusively, therefore preventing USB ports normally using these same IRQs from working properly. Many suggestions were offered to solve this problem. Some suggested changing the IRQ numbers defined in the HPET device section of the DSDT, some suggested removing them altogether, or altering or removing IRQ numbers in other device's sections. I tried all these fixes, to no avail. Finally I realized that the problem came from the fact that the HPET device seemed to randomly choose values for the two IRQs that it requires in addition to the two specified in the DSDT. So I said to myself "Well, the HPET device wants four IRQs ? Fine, I'll give it four IRQs". I started by changing the {0} code by {2}, since the HPET always seemed to use this interrupt anyway. Next, I added two more IRQNoFlags sections specifying the values 11 (0x0B) and 23 (0x17), the two values it was using on the rare occasions when everything worked fine. However, IASL gave me an error that the only acceptable values for IRQNoFlags were between 0 and 15. Fine. Hunting through IORegistryExplorer for an unused interrupt number between 0 and 15, I found out that values 0x0E and 0x0F were not used by any device. So I decided on 0x0F and altered my DSDT in the following way: Device (HPET) { Name (_HID, EisaId ("PNP0103")) Name (BUF0, ResourceTemplate () { IRQNoFlags () {2} IRQNoFlags () {8} IRQNoFlags () {11} IRQNoFlags () {15} Memory32Fixed (ReadOnly, 0xFED00000, // Address Base 0x00000400, // Address Length _Y10) }) ... I recompiled the DSDT, replaced it in my /Extra folder, replaced Slice's IOPCIFamily kext by the vanilla one, rebooted, and... Bingo ! No more "unable to get filterInterruptEventSource" errors, all the USB ports work perfectly. I rebooted several times to confirm that this was not a freak occurrence, and I can confirm that this fix permanently solves the IRQ conflict between the HPET device and USB ports. I can now use vanilla IOPCIFamily.kext on my machine and not worry about the next Snow Leopard update.
  11. I just did a clean vanilla install of osx 10.5.8 on a new hd. Everything worked fine, but when auto update came up, all the normal updates were listed there (quicktime, airport, etc) EXCEPT Safari 4.0. After applying all the updates and rebooting, installed Safari version was still 3.2.1. Anyone else noticed this ?
  12. @nerd1983: Yes, both internal and external mic are active at the same time, this is by design. Can't you select which mic to use in your software ? Anyway, that's how it works under windows, you select which mic to use in control panel. And yes, the shutdown problem was due to the old sound driver, I think because it was made from a tiger kext. Mine is made from the leopard 10.5.6 kext. @taylorsin: No idea whatsoever. My headphones work perfectly, and judging by your coded graph, your coded layout is exactly the same as mine. Sorry. @lefechka: Sleep doesn't work on my rig, so I'm unable to test whether the sound comes back after wakeup. This seems to be a common problem though, it's mentionned in many other threads relating to sound. Maybe you could check those, someone may have found a solution. I could try to work on it, but it wouldn't be very practical since I cannot test it. So these days I'm concentrating more on trying to fix the sleep issue I'm having. @yeeha: I'm using an EFI string. Check this thread: http://www.insanelymac.com/forum/index.php?showtopic=131400
  13. Laqk

    9600M GT

    @tank6b: I must point out that I'm using a vanilla leopard installation. I see that you're using iDeneb. Maybe this distro has some modified kexts or bundles that interfere with the display system. Maybe that has nothing at all to do with it, but maybe you could try to do a vanilla install and see how it goes. @ugokind: Yes, you can use OSX86Tools or EFIStudio to import the xml file, convert it to an hex string and inject it in your com.apple.Boot.plist file. Be sure to remove ALL injectors (NVinject, NVdarwin, etc) and use vanilla 10.5.6 kexts.
  14. Laqk

    9600M GT

    I Have an HP Pavillon DV5-1157ca with a NVIDIA 9600M GT card with 512 Mb memory. It works perfectly on a Leopard 10.5.6 installation with the vanilla kexts. No modification necessary. QE/CI, both laptop and external HDMI port working, rotate, mirror, etc. I haven't tested the VGA port but I suspect it would work also. I used to use NVdarwin, but now I use an EFI GFX string made from the following in xml format: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)</key> <dict> <key>@0,AAPL,boot-display</key> <data> </data> <key>@0,built-in</key> <data> </data> <key>@0,compatible</key> <string>NVDA,NVMac</string> <key>@0,device_type</key> <string>display</string> <key>@0,name</key> <string>NVDA,Display-A</string> <key>@0,use-backlight-blanking</key> <data> </data> <key>@1,can-hot-plug</key> <data> </data> <key>@1,compatible</key> <string>NVDA,NVMac</string> <key>@1,device_type</key> <string>display</string> <key>@1,name</key> <string>NVDA,Display-B</string> <key>NVCAP</key> <data> BQEAAAAAAQAGAAAAAAABCwAAAAA= </data> <key>VRAM,totalsize</key> <data> AAAAIA== </data> <key>device_type</key> <string>NVDA,parent</string> <key>model</key> <string>NVIDIA GeForce 9600M GT</string> <key>rom-revision</key> <string>test</string> </dict> </dict> </plist> Hope that helps. (Of course you'll have to check to pciroot for your machine and adjust the VRAM,totalsize parameter to reflect your card. As for the rom-revision parameter, what you write there is irrelevant, but it is what's going to appear in system information)
  15. @Silverstonne: You're welcome. @yuanshijie: TBH I don't know, but I suspect it has something to do with the fact that the driver you're talking about was made from an earlier version of the AppleHDA kext, probably even the one from Tiger. Had it not been for the shutdown issue I would have used it myself. My driver is made from the 10.5.6 kext, and I suspect that's why shutdown works properly on a Leopard system. @moi osx: Glad it works without problems for you. So now I have to figure out what's wrong with my rig. @pateras: Only if it has the same devid as mine (0x111D776B2).