Jump to content

OS X El Capitan DP's builds!


924 posts in this topic

Recommended Posts

Updated to PB4 ok here with csr set to 0x1 in Clover. Slice's HWMonitor and Quicktime Screen Recording both worked fine after booting into the new system.

 

When I run "csrutil status" it tells me that SIP is disabled (although I've only enabled unsigned kexts). During verbose boot launchd says that SIP is enabled. 

Well, isn't it technically disabled for any value other than 0x00? I got SIP saying it's enabled in Recovery. But in System, it says it's disabled. And I didn't set anything in Clover. Also, updated to PB4 with no issues whatsoever.

Link to comment
Share on other sites

Actually, I spoke too soon. After a reboot I got the prompt for launching HWMonitor for the first time. Changed to 0x3 but that didn't fix it. So I changed to 0x67 and that still hasn't fixed it (although it did fix SpotlightNetHelper crashing).

 

With 0x1 or 0x3 launchd reported during boot that SIP was engaged. With it set to 0x67 that line didn't appear.

 

Reinstalled the update with 0x67 set and now HWMonitor loads on startup without any nag.

Link to comment
Share on other sites

Well, isn't it technically disabled for any value other than 0x00? I got SIP saying it's enabled in Recovery. But in System, it says it's disabled. And I didn't set anything in Clover. Also, updated to PB4 with no issues whatsoever.

How do you open the Assistant from the OS? They removed the binary in PB4: 

 

post-1090626-0-72070600-1438721341_thumb.png

Link to comment
Share on other sites

Sorry, which Assistant are you talking about? Feedback?

Security Configuration, the image is showing the contents. It can be found in /System/Library/CoreServices, up till PB3 it could be launched from there, now the binary is gone. 

Link to comment
Share on other sites

Security Configuration, the image is showing the contents. It can be found in /System/Library/CoreServices, up till PB3 it could be launched from there, now the binary is gone. 

Oh. Sorry. I only used it from Recovery. I didn't even know it can be accessed from the OS, as well. It can still be accessed from Recovery though... Maybe it's not supposed to be accessed from the OS itself...anymore. :)) Or maybe we'll see it in the next update. I can see it's still there. It just looks damaged. So...maybe it's a bug.

Link to comment
Share on other sites

Oh. Sorry. I only used it from Recovery. I didn't even know it can be accessed from the OS, as well. It can still be accessed from Recovery though... Maybe it's not supposed to be accessed from the OS itself...anymore. :)) Or maybe we'll see it in the next update. I can see it's still there. It just looks damaged. So...maybe it's a bug.

It looks damaged because there is no binary and no config.plist anymore. Accessed it from recovery, and i got the famous error that people had before.

I used Clover to set csr-active-config %01%00%00%00 (0x01), Which will allow only loading unsigned and edited kexts:.

 

 

This is the only thing that is allowed, all the other options in SIP should be enabled now, snapshot from my logs: 

Aug  4 23:18:11 p70 smd[343]: Could not remove job "com.apple.mrt": 150: Operation not permitted while System Integrity Protection is engaged
Aug  4 23:18:21 p70 com.apple.xpc.launchd[1] (com.apple.xpc.launchd.domain.system): Caller not allowed to perform action: smd.343, action = service removal, code = 150: Operation not permitted while System Integrity Protection is engaged, uid = 0, euid = 0, gid = 0, egid = 0, asid = 100000
Aug  4 23:18:21 p70 smd[343]: Could not remove job "com.apple.mrt": 150: Operation not permitted while System Integrity Protection is engaged
Aug  4 23:18:31 p70 com.apple.xpc.launchd[1] (com.apple.xpc.launchd.domain.system): Caller not allowed to perform action: smd.343, action = service removal, code = 150: Operation not permitted while System Integrity Protection is engaged, uid = 0, euid = 0, gid = 0, egid = 0, asid = 100000
Aug  4 23:18:31 p70 smd[343]: Could not remove job "com.apple.mrt": 150: Operation not permitted while System Integrity Protection is engaged
Aug  4 23:18:41 p70 com.apple.xpc.launchd[1] (com.apple.xpc.launchd.domain.system): Caller not allowed to perform action: smd.343, action = service removal, code = 150: Operation not permitted while System Integrity Protection is engaged, uid = 0, euid = 0, gid = 0, egid = 0, asid = 100000
Aug  4 23:18:41 p70 smd[343]: Could not remove job "com.apple.mrt": 150: Operation not permitted while System Integrity Protection is engaged

To answer your initial question :)

Link to comment
Share on other sites

It looks damaged because there is no binary and no config.plist anymore. Accessed it from recovery, and i got the famous error that people had before.

I used Clover to set csr-active-config %01%00%00%00 (0x01), Which will allow only loading unsigned and edited kexts:.

 

 

This is the only thing that is allowed, all the other options in SIP should be enabled now, snapshot from my logs: 

Aug  4 23:18:11 p70 smd[343]: Could not remove job "com.apple.mrt": 150: Operation not permitted while System Integrity Protection is engaged
Aug  4 23:18:21 p70 com.apple.xpc.launchd[1] (com.apple.xpc.launchd.domain.system): Caller not allowed to perform action: smd.343, action = service removal, code = 150: Operation not permitted while System Integrity Protection is engaged, uid = 0, euid = 0, gid = 0, egid = 0, asid = 100000
Aug  4 23:18:21 p70 smd[343]: Could not remove job "com.apple.mrt": 150: Operation not permitted while System Integrity Protection is engaged
Aug  4 23:18:31 p70 com.apple.xpc.launchd[1] (com.apple.xpc.launchd.domain.system): Caller not allowed to perform action: smd.343, action = service removal, code = 150: Operation not permitted while System Integrity Protection is engaged, uid = 0, euid = 0, gid = 0, egid = 0, asid = 100000
Aug  4 23:18:31 p70 smd[343]: Could not remove job "com.apple.mrt": 150: Operation not permitted while System Integrity Protection is engaged
Aug  4 23:18:41 p70 com.apple.xpc.launchd[1] (com.apple.xpc.launchd.domain.system): Caller not allowed to perform action: smd.343, action = service removal, code = 150: Operation not permitted while System Integrity Protection is engaged, uid = 0, euid = 0, gid = 0, egid = 0, asid = 100000
Aug  4 23:18:41 p70 smd[343]: Could not remove job "com.apple.mrt": 150: Operation not permitted while System Integrity Protection is engaged

To answer your initial question :)

Ok, that's all fine and dandy but what error are you talking about? It's not that famous to me lol. I was able to access Security Configuration UI from Recovery with no issues. I didn't try turning it off... But accessing it from Utilities menu, was not a problem for me. I guess the error appears after you try to turn it on/off?

And thank you for answering that question. :P

Link to comment
Share on other sites

Ok, that's all fine and dandy but what error are you talking about? It's not that famous to me lol. I was able to access Security Configuration UI from Recovery with no issues. I didn't try turning it off... But accessing it from Utilities menu, was not a problem for me. I guess the error appears after you try to turn it on/off?

And thank you for answering that question. :P

This error, which occurs when applying the settings: 

post-1090626-0-22708100-1438760175_thumb.png

  • Like 1
Link to comment
Share on other sites

This error, which occurs when applying the settings: 

attachicon.gifSchermafbeelding 2015-08-05 om 09.35.42.png

Got it now. Thanks. :)

 

Well, maybe it's just a bug. I don't know. If it doesn't affect the overall user experience, I wouldn't worry too much about it. Things will most likely change until the final version anyway. The error is probably caused by the missing stuff. Who knows?

 

Anyway, thanks for making it clear. :) Appreciated.

  • Like 2
Link to comment
Share on other sites

root:root doesnt work via terminal  (chown -Rf root:root S/L/E) : "chown: root: illegal group name"

 

its really weird here, the computer restarted before i could enter my password to login..maybe i disable it.

now i could login, i unplugged 1 usb-device, maybe that was the problem.

Link to comment
Share on other sites

Not sure this is new in PB4, but permissions in /L/E (and /S/L/E for that matter) are now root:root not root:wheel… :o

Really?

root:wheel is still used in DP6

 

EDIT: What does the following command print?

 

cat /etc/group | grep root

Here I get

 

$ cat /etc/group | grep root
wheel:*:0:root
daemon:*:1:root
kmem:*:2:root
sys:*:3:root
tty:*:4:root
operator:*:5:root
procview:*:8:root
procmod:*:9:root
staff:*:20:root
certusers:*:29:root,_jabber,_postfix,_cyrus,_calendar,_dovecot
admin:*:80:root
  • Like 2
Link to comment
Share on other sites

ls -l /Library/Extensions  or /System/Library/Extensions 

p70:~ Lex$ ls -l /Library/Extensions 
total 0
drwxr-xr-x  3 root  wheel  102 25 apr 14:43 ACPIBatteryManager.kext
drwxr-xr-x@ 3 root  wheel  102  9 jun 14:46 ACPISensors.kext
drwxr-xr-x  3 root  wheel  102 13 jun  2014 ACS6x.kext
drwxr-xr-x  3 root  wheel  102 26 aug  2013 ATTOCelerityFC8.kext
drwxr-xr-x  3 root  wheel  102 26 aug  2013 ATTOExpressSASHBA2.kext
drwxr-xr-x  3 root  wheel  102 26 aug  2013 ATTOExpressSASRAID2.kext
drwxr-xr-x  3 root  wheel  102 20 aug  2013 ArcMSR.kext
drwxr-xr-x@ 3 root  wheel  102 21 apr 20:44 AtherosE2200Ethernet.kext
drwxr-xr-x@ 3 root  wheel  102  9 jun 14:46 CPUSensors.kext
drwxr-xr-x  3 root  wheel  102  1 sep  2013 CalDigitHDProDrv.kext
drwxr-xr-x@ 3 root  wheel  102 11 jul 15:07 FakeSMC.kext
drwxr-xr-x  3 root  wheel  102 15 aug  2014 HighPointIOP.kext
drwxr-xr-x  3 root  wheel  102 15 aug  2014 HighPointRR.kext
drwxr-xr-x  3 root  wheel  102 28 apr  2014 PromiseSTEX.kext
drwxr-xr-x  3 root  wheel  102  5 jul  2014 SoftRAID.kext
drwxr-xr-x@ 3 root  wheel  102  4 aug 17:39 SystemAudioRecorder.kext
drwxr-xr-x@ 3 root  wheel  102 23 feb 20:10 VoodooPS2Controller.kext
p70:~ Lex$ 

PB4.

  • Like 1
Link to comment
Share on other sites

I think i found the problem here.. as soon i plug-in/remove or change any USB-Devices the Computer shut-down/restarts..do all of your USB-Devices work well @DP6?

normal usb/clover boot sticks etc. are working fine here

Link to comment
Share on other sites

With my GA-Z77X-UD5H I have no issues with all USB devices I've tested, but I have not used an iLok. I'm using stock Apple kexts (no injectors/patches - the port limit actually matches to the amount of USB ports I have) with DSDT edits for the AAPL properties (clock-id, current, etc).

Link to comment
Share on other sites

i have <key>AddClockID</key><true/> <key>FixOwnership</key><true/> <key>Inject</key><true/>

 

i got 3 kexts here which makes me wonder if i need them:   

-IOAHCIBlockSotrageInjector.kext ,  AHCIPortinjector.kext & ATAPortinjector.kext.

 

"loededkextmt.plist" in S/L/Caches/Startup in 10.11 DP6 shows entries which points to other partitions (why?), for example: 

 

<string>/Volumes/mainsys/System/Library/Extensions/IOUSBFamily.kext</string> (thats the 10.10/old yosemite)
 

Part of a Log from the last Kernel-Panic:

(...)

Kernel Extensions in backtrace:
         com.apple.iokit.IOFireWireFamily(4.5.8)[383CFA9F-31A4-37BD-B384-A3BCB14C1308]@0xffffff7f80cf9000->0xffffff7f80d7cfff
         com.RME.driver.FirefaceAudioDriver(3.25)[9B29A37D-6EAA-389A-B82D-29120FEA7D4A]@0xffffff7f80d7d000->0xffffff7f80d88fff
            dependency: com.apple.iokit.IOAudioFamily(203.7)[1AE06BD8-43D0-3780-9BFB-9E3434E4140D]@0xffffff7f80cc0000
            dependency: com.apple.iokit.IOFireWireFamily(4.5.8)[383CFA9F-31A4-37BD-B384-A3BCB14C1308]@0xffffff7f80cf9000

 

The Log from Kernel-Panics when i change/plugin or remove USB-Devices:

 

*** Panic Report ***
panic(cpu 2 caller 0xffffff7f80fce6aa): "IOUSBHostIOSource::_RESERVEDIOUSBHostIOSource10 called."@/Library/Caches/com.apple.xbs/Sources/xnu/xnu-3247.1.78/libkern/c++/OSMetaClass.cpp:1072
Backtrace (CPU 2), Frame : Return Address
0xffffff91f5d53990 : 0xffffff80002e7307
0xffffff91f5d53a10 : 0xffffff7f80fce6aa
0xffffff91f5d53a30 : 0xffffff7f80fe51c2
0xffffff91f5d53a60 : 0xffffff7f80fe6237
0xffffff91f5d53ad0 : 0xffffff80008b9358
0xffffff91f5d53b40 : 0xffffff7f80fe60c4
0xffffff91f5d53bb0 : 0xffffff7f80fca3ed
0xffffff91f5d53c10 : 0xffffff7f80fc0849
0xffffff91f5d53c70 : 0xffffff80008b9358
0xffffff91f5d53ce0 : 0xffffff7f80fca297
0xffffff91f5d53d40 : 0xffffff7f80fca4eb
0xffffff91f5d53da0 : 0xffffff7f80fcaa4d
0xffffff91f5d53df0 : 0xffffff80008e1abf
0xffffff91f5d53e10 : 0xffffff800039d8e9
0xffffff91f5d53e30 : 0xffffff80002eb903
0xffffff91f5d53e60 : 0xffffff80002cf448
0xffffff91f5d53ea0 : 0xffffff80002def75
0xffffff91f5d53f10 : 0xffffff80003c2c2a
0xffffff91f5d53fb0 : 0xffffff80003f6166
      Kernel Extensions in backtrace:
         com.apple.iokit.IOUSBFamily(900.4.1)[F54FAFF7-BA04-3855-981A-70E9C4F34F73]@0xffffff7f80fb3000->0xffffff7f81035fff
            dependency: com.apple.iokit.IOPCIFamily(2.9)[C36E2FF8-615E-3090-9F76-49580C84B282]@0xffffff7f80b60000
            dependency: com.apple.iokit.IOUSBHostFamily(1.0.1)[D2B617ED-47A1-30BA-BD25-F8F07AA98DA8]@0xffffff7f80f42000

BSD process name corresponding to current thread: licenseDaemon
Boot args: kext-dev-mode=1 rootless=0 slide=0

Mac OS version:
15A244d

Kernel version:
Darwin Kernel Version 15.0.0: Sun Jul 26 19:48:55 PDT 2015; root:xnu-3247.1.78~15/RELEASE_X86_64

__HIB  text base: 0xffffff8000100000
System model name: Macmini6,2 (Mac-F65AE981FFA204ED)

 

 

 

TheRacerMaster  thanks for the info. i think the system-id you use wouldnt work here since i need firewire (for audio). everything worked anyway, so probably i did something wrong. I just saw i use Macmini6,2, i will try MacMini7,1 and Clover 3252.
Link to comment
Share on other sites

Still having problems with HWMonitor on startup. It worked ok until I updated a kext in /L/E then on the next reboot it told me I was opening the app for the first time.

 

This is beta bug.

 

Dropbox, and other launch items or work, or display "first launch" dialog every login, or not launch  :)

Random....

And this is not hack bug, same situation on real MBA, iMac....

 

Waiting.... for next beta  :)

  • Like 4
Link to comment
Share on other sites

 

Really?

root:wheel is still used in DP6

 

EDIT: What does the following command print?

cat /etc/group | grep root

Here I get

$ cat /etc/group | grep root
wheel:*:0:root
daemon:*:1:root
kmem:*:2:root
sys:*:3:root
tty:*:4:root
operator:*:5:root
procview:*:8:root
procmod:*:9:root
staff:*:20:root
certusers:*:29:root,_jabber,_postfix,_cyrus,_calendar,_dovecot
admin:*:80:root

Yes. Really. At first I thought it was just me. But apparently not. You can't set permissions to kexts using root:wheel anymore. Works with 0:0 though. I don't remember getting an error.... At least not in DP4. But I might be wrong. Anyway, it wouldn't do what it's supposed to do. And that even in DP4.

Maybe it's just a bug... and not necessarily something they meant to do?

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
 Share

×
×
  • Create New...