ammoune78 Posted June 12, 2018 Share Posted June 12, 2018 (edited) 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: 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 June 12, 2018 by ammoune78 1 1 Link to comment Share on other sites More sharing options...
MattsCreative Posted June 12, 2018 Share Posted June 12, 2018 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 1 Link to comment Share on other sites More sharing options...
HBP Posted June 12, 2018 Share Posted June 12, 2018 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 extract zip into its own folder and run < OZMTool --ozmcreate --ffs (the folder you made) --input (your current rom) --out (new name) HBP Link to comment Share on other sites More sharing options...
HBP Posted June 12, 2018 Share Posted June 12, 2018 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 1 Link to comment Share on other sites More sharing options...
v-volodi Posted June 12, 2018 Share Posted June 12, 2018 Any fix for Intel HD 3000 SandyBridge? Link to comment Share on other sites More sharing options...
ammoune78 Posted June 12, 2018 Share Posted June 12, 2018 (edited) 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, , 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" Edited June 13, 2018 by ammoune78 1 Link to comment Share on other sites More sharing options...
cecekpawon Posted June 12, 2018 Share Posted June 12, 2018 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 1 Link to comment Share on other sites More sharing options...
Pavo Posted June 12, 2018 Share Posted June 12, 2018 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. Link to comment Share on other sites More sharing options...
mnfesq Posted June 12, 2018 Share Posted June 12, 2018 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. Link to comment Share on other sites More sharing options...
Pavo Posted June 12, 2018 Share Posted June 12, 2018 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: 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. 1 Link to comment Share on other sites More sharing options...
HBP Posted June 12, 2018 Share Posted June 12, 2018 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 1 Link to comment Share on other sites More sharing options...
ammoune78 Posted June 12, 2018 Share Posted June 12, 2018 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? 1 Link to comment Share on other sites More sharing options...
MorenoAv Posted June 12, 2018 Share Posted June 12, 2018 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... Link to comment Share on other sites More sharing options...
MorenoAv Posted June 12, 2018 Share Posted June 12, 2018 (edited) 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 June 12, 2018 by MorenoAv Link to comment Share on other sites More sharing options...
MaLd0n Posted June 12, 2018 Share Posted June 12, 2018 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 1 Link to comment Share on other sites More sharing options...
HBP Posted June 12, 2018 Share Posted June 12, 2018 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. 1 Link to comment Share on other sites More sharing options...
MorenoAv Posted June 12, 2018 Share Posted June 12, 2018 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 1 Link to comment Share on other sites More sharing options...
Pavo Posted June 12, 2018 Share Posted June 12, 2018 (edited) 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 June 12, 2018 by Pavo 1 Link to comment Share on other sites More sharing options...
MorenoAv Posted June 12, 2018 Share Posted June 12, 2018 (edited) 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 June 12, 2018 by MorenoAv Link to comment Share on other sites More sharing options...
Pavo Posted June 12, 2018 Share Posted June 12, 2018 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. Link to comment Share on other sites More sharing options...
MorenoAv Posted June 12, 2018 Share Posted June 12, 2018 (edited) 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 June 12, 2018 by MorenoAv Link to comment Share on other sites More sharing options...
Pavo Posted June 12, 2018 Share Posted June 12, 2018 Just now, MorenoAv said: 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 Thanks Then you are replacing the kext and not rebooting to allow them to load the new kext because your RunMe dump is still showing the older kext are loading, so either you are doing that or you are copying and pasting the kext that I gave you into some other folder because they are not getting loaded, not even getting looked at to get loaded by Clover. So are you copying and pasting the kext and not rebooting your machine before re-running the ReunMe app? Link to comment Share on other sites More sharing options...
MorenoAv Posted June 12, 2018 Share Posted June 12, 2018 (edited) No, i replace the kexts in clover/kexts/other... then reboot an run de runme app, and then send the results... this is what I do evrytime, and the result is the kexts don't load... The only thing that I do is running kext utility to repair permissions, but not this last time... Edited June 12, 2018 by MorenoAv Link to comment Share on other sites More sharing options...
Pavo Posted June 12, 2018 Share Posted June 12, 2018 3 minutes ago, MorenoAv said: No, i replace the kexts in clover/kexts/other... then reboot an run de runme app, and then send the results... this is what I do evrytime, and the result is the kexts don't load... The only thing that I do is running kext utility to repair permissions, but not this last time... Why are you running kext utility to repair permissions when you are not touching S/L/E or L/E, you should not be touching those at all. kext utility only effects S/L/E and L/E not EFI/Clover/kexts/Other Link to comment Share on other sites More sharing options...
MorenoAv Posted June 12, 2018 Share Posted June 12, 2018 You are right, but the last time, I didn't do it... 1 Link to comment Share on other sites More sharing options...
Recommended Posts