Ecran noir démarrage très long.

Enleve ta carte SD et refait un test
 
Fait sans carte SD, même erreur lors du test et même lenteur lors du démarrage. On tiens une piste ;)
J'ai programmé un RDV téléphonique avec l'Apple Care pour demain aprem.
 
Tien nous au courant de l’avancer :)
 
  • J’aime
Réactions: Liyad
Salut Liyad.

En rapport avec ta question :

est-ce que toute la partie avant la pomme qui s'affiche fait partie de Mac OSX ou est-ce que c'est l'EFI ou autre chose ?

je te propose un peu de « théorie » - sans grandes conséquences « pratiques » malheureusement...


L'affichage du logo  signale le lancement du boot_loader : boot.efi de l'OS : le fichier démarreur du Système logique du disque, localisé sur la partition /dev/disk0s2 at: /System/Library/CoreServices/boot.efi. Par rapport à cet affichage de la , il y a donc l'« avant » et l'« après ».

L'« après » => c'est le « boot » à proprement parler (le processus logique sur le disque ou démarrage d'OS X) : le boot_loader : boot.efi charge le cache de démarrage-Système prelinkedkernelEl Capitan») ou kernelcache (OS antérieurs), ce qui revient à démarrer le kernel (micro-noyau) dont le code fait partie du cache et à lui injecter le bloc des kexts (extensions du noyau = pilotes du hardware). Cela fait, le kernel lance le processus launchd qui met en route le Système logique de l'OS, jusqu'à affichage du LoginWindow (écran d'ouverture de session) qui permet d'ouvrir une session graphique. Le démarrage du kernel se signale par la barre de chargement sous le logo .

L'« avant » => c'est le « pré-boot » spécifiquement : il est entièrement du ressort de l'EFI (micrologiciel recelé dans une puce de la Carte-Mère, qui constitue le Firmware du Mac ou Programme Interne). Ce pré-boot peut se décrire ainsi :

- a) exécution préalable du POST (Power-On Self-Test) = vérification de la compatibilité réciproque des éléments du hardware, impliquant un test de présence du Super-Drive s'il y a lieu, mais sans qu'il s'agisse d'un scan de la fonctionnalité terme à terme de chacun de ces composants intrinsèquement (Carte-Graphique, RAM etc). Le POST, en cas de validation, se conclut par le retentissement du Chime (carillon ou gong) - il est donc possible que le POST retentisse avec une Carte-Graphique HS par exemple, car ce qui a été validé est sa compatibilité, non son ustensilité.

- b) chargement des paramètres de la NVRAM : l'EFI visite cette mémoire statique de la Carte-Mère, charge les flags qui y sont inscrits (genre : SIP sous «El Capitan») et lit l'identité d'une partition de disque démarrable ou efi_boot_device (si elle est inscrite, sous forme d'UUID) ;

- c) activation des ressources foncières du hardware : l'EFI déclenche l'activation du CPU (processeur), de la Carte-Graphique, de la RAM...

- d) exécution du boot.efi : l'EFI va au système de fichiers recelé dans l'efi_boot_device (ou partition de disque) et, si ce système de fichiers est "béni" (blessed), alors le header (en-tête) de ce système de fichiers porte le chemin à suivre dans l'arborescence de l'OS pour atteindre le boot_loader : boot_efi à exécuter. Une fois exécuté le boot_loader boot.efi, l'EFI quitte en lui passant la main. Si le header du système de fichiers recelé dans l'efi_boot_device n'est pas "béni" (rare, mais accidentellement possible), le programme auxiliaire DiskManager est lancé afin de scanner le système de fichiers en vue de déceler la présence d'un boot_loader boot.efi. Si aucun efi_boot_device n'était mentionné en NVRAM, là encore le DiskManager est lancé pour scanner directement les headers (en-têtes) des systèmes de fichiers résidant sur les partitions des disques attachés au Mac, afin de vérifier s'il y a trace d'un « blessing » (inscription du chemin au boot_loader boot.efi enfoui dans l'arborescence logique de l'OS) ; en cas d'absence de blessing, le DiskManager ne scanne que l'espace-racine des volumes, sans descendre plus bas dans leur arborescence. Le premier boot.efi repéré est exécuté.​


C'est la pression sur le bouton "Power" qui lance l'EFI. L'écran du Mac reste noir aussi longtemps que la séquence est celle du pré-boot (opération de l'EFI). Pourquoi chez toi environ 3' - ce qui est beaucoup plus long que la normale ? Retour aux phases de la séquence-EFI :

- a) L'exécution du POST est très rapide (une poignée de secondes) : tu peux mesurer sur ton Mac combien de temps s'écoule approximativement entre ta pression sur le bouton "Power" et le retentissement du Chime (qui sanctionne immédiatement la fin du POST) : s'il ne s'agit que de quelques secondes, alors ton problème de délai au démarrage ne relève pas du POST (ce qui ne veut pas dire, comme mentionné plus haut, que chaque composant de la Carte-Mère est fonctionnel, mais qu'il n'y a pas incompatibilité réciproque des compostants).

- b) Le chargement des paramètres de la NVRAM est lui aussi très rapide en ce qui concerne les flags inscrits (que l'EFI passera au boot_loader boot.efi, lequel les injectera dans le kernel à son tour) : il n'y a pas de probabilités que ce soit le processus de chargement logique à cette étape qui cause un délai.

Reste alors les deux moments c) et d).

- c) S'il y a un problème d'« ustensilité » de composants du hardware activés directement par l'EFI dans le pré-boot, sans qu'il s'agisse d'une panne radicale, il n'est pas impossible a priori que ça puisse « ramer ». Je me souvient d'un fil déjà ancien dans lequel r e m y :coucou:, après avoir doublé la RAM de son Mac, signalait un allongement du temps du pré-boot dépendant de l'EFI. Ce qui avait donné lieu à l'énoncé humoristique d'un « Paradoxe de r e m y » : « Plus il y a de RAM, plus ça rame au démarrage... ». Comme si l'activation de la RAM impliquait un... temps proportionnel à sa taille. Alors (et de manière purement conjecturale, de ma part) : pourquoi ne pas imaginer que l'activation du CPU, de la Carte-Graphique et autre RAM puisse, en cas de problèmes intrinsèques sans panne radicale, voir s'augmenter le délai requis ? Avec évidemment écran noir aussi longtemps que se poursuit le processus de l'EFI...

- d) S'il y a un problème d'identification d'un efi_boot_device (= secteur-disque de démarrage pour l'EFI), ou s'il y a un problème de blessing de l'en-tête du système de fichiers recelé dans cette partition : alors cette fois ce n'est plus un problème matériel qui est responsable du délai de mise en route ; mais un problème logique de lacune d'information. La présence d'un dispositif CoreStorage sur la partition /dev/disk0s2 de l'OS au lieu d'un système de fichiers au format HFS+ standard, surtout s'il s'agit d'un CoreStorage Chiffré (suite à l'activation de «FileVault»), peut augmenter le délai d'exécution d'un boot_loader : boot.efi par l'EFI.


Afin d'essayer de tirer de ces considérations « spéculatives » quelques effets « pratiques », une fois que tu as réussi à ouvrir ta session d'utilisateur, tu pourrais aller à : Applications/Utilitaires et lancer le «Terminal».

- 1° Passe d'abord la commande (purement informative et sans impact-Système) :

Bloc de code:
nvram -p
et ↩︎ (presse la touche "Entrée" du clavier pour activer la commande) --> en retour, tu vas voir s'afficher le tableau de paramétrage actuel de ta NVRAM, sous une forme qui paraît assez inscrutable a priori --> est-ce que tu peux sélectionner l'ensemble des lignes de ce tableau, par ⌘C les copier dans le presse-papier et par ⌘V les coller ici dans ton fil ? - Ce, afin qu'il soit possible de vérifier si un efi_boot_device est bien mentionné en bonne et due forme, entre autres (et lequel) ?

- 2° Tu peux ensuite passer la commande (informative encore) :

Bloc de code:
bless --info --getBoot
et ↩︎ --> le secteur-disque de boot va s'afficher (s'il y a lieu) : peux-tu le copier-coller ici ? Et tu peux encore passer la commande (toujours informative) :

Bloc de code:
bless --info
et ↩︎ --> les désignations du dossier et du fichier de boot sur l'efi_boot_device vont être retournées en cas de blessing régulier --> idem : copier-coller ici => tout cela, pour vérifier si tout est conforme au standard dans ces paramètres ou s'il y aurait des anomalies logiques...

- 3° Tu pourrais finalement passer la commande classique (informative) :

Bloc de code:
diskutil list
et ↩︎ et copier-coller le tableau retourné de partitionnement de ton SSD interne (/dev/disk0) : histoire de voir ce qu'il en est. Et pour finir :

Bloc de code:
diskutil cs list
et ↩︎ --> si tu as un CoreStorage sur la partition /dev/disk0s2 de ton SSD, tu vas voir s'afficher le tableau complexe d'un Logical Volume Group --> si c'est le cas, idem : copier-coller de l'ensemble du Tableau afin de voir ce qu'il en est. Sinon, tu toucheras un : No Logical Volume Groups found...

- 4° Je serais (marginalement) curieux de vérifier les conséquences d'une commande (informative) :

Bloc de code:
pmset -g custom
et ↩︎ --> histoire de vérifier le statut de l'hibernatemode sur ton Mac...

 
Dernière édition par un modérateur:
Bonjour !
Déjà, ouaw ! C'est hyper complet et hyper intéressant, je comprend vraiment ce qu'il se passe dans ma machine !
Le chime retenti dès le début, donc c'est un soucis à enlever.

Voici ce que tu me demande :
nvram -p a dit:
bluetoothInternalControllerInfo %90%82%ac%05%00%000%14%d8%96%95%f3%e9V
fmm-computer-name MacBook Pro de William
bluetoothActiveControllerInfo %90%82%ac%05%00%00%00%000%14%d8%96%95%f3%e9V
ALS_Data ^%0d%8a%8a%00%00%00%00
SystemAudioVolume
SystemAudioVolumeDB %d1
LocationServicesEnabled %01
backlight-level .%01
aht-results <dict><key>_name</key><string>spdiags_aht_value</string><key>spdiags_last_run_key</key><date>2016-01-01T19:53:53Z</date><key>spdiags_version_key</key><string>1.0.16r3</string><key>spdiags_reference_code_key</key><string>VDC001</string></dict>
BootCampProcessorPstates %0b%00

bless --info --getBoot a dit:
Can't access "efi-boot-device" NVRAM variable

J'ai déjà fait CMD+OPT+P+R de nombreuses fois, étrange d'avoir ce retour non ?

bless --info a dit:
Can't access "efi-boot-device" NVRAM variable

diskutil list a dit:
#: TYPE NAME SIZE IDENTIFIER

0: GUID_partition_scheme *121.3 GB disk0

1: EFI EFI 209.7 MB disk0s1

2: Apple_HFS Macintosh HD 119.8 GB disk0s2

3: Apple_Boot Recovery HD 1.2 GB disk0s3

/dev/disk1 (internal, physical):

#: TYPE NAME SIZE IDENTIFIER

0: FDisk_partition_scheme *32.0 GB disk1

1: Apple_HFS SD 32.0 GB disk1s1


diskutil cs list a dit:
No CoreStorage logical volume groups found

Et enfin,

pmset -g custom a dit:
MBPdeWilliam2:~ William$ pmset -g custom

Battery Power:

lidwake 1

autopoweroff 1

autopoweroffdelay 14400

standbydelay 10800

standby 1

ttyskeepawake 1

hibernatemode 3

powernap 0

gpuswitch 2

hibernatefile /var/vm/sleepimage

displaysleep 2

sleep 1

acwake 0

halfdim 1

lessbright 1

disksleep 10

AC Power:

lidwake 1

autopoweroff 1

autopoweroffdelay 14400

standbydelay 10800

standby 1

ttyskeepawake 1

hibernatemode 3

powernap 1

gpuswitch 2

hibernatefile /var/vm/sleepimage

womp 1

displaysleep 0

networkoversleep 0

sleep 0

acwake 0

halfdim 1

disksleep 10
 
Je viens d'avoir l'Apple Care au téléphone, prise de rendez-vous avec un technicien qui viens chez moi (je ne savais pas que ça existait !) pour peut être aujourd'hui, mais plus vraisemblablement lundi ou mardi.
 
Eh bien ! Tu l'as ta réponse : aucun efi_boot_device n'est renseigné en NVRAM. Résultat : quand l'EFI a terminé le POST et visite la NVRAM, il n'y a aucune mention d'une partition-disque de boot nulle part qui lui indiquerait le chemin de la partition /dev/disk0s2 = Macintosh HD (par l'UUID). Et ça n'a pas l'air plus reluisant question blessing de ce système de fichiers... Conséquence : l'EFI est plantée là, sans aucun PATH de boot, bien obligée de lancer son programme auxiliaire DiskManager, pour scanner les partitions disponibles et l'arborescence d'OS X en profondeur avant que le boot.efi soit trouvé at: /System/Library/CoreServices. Pas étonnant que ça prenne un temps fou !
450622_original.gif


Tu as un MacBook Pro Retina 2015. OS d'usine «Yosemite 10.10.1 ou 2». Il y a des chances que ton OS actuel soit devenu «El Capitan». Eh bien ! le contenu de la NVRAM de ta bécane est totalement inacceptable. Anémique de chez anémique ! Tu veux voir le tableau de la NVRAM de mon MacBook Pro 17 Late_2011 qui supporte «El Capitan» ?

Bloc de code:
tbt-options    %00

efi-apple-payload0-data    %02%01%0c%00%d0A%03%0a%00%00%00%00%01%01%06%00%02%1f%03%12%0a%00%00%00%00%00%00%00%04%01*%00%01%00%00%00(%00%00%00%00%00%00%00%00@%06%00%00%00%00%00%00n%1a%b5 C%fbJ%86%fb%e7%1f%18%e6%f7%fb%02%02%04%04H%00\%00E%00F%00I%00\%00A%00P%00P%00L%00E%00\%00F%00I%00R%00M%00W%00A%00R%00E%00\%00P%00o%00r%00t%00M%00i%00c%00r%00o%00.%00b%00i%00n%00%00%00%7f%ff%04%00

gpu-policy    %01

efi-boot-device    <array><dict><key>IOMatch</key><dict><key>IOProviderClass</key><string>IOMedia</string><key>IOPropertyMatch</key><dict><key>UUID</key><string>4295CE3C-198D-4666-BEF7-5BC170A96C91</string></dict></dict><key>IOEFIShortForm</key><true/><key>BLLastBSDName</key><string>disk0s1</string></dict><dict><key>IOEFIDevicePathType</key><string>MediaFilePath</string><key>Path</key><string>\EFI\refind\refind_x64.efi</string></dict></array>%00

IORegistryCurrentSleepMode    %00

prev-lang:kbd    fr:1111

EFICapsule_Result    STAR

efi-apple-recovery    <array><dict><key>IOMatch</key><dict><key>IOProviderClass</key><string>IOMedia</string><key>IOPropertyMatch</key><dict><key>UUID</key><string>B51A6E00-4320-4AFB-86FB-E71F18E6F7FB</string></dict></dict><key>BLLastBSDName</key><string>disk0s1</string></dict><dict><key>IOEFIDevicePathType</key><string>MediaFilePath</string><key>Path</key><string>\EFI\APPLE\FIRMWARE\MBP81_0047_2AB_LOCKED.scap</string></dict></array>%00

SystemAudioVolumeDB    %f3

BootCampHD    %02%01%0c%00%d0A%03%0a%00%00%00%00%01%01%06%00%02%1f%03%12%0a%00%00%00%00%00%00%00%7f%ff%04%00

ThorUpdateResult    %00%00%05%0e%01%03%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00

csr-active-config    w%00%00%00

fmm-computer-name    MacBook Pro

backlight-level    %ff%03

SmcFlasherResult    %00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00

bluetoothActiveControllerInfo    %1a%82%ac%05%00%00%000%11%fa`%c5G%95%d1%cf

RemoteDisabled    %01

efi-apple-payload0    <array><dict><key>IOMatch</key><dict><key>IOProviderClass</key><string>IOMedia</string><key>IOPropertyMatch</key><dict><key>UUID</key><string>B51A6E00-4320-4AFB-86FB-E71F18E6F7FB</string></dict></dict><key>BLLastBSDName</key><string>disk0s1</string></dict><dict><key>IOEFIDevicePathType</key><string>MediaFilePath</string><key>Path</key><string>\EFI\APPLE\FIRMWARE\PortMicro.bin</string></dict></array>%00

SystemAudioVolume    Y

efi-boot-device-data    %04%01*%00%01%00%00%00(%00%00%00%00%00%00%00%00@%06%00%00%00%00%00<%ce%95B%8d%19fF%be%f7[%c1p%a9l%91%02%02%04%04:%00\%00E%00F%00I%00\%00r%00e%00f%00i%00n%00d%00\%00r%00e%00f%00i%00n%00d%00_%00x%006%004%00.%00e%00f%00i%00%00%00%7f%ff%04%00

boot-gamma    %10%06%00%00%ce%9c%00%00%00%00%00%00%ce%00%00%00%00%00%00%00%0f%00C%0ca%05%04%10%01%08%85%15*%0d%c6%1aI%13%0d5R5QDWGYgrm%dcr%a6xa%86I%8ad%90%d1%96%a7%9d%13%a6%af%bd%de%c8s%cef%d7%bc%f2%0d%f2%fd%f7%e8%f6%0d%00C%0c%ee%04%c4%11%b3%08E%16%cf%0cK-%ed'%90B%08?%98`%7f]\q%96m%a1%87o%80%aa%ab%09%a6%b1%c4%b6%c2%b8%e2%e2%dd%bc%f1%95%ec%bd%f7%c7%f3%11%00C%0d%a5%05%05%17D%0c%07%1e%aa%12%0d6%df+%10C%e27%9ah%adX%e1%86Fq%a6%99}%7f-%b4L%97%af%bc%0d%a0%f1%c7E%adv%d94%c0%fc%f0%05%dd%fd%f4%16%e3%fd%f7%17%e9%fe%fa%f2%f0%ff%fe%e0%fd

bluetoothInternalControllerInfo    %1a%82%ac%05%000%11%fa`%c5G%95%d1%cf

Hein ! Voilà une NVRAM où l'EFI trouve tout ce qu'il lui faut à se coltiner.

Tu noteras incidemment le : csr-active-config w%00%00%00 qui signifie que la sécurité de la configuration rootless active (= le SIP) est complètement désactivée : les 6 flags possibles sont associés, en paires, à des valeurs 0 => résultat : l'EFI charge les valeurs 00 00 00 des flags, les passe au boot.efi qui les passe au kernel qui les passe à launchd
361608_original.png
et conséquence de ce passez-muscades : l'utilisateur root garde les pleins pouvoirs comme jadis (et moi en coulisses en tant que sudoer).

Tu noteras surtout mon paramétrage de l'efi_boot_device :

Bloc de code:
efi-boot-device    <array><dict><key>IOMatch</key><dict><key>IOProviderClass</key><string>IOMedia</string><key>IOPropertyMatch</key><dict><key>UUID</key><string>4295CE3C-198D-4666-BEF7-5BC170A96C91</string></dict></dict><key>IOEFIShortForm</key><true/><key>BLLastBSDName</key><string>disk0s1</string></dict><dict><key>IOEFIDevicePathType</key><string>MediaFilePath</string><key>Path</key><string>\EFI\refind\refind_x64.efi</string></dict></array>%00
que je te court-circuite à l'essentiel =>

<key>UUID</key><string>4295CE3C-198D-4666-BEF7-5BC170A96C91</string> désigne par son UUID le secteur de boot sur mon disque. C'est l'ESP (EFI System Partition = /dev/disk0s1) et pas la partition /dev/disk0s2 d'OS X, parce que mon Mac ne boote pas sur l'OS, mais sur un gestionnaire de disque. Et voici le blessing le concernant :

<key>Path</key><string>\EFI\refind\refind_x64.efi</string> qui signifie que, dans la partition ESP désignée, le chemin est : dans le dossier EFI, dans le sous-dossier refind, exécuter le boot_loader : refind_x64.efi, qui est le boot_loader du gestionnaire de disque «rEFInd» de Roderick Smith. J'ai 12 partitions démarrables sur mon SSD de 1 To : il faut bien un gestionnaire de disque automatique pour me donner un écran de choix, non ?

Toi, tu n'as ni paramètre csr-active-config, ni paramètre efi-boot-device et c'est cette dernière lacune logique qui te fiche dedans au démarrage. Je n'arrive pas à comprendre comment ta NVRAM peut être aussi anémique. C'est inimaginable.

Si tu es sous «El Capitan», démarre par ⌘R sur ta «Recovery HD», va à la barre de menu supérieure (en négligeant la fenêtre des 4 Utilitaires OS X») au menu Utilitaires et lance le «Terminal». Dans la fenêtre ouverte, saisis la commande :

Bloc de code:
csrutil disable
et ↩︎. Quitte le «Terminal» et au menu  (tout en haut à gauche), sélectionne Disque de démarrage et, si tu vois ton Macintosh HD, sélectionne-le et re-démarre. S'il n'est pas mentionné comme disque de boot, re-démarre en aveugle et prend ton mal en patience (3'). Si tu n'es pas sous «El Capitan», passe directement à ce qui suit =>

Ta session ré-ouverte, relance le «Terminal» d'OS X et fais un copier-coller de la commande (opérative) :

Bloc de code:
sudo bless --folder /Volumes/Macintosh\ HD/System/Library/CoreServices --setBoot
et ↩︎ --> une demande de password s'affiche (commande sudo) --> tape ton mot-de-passe admin à l'aveugle - aucun caractère ne s'affichant à la frappe - et derechef ↩︎ => normalement, l'en-tête du système de fichiers de la /dev/disk0s2 (Macintosh HD) est "béni", avec PATH au répertoire CoreServices qui contient le boot.efi + une préférence de démarrage automatique est inscrite en NVRAM via l'option --setBoot. Comme le SIP est désactivé (via la «Recovery HD») si tu es sous «El Capitan», la NVRAM est déverrouillée en ce qui concerne le paramétrage de l'efi_boot_device, et donc l'option --setBoot de la commande devrait y produire un effet d'écriture.

Fais alors 2 tests :

- a) tu repasses la commande :
Bloc de code:
nvram -p
et tu scrutes s'il y a un efi_boot_device et si oui, qu'est-ce que ça dit ?


- b) tu re-démarres sans options (ou tu éteins ton Mac, puis tu le re-démarres) et tu vérifies si la vitesse de boot s'est améliorée ou pas ?​
 
Dernière édition par un modérateur:
  • J’aime
Réactions: Liyad
Alors là, je suis sur le cul. Je ne comprend pas pourquoi ma NVRAM est autant en bordel...
Et pourquoi en "zapant" la nvram il ne l'écrit pas bien comme il faut ?

J'ai fais ce que tu m'as dis, malheureusement je n'ai pas d'amélioration, voici le nvram -p :

nvram -p a dit:
ocationServicesEnabled %01

csr-active-config w%00%00%00

aht-results <dict><key>_name</key><string>spdiags_aht_value</string><key>spdiags_last_run_key</key><date>2016-01-01T19:53:53Z</date><key>spdiags_version_key</key><string>1.0.16r3</string><key>spdiags_reference_code_key</key><string>VDC001</string></dict>

SystemAudioVolume %a0

BootCampProcessorPstates %0b%00

bluetoothInternalControllerInfo %90%82%ac%05%00%000%14%d8%96%95%f3%e9V

SystemAudioVolumeDB %10

fmm-computer-name MacBook Pro de William

efi-boot-device <array><dict><key>IOMatch</key><dict><key>IOProviderClass</key><string>IOMedia</string><key>IOPropertyMatch</key><dict><key>UUID</key><string>E170E112-EFEC-4A7C-AEA4-76E5F5998ACC</string></dict></dict><key>BLLastBSDName</key><string>disk0s2</string></dict></array>%00

bluetoothActiveControllerInfo %90%82%ac%05%00%00%00%000%14%d8%96%95%f3%e9V

ALS_Data ^%0d%8a%8a%00%00%00%00

backlight-level %8e%00

efi-boot-device-data %02%01%0c%00%d0A%03%0a%00%00%00%00%01%01%06%00%05%1c%01%01%06%00%00%00%03%12%0a%00%00%00%00%00%00%00%04%01*%00%02%00%00%00(@%06%00%00%00%00%00p%01%f3%0d%00%00%00%00%12%e1p%e1%ec%ef|J%ae%a4v%e5%f5%99%8a%cc%02%02%7f%ff%04%00
 
Il n'y a plus de problème au niveau de la NVRAM apparemment. À la rubrique : efi_boot_device est mentionnée comme cible de démarrage la partition /dev/disk0s2 (= celle de Macintosh HD) via son UUID qui est E170E112-EFEC-4A7C-AEA4-76E5F5998ACC. Donc l'EFI a un PATH de boot tout tracé et devrait exécuter le boot.efi d'OS X sans délai.

Pourtant tu dis que cette apuration logique n'a pas occasionné de raccourcissement du délai avant affichage de la . J'en suis réduit à basculer sur une conjecture de problème matériel : soit dans les composants activés par l'EFI (CPU, RAM, Carte-Graphique...) avant exécution du boot_loader ; soit dans l'accès au disque supportant les écritures de l'OS (le SSD). Sur ce terrain-là, je suis hors compétences. Attends l'avis de ton technicien...
 
Arffff, c'est bien ce que je craignais donc.
J'ai eu un mec d'Apple Care qui m'a appelé, on a fait 2-3 manip (démarrage sans échec...) mais il n'était pas plus avancé.
J'attend d'avoir un technicien. Par contre, avec mes partiels et mes cours en général, c'est inimaginable de laisser mon ordi quelques jours pour réparation. D'après le mec d'Apple Care, il n'y a pas de système d'ordinateur de prêt et là, ça complique vraiment les choses.
Je ne sais pas si c'est possible de faire pression dans un Apple Store pour repartir avec un ordinateur neuf ?
 
Un peu déçu...
J'ai reçu un appel de la société qui s'occupe de réparer les Mac mais pour un enlèvement. Or au téléphone, l'Apple Care m'avait dit que c'était pour une réparation sur site "qui serait plus agréable que de se rendre en magasin".
En pleine période de partiel et avec dans tous les cas énormément de boulot scolaire, je ne peux pas me séparer de mon Mac, mais je suis déçu, j'espérais que quelqu'un viendrait et connaîtrais le problème...
 
Bonjour, je reviens de mon rendez-vous à l'Apple Store pas franchement satisfait.
Postulat général : il ne sait pas ce qu'il se passe sur l'ordinateur. En même temps, il n'écoutait pas vraiment... Et il m'a fait comprendre plusieurs fois qu'un rendez-vous c'est que 15 minutes, il n'a rien essayé de plus que le PRAM alors que je lui ai dis l'avoir fait plusieurs fois...
Bref, il voulait garder mon ordinateur en réparation une bonne semaine alors même que je lui expliquais que ce n'est pas la période...
Impossible d'avoir un ordinateur de prêt, hormis avec l'assurance à 499€. Pas terrible...
Il penche pour un problème du SSD ou du "boitier supérieur" mais je ne sais pas ce que c'est.

Me voilà pas beaucoup plus avancé :(
 
Fais une sauvegarde de tes données et trouve une solution pour laisser ton MBPr en réparation
 
Oui, je fais un clone régulièrement. Mais le problème c'est que quand je suis pas en partiel, j'ai énormément de devoir à la maison. Sans ordinateur, je ne peux pas bosser, c'est vraiment très handicapant.
Je sais que l'informatique n'est pas exempt de défaut, mais je penche toujours Apple et Mac parce qu'il y a moins de soucis en général... Je me sent pas mal bloqué pour le moment :(
 
Déposé à un premium resseller, ils ont commandé une carte mère qui serait apparement à l'origine du problème.
Je le récupère mardi.
 
Bonjour,

MAJ final du poste. Le Mac est resté 2 semaines complètes chez le premium resseller qui a tout changé à l'intérieur (carte mère 2x, ventilateur, barrette SSD...), mais le problème a empiré : le Mac freezait au démarrage, ventilos qui ne fonctionnaient plus, carte SD non plus...
Bref, pour lui impossible de trouver le problème.

Je l'ai amené mardi dans un Apple Store à la demande d'Apple qui a demandé un remplacement de la machine. La demande a été acceptée hier, je vais chercher l'ordinateur neuf dans l'aprèm-midi. Petit geste commercial sympa sans que je demande : ils me refont partir la garantie de la nouvelle machine à 0, ce qui est plutôt cool puisque j'avais acheté ma machine en mai dernier. Ils n'ont pas trouvé l'origine du problème dans tous les cas, cette histoire reste donc un mystère ! Sachant que les différents contacts que j'ai eu à l'Apple Store me disait qu'un changement complet de machine sur des ordinateurs est excessivement rare au point qu'ils n'ont pas su tout de suite quelle process utiliser en interne pour faire la demande.

En tout cas merci pour votre aide et désolé de pouvoir apporter une réponse :)
 
Je l'ai amené mardi dans un Apple Store à la demande d'Apple qui a demandé un remplacement de la machine. La demande a été acceptée hier, je vais chercher l'ordinateur neuf dans l'aprèm-midi. Petit geste commercial sympa sans que je demande : ils me refont partir la garantie de la nouvelle machine à 0, ce qui est plutôt cool puisque j'avais acheté ma machine en mai dernier. Ils n'ont pas trouvé l'origine du problème dans tous les cas, cette histoire reste donc un mystère ! Sachant que les différents contacts que j'ai eu à l'Apple Store me disait qu'un changement complet de machine sur des ordinateurs est excessivement rare au point qu'ils n'ont pas su tout de suite quelle process utiliser en interne pour faire la demande.
En voilà une bonne nouvelle pour toi. ;)

Par contre le premium Reseller n'est pas à la hauteur, à l'avenir évite-le. :)
 
:coucou: Liyad

Quelle Odyssée ! C'était manifestement un problème matériel, mais on ne saura pas lequel...

remarque 1 : le remplacement du Mac est une bonne affaire au final , qui valide le diction : « un mal pour un bien» et conforte l'idée d'une « main invisible de la Providence » ☜
361608_original.png


remarque 2 : lorsqu'on remplace l'ensemble des organes internes d'une machine et qu'elle continue de planter, alors il faut incriminer le boîtier : rayures de la coque ou patin détaché
[ceci est une blague]
367024_original.gif
 
  • J’aime
Réactions: Liyad
En voilà une bonne nouvelle pour toi. ;)

Par contre le premium Reseller n'est pas à la hauteur, à l'avenir évite-le. :)

Je ne pense pas qu'il faille incriminer le PR. Il était en contact avec Apple tout le long et même l'Apple store n'a pas trouvé le problème.