search

CloverHackyColor / CloverBootloader

Bootloader for macOS, Windows and Linux in UEFI and in legacy mode
BSD 2-Clause "Simplified" License
4.58k stars 622 forks source link

Default boot volume defaults to Recovery #67

Closed sprtm closed 4 years ago

sprtm commented 4 years ago

For a while now, I'm having issues with Clover defaulting back to the Recovery partition as the default boot volume.

Strange thing is if a do an immediate reboot, Clover will remember the last disk, but if the computer has been running for a while, like to the next day, it will default to Recovery again.

Any idea were to start?

This is from my config.plist:

`

Arguments 
    <string>dart=0 darkwake=0</string>
    <key>Debug</key>
    <false/>
    <key>DefaultVolume</key>
    <string>Hackintosh SSD</string>
    <key>Legacy</key>
    <string>PBR</string>
    <key>Log</key>
    <true/>
    <key>Secure</key>
    <false/>
    <key>Timeout</key>
    <integer>5</integer>
    <key>XMPDetection</key>
    <string>Yes</string>

`

boot.log

CMMChris commented 4 years ago

I made similar observations when installing macOS updates. Clover always picks the right boot volume during the update, but once the final reboot occurs it picks the recovery for some reason. This is happening ever since Catalina (starting from the first beta release) and I have observed this behavior on multiple machines.

MysticalOS commented 4 years ago

far as I've seen clover picks last volume in nvram, and during a macOS install/update, the volume is set to install one because INSTALLER sets it to install one in nvram, just like on a real mac.

when install is done, the installer however fails to set volume back to original volume, it's still set to installer volume (which now no longer exists). Because clover can't find it, it simply pics the first volume in list instead.

I suspect the only difference here between a real mac and Clover is the real mac if it can't find the nvram boot volume, it'll choose first macOS volume it sees, not the first drive in list like clover does.

I'd say the most straight forward fix is an if else rule in volume selection in existing code that says "if nvram volume can't be found select first volume" to something like "if nvram volume can't be found but name of missing volume contains 'install' then find first volume containing bootable macOS system else find first volume"

Now, for the Ops issue where the volume is always resetting, that sounds like broken nvram. Ensure nvram is functional with your bios. if it is not, Make sure you are using AptioMemoryFix.efi for memory and not one of other ones. AptioMemoryFix takes extra action to try and ensure functional nvram memory space. In addition, like faqs for aptiomemoryfix said, make sure above 4g encoding is ENABLED in bios settings (ONLY enable this setting with aptiomemoryfix, it actually breaks other aptio memory patch drivers). If ll that fails, possibly look into setting up emulated nvram driver from clover install.

sprtm commented 4 years ago

Now, for the Ops issue where the volume is always resetting, that sounds like broken nvram. Ensure nvram is functional with your bios. if it is not, Make sure you are using AptioMemoryFix.efi for memory and not one of other ones. AptioMemoryFix takes extra action to try and ensure functional nvram memory space. In addition, like faqs for aptiomemoryfix said, make sure above 4g encoding is ENABLED in bios settings (ONLY enable this setting with aptiomemoryfix, it actually breaks other aptio memory patch drivers). If ll that fails, possibly look into setting up emulated nvram driver from clover install.

Thank you for your detailed reply. Before opening this ticket I noticed that I had both AptioMemoryFix-64.efi and EmuVariableUefi-64.efi installed. I removed EmuVariableUefi-64.efi and nvram.plist to see if it resolved the issue. After a couple of restarts Clover still selected the correct start disk, but the following day, it was back to Recovery again. I've saved a TestVar=HelloWorld variable in NVRAM, and it's always kept between restarts.

I have now changed "Above 4G Decoding" to ENABLED in BIOS. I wasn't aware of that setting before. Let's see if that helps.

mhaeuser commented 4 years ago

@MysticalOS Macs do not use the efi-boot-device variable as Clover does at all, iirc it is basically a trigger for the AppleEFINVRAM kext to set the actual variable (Boot0080). I don't know of any issues with OpenCore, or Macs, and updating, infact I heard their issues got fixed by people switching from Clover. Also Macs use bless and (mostly) not bruteforcing, and they use Preboot over the OS volume.

roddy20 commented 4 years ago

Macs do not use the efi-boot-device variable as Clover does at all,

legacy systems require a very complicated script to save Boot0080 https://github.com/acidanthera/OcSupportPkg/blob/master/Utilities/LogoutHook/LogoutHook.command efi-boot-device-data can be stored as nvram -xp > file

mhaeuser commented 4 years ago

@roddy20 That is true, but also has nothing to do with the point that the behaviour is not Mac-alike and may cause unexpected results.

roddy20 commented 4 years ago

boot0080 and efi-boot-device-data contain very similar data boot0080 contains extra 24 bytes that I cannot decode, but I believe there is a way to convert one key to another boot0080=24bytes+efi-boot-device-data

mhaeuser commented 4 years ago

Usually they do, yes, but nobody guarantees you consistency among all situations (install, update, ...)

roddy20 commented 4 years ago

I want to know what is it: hexdump -C Boot0080 00000000 01 00 00 00 4a 00 4d 00 61 00 63 00 20 00 4f 00 |....J.M.a.c. .O.| 00000010 53 00 20 00 58 00 00 00 |S. .X...| 00000018 seems to be the word "J Mac O S X" with spaces

roddy20 commented 4 years ago

Usually they do, yes, but nobody guarantees you consistency among all situations (install, update, ...)

maybe Apple uses not Boot0080 but BootNext, to boot from the update only once

mhaeuser commented 4 years ago

@roddy20 "Mac OS X" is the name, "J" is not part of it, it's the UEFI Boot Entry header (check the spec, I don't have it at hand right now). BootNext is possible, but doesn't change the point

sprtm commented 4 years ago

Unfortunately changing the "Above 4G" setting in BIOS didn't change anything.

As @CMMChris said, I also think this issue started when I updated to Catalina. But I also updated Clover from 4920 to 5070 at the same time, don't know if anything changed in Clover regarding boot volume/NVRAM between those versions.

CMMChris commented 4 years ago

The issue definitely did start with Catalina and is not dependent on the Clover version. That being said, I don't have any issues with Clover picking the latest booted entry. It always works fine. I only noticed the issue with auto selecting boot entries during macOS install and updates. I think it has something to do with Clover picking the first macOS entry after an update or the install has finished. Since Catalina, first boot entry is Recovery. Back in High Sierra and Mojave it used to be the main boot entry. I personally fixed this for now by hiding the recovery entry. This causes Clover to pick the correct boot entry after finished install or update.

MysticalOS commented 4 years ago

I'm on 10.13 but my boot entry order looks a bit like this

microsoft EFI, recovery, recovery, macOS, macOS, bunch more windows things.

I believe I hide the preboot volumes. but I'm used to process after install is to arrow over 3x to get to boot.

my setup is 3 different disks, one windows 10, one main macOs volume, and one clone volume (that's identical to main one).

clover is installed on main one only though not clone, two clover would be bad :D

But TL/DR, i'm NOT on Catalina and macOs is definitely not first entry. after a macOS install if I don't choose correct volume, I'd also end up in recovery if not for windows volume. there are times I was afk too long in install and i come back and see windows login window :D

Any other time though, clover remembers last volume no problem, it's only after a macOS install has completed and purged it's APFS container/volume

CMMChris commented 4 years ago

Funny, I have never seen recovery in first place pre Catalina. Anyhow, my assumption above is wrong in that case. For me it looked like this pre Catalina with Preboot hidden on two different machines: Boot Option 1: Windows Boot Option 2: macOS Boot Option 3: macOS Recovery Boot Option 4: Some additional non-working Windows entry

Since Catalina it looks like this on the same machines: Boot Option 1: Windows Boot Option 2: macOS Recovery Boot Option 3: macOS Boot Option 4: Some additional non-working Windows entry

And both machines show the same behavior when installing macOS updates: 1st Reboot: Picks the right volume (macOS install) 2nd Reboot: Picks recovery (in case macOS install is gone)

When I hide the recovery volume both machines automatically boot into macOS as it should be after update is finished.

On normal reboots both machines always pick the correct boot volume without exception no matter if Recovery is hidden or not.

MysticalOS commented 4 years ago

you know, come to think of it, my 10.13 setup may not be standard order. carbon copy cloner might use 10.15 boot order when cloning even a 10.13 disk? who knows at this point :D

maya923 commented 4 years ago

I have a space in my startup disk as well, both on my Hackintosh and my actual Mac Pro. Spaces never seemed to matter until recently, where now I am experiencing the same thing.

SergeySlice commented 4 years ago

Is the issue true for 5117?

maya923 commented 4 years ago

Is the issue true for 5117?

Yes. I had DefaultVolume set to LastBootedVolume as a workaround, so I undid all that and it's defaulting back to Recovery.

TonyC5 commented 4 years ago

I just experienced this (Clover defaulted to Recovery after a normal shutdown) on my HP EliteDesk 800 G4 Mini (Clover r5118, UEFI). My EFI and system description are here. More details below. This is my first UEFI-capable hackintosh and I have never seen this with Clover Legacy booting on my other hacks.

By the way - thank you for Clover. It is awesome! You and your team are doing a fantastic job.

SergeySlice commented 4 years ago

Is the issue true for 5117?

Yes. I had DefaultVolume set to LastBootedVolume as a workaround, so I undid all that and it's defaulting back to Recovery.

LastBootedVolume is not a workaround. It is recommended setting to have normal behaviour.

TonyC5 commented 4 years ago

I was following this issue for a potential solution, since I still occasionally observe the default back to Recovery after a normal shutdown or restart. My system specs/configuration are below, with further description here. Is there a work-around for this issue (or a user error that I need to correct)?

System Specs / Configuration