Jump to content

FileVault 2


vit9696
 Share

496 posts in this topic

Recommended Posts

Just because you see things in a way, doesn't mean that it's "horrible workaround which is a spit away from a somewhat proper solution". At least, it's worth thinking about it. Even if it's for to conclude that you're right.

Explain your reasons instead of just saying that the others are wrong. I still don't get why Clover asking for a password is such an horrible thing. A bootloader that need a password to boot a partition : why is it bad design ?

 

Let me get that right... you don't see what is wrong with either modding the AppleKeyMapDb protocol, introducing a listener to a proprietary event or even using a repeating event as a "multi-thread pause" fake to even determine when boot.efi is ready for input, and then either modding AppleKeyMapDb again to provide a new key on every stroke or introduce another event to feed the right data in the right intervals, is worse than just doing the conversion and feeding where it is supposed to be, in the PS2 kb driver? And you think "you don't use Clover" is a good argument for implementing such a crutch of a workaround in contrast to doing it proper, across the entire UEFI environment? Please explain how any of that is subjective... for me, this is not debatable, as that 'workaround' is not even less work than the proper solution.

Link to comment
Share on other sites

@vit9696 : You know my profession ? Interesting the way some people need to attack other when they may disagree.

 

Security problems in Clover could be a reason, I agree.

 

@Download-Fritz : I never said "you don't use Clover". I agree that feeding the pre-boot boot.efi seems not right. My question was : is it possible to entirely skip Apple pre-boot, doing what pre-boot does, except for the GUI part. In other words : would it possible to boot an encrypted partition if no Recovery partition exists ?

 

The question might stupid, I know. That doesn't mean I am, neither I need to change profession. Please everyone, stay nice and calm. It is just question. Question to people who know more than me on that subject. I'm not criticizing your work, or Clover.

  • Like 2
Link to comment
Share on other sites

lots of discussion here, which is good, but i want to circle back to some basic stuff-namely have people been able to get FV2 to work in High Sierra? i have it working fine in Sierra, but have been reluctant to upgrade to HS because of concerns about FV2

lots of discussion here, which is good, but i want to circle back to some basic stuff-namely have people been able to get FV2 to work in High Sierra? i have it working fine in Sierra, but have been reluctant to upgrade to HS because of concerns about FV2

Link to comment
Share on other sites

lots of discussion here, which is good, but i want to circle back to some basic stuff-namely have people been able to get FV2 to work in High Sierra? i have it working fine in Sierra, but have been reluctant to upgrade to HS because of concerns about FV2

lots of discussion here, which is good, but i want to circle back to some basic stuff-namely have people been able to get FV2 to work in High Sierra? i have it working fine in Sierra, but have been reluctant to upgrade to HS because of concerns about FV2

Yes, I'm using FileVault 2 on my High Sierra installation on a SSD with apfs formatting.

Link to comment
Share on other sites

I never said "you don't use Clover".

 

Slice did and you replied to my answer to Slice.

 

My question was : is it possible to entirely skip Apple pre-boot, doing what pre-boot does, except for the GUI part. In other words : would it possible to boot an encrypted partition if no Recovery partition exists ?

 

Not by chainloading boot.efi, no.

Link to comment
Share on other sites

  • 2 weeks later...
  • 2 weeks later...

I'm stuck in a update loop. My system boots again in 10.13.1 after I install 10.13.2.

Do I need to select another device on boot other than FileVault volume?

 

Edit: Somehow I got it, either by disabling IgnoreNVRAMBoot and removing default volume or by booting into macOS Installer prebooter, which I think installs the OS again.

Link to comment
Share on other sites

Slice, I have just gotten into the same issue. Whenever you try to update to 10.13.2 it will fail to load with "was error, press any key".

In verbose mode you ger "Error loading kernel cache (0xe).

Boot failed, sleeping for 10 seconds before exiting.

 

This is the same thing I got when trying to upgrade from 10.12.6 to 10.13.1, and it continued to fail until I disabled CoreStorage.

The cause is that there are now 3 boot.efi on Recovery HD partition:

— com.apple.boot.S/boot.efi

— com.apple.recovery.boot/boot.efi

— System/LibraryCoreServices/boot.efi

 

Second is the normal recovery, third is a normal system to boot: those two are displayed and suggested by Clover.

Yet it is wrong, because when upgrading the OS the one to be loaded must be com.apple.boot.S, but clover does not suggest it.

 

We need to fix it as soon as possible…

  • Like 1
Link to comment
Share on other sites

Clover already has

    AddLoaderEntry(L"\\com.apple.boot.R\\boot.efi", NULL, L"macOS Install", Volume, NULL, OSTYPE_OSX_INSTALLER, 0);

This is the game Rock-Scissor-Paper.

In your case Scissor is winner.

Clover should be able to play the game.

  • Like 1
Link to comment
Share on other sites

Clover already has

 

AddLoaderEntry(L"\\com.apple.boot.R\\boot.efi", NULL, L"macOS Install", Volume, NULL, OSTYPE_OSX_INSTALLER, 0);

This is the game Rock-Scissor-Paper.

In your case Scissor is winner.

Clover should be able to play the game.

Well, mhm, this makes sense, but I do not see the entry obviously, and the file is there.
Link to comment
Share on other sites

Slice, I also looked into the improper progress bar drawing issue (lowres/no bg) with FV2 on.

It appears to be due to boot.efi switching console mode more than it actually needs to.

I attached a patch to the latest rev and an image to give you an idea how it looks (and should look) after applying the patch.

post-1135927-0-93191300-1512941403_thumb.jpg

progressbar.patch.zip

  • Like 5
Link to comment
Share on other sites

Ok, I can confirm that vit9696's patch is really working. Here's the pre-compiled binary for those who don't have Clover compilation environment.

 

[REMOVED]

EDIT: Now that Slice has published a new official version, this attachment is going to be deprecated.

Edited by PMheart
  • Like 1
Link to comment
Share on other sites

Slice, I also looked into the improper progress bar drawing issue (lowres/no bg) with FV2 on.

It appears to be due to boot.efi switching console mode more than it actually needs to.

I attached a patch to the latest rev and an image to give you an idea how it looks (and should look) after applying the patch.

Sent to 4345.

I have no installed FV2 so I can't check. But I checked that it not influences on ordinary boot.

  • Like 1
Link to comment
Share on other sites

If this is the patch to make the second stage boot look ok when FV2 is ON, then I'd be happy to try and report back.

 

I don't have a build of Clover 4345 though... And I just reinstalled my OS, so no Xcode either. I can install it. But it if anyone has a Clover 4345 already compiled, it would be more efficient to try that until I'm done recreating my environment. :)

 

Also, big thanks to vit9696 for the patch. I've been looking for this for so long!

Link to comment
Share on other sites

If this is the patch to make the second stage boot look ok when FV2 is ON, then I'd be happy to try and report back.

 

I don't have a build of Clover 4345 though... And I just reinstalled my OS, so no Xcode either. I can install it. But it if anyone has a Clover 4345 already compiled, it would be more efficient to try that until I'm done recreating my environment. :)

 

Also, big thanks to vit9696 for the patch. I've been looking for this for so long!

I tested it already. It didn't change anything about second stage boot screen...

  • Like 1
Link to comment
Share on other sites

2nd stage is a different question, to get to it we needed to fix the 1st stage, which was also broken for many configurations.

We will likely release a fix for Intel with lvs1974 reasonably soon as a part of IntelGraphicsFixup project (at least it was prototyped and proven to be reasonably good).

There might be something for AMD (built into WhateverGreen), but there is only partial success with it at the moment…

As for NVIDIA it will need a completely different approach, and I am not positive I could build something decent for it.

 

UPDATE:

IntelGraphicsFixup 1.2.1 now contains the mentioned fix.

  • Like 3
Link to comment
Share on other sites

 Share

×
×
  • Create New...