remy!
[
M'enfin! Tu te sens tellement pressé de re-démarrer la vie virtuelle? - Inversement, je trouve qu'avoir un Mac qui prend tout son temps au démarrage me ménage une espèce de 'pause préliminaire', comme lors de ces faux-départs des courses de sprint, si bien qu'une fois en prise avec l'espace informatique, je vais garder la rémanence de ce délai en une sorte d'imperceptible distance_aux_processus. Un 'n'y_pas_être' où je respire en liberté. <Te connaissant plein d'humour, je sais que tu prendras cette 'profession-de-foi' cum grano salis >]
⎋
Indépendamment des questions de
préférences personnelles que je viens de mettre entre parenthèses
au démarrage , le problème que tu soulèves est intéressant
in se & per se.
Je pense que le réglage que tu souhaitais, possible sur les ordinateurs faisant tourner
Mac OS 9, est indisponible avec les Macs Intel supportant
OS X. Car la vérification_mémoire fait partie du
POST (Power-On-Self-Test) qui est inscrit dans la
Boot_ROM stockée sur la Carte-Mère. Je ne vois pas comment on pourrait interférer dans cet automatisme.
Maintenant, ta conjecture que l'augmentation du nombre de barrettes RAM rallonge
sensiblement le temps du
POST me surprend. Car l'exécution du
POST est tout ce qu'il y a de plus rapide sur un Mac. Mais peut-être y a-t-il divergence d'interprétation du processus de
boot - par quoi j'entends la façon de mettre en corrélation la succession des «
phénomènes sensibles» (sons de démarrage et affichages à l'écran) avec l'«
enchaînement réel» (ce qui se passe effectivement derrière ces signaux)? [
C'est d'autant plus possible, que la «chose en soi» échappe à l'«expérience» et n'est l'objet que de conjectures, comme le martèle le vieux Kant qui à n'en pas douter aurait été ravi par la contemplation d'un Mac en lequel il aurait vu une preuve du bien-fondé de sa théorie critique ]
⎋
Je me jette alors à l'eau à mes risques et périls, en délivrant ma vision schématique du déroulement. Ayant un
MacBook Pro_Early 2011, 8 Go de RAM d'usine, avec un DDI (pas de SSD), donc un engin qui me permet de respirer tranquillement tout le temps du démarrage
, j'ai noté au chronomètre les temps correspondants aux signaux sensibles lors du démarrage [
Comme je fais partie de ceux que le 'Chime' (carrillon de démarrage) horripile, normalement il est neutralisé puis le son restauré à l'ouverture de session grâce à un jeu de LogoutHook et de LonginHook. Afin de pouvoir noter le temps d'intervention du 'Chime', j'ai donc détruit provisoirement mes 'hameçons' - que je ne manquerai pas de reconstituer ultérieurement, je te rassure .]
-a) Appui du bouton 'Power' → signal sonore du test du Super-Drive = 0"
-b) Chime → écran clair = 2,5"
-c) Écran gris + Pomme seule = 6,5"
-d) Écran gris + Pomme + roue crantée giratoire = 12"
-e) Écran gris + Pomme seule da cappo = 26"
-f) Fenêtre de Login = 38"
[Je te fais grâce du
lent processus de chargement de ma session d'utilisateur, grevé par une foultitude d'applications activées au démarrage. En moyenne, donc, à partir de l'instant 0 où j'appuie sur le bouton 'Power', il faut 38" pour que la fenêtre de
Login s'affiche, et 2' 30" en tout pour que ma session d'utilisateur soit exhaustivement chargée, soit 1' 52" de chargement de mon espace d'utilisateur (
)]
⎋
Maintenant, voici mon interprétation :
- de a) à b) : exécution du POST dont le signal de démarrage = celui du test du Super-drive, et le signal de complétion est le Chime. Temps : 2,5". Je ne vois pas que mes 8Go de RAM fasse traîner quoi que ce soit. L'affichage de l'écran clair sans logo, juste après le Chime : l'EFI_Boot, après exécution du POST, vient de trouver le 'Booter_File' dont le chemin est stocké en NVRAM : il s'agit du fichier boot.efi (System/Library/CoreServices) de l'OS installé sur le disque interne (en cas de boot régulier).
- de b) à c) (pomme seule) : exécution du booter (comme tu peux voir, ça prend étrangement du temps sur mon Mac non customisé = 4"!).
- de c) à d) (pomme roue crantée) : chargement du kernel et des KEXTs à l'initiative du booter = 5,5"
- de d) à e) (pomme seule da cappo) : exécution du processus launchd (principalement) = 14"
- de e) à f) (LoginWindow) : exécution du processus WindowServer = 12"
- f) (fenêtre de Login) : espace d'utilisateur prêt à être chargé (38" au total à partir du démarrage).
⎋
Il y a donc une
étrangeté dans l'ensemble de ce déroulement, c'est le temps réclamé par le
booter :
boot.efi pour exécuter son programme (les limites signalées de son processus sont : en
amont =
Écran clair juste après
Chime ; en
aval =
Écran gris + Pomme seule).
C'est ici que je placerais une
conjecture (dont je suis fertile
) : le
booter ne va pas directement au chargement du
kernel et des
kexts, mais il prend le temps d'un détour par
private/var/vm (notamment) histoire de vérifier le statut de la
sleepimage. Ce qui me le fait dire, c'est que quand je fais le test de démarrer à partir d'un état d'
hibernation stricte (
hibernatemode 1) commandé dans le «
Terminal» -
hibernation qui est une véritable
extinction du Mac, avec re-démarrage obligé sur
EFI_ROM_Boot et donc exécution du
POST et lancement du
Booter - l'instruction stockée d'activation logicielle est celle de relancer les processus à partir de la lecture de la
sleepimage strictement et rigoureusement. Dans ce cas de figure, après l'exécution du
POST (= 2,5"), il ne faut que 2" au
Booter pour activer la relance des processus à partir de la
sleepimage - ce qui se signale par l'affichage à l'écran d'un
filigrane laiteux du Bureau de la session active. À partir de quoi, il faut 9" à mon Mac non customisé pour avoir complété l'exécution des processus à partir de la
sleepimage . Je re-démarre donc, en sortie d'
hibernation qui est donc une
extinction du Mac (et aucunement un '
sommeil') en exactement
14'.
Je conjecturerais donc, sur ton Mac, que la différence de la RAM ne conduit pas notablement à une augmentation du délai du
POST, mais à une augmentation du délai d'exécution du
Booter (
boot.efi) par l'augmentation du volume des données stockées dans la
sleepimage dont le
Booter assurerait la vérification avant déclenchement du chargement du
kernel et des
kexts, même si tu n'es pas en option
hibernatemode 1, mais je le présume en option par défaut
hibernatemode 3 = '
SAFE_SLEEP'.
[
La possibilité tout à fait étrange d'un re-démarrage complet sur un Mac non customisé en exactement 14" à partir de l'état d'hibernation (qui est une véritable extinction et pas un 'sommeil'), càd. par instruction au Booter de booter logiciellement à partir de la sleepimage, par contournement donc de la tâche de chargement préalable du kernel et des kexts, ne paraît envisageable qu'avec une architecture_noyau non strictement monolithique.]
⎋
