The Robservatory

Robservations on everything…

 

Frankenmac 2017: Troubleshooting tips

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:

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.

3 Comments

Add a Comment
  1. 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?

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

      -rob.

  2. 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!

Leave a Reply to Kennedy Brandt Cancel reply

The Robservatory © 2018 • Privacy Policy Built from the Frontier theme