10.11 El Capitan Partition de données inaccessible

[Typhuss]

Est-ce parce que je me suis lancé sur forums.macg il y a peu que de nouveaux problèmes surgissent régulièrement ?

à tous,

Je n'ai pas fait ça :
http://forums.macg.co/threads/changement-volontaire-des-autorisations-du-disque-dur.1242639
mais plutôt le contraire (autoriser largement au lieu de restreindre) mais le résultat semble similaire : bug :banghead:
La situation est différente de celle évoquée ici :
http://forums.macg.co/threads/permissions-des-nouveaux-elements-entre-utilisateurs.1281336/
et ressemble peut-être davantage à ce sujet-ci : http://forums.macg.co/threads/disque-dur-interne-passe-en-mode-read-only.1269035/ bien que ce ne soit pas réellement un problème de "Read only".

Explications
Je suis sur mon MacBook Pro (2010) :
SSD 1To / 3 partitions : 1 pour El Capitan / 1 pour Snow Leopard / 1 de Données (qui est inaccesssible)

Voici quelques retour du Terminal pour bien vous aider à situer (j'ai souligné le disque qui pose problème) :

diskutil list
/dev/disk0 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *1.0 TB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_CoreStorage MX200_OSX 99.3 GB disk0s2
3: Apple_Boot Recovery HD 650.0 MB disk0s3
4: Apple_HFS MX200_DATA 850.0 GB disk0s4
5: Apple_HFS MX200_SL 49.6 GB disk0s6
/dev/disk1 (internal, virtual):
#: TYPE NAME SIZE IDENTIFIER
0: Apple_HFSX MX200_OSX +99.0 GB disk1
Logical Volume on disk0s2
D8619122-782D-4AE1-8376-842D2FC0733D
Unencrypted

ls -al /Volumes
total 264
drwxrwxrwt@ 5 root admin 204 31 mai 16:14 .
drwxr-xr-x 21 root wheel 1054 30 mai 12:10 ..
drw-rw-r--+ 32 sylvain staff 1496 20 avr 23:49 MX200_DATA
lrwxr-xr-x 1 root admin 1 31 mai 14:59 MX200_OSX -> /
drwxrwxr-x 20 root wheel 1190 28 mai 01:23 MX200_SL

ls -aln /Volumes
total 264
drwxrwxrwt@ 5 0 80 204 31 mai 16:14 .
drwxr-xr-x 21 0 0 1054 30 mai 12:10 ..
drw-rw-r--+ 32 501 20 1496 20 avr 23:49 MX200_DATA
lrwxr-xr-x 1 0 80 1 31 mai 14:59 MX200_OSX -> /
drwxrwxr-x 20 0 0 1190 28 mai 01:23 MX200_SL

Mon souci vient du disque MX200_DATA qui est "bloqué" ? Impossible de modifier les permissions via Cmd-I, impossible en boot single user, et en session avec droits admin, les commandes dans Terminal "chmod" que j'ai pu lire ici sont rejetées car le disque est précisément "inaccessible".

Peut-être à cause des 2 OS chacun sur leur partition qui utilisent le même espace de stockage (MX200_DATA) j'avais un problème sous Snow de refus d'accès au disque MX200_DATA (désolé je ne me souviens plus exactement l'ampleur), mais cela m'a conduit à autoriser largement les utilisateurs.

J'ai donc passé en "lecture et écriture" les utilisateurs existants via Cmd-I du disque MX200_DATA, et ai ajouté les utilisateurs que je suis respectivement sous SL et ELCap.

Et au démarrage suivant, impossible de lire le disque : "vous ne disposez pas de l'autorisation nécessaire pour afficher son contenu".

Cmd-I ne me permet pas de modifier les réglages qui sont tous devenus "personnalisé".

NB : impossible de modifier ces permissions tant sous SL que sous ElCap.

Bref, je ne sais pas comment faire.
Auriez-vous une suggestion pour débloquer ce disque ?
Merci beaucoup d'avance.

 

[Deleted member 1099514]

Salut.
Tente depuis le terminal les commandes suivantes :
sudo chmod -R -N /Volumes/MX200_DATA
Puis
sudo chmod -R 755 /Volumes/MX200_DATA
Ton mot de passe administrateur te sera demandé. Il ne s'affiche pas.

 

[Membre supprimé 1060554]

Typhuss

[toujours les mêmes, hein !

]

☞ indépendamment de la question des autorisations absolues (inscrites sur l'arborescence du volume) que Jean vient d'aborder ; je te fais part d'un 2è aspect de la question, qui est celui des autorisations relatives - un facteur non négligeable dès lors qu'on considère un volume de stockage dont l'accès est susceptible d'être partagé entre de multiples utilisateurs en provenance éventuellement de plusieurs OS.

Lorsque un volume de stockage est donc destiné à être partagé entre de nombreux utilisateurs, éventuellement venant d'OS différents, le procédé le plus commode consiste à désactiver l'« ownership » (disable_ownership) sur le volume => cela revient à dissocier les accédants-propriétaires (utilisateurs et groupe) absolus (càd. inscrits sur l'arborescence du volume) des accédants propriétaires relatifs, qui deviennent par provision l'user dont la session est ouverte (et le groupe staff) => c'est donc à chaque fois l'utilisateur dont la session est ouverte et pour lequel le volume se trouve monté qui est intronisé par provision propriétaire en lecture / écriture de l'arborescence du volume.

Pour ce faire (en mode graphique) : tu fais un ⌘I sur l'icône du volume MX200_DATA ce qui ouvre la fenêtre d'info du Finder dont tu as donné la capture > tu déverrouilles le cadenas d'administration avec ton mot-de-passe admin (à supposer que tu y parviennes ?) > tu coches la case tout en bas : "Ignorer les autorisations de ce volume" [j'ai noté dans ta capture que cette case n'est pas cochée => il n'y a donc pas de désactivation de l'ownership sur le volume] > tu peux peut-être démonter > remonter le volume histoire de marquer le coup.

=> est-ce que tu as désormais un accès légitime en mode multi-utilisateurs, ce dans les sessions de tes 2 OS ?

 

[Typhuss]

jeanjd63

sudo chmod -R -N /Volumes/MX200_DATA

=> a priori ok

sudo chmod -R 755 /Volumes/MX200_DATA

là par contre échec :
chmod: Unable to change file mode on /Volumes/MX200_DATA: Operation not permitted

macomaniac (et oui ! toujours les mêmes, et c'est pas fini !!!)

=> est-ce que tu as désormais un accès légitime en mode multi-utilisateurs, ce dans les sessions de tes 2 OS ?

Entre temps, j'avais effectivement tenté en cochant cette case. Le résultat des commandes Terminal ci-dessus sont avec la case cochée.
Lorsque je déverrouille le cadenas, je ne peux pas changer les permissions, le menu déroulant s'affiche bien, mais si je selectionne par exemple "lecture et écriture" ça affiche ensuite "personnalisé" !
Grrrr :banghead:

 

[Deleted member 1099514]

Tente un
sudo chflags -R nouchg /Volumes/MX200_DATA
Puis refais la 2ème commande qui n'a pas fonctionné.

 

[Typhuss]

jeanjd63 ça a marché !!!!

Grand merci ! je bascule vers Capitan pour vérifier tout.

 

[Typhuss]

(Evidemment) ça fonctionne aussi sous Capitan.

Donc, avec la case cochée, aucun problème de droits d'accès ? garanti ?
Merci à vous deux pour cette aide.

Puisque j'y suis j'abuse un peu... : un problème venait aussi de Dropbox, dont j'ai installé le dossier racine sur ce disque de stockage.
J'ai remarqué que dès que je basculais d'un OS à l'autre* le dossier Dropbox ne se synchronisait pas bien, ou plutôt, il se resynchronisait en mettant à jour une série de fichier que je n'avais pas modifiés...
J'avais fini par désintaller Dropbox sur l'un des OS.

J'ai aussi le problème d'un partage de bibli iTunes entre ces 2 OS sur cette partition de stockage (mais là je suis en train d'éplucher les nombreux fils qui existent ssur le forum, et je crois que je vais finir par ne pas utiliser iTunes dans Snow (à regret mais nécessaire pour synchroniser les iBidules que la dernière version de iTunes sous SL ne prend pas en charge)

Bref, est-ce que toutes ces questions sont vraiment utiles ou futiles ?
A bientôt...



* je bascule car je suis victime du problème d'extinction inopinée du MBP. J'ai beau aussi suivre les fils qui existent sur le sujet :
- sous SL : ça tourne (très) bien pendant plusieurs heures voire plusieurs jours et il arrive qu'occasionnellement, l'ordi plante et reboot
- sous Capitan (donc avec le même matériel physique) : il est rare de tenir une heure sans que le système ne redémarre et souvent alors il reboot en cours de redémarrage...
D'où mon interrogation sur la stabilité et fiabilité des nouveaux OS face à Snow (qui je l'avoue a été mon premier OS sous mac)

 

[Deleted member 1099514]

Pas normal. El capitan est très stable et ne devrait pas rebooter inopinément.
Peux-tu fournir le rapport Etrecheck depuis El Capitan (entre balises Code).

Autre chose : il est déconseillé de partager tes bibliothèques entre 2 versions os x. Tu risques de les rendre inaccessibles.

 

[Membre supprimé 1060554]

Salut Typhuss

Apparemment, il y avait un attribut invisible d'immutabilité (le flag: uchg, comme un_change) qui s'était fixé accidentellement sur le départ de ton volume MX200_DATA => la conséquence en était que, s'il était possible d'accéder en lecture aux contenus du volume, aucune action d'écriture par contre (comme par exemple de modifier les permissions sur le volume) ne pouvait être enregistrée.

La commande de Jean :

sudo chflags -R nouchg /Volumes/MX200_DATA

a appelé l'utilitaire chflags (change_flags : modifier les attributs) avec l'option nouchg [abrégé de no_un_change (en quoi tu admireras l'effet de double négation {dont il serait faux de dire que l'art n'existe plus

} ) : "non_in_modifiable"] sur la cible de ton volume MX200_DATA - ce qui a eu pour effet de débloquer en écriture le répertoire de ce volume.

--------------------
​

D'après ce exorde, tu sais déjà que le sieur maco est lancé pour un exercice entremêlant « technique » & « ironie »

​

Puisque ton problème de maniement des autorisations du volume est réglé, j'en profite pour revenir sur l'option de « désactivation des autorisations » sur le volume que je t'avais préconisée (et qui ne pouvait pas avoir d'effet aussi longtemps que le flag: uchg adhérait à l'arborescence du volume) - option qui fait l'objet de ta question :

Donc, avec la case cochée, aucun problème de droits d'accès ? garanti ?

Les autorisations d'accès à un volume de stockage (et pas à un volume démarrable : celui d'un OS, car dans ce cas figure elles ne sont pas "relativisables") sont, absolument parlant, celles qui sont inscrites sur le répertoire de ce volume (et ses sous-répertoires et fichiers) : elles adhèrent donc à l'arborescence de ce volume.

Mais cet état de choses mérite d'être "relativisé" pour un usage commode, parce qu'un volume de stockage (qu'il soit supporté par un périphérique externe : clé USB ou DDE attachable et détachable ; ou qu'il dépende d'une partition du disque interne du Mac) est, par son statut même de "réservoir de données" indépendantes d'un compte particulier d'utilisateur, accessible en mode partagé à divers utilisateurs d'un même OS du Mac, voire de plusieurs OS résidant sur plusieurs partitions parallèles du disque.

Les ingénieurs informatiques ont donc mis-au-point un procédé logique remarquable concernant les volumes de stockage : la possibilité de « désactiver les autorisations absolues sur le volume » et d'« activer les autorisations relatives sur le volume ». Ce qui s'opère, en mode graphique, par le fait de cocher la case d'une fenêtre d'information du Finder ouverte sur le volume "Ignorer les autorisation de ce volume".

Cet acte graphique équivaut à la passation d'une commande de coulisse :

sudo diskutil disableOwnership [DEVICE]

qui a pour effet un acte d'édition du fichier d'enregistrement des options d'« ownership » sur les volumes : /private/var/db/volinfo.database. Ce fichier se compose d'une liste des volumes qui ont été montés pour l'OS considéré, volumes désignés par un identifiant alpha-numérique de 15 caractères qui n'est pas leur UUID standard, avec en regard une valeur numérique 00000001 en cas d'« ownership » activé et de 00000000 en cas d'« ownership » désactivé => tu remarqueras qu'il s'agit d'un integer 1 = TRUE = VRAI lorsque l'« ownership » (autorisations absolues ou "actuelles") est activé ; et d'un integer 0 = FALSE = FAUX lorsque l'« ownership » est désactivé (donnant lieu à des autorisations relatives, ou "courantes").

L'existence de ce fichier base-de-données des préférences d'« ownership » dans l'OS explique la persistence de l'option d'activation ou de désactivation de l'« ownership » d'un montage à l'autre d'un volume considéré. Mais il faut également considérer que l'édition en écriture de ce fichier s'effectue à la volée en temps direct (sans nécessiter de re-démarrage) par l'effet d'un daemon du Système, et que toute édition d'écriture de 0 => 1 ou de 1 => 0 de la valeur associée à un volume prend effet immédiat sur les autorisations du volume sans re-démarrage ni démontage / remontage requis de ce volume - par l'effet encore d'un daemon du Système.

C'est ce que tu peux constater si tu ouvres une fenêtre d'info du Finder sur un volume de stockage et si tu t'amuses à alterner les actes de cochage (=> integer 0 dans la database) / décochage (=> integer 1 dans la database) de la case "Ignorer les autorisations de ce volume" => pour le cas (seul visible) où l'utilisateur propriétaire et de groupe propriétaire en mode absolu ("actuel") ne sont pas les mêmes que l'utilisateur dont la session est ouverte (utilisateur "courant") ni le groupe défaut staff (groupe "courant"), par exemple user actuel = root & group actuel = wheel vs user courant = sylvain & group courant = staff => alors, décocher la case révèle user=root en lecture/écriture & group=wheel en lecture vs cocher la case révèle user=sylvain en lecture/écriture & group=staff en lecture - variations qui interviennent en temps réel.

D'après les commandes & captures que tu as données, il est clair que l'user absolu ("actuel") sur ton volume MX200_DATA est root et le group absolu ("actuel") est wheel (le groupe-Système) - ce qui intrinsèquement bloque en accès n'importe quel user, fût-il admin, qui n'a accès au volume qu'en lecture en tant que membre du groupe secondaire everyone. Par contre, dès que tu coches la case, si l'utilisateur dont la session est ouverte est sylvain, alors c'est sylvain qui est l'user propriétaire courant en lecture / écriture. Si sylvain se délogge et si un nommé toto ouvre sa session, alors c'est l'utilisateur courant toto qui devient l'user propriétaire en lecture / écriture du volume.

Cette relativisation des autorisations, remplaçant les accédants absolus ("actuels") par les accédants relatifs ("courants"), est un apport précieux au partage d'un seul volume de stockage par de nombreux utilisateurs potentiels. Elle évite (comme tu avais cherché à le faire) de créer des autorisations supplémentaires dans la liste d'ACL du volume considéré, si l'on n'a pas besoin de filtrer finement des accès à ce volume, mais s'il est réellement « à ciel ouvert ».

[Remarques annexes : personnellement, je n'instaure jamais root:wheel comme propriétaires absolus ("actuels") d'un volume de stockage) sur mes Macs, mais toujours maco:staff - ce qui évite a priori un blocage. Et par-dessus le marché, je coche la case "ignorer les autorisations sur le volume" s'il est question d'un accès en mode partagé de ce volume de stockage par plusieurs utilisateurs diffférents.

Je note dans les permissions qui étaient en place une fois la case cochée (puisque l'user et le group sont identifiés comme les accédants "courants" sylvain:staff et non les "actuels" root:wheel) :

drw-rw-r--+  sylvain staff  MX200_DATA

qu'il manquait tant pour sylvain, que pour le groupe staff, que pour everyone, l'executable_bit sur le répertoire du volume, càd. le bit terminal x (1 en valeur octale) de chaque triplette de permissions, lequel autorise l'« entrée à l'espace du répertoire du volume » => telles quelles, les permissions proscrivaient l'entrée dans le volume par les propriétaires" courants" - ce qui témoignait d'un paradoxe qui devait avoir des effets pénibles. La commande de Jean (après déverrouillage du volume) :

sudo chmod -R 755 /Volumes/MX200_DATA

a pour effet de restaurer cet executable_bit pour les 3 accédants "courants" par la valeur octale 755 (4 lecture + 2 écriture + 1 exécution de l'entrée pour sylvain > 4 lecture + 1 exécution de l'entrée pour staff > 4 lecture + 1 exécution de l'entrée pour everyone => 7+5+5 : 755).

Bref : il faut se méfier de ne pas trop tourmenter les conditions de droits sur des volumes et de garder de préférence l'état de choses logiques sobre et évident - dans la mesure du possible...]

 

[Typhuss]

rapport Etrecheck depuis El Capitan

Voilà le résultat :

EtreCheck version : 2.9.12 (265)
Rapport créé le 2016-06-04 18:55:39
Télécharger EtreCheck chez https://etrecheck.com
Runtime 1:41
La vitesse : Excellent

Cliquez sur les liens [L’aide] pour l’assistance avec les produits non-Apple.
Cliquez sur les liens [Les détails] pour plus d'informations sur cette ligne.

Problème :L‘ordinateur redémarre

Les informations matérielles : ⓘ
    MacBook Pro (15 pouces, mi-2010)
    [Les caractéristiques techniques] - [Le guide de l’utilisateur] - [Garantie & service]
    MacBook Pro - modèle : MacBookPro6,2
    1 2,53 GHz Intel Core i5 CPU : 2-core
    4 GB RAM Extensible - [Instruction]
        BANK 0/DIMM0
            2 GB DDR3 1067 MHz ok
        BANK 1/DIMM0
            2 GB DDR3 1067 MHz ok
    Bluetooth: Vieux - Handoff/Airdrop2 pas disponible
    Wireless:  en1: 802.11 a/b/g/n
    La batterie : Santé = Normal - Comptage de cycles = 509

Les informations vidéo : ⓘ
    Intel HD Graphics
    NVIDIA GeForce GT 330M - VRAM : 256 MB
        Color LCD 1440 x 900

Les logiciel du système : ⓘ
    OS X El Capitan 10.11.3 (15D21) - Temps depuis le démarrage : moins d’une heure

Les informations des disques : ⓘ
    Crucial_CT1024MX200SSD1 disk0 : (1 TB) (Solid State - TRIM: Non)
        EFI (disk0s1) <non monté>  : 210 Mo
        Recovery HD (disk0s3) <non monté>  [Restauration] : 650 Mo
        MX200_DATA (disk0s4) /Volumes/MX200_DATA  : 850.00 Go (288.69 Go libre)
        MX200_SL (disk0s5) <non monté>  : 49.59 Go
        MX200_OSX (disk1) /  : 98.98 Go (64.27 Go libre)
            Core Storage: disk0s2 99.35 Go Online

    MATSHITADVD-R   UJ-898   ()

Les informations USB : ⓘ
    Apple Computer, Inc. IR Receiver
    Apple Inc. Built-in iSight
    Apple Card Reader
    Apple Inc. Apple Internal Keyboard / Trackpad
    Apple Inc. BRCM2070 Hub
        Apple Inc. Bluetooth USB Host Controller

Le gatekeeper : ⓘ
    N’importe où

Les agents de lancement systèmes : ⓘ
    [désengagé]    7 tâches d’Apple
    [engagé]    163 tâches d’Apple
    [en marche]    66 tâches d’Apple

Les daemons de lancement systèmes : ⓘ
    [désengagé]    46 tâches d’Apple
    [engagé]    159 tâches d’Apple
    [en marche]    82 tâches d’Apple

Les agents de lancement pour l’utilisateur : ⓘ
    [engagé]    com.google.keystone.agent.plist (2016-05-27) [L’aide]

Les éléments Ouverture : ⓘ
    iTunesHelper    Application  (/Applications/iTunes.app/Contents/MacOS/iTunesHelper.app)

Les autres apps : ⓘ
    [en marche]    com.etresoft.EtreCheck.420192
    [engagé]    406 tâches d’Apple
    [en marche]    166 tâches d’Apple

Les plug-ins internets : ⓘ
    Default Browser : 601 - SDK 10.11 (2016-01-14)
    QuickTime Plugin : 7.7.3 (2016-01-14)

Les panneaux de préférences tiers : ⓘ
    Aucun

Le Time Machine : ⓘ
    Time Machine n’est pas configuré !

L’utilisation du CPU par processus : ⓘ
         9%    mdworker(4)
         6%    mds
         5%    WindowServer
         5%    aslmanager
         4%    mds_stores

L’utilisation de la RAM par processus : ⓘ
    497 Mo    kernel_task
    254 Mo    mds_stores
    102 Mo    WindowServer
    70 Mo    mds
    61 Mo    Finder

Les informations de la mémoire virtuelle : ⓘ
    1.21 Go    RAM Disponible
    2.79 Go    RAM Utilisée (1.35 Go Cached)
    0 o    Fichier d’échange utilisé

Les informations du diagnostic : ⓘ
    Jun 4, 2016, 06:49:40 PM    Examen de soi - succès
    May 30, 2016, 06:42:07 PM    /Library/Logs/DiagnosticReports/Kernel_2016-05-30-184207_[expurgé].panic [Les détails]
    May 30, 2016, 01:43:28 PM    /Library/Logs/DiagnosticReports/Kernel_2016-05-30-134328_[expurgé].panic [Les détails]
    May 30, 2016, 01:37:17 PM    /Library/Logs/DiagnosticReports/Kernel_2016-05-30-133717_[expurgé].panic [Les détails]
    May 30, 2016, 11:43:39 AM    /Library/Logs/DiagnosticReports/Kernel_2016-05-30-114339_[expurgé].panic [Les détails]
    May 27, 2016, 04:10:37 PM    /Library/Logs/DiagnosticReports/Kernel_2016-05-27-161037_[expurgé].panic [Les détails]
    May 27, 2016, 03:36:03 PM    /Library/Logs/DiagnosticReports/Kernel_2016-05-27-153603_[expurgé].panic [Les détails]
    May 27, 2016, 03:21:08 PM    /Library/Logs/DiagnosticReports/Kernel_2016-05-27-152108_[expurgé].panic [Les détails]

Peut-être faut-il ouvrir un nouveau sujet sur ces extinctions inopinées ? (même s'il y a déjà pas mal de sujets dessus?)
ou alors on reste entre nous sur ce fil-ci ?

Car j'ai encore un autre sujet potentiel : j'ai changé le DD d'origine de mon MacBookPro (Toshiba 500Go) par un SSD Crucial 1To. Sur ce SSD, j'ai installé la partition ElCapitan. Et depuis, la batterie fond comme neige au soleil sous EC (en pleine charge, le MBP affiche entre 2h et 3h d'autonomie seulement - et c'est effectivement ça) ; et sous SL, c'est un peu mieux (4-5h affichées) mais loin des 8-10h que j'avais sous SL avant de changer ce SSD... (cependant, j'ai cloné SL du DD Toshiba vers le DD Crucial, pas fait une réinstall à zéro ; EC en revanche est une clean install à zéro)
Et comme un bonheur n'arrive jamais seul, je suis parti ce week-end sans le chargeur... donc le MBP est presque à plat (je peux toujours suivre le topic, mais plus dur de tester sur la machine d'ici lundi...

 

[Deleted member 1099514]

Je te donnerai 2 conseils :
1) passer à 8 go de mémoire.
2) mettre à jour El capitan en version 10.11.5

 

[Membre supprimé 1060554]

je suis parti ce week-end sans le chargeur... donc le MBP est presque à plat (je peux toujours suivre le topic, mais plus dur de tester sur la machine d'ici lundi...

☝︎

J'aime à lire, le dimanche, tout ce qui augure de vacances logiques...​

♤​

Peut-être faut-il ouvrir un nouveau sujet sur ces extinctions inopinées ? (même s'il y a déjà pas mal de sujets dessus?)
ou alors on reste entre nous sur ce fil-ci ?

Je ne suis pas modérateur, mais je pense qu'il serait plus cohérent que tu ouvres un nouveau fil consacré à ces questions spécifiques sans commune mesure avec le sujet présent d'une partition de stockage inaccessible...​

♧​

Ton rapport «EtreCheck» est d'un laconisme à la mesure de l'emploi spartiate que tu parais faire de ton OS (4 Go de RAM obligent ?). Je ne relève que ce point suppémentaire :

Les informations des disques : ⓘ
Crucial_CT1024MX200SSD1 disk0 : (1 TB) (Solid State - TRIM: Non)

montrant que tu n'as pas activé le TRIM à destination de ton SSD «Crucial». Dans «El Capitan», cela s'opère via le «Terminal» par la commande :

sudo trimforce enable

qui doit être suivie par un re-démarrage du Mac.

Cette commande concerne la nouvelle extension du noyau Apple chargée de gérer le TRIM sur les SSD de tierce-partie, dont l'original est par défaut tenu en réserve en mode inactif à la localisation suivante : /System/Library/Filesystems/ AppleDataSetManagement.kext => la commande opère pour l'essentiel une recopie de cet original dans le répertoire réglementaire des extensions : /System/Library/Extensions, de telle manière qu'au re-démarrage du Mac, elle se trouvera injectée dans le kernel avec ses comparses du dossier.

♡​

 

[Typhuss]

Salut jeanjd63,
upgrade 10.11.5 : en cours...
passage à 8Go : prévu, mais ces redémarrages intempestifs me font hésiter : intérêt d'investir dans cette RAM si le MBP reste instable - indépendamment de l'OS d'ailleurs car sous Snow, ça le fait aussi. Et ça le faisait aussi avant de passer au SSD...
je reste en mode "observation" quelques temps et j'ouvrirai un topic dédié le cas échéant.

Salut macomaciac,

Ton rapport «EtreCheck» est d'un laconisme à la mesure de l'emploi spartiate que tu parais faire de ton OS

En réalité, je viens de ré-installer sur partition formatée El Capitan (car précédemment cloné depuis la version installée sur l'iMac - pour gagner en temps de ré-installation des logiciels), et suis en train de progressivement réinstaller les logiciels, d'où ce rapport laconique. Mon objectif était précisément de constater si avec El Capitan propre et "peu chargé" cela empêchait ces redémarrages intempestifs fort dérangeants.
J'ai par ailleurs bien lu il y a peu ton message expliquant comment démonter automatiquement la partition de "l'autre OS" dès le démarrage (http://forums.macg.co/threads/deux-osx-qui-sembrouillent.1279493/) C'était pour le couple Mavericks/El Capitan, est-ce bien la même procédure pour SL / EC ?

tu n'as pas activé le TRIM à destination de ton SSD

Oui, grâce à Etrecheck j'ai aussi noté ce point-ci. Je l'avais fait, mais il semble que la réinstallation de El Capitan a donc supprimé la gestion du trim... C'est rétabli depuis !

 

[Membre supprimé 1060554]

Typhuss

Une petite application-script (qui se lance à l'ouverture de session et qui commande le démontage d'un volume du disque supportant un OS alternatif : ton «Snow Léopard», par exemple) est une solution facile à mettre en place et tout aussi facile à désactiver. Elle marchera sans problème dans «El Capitan».

Personnellement, sur le SSD de 1 To de mon MacBook Pro 17" Late_2011, j'ai 6 OS démarrables sur des partitions séparées (de 10.6 à 10.11). Je laisse coexister les volumes montés des 5 OS non-démarrés avec le volume de l'OS démarré et je n'ai jamais eu d'interférences logiques quelconques.

Pour ce qui est du laconisme du rapport EtreCheck : tout s'explique => tu en étais encore à une sorte de clean install...

 

[Typhuss]

macomaniac et jeanjd63

pour info, j'ai changé la RAM pour la porter à 8Go... sans effets positifs.
Rien n'y fait.

Puis j'ai vu que mon MBP n'est plus éligible aux réparations apple.
je verrai pour un nouveau topic le cas échéant. (mais i y en a déjà sans solution... alors un de plus n'est pas utile)

 

[bompi]

macomaniac et jeanjd63

pour info, j'ai changé la RAM pour la porter à 8Go... sans effets positifs.
Rien n'y fait.

Puis j'ai vu que mon MBP n'est plus éligible aux réparations apple.
je verrai pour un nouveau topic le cas échéant. (mais i y en a déjà sans solution... alors un de plus n'est pas utile)

Sans effets positifs sur quoi, précisément ?

[Personnellement je déconseille de monter simultanément divers systèmes installés sur la machine : a priori rien ne l'empêche et, lorsque le besoin est là, pourquoi pas, cependant on risque de lancer sur le système démarré des applications installées sur un système non démarré. Et créer des carabistouilles dans les configurations des applications.
Exemple : après démarrage sur El Capitan lancer une application dans sa version installée sur Snow Leopard et non compatible avec El Capitan. Et qui ne comprendrait pas bien les préférences, écrites par l'application installée sur El Capitan, plus récente.
Normalement, rien de catastrophique, mais de quoi se faire des noeuds au cerveau quand certaines fonctions ne sont plus disponibles ou opèrent bizarrement ou plantent [normal puisqu'on n'utilise pas la bonne version].]

 

[Deleted member 1099514]

macomaniac et jeanjd63

pour info, j'ai changé la RAM pour la porter à 8Go... sans effets positifs.
Rien n'y fait.

Puis j'ai vu que mon MBP n'est plus éligible aux réparations apple.
je verrai pour un nouveau topic le cas échéant. (mais i y en a déjà sans solution... alors un de plus n'est pas utile)

Passe un Hardware Test : https://support.apple.com/fr-fr/HT201257
Il faut mettre le DVD n°2 et appuyer sur D lors du boot.

 

[Membre supprimé 1060554]

Typhuss

Le souci auquel tu fais allusion : c'est des extinctions inopinées suivies de redémarrages de ton Mac ? Quel que soit l'OS démarré : «El Capitan» aussi bien que «Snow Léopard» ?