- Joined
- Jul 31, 2012
- Messages
- 111
- Motherboard
- ASUS STRIX Z370G
- CPU
- i7-8700K
- Graphics
- Vega 64
- Mac
- Mobile Phone
Just ran into a strange issue and learned a few things in the process, thought I'd share here (mods please move if there's a better location) in case anyone else encounters something similar.
My NUC has been working fine for a week or two with 10.13.2 - this morning when starting it up it got stuck in a boot loop, it immediately reboots after:
(Note the absence of +++++++++++++++++++++++)
I'm not the primary user of this NUC, apparently the only thing that changed since yesterday was the installation of some printer drivers from Canon.
I took the SSD out and put it in my desktop, when trying to boot my desktop as usual, the same thing happened! Even though it's loading clover from my desktop SSD (newer version of clover than NUC SSD) and booting the desktop SSD, the exact same thing was happening. I played around a bit and found that if I unplug the NUC SSD, boot clover from the desktop SSD, plug in the NUC SSD and then pick the desktop partition - the desktop boots as before and now I can take a look at the NUC SSD also (doesn't appear to support hot plugging - after it's booted).
So something must be read from the NUC SSD when clover starts up but before it presents the boot options.
I noticed that the NUC SSD had a nvram.plist in the root of the EFI partition. I moved it out of the way and voila, booted fine. Installed it back into the NUC and had to go through the keyboard type detection wizard again (I surmise this is saved in NVRAM). I checked the EFI partition, nothing there, guess it must be saved on shutdown, so did that and rebooted, a new nvram.plist was indeed created (I've since read up on how this is done with RC scripts and EmuVariableUefi-64.efi - and that my desktop has native NVRAM - no need for emulation). So I took a look at the diff between the two:
I took out the USB BT dongle while troubleshooting, haven't plugged it back in, doubt that's the cause of the problem... but boot-image on the other hand seems like the culprit. No idea how that got in there? Referring to NetBoot??
Anyways, crisis averted, NUC humming along without problems and intact again. Hopefully this can save someone a reinstall.
My NUC has been working fine for a week or two with 10.13.2 - this morning when starting it up it got stuck in a boot loop, it immediately reboots after:
Code:
OsxAptioFix2Drv: Starting overrides for: \system\library\coreservices\boot.efi
Using reloc block: no, hibernate wake: no(Note the absence of +++++++++++++++++++++++)
I'm not the primary user of this NUC, apparently the only thing that changed since yesterday was the installation of some printer drivers from Canon.
I took the SSD out and put it in my desktop, when trying to boot my desktop as usual, the same thing happened! Even though it's loading clover from my desktop SSD (newer version of clover than NUC SSD) and booting the desktop SSD, the exact same thing was happening. I played around a bit and found that if I unplug the NUC SSD, boot clover from the desktop SSD, plug in the NUC SSD and then pick the desktop partition - the desktop boots as before and now I can take a look at the NUC SSD also (doesn't appear to support hot plugging - after it's booted).
So something must be read from the NUC SSD when clover starts up but before it presents the boot options.
I noticed that the NUC SSD had a nvram.plist in the root of the EFI partition. I moved it out of the way and voila, booted fine. Installed it back into the NUC and had to go through the keyboard type detection wizard again (I surmise this is saved in NVRAM). I checked the EFI partition, nothing there, guess it must be saved on shutdown, so did that and rebooted, a new nvram.plist was indeed created (I've since read up on how this is done with RC scripts and EmuVariableUefi-64.efi - and that my desktop has native NVRAM - no need for emulation). So I took a look at the diff between the two:
Code:
$ diff nvram.plist nvram.plist.orig
16a17,25
> <key>bluetoothActiveControllerInfo</key>
> <data>
> KwqHgAAAAACAFAAAAAAAAA==
> </data>
> <key>boot-image</key>
> <data>
> AgEMANBBAwoAAAAAAQEGAAAXAxIKAAAAAAAAAAQEGAAxAGMAZAAxADQANwAwADAAMAAA
> AH//BAA=
> </data>
27c36
< AAAAAA==
---
> AAAAEA==I took out the USB BT dongle while troubleshooting, haven't plugged it back in, doubt that's the cause of the problem... but boot-image on the other hand seems like the culprit. No idea how that got in there? Referring to NetBoot??
Anyways, crisis averted, NUC humming along without problems and intact again. Hopefully this can save someone a reinstall.