smolderas

Did you report this "bug"?

Yes, you need to boot into the other partition after first boot in order to be able to update... See previously comments.

Can't this update problem (at least on legacy) be solved with clover? Why would we need to boot manually in order to update.

I think it has to do with your mac model identifier.

I too have the same issue, I was trying to find the culprit. I'll take a look at it on the weekend.

I removed the file, and tried to build with ebuild.sh, same issue. Somewhere along there is an error. Edit: I found the culprit: Change the line 614 in the ebuild.sh to repoRev=$(svn info|awk '{ if ($1=="Revision:") {print $2}}') So here is the diff: 614c614 < repoRev=$(svn info | grep "Revision" | tr -cd [:digit:]) --- > repoRev=$(svn info|awk '{ if ($1=="Revision:") {print $2}}')

I removed the file, and tried to build with ebuild.sh, same issue. Somewhere along there is an error.

bdmesg started to report faulty version number: 3:616 0:000 Starting Clover revision: 01314556 on CLOVER EFI Do the ebuild.sh script update the Version.h file? Here is mine: #define FIRMWARE_BUILDDATE "2018-06-17 15:46:09" #define FIRMWARE_REVISION L"01314556" #define REVISION_STR "Clover revision: 01314556" #define BUILDINFOS_STR "Args: -n 9 -t XCODE8 --vbios-patch-cloverefi --only-sata0 --no-ext -D USE_LOW_EBDA -D NO_GRUB_DRIVERS -D NO_GRUB_DRIVERS_EMBEDDED -D EXIT_USBKB=1 --x64 | -D USE_LOW_EBDA -D NO_GRUB_DRIVERS -D NO_GRUB_DRIVERS_EMBEDDED -D EXIT_USBKB=1 -D ENABLE_VBIOS_PATCH_CLOVEREFI -D ONLY_SATA_0 -D USE_LOW_EBDA -a X64 -b RELEASE -t XCODE8 -n 9 | OS: 10.13.5 | XCODE: 9.4" So the script should be faulty...

I could test, if you publish the source.

I'm using FileVault2, so it's based on Core storage like fusion drive. It's set like this here: <key>DefaultVolume</key> <string>HD(2,GPT,159588F2-432D-4C37-A81C-5B788C3AA48A,0x64028,0xDF30B60)\VenMedia(BE74FCF7-0B7C-49F3-9147-01F4042E6842,2C597282D9D1154385E5FBD28A73FDF0)</string>

Yes, but I had that automatically before activating FileVault. I never had to boot into another partition manually. Does it have to do with nvram being not read? Edit: I don't know what you changed, but it didn't do anything for me...

Does that mean I could update normally without booting into another partition after restarting?

Sorry it didn't work for me, because I have tons of modification on the source. Please provide the diff file and I would compile myself and test.

Yes, there is. I think it is in the folder "Boot Files". Nevertheless take a look at it: If you want me to test some changes, please only provide diffs and no binaries... Thanks... Dropbox link

So I've tried to reinstall the update and after rebooting I was this folder in the root partition (disk6s1 in the list), which relates to "FileVault Prebooter": apfs structure: $ diskutil apfs list APFS Container (1 found) | +-- Container disk6 AA7592E9-ED6D-4EF7-B7DE-E78931D69CF6 ==================================================== APFS Container Reference: disk6 Size (Capacity Ceiling): 119824367616 B (119.8 GB) Minimum Size: 120075382784 B (120.1 GB) Capacity In Use By Volumes: 102107136000 B (102.1 GB) (85.2% used) Capacity Not Allocated: 17717231616 B (17.7 GB) (14.8% free) | +-< Physical Store disk5s2 159588F2-432D-4C37-A81C-5B788C3AA48A | ----------------------------------------------------------- | APFS Physical Store Disk: disk5s2 | Size: 119824367616 B (119.8 GB) | +-> Volume disk6s1 C035E33B-7D9E-44C0-82FA-9868355B0AA4 | --------------------------------------------------- | APFS Volume Disk (Role): disk6s1 (No specific role) | Name: Macintosh HD (Case-insensitive) | Mount Point: / | Capacity Consumed: 100900511744 B (100.9 GB) | FileVault: Yes (Unlocked) | +-> Volume disk6s2 8272592C-D1D9-4315-85E5-FBD28A73FDF0 | --------------------------------------------------- | APFS Volume Disk (Role): disk6s2 (Preboot) | Name: Preboot (Case-insensitive) | Mount Point: Not Mounted | Capacity Consumed: 43139072 B (43.1 MB) | FileVault: No | +-> Volume disk6s3 734D0FC9-1C30-4C06-AC88-036BAC0A294E | --------------------------------------------------- | APFS Volume Disk (Role): disk6s3 (Recovery) | Name: Recovery (Case-insensitive) | Mount Point: Not Mounted | Capacity Consumed: 1038516224 B (1.0 GB) | FileVault: No | +-> Volume disk6s4 DF8560DE-6A29-40BF-9E8C-645941F0737B --------------------------------------------------- APFS Volume Disk (Role): disk6s4 (VM) Name: VM (Case-insensitive) Mount Point: /private/var/vm Capacity Consumed: 24576 B (24.6 KB) FileVault: No the content of the "macOS Install Data" folder: -rwxr-xr-x 1 root wheel 246192 Apr 18 09:33 /macOS Install Data/brtool -rw-r--r-- 1 root wheel 181 Apr 29 09:44 /macOS Install Data/index.sproduct -rw-r--r-- 1 root wheel 664 Apr 29 09:44 /macOS Install Data/InstallInfo.plist -rw-r--r-- 1 root wheel 518 Apr 29 09:44 /macOS Install Data/minstallconfig.xml -rw-r--r-- 1 root wheel 378 Apr 29 09:44 /macOS Install Data/OSInstallAttr.plist /macOS Install Data/Locked Files: total 952896 -rw-r--r--@ 1 root wheel 2648713 Apr 18 09:32 AppleDiagnostics.dmg -rw-r--r--@ 1 root wheel 485208494 Apr 18 09:35 BaseSystem.dmg -rw-r--r-- 1 root wheel 1984 Apr 18 10:03 BaseSystem.chunklist -rw-r--r-- 1 root wheel 328 Apr 18 10:03 AppleDiagnostics.chunklist -rw-r--r-- 1 root wheel 893 Apr 29 09:44 .disk_label -rw-r--r-- 1 root wheel 3557 Apr 29 09:44 .disk_label_2x -rw-r--r--@ 1 root wheel 15 Apr 29 09:44 .disk_label.contentDetails drwxr-xr-x@ 8 root wheel 256 Apr 29 09:44 .. drwx------@ 10 root wheel 320 Apr 29 09:45 . drwxr-xr-x 11 root wheel 352 Apr 29 09:45 Boot Files