Jump to content
fantomas1

[pre-release] macOS Mojave

2,463 posts in this topic

Recommended Posts

33 minutes ago, Pavo said:

Yes this is the reason why I quoted you, you should never use older macOS version of the drivers unless its 100% absolutely needed. I wanted him to keep trying with the small modifications that I made in order to narrow down the real cause of his issue, if it is not supported anymore then yes using an older driver would be the next logical step. But you don't just jump to the very last step before debugging and narrowing it down. This helps the developers determine what exact drivers that are not 100% supported.

 

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

Edited by ammoune78

Share this post


Link to post
Share on other sites
Advertisement
1 minute 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

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.

Share this post


Link to post
Share on other sites

After re install and implementation of your suggestions Pavo I tried to run the RUNMe App but it gave error, and never finishes...

That was my first thought, but because of the error, I didn't post it...

I' m all for experimenting all and if I remember correctly this is the first time that an macOS is that difficult to solve an problem, but we continue to try... 

Edited by MorenoAv

Share this post


Link to post
Share on other sites
Just now, MorenoAv said:

After re install and implementation of your suggestions Pavo I tried to run the RUNMe App but it gave error, and never finishes...

That was my first thought, but because of the error, I didn't post it...

Yes the Runme app is very unstable and buggy on Mojave, but if you allow it permissions it should work better. In the process of trying make it work better.

Share this post


Link to post
Share on other sites

I gave all the permissions that the app requested, but in the end, didn't work... but I'll try again and again... 

Share this post


Link to post
Share on other sites
Just now, MorenoAv said:

I gave all the permissions that the app requested, but in the end, didn't work... but I'll try again and again... 

Yeah I had to run it a few times to make it complete

Share this post


Link to post
Share on other sites

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
Guest
This topic is now closed to further replies.

  • Recently Browsing   0 members

    No registered users viewing this page.

×