Earlier today, I managed to kill Frankenmac…again. Technically, it's "again again," because I also did so over the weekend. The weekend death was a black screen, same as the first, but this time, I managed to find the solution.
Today's death looked more serious—Frankenmac would reboot itself about a second after I started the boot sequence. I tried my backup drive, and it didn't work either—despite the fact that I tested it over the weekend. I couldn't boot in single user mode or safe mode from either drive. I could, though, boot into single user mode from the original USB stick I made for the install.
From there, with some help, I eventually got things working again. If you choose to build one of these things, you may find yourself with a similarly-dead machine at some point in time. Worst case, you should also be able to boot in single user mode from the USB stick, but then what? Here are a few tips on things you can do while booted in single user mode that might help debug the problem.
First off, you'll want to mount the USB stick's filesystem as read-write, which the single user boot screen tells you how to do: /sbin/mount -uw /
This doesn't directly help solve the problem, though, because you can't see your hackintosh's hard drive and EFI partition. To see and work with the hackintosh's files, you'll need to mount its hard drive and EFI partition in single user mode.
To do that, you need to figure out which drives they are. If you were booted into macOS, you could do this with diskutil, but there's no access to that tool in single user mode. Instead, you'll have to do it this way. First, run this command to show all the drives in the system:
$ ls -l /dev/disk* brw-r----- 1 root operator 1, 0 Apr 19 17:06 /dev/disk0 brw-r----- 1 root operator 1, 4 Apr 19 17:06 /dev/disk0s1 brw-r----- 1 root operator 1, 1 Apr 19 17:06 /dev/disk0s2 brw-r----- 1 root operator 1, 2 Apr 19 17:06 /dev/disk0s3 brw-r----- 1 root operator 1, 5 Apr 19 17:06 /dev/disk1 brw-r----- 1 root operator 1, 6 Apr 19 17:06 /dev/disk1s1 brw-r----- 1 root operator 1, 7 Apr 19 17:06 /dev/disk1s2
In the output above, there are two disks (disk0 and disk1); the first has three partitions, the second, two. Assuming you have only one disk in your hackintosh, you'd see something similar to the above. Typically, the first disk listed will be the internal, and the second the USB stick you booted from.
To mount the drives you need to work with, you need to figure out which one is the actual in-use partition and which is the EFI partition. The fstyp command is the trick to answering that question:
$ fstyp /dev/disk0s1 msdos $ fstyp /dev/disk0s2 hfs
The msdos partition is the EFI partition, and the hfs partition is your hackintosh' main drive. To mount these, the system needs somewhere to mount them. The /Volumes folder is where they belong, so create a couple of mount points in that folder:
$ mkdir /Volumes/hack_efi $ mkdir /Volumes/hack_drive
The above two commands create two new folders—you can name them whatever you like, but make sure you know which one is which. After that, all you need to do is mount each drive to its mount point:
$ mount -t msdos /dev/disk0s1 /Volumes/hack_efi $ mount -t hfs /Volumes/hack_drive
You may see some output go past after each mount command, but they should work. Confirm the drives are mounted by checking the two folders you created:
$ ls -al /Volumes/hack_efi $ ls -al /Volumes/hack_drive
With everything mounted, you can start troubleshooting. A reasonable suspect in startup-related issues is the last kernel extension you installed. You can find extensions in a few spots on a hackintosh…
- The /System/Library/Extensions folder.
- The /Library/Extensions folder.
- On the EFI disk.
For the first two, listing those folders' contents in date order may reveal the culprit:
$ ls -alt /Volumes/hack_drive/System/Library/Extensions $ ls -alt /Volumes/hack_drive/Library/Extensions
The EFI disk was the source of my today's Frankenmac death, and I totally forgot that kernel extensions can reside there, too. Specifically, look in /Volumes/hack_efi/EFI/CLOVER/kexts. There are subfolders there for each macOS release; look in 10.12 for Sierra-specific kexts. In my case, I found two, and didn't know which might be causing the problem. So I renamed both extensions from .kext to .donotuse, and then rebooted—and it worked.
You might also check the /Volumes/hack_efi/EFI/CLOVER/ACPI/patched folder, though none of Frankenmac's deaths have been caused by items in this folder.
In addition to the above, I've found these two resources useful:
- Big List of Solutions for El Capitan Install Problems
- Solving NVIDIA Driver Install & Loading Problems
Troubleshooting a hackintosh is very much a dark art; there are no hard and fast rules about how to fix the problem. Try to keep a current backup, and (unlike my day today) hopefully it works when you need it.
So what Clover kexts nuked your startup? Was it obvious afterward why they didn’t work? Clover has so many startup options I’m surprised there are no switches or key-combos to bypass kext loading from selectable locations. Shouldn’t Safe mode have ignored them?
There were only two there - one for the RealTek driver, one AppleALC which I had added to try to fix the no sound after wake issue. I reactivated the RealTek one after reboot, and it worked fine. So I deleted the AppleALC one and it's booting fine now. Back to ground zero in terms of getting music post sleep working, but at least the machine works.
I thought safe mode should have done that, indeed. Either it didn't, or there was a related issue going on that I somehow resolved.
This has been a very insightful series of articles. Thank you. This last one has effectively convinced me to forget about ever investing a penny of budget or a second of time in building my own Hackintosh. So, thank you, twice!
Comments are closed.