Jump to content
30960 posts in this topic

Recommended Posts

14 minutes ago, arsradu said:

 

Yeah, but in this case, it was all automatic. Good thing I was paying attention to the log, so I could see what was it doing. :))) Otherwise, it would continue to be a mystery forever.

Well, but I hope it is clear that Clover didn't remove any kext, no way.;)

Edited by vector sigma
damn the grammar corrector
  • Like 2
Just now, vector sigma said:

Well, but I hope is clear that Clover didn't remove kext, no way.;)

 

Yep. I thought it could have been a bug somewhere, with the post-isntall script. But also, I see no reason why the post-install script would even go into the kexts folder to begin with. That's why I thought I could just ask... Also, it was weird from the beginning, cause I use the same version of Clover on my systems. And this only happened on one of them. :)) That was my next step debugging this issue. But I totally missed the part where I used a custom script to see if Error 65 occurs... and that script also installed FakeSMC. And now that I think about it, I remember I was surprised it did that. :)) I never thought it will actually create issues later on. But yeah, everything that Slice said makes perfect sense now. 

 

Many thanks, guys. :)

  • Like 1

Hi Guys

 

Great Job :thumbsup_anim:

 

Thanks a lot @Slice @vector sigma  @Sherlocks @arsradu for theirs work and their remarks. I test two UDK2018 script: they work well on Mojave with Xcode 10 beta 5.

 

A small detail though:

 

  • the Clover logo would not appear in dark mode
  • I have a problem with the alphabetical order of UEFI drivers

Capture d’écran 2018-08-04 à 07.22.21.png

  • Like 1
5 hours ago, Matgen84 said:
  • I have a problem with the alphabetical order of UEFI drivers

 

This happens if you compile Clover on an apfs volume.  Alphabetical order is maintained if compiled on an HFS+ volume (but mandatory drivers show first, then optional drivers in "drivers-Off", in alphabetical order) eg

 

1159161715_CloverInstaller.png.95629320c6084ab88685e0df51aed675.png

  • Like 2
1 hour ago, fusion71au said:

 

This happens if you compile Clover on an apfs volume.  Alphabetical order is maintained if compiled on an HFS+ volume (but mandatory drivers show first, then optional drivers in "drivers-Off", in alphabetical order) eg

 

 

 

Thank you for this clarification, which gives the cause of the problem of alphabetical order under Mojave (apfs). :yes:

As on High Sierra, the drivers list includes the mandatory and then the additional drivers. These two groups are affected by the problem indicated on 10.14.

I don't know if there is a solution.

  • Thanks 1
7 hours ago, arsradu said:

I was also wondering how to order the drivers alphabetically in the installer.

 

34 minutes ago, Matgen84 said:

As on High Sierra, the drivers list includes the mandatory and then the additional drivers. These two groups are affected by the problem indicated on 10.14

 

2 hours ago, fusion71au said:

This happens if you compile Clover on an apfs volume.  Alphabetical order is maintained if compiled on an HFS+ volume (but mandatory drivers show first, then optional drivers in "drivers-Off", in alphabetical order) eg

Guys try r4636:)

  • Like 4

@Slice,

 

As I reported in the Clover problems thread, and as some others have noticed after trying to install recent Clover revisions in legacy mode, there was a regression introduced in r4541 which causes boot0 to fail to install in the MBR of the target disk.  You won't notice an issue unless you haven't installed boot0 on the disk before with older Clover revisions eg you are installing on a new disk or the disk has Windows MBR.

 

Noticed some typos and found that while dd for macOS fails to write to the disk unless it is unmounted, fdisk is OK.

 

if="${DEST_VOL}/usr/standalone/i386/${diskloader}" of=newMBR bs=1 count=440 conv=notrunc should be

if="${DEST_VOL}/usr/standalone/i386/${diskloader}" of=newMBR bs=440 count=1 conv=notrunc

 

"Writting" should be spelt as "Writing".  Modified code below fixes the problem and I have attached the edited postinstall script...

 

Spoiler

### Stage 0 ###
echo "Stage 0 - Writing ${diskloader} to ${bootdisk}" >> "$install_log"
#echo "$fdisk440 -u -f ${DEST_VOL}/usr/standalone/i386/${diskloader} -y ${bootdisk}" >> "$install_log"
#"$fdisk440" -u -f "${DEST_VOL}/usr/standalone/i386/${diskloader}" -y ${bootdisk}
echo dd if=${bootdisk} count=1 bs=512 of=/tmp/origMBR >> "$install_log"
dd if=${bootdisk} count=1 bs=512 of=/tmp/origMBR
echo cp /tmp/origMBR /tmp/newMBR >> "$install_log"
cp /tmp/origMBR /tmp/newMBR
echo dd if="${DEST_VOL}/usr/standalone/i386/${diskloader}" of=/tmp/newMBR bs=440 count=1 conv=notrunc >> "$install_log"
dd if="${DEST_VOL}/usr/standalone/i386/${diskloader}" of=/tmp/newMBR bs=440 count=1 conv=notrunc
echo fdisk -f /tmp/newMBR -u -y ${bootdisk} >> "$install_log"
fdisk -f /tmp/newMBR -u -y ${bootdisk}
echo "" >> "$install_log"

 

 

postinstall.zip

Clover_v2.4k_r4637_fixedMBR.pkg.zip

Edited by fusion71au
Fixed code to use macOS fdisk to write MBR
  • Like 1
  • Thanks 1
3 hours ago, fusion71au said:

Script may fail due to timing issues with un-mount, mounting drive

With both dd and fdisk440 you will get "Resource Busy"  and this is what cause the failure.

 

I can propose to use dd only for boot1f32:

/bin/dd if=/dev/rawdisk count=1 bs=512 of=/path/to/origbootsectors
/bin/dd if=/private/tmp/origbootsectors of=/path/to/boot1f32_copy skip=3 seek=3 bs=1 count=87 conv=notrunc
/bin/dd if=/path/to/boot1f32_copy  of=/dev/rawdisk count=1 bs=512

in other all other cases just use boot1-install:

/path/to/boot1-install -y -u -f /path/to/boot1xx /dev/rawdisk

 

where the -u option given used only if the target volume is not "/", otherwise -M. And additional task is to remount the Volume if that doesn't happen.

boot1-install is well aware of what to do and automatically..

 

But for boot0, isn't fdisk (not fdisk440) just enough since we have to write 512 bytes and not 440?

I mean, we can just save to a file from byte at index 440 to byte at index 511 and merge all with our first 440 bytes????. Just an idea so the stock fdisk will be just fine..

Il try that..

 

Edited by vector sigma
from byte at index 440 ;-)
  • Like 1
  • Thanks 1
20 hours ago, vector sigma said:

But for boot0, isn't fdisk (not fdisk440) just enough since we have to write 512 bytes and not 440?

I mean, we can just save to a file from byte at index 440 to byte at index 511 and merge all with our first 440 bytes????. Just an idea so the stock fdisk will be just fine..

Il try that..

 

Yep, standard fdisk works while target disk still mounted, as long as we pre-process the new MBR as a file - also saw @blackosxpost #10 in old Chameleon thread :)

 

Modified Clover package from my post above now works (tested by replacing MBR on USB disk with Windows MBR, then running Clover installer  ---> boot0af restored to MBR and legacy Clover boots again).

  • Like 1

@fusion71au, I made really tens and tens of tests installing boot sectors, and I have to admit that using dd is a pain. It worked once but mostly I get 'Resource Busy' even on un-monted devices, also using Terminal. I've rolled back fdisk440 in my working copy but this time is 64 bit only and is linked to 10.6 as minimum.

Please try and let my know, here work like a sharm:

 

Clover_r4637_fdisk440-64bit.pkg

 

P.S. during my tests I've understood also why many peoples claim that the pkg didn't records choices previously selected: the Distribution is set to not allowing external scripts and so java functions cannot be used to read the com.projectosx.clover.installer.plist. The attached pkg is able again.

 

@Slice, are you opposed to using fdisk440 again? Let me know because I'm ready for a commit..

  • Like 1
  • Thanks 1

I want to exclude fdisk440 because it will not compiled in 10.14 with Xcode10.

Is there any other possibility?

On 8/7/2018 at 1:22 PM, fusion71au said:

 

 

if="${DEST_VOL}/usr/standalone/i386/${diskloader}" of=newMBR bs=1 count=440 conv=notrunc should be

if="${DEST_VOL}/usr/standalone/i386/${diskloader}" of=newMBR bs=440 count=1 conv=notrunc

 

Is this change make the installer working?

1 hour ago, Badruzeus said:

I know. No need to reming me obvious things.

  • Like 1
42 minutes ago, Slice said:

I want to exclude fdisk440 because it will not compiled in 10.14 with Xcode10.

Compile fine here with all the Xcode I have, Xcode 10 included in 10.14. Just exluded the 32 bit part from the make file:


PROGRAM = fdisk440

SRCROOT := $(abspath $(CURDIR)/..)
SYMROOT := $(abspath $(CURDIR)/../../sym)
OBJROOT := $(SYMROOT)/build/$(PROGRAM)

INSTALL_DIR_NAME := utils
UTILSDIR := $(SYMROOT)/$(INSTALL_DIR_NAME)

DIRS_NEEDED := $(OBJROOT)

include ${SRCROOT}/Make.rules

LDFLAGS := $(LDFALGS) -mmacosx-version-min=10.6

SRCS := $(wildcard *.c)

OBJS =  $(SRCS:.c=.o64)
OBJS := $(addprefix $(OBJROOT)/, $(OBJS))

PROGRAM := $(addprefix $(UTILSDIR)/, $(PROGRAM))

all: $(PROGRAM)

$(PROGRAM): $(DIRS_NEEDED) $(OBJS)
	@mkdir -p $(UTILSDIR)
	@echo "\t[LD64] $(@F)_64"
	@$(CC) $(CFLAGS) $(LDFLAGS) $(DEFINES) -arch x86_64 -o $@_64 $(filter %.o64,$^)
	@echo "\t[LIPO] $@"
	@lipo -create -arch x86_64 $@_64 -output $@
	@strip $@
	@rm $@_64

install-local: $(PROGRAM)
	@sudo install -d -g 0 -o 0 /usr/local/bin /usr/local/man/man8
	@sudo install -psv -g 0 -o 0 $(PROGRAM) /usr/local/bin
	@sudo install -pv  -g 0 -o 0 fdisk440.8 /usr/local/man/man8

clean-local:
	@rm -f $(PROGRAM)
	@rm -rf $(OBJROOT) *~

 

fdisk440.zip

Edited by vector sigma
1 hour ago, Slice said:

I want to exclude fdisk440 because it will not compiled in 10.14 with Xcode10.

Is there any other possibility?

Is this change make the installer working?

 

The code below works for me and uses the built in macOS fdisk to write boot0 to MBR (no need to compile fdisk440).  Attached postinstall_fixed script...

 

### Stage 0 ###
echo "Stage 0 - Writing ${diskloader} to ${bootdisk}" >> "$install_log"
echo dd if=${bootdisk} count=1 bs=512 of=/tmp/origMBR >> "$install_log"
dd if=${bootdisk} count=1 bs=512 of=/tmp/origMBR
echo cp /tmp/origMBR /tmp/newMBR >> "$install_log"
cp /tmp/origMBR /tmp/newMBR
echo dd if="${DEST_VOL}/usr/standalone/i386/${diskloader}" of=/tmp/newMBR bs=440 count=1 conv=notrunc >> "$install_log"
dd if="${DEST_VOL}/usr/standalone/i386/${diskloader}" of=/tmp/newMBR bs=440 count=1 conv=notrunc
echo fdisk -f /tmp/newMBR -u -y ${bootdisk} >> "$install_log"
fdisk -f /tmp/newMBR -u -y ${bootdisk}
echo "" >> "$install_log"

 

2 hours ago, vector sigma said:

@fusion71au, I made really tens and tens of tests installing boot sectors, and I have to admit that using dd is a pain. It worked once but mostly I get 'Resource Busy' even on un-monted devices, also using Terminal. I've rolled back fdisk440 in my working copy but this time is 64 bit only and is linked to 10.6 as minimum.

Please try and let my know, here work like a sharm:

 

Clover_r4637_fdisk440-64bit.pkg

 

I agree - can't make dd work unless target disk/volume is unmounted, and this also causes timing problems for other parts of the Clover pkg installer.  Both fdisk440 or standard macOS fdisk allows installation to MBR while disk still mounted so I would be happy with either solution :).

postinstall_fixed.zip

  • Like 1

@fusion71au

Nice to use combination of dd and system fdisk. I think it will be best solution.

 

11 minutes ago, nms said:

Fdisk440 or not fdisk440?

 

There is the bug in "dd" case. All boot blocks must be written to /dev/rdisk*.

Someone can correct this? We use

dd if=${bootdisk}

so there will be calculation before to define {rbootdisk}.

  • Like 2
  • Thanks 1
×
×
  • Create New...