neo_cd
Alors voici le scénario « moyen » tel que je me l'imagine :
- disons qu'à 20 heures du soir tu "démarres" ton iMac et tu utilises ta session jusqu'à minuit
- à minuit > tu forces la mise-en-sommeil (sleep) directe du Système (kernel) via l'option du menu
- comme l'iMac ne va pas être "réveillé" jusqu'à 8 heures du soir du lendemain (laps de temps de 20 heures d'inactivité) > la fonction standby activée intervient après le délai de sommeil simple (sleep) fixé par le standbydelay qui est de 3 heures --> donc aux alentours de 3 heures du matin > le Système du Mac passe au mode hibernation (qui est l'effet du standby)
- [ce passage à l'hibernation du Système > en supprimant l'état de sommeil (simple sleep) antérieur > « coupe l'herbe sous les pieds » (si je puis dire) de la fonctionnalité autopoweroff (passage au sommeil profond = deep sleep) > dans la mesure où cette fonctionnalité est réglée sur un délai de 8 heures de sommeil simple. Disparu l'état de sommeil (avec le passage à l'hibernation) > disparu l'état de référence permettant l'activation de la fonctionnalité autopoweroff.]
=> on a donc affaire à un Système du Mac qui hiberne de 3 heures du matin à 20 heures du soir (en moyenne) > soit pendant 17 heures.
----------
Étant donné ce scénario moyen que je suppose > qu'est-ce que la fonction
standby (convertissant le sommeil en hibernation) fait-elle intervenir comme différence ? - pour l'essentiel (me figuré-je) une
désactivation de la
RAM dont les contenus sont effacés > après leur sauvegarde à une
sleepimage sur le disque. Aussi le Mac se réveillera-t-il de l'hibernation dans laquelle l'a plongé le
standby > par une recopie dans la
RAM du contenu de la
sleepimage > ce qui reconstituera le contexte initial.
Pourquoi ce scénario en principe bien réglé donne-t-il lieu chez toi, au réveil, à un écran avec un dossier incluant le
?
----------
Ce cas de figure m'intrigue puissamment par ses implications théoriques - mais je t'annonce que je passe ici carrément en mode : « imagination conceptuelle » [rêverie logique].
Le dossier avec le
? signale qu'un volume démarrable n'est pas trouvé. Cela ne peut vouloir dire qu'une chose : le
kernel (ou noyau du Système opérateur recelé dans le volume
Macintosh HD) a été
arrêté carrément avec le passage à l'hibernation (et pas seulement ralenti dans ses opérations). Car (simple argument par l'absurde) : si le
kernel avait continué d'être en fonction > le volume qui le recèle aurait forcément continué d'être monté et ne pourrait pas être introuvable. Donc le
kernel doit à toute force
quitter avec le passage à l'hibernation. Càd. que le Système intégral doit s'éteindre. Le fait que l'hibernation déclenchée par le
standby implique la
désactivation de la
RAM après sauvegarde de son contenu à une
sleepimage du disque > signifie
ipso facto que la
kernel_task = le processus du
kernel en
RAM est forcément terminée.
Or c'est le
kernel qui supporte le montage des volumes (dans le temps "opératoire"). On admettra donc sans trop de difficulté que tous les volumes des partitions sont alors
démontés pendant l'hibernation.
Comment s'opère alors le réveil du Mac ? - ton échec (et cet échec seul - car les réussites n'ont jamais une valeur théorique > seul les incidents remarquables conduisent "récursivement" à imaginer ce qui devrait se passer et qui ne se passe pas) m'amène à me figurer le scénario suivant : le
kernel étant
éteint > le processus de
boot doit être relancé à la racine. Càd. par le logiciel de démarrage qui est l'
EFI de la Carte-Mère.
Mais si l'
EFI se trouvait relancée comme dans le cas de figure d'un
démarrage absolu > alors il n'y aurait pas de problème de volume non trouvé > car tous les volumes montables sont montés automatiquement
dans le temps du boot > de manière à ce que l'
EFI puisse adresser le volume de démarrage automatique. Je suis donc conduit à me représenter le réveil du Mac sur le modèle de ce qui se passe lors d'une
installation de l'OS : le Mac
re-démarre plusieurs fois > donc par l'
EFI > sans du tout que ce logiciel ne refasse la séquence préliminaire du check-up hardware (=
POST) > mais selon un mode purement logiciel. C'est ce qui me paraît s'effectuer aussi lors d'un démarrage par internet : une fois l'image-disque de démarrage téléchargée en
RAM > une commande relance l'
EFI pour
exécution directe du démarreur du Système de l'image-disque.
Or tu as le [malheur] d'avoir fait la mise-à-niveau directe au système de stockage
APFS (beta !). Tu as donc un
Conteneur Logique reposant en mode "
Fusion Style" sur 2 magasins de stockage physique
Physical Stores (un sur la partition du SSD et un sur celle du HDD). Ce
Conteneur Logique recèle 4
Volumes Logiques virtuels : celui de
macOS > celui du
preboot > celui de la
recovery > celui de la
vm.
Le volume de la
recovery ne joue aucun rôle dans le démarrage. C'est le volume du
preboot qui fait tout : il assume la fonction de
booter du volume
macOS > en recelant un démarreur
boot.efi et un cache de démarrage
prelinkedkernel. Le volume
vm (
virtual memory) recèle la
sleepimage à laquelle a été écrite le contexte de la
RAM avant passage à l'hibernation. Je suppose alors que le réveil de ce mode hibernation doit se faire par une espèce de
court-circuit où le
boot_loader boot.efi recharge directement la
RAM à partir de la
sleepimage du volume
vm > re-démarrant ainsi la
kernel_task dans son contexte précédent. Ce qui implique nécessairement qu'au moment du passage à l'hibernation de la part du
standby > non seulement le contexte de la
RAM a été écrit au volume
vm > mais qu'une
instruction provisoire pour l'
EFI a dû être écrite en
NVRAM > lui intimant lors de son exécution du
boot_loader boot.efi de lui passer l'argument d'avoir à recharger la
RAM à partir de la
sleepimage du volume
vm.
Soit ! - encore faut-il que l'
EFI réactivée en mode "
re-démarrage logiciel direct" > et ayant chargé les instructions de la
NVRAM > trouve le volume
preboot monté > pour pouvoir exécuter son
boot_loader boot.efi. Et.... ton cas de figure montre qu'à ce moment-là > le volume
preboot n'est
pas monté. Donc le volume
macOS ne peut pas être
réactivé à partir de la
vm. Donc l'
EFI relance son logiciel auxiliaire
boot_manager > lequel... ne trouve pas le volume monté attendu (
preboot) > et pof ! dossier avec le
?
----------
Je pense donc que ton intuition initiale était correcte :
Depuis que j'ai installé la première beta, j'ai un bug qui n'était jamais apparu auparavant où durant la mise en veille de l'iMac, un dossier avec un point d'interrogation apparait.
Je pense que c'est un
bogue du système de stockage
APFS - du moins dans un dispositif "
Fusion Style" où le
Conteneur Logique est supporté par 2 magasins de stockage physiques sur 2 partitions de disques distincts : le volume
preboot n'est
pas remonté au moment du réveil d'hibernation du Mac > ce qui fait que l'
EFI ne parvient pas à le trouver pour exécuter le
booter APFS et lui passer l'argument spécifique : recharger la
RAM à partir de la
sleepimage du volume
vm.
[Disons que tu t'es complu à cumuler les difficultés :
convertir un
CoreStorage "
Fusion Drive" au mode
APFS "
Fusion Style" et lui coller par le
standby le passage à l'
hibernation.]
En conséquence > je pense que tu as 2 choix provisoires pour pallier ce bogue :
- soit éteindre ton Mac tous les soirs et le rallumer normalement quand tu veux t'en servir (vu ton usage vespéral > cela me paraît une option raisonnable)
- soit désactiver les 2 options standby et autopoweroff (je peux te passer les commandes ad hoc) pour interdire le virage du sommeil (sleep) du Mac à l'état d'hibernation --> la RAM demeurant sous tension > le kernel ne quittera pas > et le réveil devrait se produire instantanément à partir du contexte de la RAM.
