Alléger Mavericks
- Créateur du sujet Oui
- Date de début
M
Membre supprimé 1060554
Invité
Ah! Ce fil a quelque chose des 'problèmes récréatifs' de l'enfance. Où l'on parle de chèvre, de chou et de berger qui ne peuvent pas traverser ensemble la rivière dans une barque trop étroite... 
Sur le moment, j'ai pensé que Moon avait lobé maco ('bien joué!'), étant donné qu'à la différence d'un laptop qui a l'hibernatemode 3 par défaut (écriture du contenu de la RAM à la sleepimage du disque avant mise en sommeil), un desktop, lui, a par défaut l'hibernatemode 0 (pas d'écriture du contenu de la RAM à la sleepimage du disque avant mise en sommeil). Il paraît donc logique d'induire de ce fonctionnement a posteriori un a priori relatif au protocole d'installation d'OSX sur un desktop - genre : «donc l'installateur, à l'installation première de l'OS sur un 'desktop', ne créera pas sur le disque une sleepimage destinée à ne pas servir». Sacré gain de place à l'install : l'équivalent de la taille de la RAM.
Mais Jiminy Cricket n'arrêtait pas de striduler dans mon oreille gauche : rappelle-toi le coup de «Smart Sleep». Il s'agit d'un petit logiciel malin, qui offre le choix de changer l'hibernatemode à la volée dans une GUI, sans passer par la ligne de commande. Or ce petit fûté commence, lorsqu'il s'installe par exemple sur un Mac déjà en hibernatemode 0 et dont la sleepimage a été supprimée, par re-créer une sleepimage vide d'une taille équivalente à la RAM, afin justement qu'un espace-disque soit disponible au cas où l'utilisateur, abruptement, opterait pour l'hibernatemode 3.
J'ai donc fait le test sur mon iMac (hibernatemode 0 vérifié et sleepimage supprimée de /private/var/vm) d'installer sur une partition ad-hoc de DDE un OSX «Mavericks» tout neuf. J'ai répété 3 fois le test : chaque fois une sleepimage de la taille de la RAM est créée à l'adresse susdite, quoique sur le nouvel OS, l'hibernatemode 0 soit actif en miroir du Mac source de l'install.
J'en tire la conséquence qu'on ne peut pas éviter a priori, quel que soit le Mac qui supporte le processus d'installation d'OSX, la création formelle d'une sleepimage de la taille de la RAM du Mac 'support' (création qui s'effectue a priori, même si a posteriori ce fichier est destiné à ne pas recevoir d'écriture des contenus de la RAM). Il y a plus : quelqu'un qui boote sur le volume ainsi installé en attachant le disque-support (un DDE pour moi) à un autre Mac, voit la taille de la sleepimage d'origine varier comme la RAM du Mac auquel le disque est attaché : en bootant le «Mavericks» dont la sleepimage à l'install était de 8 go (miroir de la RAM de mon iMac) sur mon MacBook Pro dont la RAM est de 16 Go, la taille de la sleepimage du volume attaché se trouve dilatée en miroir à 16 Go après le boot. En hibernatemode 0! Seule la substitution d'un fichier verrouillé de 0 Ko à l'adresse indiquée bloque ce 'retaillage'.
Ce qui me fait aller dans le sens de bompi :
À cause de cette création automatique d'une sleepimage de la taille de la RAM à l'install, ce dans tous les cas de figure, je n'arrive pas à concevoir comment on peut installer a priori Mavericks sur une clé de 8 Go seulement. Qu'on puisse, a posteriori, cloner un «Mavericks» 'allégé' de toutes sortes de composants, en ayant opté pour l'hinernatemode 0 notamment et verrouillé une sleepimage de 0 Ko, sur une clé USB de 8 Go - passe encore. Mais vu la quantité phénoménale de cache généré structurellement par cet OS, j'ai l'impression que ça doit 'péter aux entournures' à très brève échéance. À moins de sacrifier carrément la plupart des applications. Mais un OS sans 'applications', ça sert à quoi?
Sur le moment, j'ai pensé que Moon
avait lobé maco ('bien joué!'), étant donné qu'à la différence d'un laptop qui a l'hibernatemode 3 par défaut (écriture du contenu de la RAM à la sleepimage du disque avant mise en sommeil), un desktop, lui, a par défaut l'hibernatemode 0 (pas d'écriture du contenu de la RAM à la sleepimage du disque avant mise en sommeil). Il paraît donc logique d'induire de ce fonctionnement a posteriori un a priori relatif au protocole d'installation d'OSX sur un desktop - genre : «donc l'installateur, à l'installation première de l'OS sur un 'desktop', ne créera pas sur le disque une sleepimage destinée à ne pas servir». Sacré gain de place à l'install : l'équivalent de la taille de la RAM.Mais Jiminy Cricket n'arrêtait pas de striduler dans mon oreille gauche : rappelle-toi le coup de «Smart Sleep». Il s'agit d'un petit logiciel malin, qui offre le choix de changer l'hibernatemode à la volée dans une GUI, sans passer par la ligne de commande. Or ce petit fûté commence, lorsqu'il s'installe par exemple sur un Mac déjà en hibernatemode 0 et dont la sleepimage a été supprimée, par re-créer une sleepimage vide d'une taille équivalente à la RAM, afin justement qu'un espace-disque soit disponible au cas où l'utilisateur, abruptement, opterait pour l'hibernatemode 3.
J'ai donc fait le test sur mon iMac (hibernatemode 0 vérifié et sleepimage supprimée de /private/var/vm) d'installer sur une partition ad-hoc de DDE un OSX «Mavericks» tout neuf. J'ai répété 3 fois le test : chaque fois une sleepimage de la taille de la RAM est créée à l'adresse susdite, quoique sur le nouvel OS, l'hibernatemode 0 soit actif en miroir du Mac source de l'install.
J'en tire la conséquence qu'on ne peut pas éviter a priori, quel que soit le Mac qui supporte le processus d'installation d'OSX, la création formelle d'une sleepimage de la taille de la RAM du Mac 'support' (création qui s'effectue a priori, même si a posteriori ce fichier est destiné à ne pas recevoir d'écriture des contenus de la RAM). Il y a plus : quelqu'un qui boote sur le volume ainsi installé en attachant le disque-support (un DDE pour moi) à un autre Mac, voit la taille de la sleepimage d'origine varier comme la RAM du Mac auquel le disque est attaché : en bootant le «Mavericks» dont la sleepimage à l'install était de 8 go (miroir de la RAM de mon iMac) sur mon MacBook Pro dont la RAM est de 16 Go, la taille de la sleepimage du volume attaché se trouve dilatée en miroir à 16 Go après le boot. En hibernatemode 0! Seule la substitution d'un fichier verrouillé de 0 Ko à l'adresse indiquée bloque ce 'retaillage'.
Ce qui me fait aller dans le sens de bompi :
À cause de cette création automatique d'une sleepimage de la taille de la RAM à l'install, ce dans tous les cas de figure, je n'arrive pas à concevoir comment on peut installer a priori Mavericks sur une clé de 8 Go seulement. Qu'on puisse, a posteriori, cloner un «Mavericks» 'allégé' de toutes sortes de composants, en ayant opté pour l'hinernatemode 0 notamment et verrouillé une sleepimage de 0 Ko, sur une clé USB de 8 Go - passe encore. Mais vu la quantité phénoménale de cache généré structurellement par cet OS, j'ai l'impression que ça doit 'péter aux entournures' à très brève échéance. À moins de sacrifier carrément la plupart des applications. Mais un OS sans 'applications', ça sert à quoi?
Un OS sans applications ca peut servir a tout simplement tester le système en lui même ou juste aller sur internet, tester une beta...
Chez moi système fait 6,05Go, je vais voir ce que ca donne de le copier sur la clé USB.
Edit: impossible à copier, il parait qu'il n'y a pas assez de place et pourtant il y en a assez.
Chez moi système fait 6,05Go, je vais voir ce que ca donne de le copier sur la clé USB.
Edit: impossible à copier, il parait qu'il n'y a pas assez de place et pourtant il y en a assez.
Dernière édition:
M
Membre supprimé 1060554
Invité
Ce fil ne répondant à aucune 'exigence vitale' de la part d'utilisateurs en détresse, mais découlant a contrario d'un 'désir dispensable' en & pour soi (booter un Mac à partir d'un OS «Mavericks» installé sur une clé USB de 8 Go) - j'ai l'impression d'avoir toute latitude d'y souscrire une glose marginale.
- En ce qui concerne d'abord le problème a parte priori (càd. en termes de possibilité d'installation de «Mavericks» sur une clé de 8 Go).
Renaud31 (dont l'esprit d'exactitude renvoie toujours le nommé macomaniac à la posture qu'il n'a jamais quittée : celle d'un gamin imaginatif en train d'esquisser dans les bacs à sable des jardins publics de l'enfance la construction de châteaux voués à s'effondrer avant terme) - m'a communiqué le résultat d'une expérience personnelle --> lorsque le programme d'installation d'OSX a assez de place sur le disque de destination pour mettre en place le Système, mais pas assez pour créer la sleepimage de la taille de la RAM du Mac_support qu'il a l'instruction par défaut de générer, alors aucune sleepimage n'est créée sur le disque de destination. J'ai pu vérifier la validité de ce constat en lançant l'installation de «Mavericks» sur la partition d'un DDE de 12 Go : assez pour accueillir les fichiers-Système de l'OS (8,5 Go requis), pas assez pour accueillir une sleepimage de 16 Go (la taille de la RAM de mon Mac) --> à l'arrivée, aucune sleepimage n'est créée à l'emplacement attendu : /private/var/vm.
Nonobstant, je constate que les 2 swapfiles : swapfile0 (de 67 Mo) et swapfile1 (de 1 Go) sont, elles, créées par défaut (quand bien même un Mac avec 16 Go de RAM est quasiment insusceptible d'avoir jamais à swapper) - sans que je puisse juger si l'instruction du programme d'installation de les créer est ou non suspensible, au cas où l'espace requis pour les 1 Go de la swapfile1 ferait défaut. N'ayant pas à ma disposition actuellement de clé USB disons de 11 Go, je suis incapable de vérifier cette éventualité. En tout cas, ce qui apert est que toutes les instructions du programme d'installation d'OSX ne sont pas 'inconditionnelles' (du style : tout ou rien, rapportées à l'espace disponible sur le disque de destination), mais il en est au moins une de 'conditionnelle' (suspendue dans son exécution à la la mesure de l'espace disponible sur le disque de destination). Je suis incapable de juger s'il y a ou non d'autres instructions 'conditionnelles'. Les expériences de fousfous semblent montrer qu'on se heurte très vite à une 'inconditionnalité'.
Je me suis livré à quelques 'mesures'. «Mavericks» installé à neuf sur une partition de DDE, je lui ai soustrait la sleepimage et les swapfiles --> la taille du Système de fichiers 'résiduel' est alors de 8,5 Go. Franchement, je ne vois pas comment ça pourrait passer a priori (à l'install) sur une clé USB de 8 Go (ne pas oublier que la taille de l'installateur de «Mavericks» = 5,1 Go ne mesure qu'une image comprimée).
Des remarques de Moonwalker précédemment me conduisent à introduire 2 autres paramètres qui vont dans le sens d'une impossibilité a priori d'installer «Mavericks» sur une clé USB de 8 Go.
La 1ère est la nécessité de la formater en Tableau de partition GUID pour qu'elle soit bootable avec un Mac Intel. Or cette 'tablature' logique préalable instaure structurellement, de manière incontournable, une bi-partition a priori du disque concerné = /dev/disk1 --> une partition /dev/disk1s1, toujours de 220 Mo, dite EFI, qui se crée toujours sans exception sur tout disque logiquement 'tablé' en GUID comme la 1ère des partitions-disque (invisible et inmontable par défaut). Et une partition /dev/disk1s2, la 2è des partitions-disque par défaut, dédiée à l'exploitation du disque par l'utilisateur --> une clé de 8 Go 'tablée' en GUID n'offre donc a priori qu'un espace de 7,8 Go au mieux pour l'installation de l'OS, et pas 8 Go donc.
La 2è est l'instruction inhérente au programme d'installation d'OSX (depuis «Lion» et la dématérialisation des ressources d'installation) - instruction que l'expérience de nombreux utilisateurs paraît bien désigner comme 'inconditionnelle' - qui est la bi-partition là encore de l'espace d'exploitation disponible d'un disque de destination : une partition strictement /dev/disk1s2 dédiée à l'OS et une partition /dev/disk1s3 dédiée à la 'Recovery HD'. Sans espace suffisant pour pouvoir créer en parallèle cette partition de récupération invisible, le programme d'installation de «Mavericks» rejette la tâche d'installation.
Or cette partition, dont l'«Utilitaire de Disque» (débogué) mesure le volume monté à 650 Mo, n'a pas une taille réduite à 650 Mo, mais requiert un espace de 1,250 Go minimum. En effet, la 'Recovery HD' est une structure gigogne : c'est un disque (partition) supportant un volume (l'Apple Boot Recovery), lequel recèle un disque-virtuel (le .dmg : OS X BaseSystem) qui, lorsqu'on démarre sur la 'Recovery', monte un volume contenant un OSX simplifié. Le .dmg est une image-disque comprimée de 550 Mo, mais le volume monté à l'issue de sa décompression est de 1,2 Go --> a priori, le programme d'installation de «Mavericks» requiert donc un espace de 1,25 Go pour la partition 'Recovery HD', qu'il faut donc soustraire encore à l'espace disponible de la clé qui était déjà réduit à 7,8 Go --> 6,5 Go au mieux.
Or le Système qui s'installe requérant 8,5 Go pour les fichiers-Système (+ 1 Go de swapfile1 dont je ne sais pas si l'instruction de la créer est ou non conditionnelle), il s'ensuit logiquement que «Mavericks» est, a priori, ininstallable sur une clé USB de 8 Go. À moins d'aller soustraire a priori au bundle d'installation des .pkg jugés dispensables pour alléger l'installation. À cet égard, je suis incompétent pour juger si cet allégement serait honoré par le programme d'installation, ou bien s'il engendrerait le blocage de ses instructions par lacune de ressources constatée.
⦿
- En ce qui concerne ensuite le problème a parte posteriori (càd. en termes de possibilité de cloner un «Mavericks» pré-installé d'abord sur un disque assez spacieux, sur une clé de 8 Go après allègement de ressources).
La suppression de la partition EFI d'une clé 'tablée' en GUID me paraît logiquement impossible, car la présence de cette partition fait corps avec cette 'tablature'. Donc il ne faudrait compter que sur 7,8 Go disponibles au mieux.
Cloner «Mavericks» sans la partition 'Recovery HD' créée à l'installation sur le disque de destination, ça c'est parfaitement possible a posteriori (gain : 1,25 Go).
Alléger le Système «Mavericks» de ressources dispensables, c'est toujours possible encore : la sleepimage (s'il y a lieu) et les swapfiles (à remplacer par des fichiers verrouillés de 0 Ko --> gain : 1 Go).
Il est possible sans dommage encore (d'après mes tests personnels) de supprimer le contenu du dossier des 'Voix' (at : System/Library/Speech/Voices) --> gain = 550 Mo. Également de supprimer sans dommage le contenu des fonds d'écran-Système sauf l'image par défaut Wave.jpg pour avoir au moins un fond d'écran (at : /Library/Desktop Pictures) --> gain = 355 Mo.
En opérant ces allègements a posteriori, j'obtiens 7,49 Go de taille du Système. À cloner sur une clé dont l'espace disponible est donc de 7,8 Go. Théoriquement, ça peut passer rasibus, à condition que le logiciel de clonage accepte d'exécuter la tâche avec aussi peu de marge.
«Mavericks» générant énormément de cache, on peut toujours espérer que le cache des applications ouvertes est supporté en RAM pendant la session ouverte d'utilisateur et, faute d'espace pour écriture au disque lors de l'extinction, serait purement et simplement 'dissipé'. Mais quid du cache du kernel et du cache des extensions? Pfuiii! J'ai l'impression que c'est mal barré tout ça : pas assez de marge d'espace sur le disque-support.
◉
Sur le moment, j'ai pensé que Moon
Mais Jiminy Cricket n'arrêtait pas de striduler dans mon oreille gauche : rappelle-toi le coup de «Smart Sleep». Il s'agit d'un petit logiciel malin, qui offre le choix de changer l'hibernatemode à la volée dans une GUI, sans passer par la ligne de commande. Or ce petit fûté commence, lorsqu'il s'installe par exemple sur un Mac déjà en hibernatemode 0 et dont la sleepimage a été supprimée, par re-créer une sleepimage vide d'une taille équivalente à la RAM, afin justement qu'un espace-disque soit disponible au cas où l'utilisateur, abruptement, opterait pour l'hibernatemode 3.
J'ai donc fait le test sur mon iMac (hibernatemode 0 vérifié et sleepimage supprimée de /private/var/vm) d'installer sur une partition ad-hoc de DDE un OSX «Mavericks» tout neuf. J'ai répété 3 fois le test : chaque fois une sleepimage de la taille de la RAM est créée à l'adresse susdite, quoique sur le nouvel OS, l'hibernatemode 0 soit actif en miroir du Mac source de l'install.
J'en tire la conséquence qu'on ne peut pas éviter a priori, quel que soit le Mac qui supporte le processus d'installation d'OSX, la création formelle d'une sleepimage de la taille de la RAM du Mac 'support' (création qui s'effectue a priori, même si a posteriori ce fichier est destiné à ne pas recevoir d'écriture des contenus de la RAM). Il y a plus : quelqu'un qui boote sur le volume ainsi installé en attachant le disque-support (un DDE pour moi) à un autre Mac, voit la taille de la sleepimage d'origine varier comme la RAM du Mac auquel le disque est attaché : en bootant le «Mavericks» dont la sleepimage à l'install était de 8 go (miroir de la RAM de mon iMac) sur mon MacBook Pro dont la RAM est de 16 Go, la taille de la sleepimage du volume attaché se trouve dilatée en miroir à 16 Go après le boot. En hibernatemode 0! Seule la substitution d'un fichier verrouillé de 0 Ko à l'adresse indiquée bloque ce 'retaillage'.
Hum ça n'est pas ce que j'avais constaté jusqu'ici lorsque j'installais OS X sur un disque externe à partir d'un iMac. Je ferai des tests plus approfondis à l'occasion (Pas trop le temps en ce moment).
M
Membre supprimé 1060554
Invité
D'abord, le volume théorique de la clé (16 Go) a été amputé à la tablature en GUID des 210 Mo de la partition EFI invisible (disk1s1). Par ailleurs, je présume que même une version bêta de «Mavericks» crée un volume invisible de «Recovery HD», qui se mesure régulièrement à 1,25 Go (disk1s3). On a donc déjà 1,5 Go soustraits au volume principal visible où l'OS est installé, qui doit donc être environ de 14,5 Go exploitable (disk1s2).
Maintenant, la taille de l'installateur de «Mavericks» (5,1 Go pour la version officielle 10.9.2) ne mesure pas la taille des fichiers écrits à l'installation, car l'installateur est un bundle comprimé en écriture.
Enfin, les 4 répertoires visibles incluant les fichiers-Système de l'OS installé (Applications = 1,1 Go + Bibliothèque = 2,3 Go + Système = 6,1 Go + Utilisateurs = 230 Mo, pour un total -d'OS 'clean'- de 9,72 Go) ; n'englobent pas toutes les écritures de l'OS, puisqu'il faut compter en parallèle les répertoires invisibles, dont les 2 plus volumineux sont respectivement /usr d'environ 800 Mo et /private d'environ 1,4 Go de base + les 2 fichiers volumineux (at /private/var/vm) de 1 Go pour swapfile1 et 4/8/16 Go de sleepimage en fonction de la taille de la RAM du Mac-support.
Abstraction faite de la sleepimage, alors aux ≃ 9,72 Go des répertoires 'visibles', il faut ajouter ≃ 800 Mo d'usr + 2,4 Go de private (1,4 Go base + 1 Go de swapfile1 qui se recrée automatiquement si on n'instaure pas un fichier 0 Ko verrouillé du même nom) = 3,2 Go --> on arrive alors à 12,92 Go pour un volume exploitable de la clé de 14,5 Go (cf. ci-dessus --> disk1s2) - ce qui ne laisse une marge que de 1,6 Go. En vertu de ce que je peux bien appeler le «Théorème_de_Renaud», aucune sleepimage ne se créant en cas de place insuffisante à l'installation sur le disque de destination, et la taille minimum de la RAM du Mac pouvant supporter «Mavericks» étant de 4 Go, il est donc évident qu'aucune sleepimage n'est théoriquement présente at /private/var/vm. Sinon, le volume d'écriture requis serait de 12,92 Go + 4 Go (minimum) = 16,92 Go mimimum, ce qui excède le volume de la clé.
☞ il s'en déduit aisément que les fenêtres d'info du Finder mesurent la taille des fichiers/répertoires visibles de l'OS, non celle des fichiers/répertoires invisibles qui sont exclus de la mesure. Si je fais ⌘I sur le volume de l'OS-test que j'ai installé sur la partition d'un DDE, le Finder affiche 9,72 utilisés (càd. la somme des dossiers visibles), là où, addition faite des 3,2 Go invisibles, l'espace réellement occupé est de 12,92 Go (compte non tenu des 'petits' répertoires : bin, sbin etc. ce qui nous conduit aux 13 Go finaux).
♤
Par ailleurs, j'ai dégoté une clé USB on ne peut plus basique de 8 Go et j'ai pu faire cloner par «Carbon Copy Cloner» une version de «Mavericks 10.9.2» allégée a posteriori à 7,71 Go (ablation des swapfiles, absence de sleepimage, élimination des voices ainsi que des Desktop Pictures et évidemment non clonage de la 'Recovery HD'). Sachant qu'il y a sur la clé une partition EFI de 210 Mo, l'espace occupé global est donc de 7,92 Go sur 8 Go
.Ahaaa! Démarrer sur une telle clé est ce qu'on peut appeler un authentique exercice de patience (comme r e m y
le pronostiquait bien dans un autre fil remonté à la surface de l'actualité ☞ici☜ --> il faut 15' au kernel pour réussir à charger l'infrastructure UNIX de l'OS, et il faut 15' au processus launchd pour compléter le chargement de l'OS jusqu'à la LoginWindow d'ouverture de session. Sans compter bien 10' pour la mise en place de la GUI d'utilisateur. La moindre action au pointeur déclenchant bien évidemment le 'ballon de plage'...☞ j'en tire personnellement les conclusions qui s'imposent : non seulement une clé USB de 8 Go est ininstallable a priori par «Mavericks» et seulement clonable à l'extrême rigueur par une version allégée a posteriori du Système ; mais la vitesse de transfert ridiculement lente des données entre le Mac et pareil disque attaché rend inexploitable raisonnablement un pareil support comme disque de démarrage d'un Mac. Je ne peux que souscrire à l'avis de r e m y dans le fil évoqué : le choix rationnel est celui d'un DDE de boot dont on réserve une (ou plusieurs) partition(s) à des tests d'OS. C'est ce que je fais toujours sans problème notable.
♧
Dernière édition par un modérateur:
Et ces fichiers invisible tu fais comment pour les supprimer?
En supprimant les langues j'ai enlevé 1,4Go, il ne reste pourtant que 1,25Go de libre...
Je savais que ce serai lent, mais étant donné que c'est juste par expérience je m'en fiche.
En supprimant les langues j'ai enlevé 1,4Go, il ne reste pourtant que 1,25Go de libre...
Je savais que ce serai lent, mais étant donné que c'est juste par expérience je m'en fiche.
Merci à tous. Je vois que pendant mon absence le sujet a chauffé. Je voulais apprendre & comprendre & là j'en suis servi, même si j'ai pas tout digéré, j'apprécie les détails.
J'ai mis Mavericks dans une clé 8 Go suivant les indications du site Apple et "Comment ça marche" & 2 autres pages web consultés il y a plus d'un mois...
C'est CCC qui a fait un clone du système du DD int sans les Applis. Et il restait 40 Mo d libres dans la clé.
Elle fonctionnait jusqu'au moment où j'ai essayé d'ajouter des outils. Je suis prêt à recommencer (en mieux) d'où ma requête initiale.
fousfous : Pour accéder aux fichier invisibles je demande à TinkerTool.
J'ai mis Mavericks dans une clé 8 Go suivant les indications du site Apple et "Comment ça marche" & 2 autres pages web consultés il y a plus d'un mois...
C'est CCC qui a fait un clone du système du DD int sans les Applis. Et il restait 40 Mo d libres dans la clé.
Elle fonctionnait jusqu'au moment où j'ai essayé d'ajouter des outils. Je suis prêt à recommencer (en mieux) d'où ma requête initiale.
fousfous : Pour accéder aux fichier invisibles je demande à TinkerTool.
Tu as mal lu : c'est l'installeur de Mavericks qui doit être mis sur une clé de 8 Go, pas le système installé.
Plouf. Je suis confus.
Et j'ai réalisé un exploit?
"Il ne savait pas que c'était impossible, alors il l'a fait"
.
Bonjour,
Je suis surpris ! En relisant de près la prose de macomaniac de constater que la taille de la sleepimage est toujours de la taille de la ram.
Hors chez moi, sur Imac 27" et sur le macbook pro, tout deux avec 8 Go de ram et en hibernatemode 0, la taille de la sleepimage est de 2,15 Go.
Pour être sur du fait, j'ai supprimé le fichier sleepimage et après redemarrage le fichier recréé est bien de 2,15 Go.
Je m'en était rendu compte il y à 3 semaines lors d'un ajout de mémoire (16Go de marque crucial) j'avais un kernel panique à chaque mise en suspension d'activité.Soupçonnant que le problème venait de l'écriture de la sleepimage dans la ram au réveil, J'ai tout essayé pour éviter ce kernel panique, sans trouver de solution fiable, j'ai fini par rendre les barrettes en cause.
Donc chez moi la sleepimage n'est pas de taille égale à la RAM !:eek:
Je suis surpris ! En relisant de près la prose de macomaniac de constater que la taille de la sleepimage est toujours de la taille de la ram.
Hors chez moi, sur Imac 27" et sur le macbook pro, tout deux avec 8 Go de ram et en hibernatemode 0, la taille de la sleepimage est de 2,15 Go.
Pour être sur du fait, j'ai supprimé le fichier sleepimage et après redemarrage le fichier recréé est bien de 2,15 Go.
Je m'en était rendu compte il y à 3 semaines lors d'un ajout de mémoire (16Go de marque crucial) j'avais un kernel panique à chaque mise en suspension d'activité.Soupçonnant que le problème venait de l'écriture de la sleepimage dans la ram au réveil, J'ai tout essayé pour éviter ce kernel panique, sans trouver de solution fiable, j'ai fini par rendre les barrettes en cause.
Donc chez moi la sleepimage n'est pas de taille égale à la RAM !:eek:
Sur mon MBP avec 4 Go de RAM et en hibernatemode 3, la taille de la sleepimage est de 2,15 Go. :heu:
---------- Nouveau message ajouté à 18h27 ---------- Le message précédent a été envoyé à 18h19 ----------
Il n'y a que toi qui veuilles alléger
= ou tu achètes une clé USB de 32 Go, et tu la promènes avec ton MBP,
ou tu clones ton système (actuel ou neuf) sur une partition externe (et éventuellement l'installeur de la clé 8 Go sur une autre parition).
De mon côté, j'ai un clone (qui contient tous les bons utilitaires de dépannage),
et, ailleurs, une simple copie de l'application d'installation de 10.9 (qui me permettra de refaire une clé de 8 Go si un jour j'en ai le besoin ou l'envie)
et, encore ailleurs, un clone de la partition Recovery
= je n'ai pas confiance dans la durée de vie des clés USB.
