Jump to content
fantomas

[pre-release] macOS Mojave

2,434 posts in this topic

Recommended Posts

Advertisement

I have Mojave installed on a test partition (only 40 GB).  The nature of my testing, like everyone else, requires us to grant admin privileges to the apps we are installing or testing or even the mounting of the EFI partition.  Because of this, I like to use a VERY short password to reduce the amount of typing and reduce the likelihood of mistakes in entering my password.  However, Mojave requires a much stronger password.  Any idea how to disable that feature?

Share this post


Link to post
Share on other sites

 

1 hour ago, Nightf4ll said:

Safari is very buggy in Mohave.. It even freezes my computer when I leave it open and it goes to sleep (specially with sites like youtube)

if you are using intel graphics you might need the lilu plugin shiki and run it with -shikibeta flag

Share this post


Link to post
Share on other sites
13 minutes ago, bronxteck said:

 

if you are using intel graphics you might need the lilu plugin shiki and run it with -shikibeta flag

no, RX480.. disabled the igpu. It just breaks after sleep though. Took me long enough to figure out that Safari was the cause lol, so thats why i wrote in here...

 

(although, haven't tested other browsers except chrome)

Edited by Nightf4ll

Share this post


Link to post
Share on other sites
4 hours ago, Pavo said:

Betas are exactly made for that, to test and see what works and what doesn’t, a easy wrong over the hard right isn’t always the best overall solution.

 

This really doesn't mean something for me, because of HACKINTOSH  first, beta for MAC yes, on Hackintosh you do everything that will work for your hack, this is the only reason that push you to subscribe here and on other forums!

 

Developers here are known, they do the hard work, but don't put your own idea to let me gob it, sorry, but it's like that i see. Everyone give the help, from what he know, based on he's experience and trying, doing and other things! 

 

Rolling back is solution for me and for everyone, and i confirm that its not wrong or hard wrong like you said, i don't want to trust what you say, and i don't want to waste my time to give a proof, just like the previous post.

 

The proofs exist here at insanelymac and many other website

 

And I didn't understand why you made this SSDT like that, while you just have to put _DSM method simply, and the other thing the _ADR, Zero, and above that in the definitionblock the zeros, without forgetting the Scope for HDEF under it Device HDEF, this is the complete hard wrong thing i've seen I'll post it for everyone to see it, so here it is:

 

DefinitionBlock ("", "SSDT", 1, "Pavo", "HDEF", 0x00000000) #this should be uper than DSDT or SSDT's that are on the firmware 0x00002000
{
    External (_SB_.PCI0.HDEF, DeviceObj)    // (from opcode)

    Scope (\_SB.PCI0.HDEF)
    {
        Device (HDEF) #this should not be here
        {
            Name (_ADR, Zero)  // _ADR: #Address this one also should not be here
            Method (_DSM, 4, NotSerialized)  // _DSM: Device-Specific Method
            {
                If (LEqual (Arg2, Zero))
                {
                    Return (Buffer (One)
                    {
                         0x03                                           
                    })
                }

                Return (Package (0x10)
                {
                    "AAPL,slot-name", 
                    "Built In", 
                    "name", 
                    "Audio Controller", 
                    "model", 
                    Buffer (0x27)
                    {
                        "Apple High Definition Audio Controller"
                    }, 

                    "device_type", 
                    Buffer (0x11)
                    {
                        "Audio Controller"
                    }, 

                    "alc-layout-id", 
                    Buffer (0x04)
                    {
                         0x01, 0x00, 0x00, 0x00                         
                    }, 

                    "MaximumBootBeepVolume", 
                    Buffer (One)
                    {
                         0x01                                           
                    }, 

                    "PinConfigurations", 
                    Buffer (Zero){}, 
                    "hda-gfx", 
                    Buffer (0x0A)
                    {
                        "onboard-1"
                    }
                })
            }
        }
    }
}

Why putting External _SB_.PCI0.HDEF , and Scope (\_SB.PCI0.HDEF), and Device (HDEF), do you think that asl don't understand or what?

The simple thing and normal is External (_SB_.PCI0, DeviceObj) and Scope (\_SB.PCI0.HDEF) then start your _DSM

But why putting _ADR, Zero while it is useless

 

here's example from ACPI table inside firmware:

 

Example.thumb.png.77e05a000821c2b7b346b2dd62cfc838.png

 

The SSDT's have always upper numbers that DSDT, you put 0

 

This is for me the hard wrong, but never what i uploaded here

And i don't want you to reply, because i don't want to view another story

Edited by ammoune78

Share this post


Link to post
Share on other sites
4 hours ago, ammoune78 said:

 

I use quickest solution for the MAN, your solution have to wait other DEVELOPERS to post final things as i see, rolling back AppleHDA or Atheros kext helped a lot of people, have you a solution for that instead, or what can you say Hhhh

pavo is right dont ever use anything from past macos it can cause more issues than help as its done in the past its honestly a STUPID thing is mention at all wait for the devs thats why we have em 

Share this post


Link to post
Share on other sites
14 hours ago, TypeThree said:

That sounds really good... Does it load the apfs from the installdrive, e.g from /usr/standalone/i386/ or is it a different init? Do you have or remember a source by any chance?

 

The file has very little code and the ffs version does not have a file subtype so it doesn't get recognized as a freeform, driver, etc. Are you sure that it works like this? Just being curious:huh: 

 


extract zip into its own folder  and run < OZMTool --ozmcreate --ffs (the folder you made) --input (your current rom) --out (new name)

 

HBP

Share this post


Link to post
Share on other sites
2 hours ago, mnfesq said:

I have Mojave installed on a test partition (only 40 GB).  The nature of my testing, like everyone else, requires us to grant admin privileges to the apps we are installing or testing or even the mounting of the EFI partition.  Because of this, I like to use a VERY short password to reduce the amount of typing and reduce the likelihood of mistakes in entering my password.  However, Mojave requires a much stronger password.  Any idea how to disable that feature?

open terminal 

$passwd

it will ask for a new password

Give it a new password

give it a new password

 

then your password should be updated to short pass.

 

my favorite short pass is @sk

 

HBP

Share this post


Link to post
Share on other sites
5 hours ago, WarDoc said:

pavo is right dont ever use anything from past macos it can cause more issues than help as its done in the past its honestly a STUPID thing is mention at all wait for the devs thats why we have em 

 

I clearly understand the meaning of your quote, others know that, just few days ago, :whistle:, do you remember? As you should "STOP BAD WORDS", this is my meaning

21 hours ago, HBP said:

Woot!!! I am up and running with Ozmosis AND APFS!!!

the Attached APFS.FFS is APFS.EFI Jumpstart from High Sierra. I do not remember who made it or where the Credit is due, I have checked that it still jumpstarts the current APFS.

 

Ozmosis can one again be used.  Kext injection doesn't seem to be working so I had to add Fakesmc to the System folder.

 

HBP

APFS.ffs.zip

 

This one doesn't worked, in UEFITool it shows under Subtype "Unknown" :huh:

Edited by ammoune78

Share this post


Link to post
Share on other sites
30 minutes ago, HBP said:

extract zip into its own folder  and run < OZMTool --ozmcreate --ffs (the folder you made) --input (your current rom) --out (new name)

 

HBP

 

This "ffs"?

$ xxd apfs.ffs
00000000: 6270 6c69 7374 3030 d301 0203 0405 065c  bplist00.......\
00000010: 4e53 5552 4c4e 616d 654b 6579 5f10 104e  NSURLNameKey_..N
00000020: 5355 524c 4669 6c65 5369 7a65 4b65 795f  SURLFileSizeKey_
00000030: 1018 4e53 5552 4c46 696c 6552 6573 6f75  ..NSURLFileResou
00000040: 7263 6554 7970 654b 6579 5841 5046 532e  rceTypeKeyXAPFS.
00000050: 6666 7311 0f41 5f10 1c4e 5355 524c 4669  ffs..A_..NSURLFi
00000060: 6c65 5265 736f 7572 6365 5479 7065 5265  leResourceTypeRe
00000070: 6775 6c61 7208 0f1c 2f4a 5356 0000 0000  gular.../JSV....
00000080: 0000 0101 0000 0000 0000 0007 0000 0000  ................
00000090: 0000 0000 0000 0000 0000 0075            ...........u

 

Share this post


Link to post
Share on other sites
3 hours ago, MorenoAv said:

Thanks Pavo, I really appreciate your help... 

OK still not using the newer Lilu.kext or AppleALC.kext that I provided for you.

bootlog.log

6:506  0:008  Extra kext: EFI\CLOVER\kexts\Other\AppleALC.kext (v.1.2.6)
7:309  0:022  Extra kext: EFI\CLOVER\kexts\Other\Lilu.kext (v.1.2.3)

This happens in kernel.log when you use an older version of these kext

2018-06-12 18:55:04.472178+0100 0x73       Default     0x0                  0      0    kernel: (kernel) Lilu:  config @ automatically disabling on an unsupported operating system
2018-06-12 18:55:04.472182+0100 0x73       Default     0x0                  0      0    kernel: (kernel) Lilu:    init @ found a disabling argument or no arguments, exiting

Lilu is 100% required to load in order for AppleALC.kext to load, with you using an older version of Lilu + AppleALC the new all-layout-id in the SSDT will never work. Please replace the Lilu.kext and AppleALC.kext in EFI/Clover/kexts/Other folder with the ones I provided for you. If you don't have audio again after using those newer kext re-run the RunMe app again with those kext installed in that locate so I can verify that you are using the correct kext.

Share this post


Link to post
Share on other sites
23 minutes ago, HBP said:

open terminal 

$passwd

it will ask for a new password

Give it a new password

give it a new password

 

then your password should be updated to short pass.

 

my favorite short pass is @sk

 

HBP

 

I was hoping for 2-character password -- mf, my initials.  Unfortunately, I got this:

 

passwd: authentication token failure

 

However, it appears that I can, at least, get a 4-digit "PIN" code to work.  That's good enough, I guess.

Share this post


Link to post
Share on other sites
1 hour ago, ammoune78 said:

 

This really doesn't mean something for me, because of HACKINTOSH  first, beta for MAC yes, on Hackintosh you do everything that will work for your hack, this is the only reason that push you to subscribe here and on other forums!

 

Developers here are known, they do the hard work, but don't put your own idea to let me gob it, sorry, but it's like that i see. Everyone give the help, from what he know, based on he's experience and trying, doing and other things! 

 

Rolling back is solution for me and for everyone, and i confirm that its not wrong or hard wrong like you said, i don't want to trust what you say, and i don't want to waste my time to give a proof, just like the previous post.

 

The proofs exist here at insanelymac and many other website

 

And I didn't understand why you made this SSDT like that, while you just have to put _DSM method simply, and the other thing the _ADR, Zero, and above that in the definitionblock the zeros, without forgetting the Scope for HDEF under it Device HDEF, this is the complete hard wrong thing i've seen I'll post it for everyone to see it, so here it is:

 


DefinitionBlock ("", "SSDT", 1, "Pavo", "HDEF", 0x00000000) #this should be uper than DSDT or SSDT's that are on the firmware 0x00002000
{
    External (_SB_.PCI0.HDEF, DeviceObj)    // (from opcode)

    Scope (\_SB.PCI0.HDEF)
    {
        Device (HDEF) #this should not be here
        {
            Name (_ADR, Zero)  // _ADR: #Address this one also should not be here
            Method (_DSM, 4, NotSerialized)  // _DSM: Device-Specific Method
            {
                If (LEqual (Arg2, Zero))
                {
                    Return (Buffer (One)
                    {
                         0x03                                           
                    })
                }

                Return (Package (0x10)
                {
                    "AAPL,slot-name", 
                    "Built In", 
                    "name", 
                    "Audio Controller", 
                    "model", 
                    Buffer (0x27)
                    {
                        "Apple High Definition Audio Controller"
                    }, 

                    "device_type", 
                    Buffer (0x11)
                    {
                        "Audio Controller"
                    }, 

                    "alc-layout-id", 
                    Buffer (0x04)
                    {
                         0x01, 0x00, 0x00, 0x00                         
                    }, 

                    "MaximumBootBeepVolume", 
                    Buffer (One)
                    {
                         0x01                                           
                    }, 

                    "PinConfigurations", 
                    Buffer (Zero){}, 
                    "hda-gfx", 
                    Buffer (0x0A)
                    {
                        "onboard-1"
                    }
                })
            }
        }
    }
}

Why putting External _SB_.PCI0.HDEF , and Scope (\_SB.PCI0.HDEF), and Device (HDEF), do you think that asl don't understand or what?

The simple thing and normal is External (_SB_.PCI0, DeviceObj) and Scope (\_SB.PCI0.HDEF) then start your _DSM

But why putting _ADR, Zero while it is useless

 

here's example from ACPI table inside firmware:

 

Example.thumb.png.77e05a000821c2b7b346b2dd62cfc838.png

 

The SSDT's have always upper numbers that DSDT, you put 0

 

This is for me the hard wrong, but never what i uploaded here

And i don't want you to reply, because i don't want to view another story

I am not even gonna explain to you where you are wrong in this post, gonna allow you to continue to have your systems wrong. Its not worth my time or effort. 

Share this post


Link to post
Share on other sites

 

here is where the originalAPFS.EFI jumpstarted I posted came from, I simply extracted the one from my ROM instead of taking the time to locate the original post.

 

HBP

 

Share this post


Link to post
Share on other sites
11 minutes ago, HBP said:

 

here is where the originalAPFS.EFI jumpstarted I posted came from, I simply extracted the one from my ROM instead of taking the time to locate the original post.

 

HBP

 

 

You deleted the one I inserted in the rom, and used this, and now you're able to boot APFS Volumes such as Mojave and High Sierra? Is it right?

Share this post


Link to post
Share on other sites
34 minutes ago, Pavo said:

OK still not using the newer Lilu.kext or AppleALC.kext that I provided for you.

bootlog.log


6:506  0:008  Extra kext: EFI\CLOVER\kexts\Other\AppleALC.kext (v.1.2.6)
7:309  0:022  Extra kext: EFI\CLOVER\kexts\Other\Lilu.kext (v.1.2.3)

This happens in kernel.log when you use an older version of these kext


2018-06-12 18:55:04.472178+0100 0x73       Default     0x0                  0      0    kernel: (kernel) Lilu:  config @ automatically disabling on an unsupported operating system
2018-06-12 18:55:04.472182+0100 0x73       Default     0x0                  0      0    kernel: (kernel) Lilu:    init @ found a disabling argument or no arguments, exiting

Lilu is 100% required to load in order for AppleALC.kext to load, with you using an older version of Lilu + AppleALC the new all-layout-id in the SSDT will never work. Please replace the Lilu.kext and AppleALC.kext in EFI/Clover/kexts/Other folder with the ones I provided for you. If you don't have audio again after using those newer kext re-run the RunMe app again with those kext installed in that locate so I can verify that you are using the correct kext.

The problem is that I have replaced the kexts with the ones you provided, and that is the problem, I replace the kexts and then they don't load... I don't know why...

Share this post


Link to post
Share on other sites

replaced again the kexts, the config.plist and the DSDT-HDEF.aml, and run the app RUNMe again... see the dump...

I hope that the app have run till the end, it was much flicker and unstable...

 

iMac de AC.ioreg

 

Now it run till the end, thanks the gods... 

Send me iMac-de-AC.lan.zip

Edited by MorenoAv

Share this post


Link to post
Share on other sites
18 minutes ago, MorenoAv said:

replaced again the kexts, the config.plist and the DSDT-HDEF.aml, and run the app RUNMe again... see the dump...

I hope that the app have run till the end, it was much flicker and unstable...

 

iMac de AC.ioreg

 

Now it run till the end, thanks the gods... 

Send me iMac-de-AC.lan.zip

if u can/need/want inject via ssdt, remove _DSM into device HDEF and inject only _DSM

DSDT.aml.zip

 

@Pavo, now need "alc-layout-id" instead "layout-id"?

 

my alc892 with layout-id 7 stay work normal

 

 

Share this post


Link to post
Share on other sites
57 minutes ago, ammoune78 said:

 

You deleted the one I inserted in the rom, and used this, and now you're able to boot APFS Volumes such as Mojave and High Sierra? Is it right?

right, APFS now works, 

I can send you a copy of my ROM to look at on the side channel you have been using to help me.

Share this post


Link to post
Share on other sites

Hi MaLd0n,

I don't need, want inject via ssd... I don't seem to make the darned thing to work, and Pavo suggested via ssdt... for me is equal all I want is having sound...

Thanks

Share this post


Link to post
Share on other sites
9 minutes ago, MaLd0n said:

if u can/need/want inject via ssdt, remove _DSM into device HDEF and inject only _DSM

DSDT.aml.zip

 

@Pavo, now need "alc-layout-id" instead "layout-id"?

 

my alc892 with layout-id 7 stay work normal

 

 

Vit9696 stated that you can still use layout-id but AppleALC will auto convert it to alc-layout-id, but the new way for layout-id in SSDT/DSDT is alc-layout-id.

26 minutes ago, MorenoAv said:

replaced again the kexts, the config.plist and the DSDT-HDEF.aml, and run the app RUNMe again... see the dump...

I hope that the app have run till the end, it was much flicker and unstable...

 

iMac de AC.ioreg

 

Now it run till the end, thanks the gods... 

Send me iMac-de-AC.lan.zip

I dunno how you are doing it but you are not using the kext that I made for you, the boot.log tells exactly what version of the kext that Clover is injecting. Your boot.log again says:

7:249  0:008  Extra kext: EFI\CLOVER\kexts\Other\AppleALC.kext (v.1.2.6)
8:052  0:022  Extra kext: EFI\CLOVER\kexts\Other\Lilu.kext (v.1.2.3)

My boot.log shows:

7:449  0:028  Extra kext: EFI\CLOVER\kexts\Other\AppleALC.kext (v.1.2.8)
8:170  0:720  Extra kext: EFI\CLOVER\kexts\Other\Lilu.kext (v.1.2.4)

Again here attached are the exact kext that I am using, unzip and replace them again with these and reboot and re-run RunMe app. Upload file

Archive.zip

Edited by Pavo

Share this post


Link to post
Share on other sites
20 minutes ago, Pavo said:

Vit9696 stated that you can still use layout-id but AppleALC will auto convert it to alc-layout-id, but the new way for layout-id in SSDT/DSDT is alc-layout-id.

I dunno how you are doing it but you are not using the kext that I made for you, the boot.log tells exactly what version of the kext that Clover is injecting. Your boot.log again says:


7:249  0:008  Extra kext: EFI\CLOVER\kexts\Other\AppleALC.kext (v.1.2.6)
8:052  0:022  Extra kext: EFI\CLOVER\kexts\Other\Lilu.kext (v.1.2.3)

My boot.log shows:


7:449  0:028  Extra kext: EFI\CLOVER\kexts\Other\AppleALC.kext (v.1.2.8)
8:170  0:720  Extra kext: EFI\CLOVER\kexts\Other\Lilu.kext (v.1.2.4)

Again here attached are the exact kext that I am using, unzip and replace them again with these and reboot and re-run RunMe app. Upload file

Archive.zip

here it is one Moore time, the dump... but is the second time that I replace the kexts, and they don't load and apparently don't replace the others, and that is the problem... 

Send me iMac-de-AC.lan.zip

Edited by MorenoAv

Share this post


Link to post
Share on other sites
5 minutes ago, MorenoAv said:

here it is one Moore time, the dump... but is the second time that I replace the kexts, and they don't load and apparently don't replace the others, and that is the problem... 

Send me iMac-de-AC.lan.zip

Ok.... you are doing something totally wrong with replacing the kext, I am done.

Share this post


Link to post
Share on other sites

i understand Pavo, sorry for all the trouble, but replacing kexts is only copy and replace kexts and is all I do... I can't do it wrong.

I think the real culprit is the reason behind the impossibility of replacing this kexts with another, that lies the real problem, the reason I don't know what is...

Thanks 

Edited by MorenoAv

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.

  • Recently Browsing   0 members

    No registered users viewing this page.

Announcements

×