Jump to content

Versions bêtas : OS X 10.11


fantomas
 Share

162 posts in this topic

Recommended Posts

Installée après avoir un peu galéré. Apparemment, l'injection des kexts avec Clover ne fonctionne plus s'ils sont dans l'EFI ?

 

En tout cas, en les mettant dans /Library/Extensions ou dans /S/L/E et après avoir réparer les permissions et reconstruit le cache, ça fonctionne :D.

 

Heureusement que j'ai accès à Yosemite sur la même machine pour faire tout ça… :).

 

 

10.11_15a226f.png

Link to comment
Share on other sites

10.11 démarre parfaitement avec Enoch r2725 et r2737. Je peux repartir sur mon mode opérationnel habituel.  :yes:

 

Pas besoin de l'option kext-dev-mode=1 pour utiliser des kexts non-Apple, mais l'option rootless=0 est requise si on veut modifier des fichiers clés, comme des kexts dans /S/L/E par exemple.

 

Tu as essayé en laissant les kexts dans Extra/Extensions ? J'imagine que c'est le même problème qu'avec ceux dans EFI/Clover/kexts/10.11 mais je voudrais vérifier :D

 

Sinon, il me semble que les dernières versions d'Enoch incluent en standard kext-dev-mode=1 et rootless=0 :unsure:...

Link to comment
Share on other sites

Je ne saurais être catégorique pour kext-dev-mode, mais rootless=0 n'est pas/plus en standard/par défaut, non. Tu peux faire l'essai de redémarrer sans l'option et de mettre /S/L/E/AppleHDA.kext à la poubelle; tu nous diras le résultat...

 

Pour les kexts dans /E/E, ça n'a pas marché lors de mes 1ers essais: j'y avais laissé FakeSMC et 10.11 ne démarrait pas, jusqu'à ce que je déplace le kext dans /S/L/E ou /L/E. Cela semble être devenu spécifique à 10.11 DP5 mais, à titre de comparaison, pas de souci à conserver FakeSMC dans /E/E sous 10.10.5 DP + Chameleon r2700.

 

Ah OK pour rootless=0. J'avais essayé avec les toutes premières versions de Chameleon proposées ici et c'était le cas à l'époque. En tout cas, c'est ce qu'indiquait le mode verbose car je n'ai pas réussi à démarrer une installation avec cette version. Une clé d'installation oui mais un disque, jamais :wacko:. Je pouvais démarrer sans aucun bootflags :D.

 

Pour E/E, ce n'est pas étonnant et en fait c'est le contraire qui l'aurait été car ça vient très probablement de l'OS et pas des bootloaders. Ce qui m'inquiète d'ailleurs un peu pour l'avenir. Non pas que ce soit réellement gênant de devoir installer les kexts dans L/E ou S/L/E mais bon, au moins on savait à peu près où se trouvait chaque kexts… Là, on va se retrouver avec un fourre-tout :D

Link to comment
Share on other sites

pour le rootless=0 inclus pas défaut, il fut le cas dans les versions stables de chameleon supportant El Capitan

 

mais Pike a suggeré que cela ne soit plus le cas, car rootless=0 est une porte grand ouverte aux attaques néfastes

 

si non, kext-dev-mode=1 est déjà implémanté dans rootless=0, plus la peine de l'ajouter au boot.

 

 

EDIT :

 

PB2 était aussi de sortie !   ^_^

Link to comment
Share on other sites

Hé bé, ça va vite! La DB5 est déjà dans les bacs...

 

Ouais ben ne courrez pas l'installer ! Aucun kext "untrusted" ne se chargera si vous avez le malheur de reconstruire le cache… Et ce, même avec rootless=0, les kexts dans /L/E ou /S/L/E et la reconstruction du cache depuis Yosemite.

  • Like 1
Link to comment
Share on other sites

OK. En passant par la clé d'install de la PB1 :blink:, j'ai pu désactiver Enforce System Integrity Protection et maintenant ça boot :thumbsup_anim: .

 

Mais j'arrête de toucher au cache maintenant en attendant d'avoir une solution plus simple et plus rapide ;).

Link to comment
Share on other sites

Slt,

 

Avec la dernière version de clover et dp5 tout fonctionne nickel en mettant les kexts dans L/E.

J'ai du mal à comprendre tous les problèmes que je lis sur IM.

Pas de soucis de rebuild cache.

 

Fred

Link to comment
Share on other sites

@Hervé :

 

En fait je ne comprends rien à ce qui se passe réellement. Pour l'installation, pas de soucis particulier avec Clover à part le fait qu'il m'a fait le coup de "je m'installe mais en fait non". La deuxième tentative était la bonne. Les kexts étaient dans /S/L/E et tout fonctionnait nickel. Par réflexe, j'ai lancé ce script que j'utilise depuis Yosemite et qui fonctionnait très bien avec les DPs et les PBs jusqu'ici :

#!/bin/bash
#
sudo chmod -R 755 /Library/Extensions
sudo chown -R 0:0 /Library/Extensions
sudo chmod -R 755 /System/Library/Extensions
sudo chown -R 0:0 /System/Library/Extensions
sudo touch /System/Library/Extensions
sudo kextcache -Boot -U /

Je l'ai juste modifié pour qu'il prenne en compte le dossier /Library/Extensions.

 

Et là, effectivement, je me suis mangé des Operation not permited à la pelle alors que rootless=0 était bien dans mes boot-args.

 

J'ai ensuite essayé de virer le kernelcache & le prelinkedkernel depuis Yosemite. Pas de boot.

J'ai essayé le RebuildCache que Fred avait donné ici en pointant la partition El Capitan. Pas de boot.

J'ai déplacé les kexts dans /L/E plutôt que /S/L/E. Pas de boot.

J'ai finalement démarré sur la clé, décoché Enforce SIP et redémarré. Boom, l'OS s'est lancé sans broncher et avec tous les kexts chargés.

 

J'ai voulu faire le malin et j'ai réessayé de reconstruire le cache en pensant que le SIP étant à priori désactivé, il n'y avait plus de raison qu'il me rebalance des Operation not permitted. Ben si, rebelote…

 

Depuis, j'ai refait les mêmes manips mais rien à faire, ça ne veut plus démarrer ou alors, parfois, ça démarre mais qu'avec FakeSMC. Du coup, je n'ai ni clavier/souris, ni réseau ni son (mais bon, ça on s'en fout).

 

Maintenant, je vais vite essayé ta méthode au niveau de la réparation des permissions :D Merci pour l'info !

 

@Fred :

 

Avec la version 3251, j'ai toujours le même soucis, que les kexts soient dans /S/L/E ou /L/E. Où est-ce que ça pourrait coincer ?

Link to comment
Share on other sites

Clover Configurator, n'est pas encore prêt.

 

 

<key>RtVariables</key>
<dict>
 
<key>CsrActiveConfig</key>
<string>0x67</string>
<key>BooterConfig</key>
<string>0x28</string>

 

</dict>
  • Like 1
Link to comment
Share on other sites

 

Clover Configurator, n'est pas encore prêt.

 

 

<key>RtVariables</key>
<dict>
 
<key>CsrActiveConfig</key>
<string>0x67</string>
<key>BooterConfig</key>
<string>0x28</string>

 

</dict>

 

 

Merci ! :thumbsup_anim:

 

Ça fonctionne en mixant vos deux techniques : RtVariables + reconstruction des permissions avec -Rf ! Bravo les gars !

 

 

Ici, on constate que le comportement de DB5 au niveau des permissions et de la reconstruction du cache est différent des DB précédentes. La gestion du SLE a clairement changé.

 

Je dirais même que c'est carrément tout le dossier System qui est concerné ;).

Link to comment
Share on other sites

dp5 + clover v3251 + kexts dans /L/E = tout baigne !   ^_^

 

j'a bien aimé le petit effet cube 3D après la seconde phase de l'installation de la mise à jour (celle qui dure 8 minutes)   ;)

 

Yep, vu aussi et c'est très zoooolie :hysterical: !

  • Like 1
Link to comment
Share on other sites

Vu que ça avance plutôt bien je vais peut-être me lancer moi !  :yes:

 

Donc si je fais la synthèse pour la DP5:

  • kext-dev-mode=1 ne sert rien depuis un bout de temps
  • rootless=0 ne sert plus (depuis la 10.11.DP5)
  • Clover n'injecte plus rien de EFI/CLOVER/kext (depuis la 10.11.DP4, il y a peut être un espoir avec la méthode de Pike.R.alpha)
  • les kexts à injecter doivent être dans L/E ou S/L/E
  • la recontruction du cache est impossible (ou plutôt super compliquée) avec Clover v3241 et moins et la DP5
  • Clover v3251 permet le réglage du CsrActiveConfig par plist et donc la modification des kexts/caches

Donc si j'ai bien compris on désactive SIP pour faire ce que l'on veut (un peu à la sauce rootless), et le seul à avoir réussi à activer pleinement SIP et à injecter des kexts non signé est Pike.R.Alpha et son RevoBoot ...

 

Il me reste une question c'est quoi ce BooterConfig qui du coup semble faire double emploi ?

 

EDIT: la réponse est : ça écrit un truc en NVRam, après si c'est utile ou pas .... ?

 

EDIT 2:

 

D'après ce que j'ai compris BooterConfig est un truc purement Clover bootloader et sert à activer un certain nombre de trucs au boot

0x28 (00101000)
bootercfg %00%00
csr-active-config g%00%00%00

0 kBootArgsFlagRebootOnPanic      (1 << 0)
0 kBootArgsFlagHiDPI              (1 << 1)
0 kBootArgsFlagBlack              (1 << 2)
1 kBootArgsFlagCSRActiveConfig	  (1 << 3)
0 kBootArgsFlagCSRPendingConfig	  (1 << 4)
1 kBootArgsFlagCSRBoot            (1 << 5)
0 kBootArgsFlagBlackBg            (1 << 6)
0 kBootArgsFlagLoginUI            (1 << 7)

ça n'a pas l'air de super bien marcher ...

et ça n'est pas (plus ?) présent dans l'exemple de plist sur SF

 

Par contre CsrActiveConfig est un truc Apple dans le code source du kernel :

 CA (01100111)

1 CSR_ALLOW_UNTRUSTED_KEXTS       (1 << 0)
1 CSR_ALLOW_UNRESTRICTED_FS       (1 << 1)
1 CSR_ALLOW_TASK_FOR_PID          (1 << 2)
0 CSR_ALLOW_KERNEL_DEBUGGER       (1 << 3)
0 CSR_ALLOW_APPLE_INTERNA         (1 << 4)
1 CSR_ALLOW_UNRESTRICTED_DTRACE   (1 << 5)
1 CSR_ALLOW_UNRESTRICTED_NVRAM    (1 << 6)
 
Security is completely disabled.
I can edit a kext’s info.plist in S/L/E
DarwinDumper’s memory dump (dtrace) and loading DirectHW.kext both run.

 

  • Like 2
Link to comment
Share on other sites

Mais bon, le résultat est là même si j'ai perdu l'USB3.0 et un port USB dans l'affaire. Ha oui, la RAM est rapportée bizarrement: plus qu'il n'y en a en réalité. Y'a du taf!

attachicon.gifE6440_10.11DB5.jpg

 

'plus que le bon vieux Latitude D630 Core2Duo à traiter...

 

Pour les ports USB, t'as essayé la méthode des DummyUSBxxx décrite ici ?

 

Et pour le D630, si tu veux tenter Clover, je peux te passer mon dossier EFI :D et le DummyUSBEHCI.kext qui marche… quand il veut :hysterical:.

Sinon et si tu veux pas te prendre la tête avec ça, utilise un SMBios de MacBookPro3,1, il a exactement les mêmes ports EHC1/EHC2 que les Latitude Dxxx ;).

Link to comment
Share on other sites

J'ai fait l'installation sir le D630 nVidia. Comme une lettre à la poste avec Enoch r2737 jusqu'en DB4. Par contre, effectivement, il reste un peu de travail avec les ports USB: l'AR droit et celui en bas à droite ne sont pas fonctionnels. Je vais plancher sur la table DSDT et l'IOReg pour repérer tout ça...

 

Sur le D830, en fait ça dépend. De quoi, je sais pas trop mais L'AR fonctionne quoiqu'il arrive avec ma souris sans fil, les deux autres sur le coté droit fonctionnent mais pas avec tous les périphériques (USB3, clés, disques) et pas tout le temps.

 

Parfois, quand je laisse branché mon disque USB3 et que je démarre la PB, il apparait sur le bureau. D'autres fois, non. Idem, si je le branche après coup. Bref, c'est un peu la roulette russe à chaque fois alors que la DSDT est corrigée, que le DummyUSBEHCI.kext est correctement configuré.

 

À n'y rien comprendre et certainement dû au fait que ce sont des bêtas (enfin, j'espère que c'est ça :unsure:).

 

Et la veille fonctionne chez toi ?

Link to comment
Share on other sites

la beta 6 installée sans encombres...

 

je ne vois pas d'améliorations flagrantes... et vous ?

 

EDIT :

 

avez-vous aussi ce nom drôle de la corbeille dans le dock ?

 

Capture d’écran 2015-08-04 à 11.17.53.png

 

 

par contre, quand j'essaie de la vider, le nom corbeille (pas le chanteur, hein) est bien présent

 

Capture d’écran 2015-08-04 à 11.19.12.png

 

je crois que ce petit glitch est présent depuis la beta 4

Link to comment
Share on other sites

 Share

×
×
  • Create New...