doc
Je trouve bizarre qu'une seule extension en plus à injecter dans le
kernel au démarrage --> prenne
15" de temps de boot en plus.
Parce que normalement la séquence est celle-ci --> l'
EFI exécute le programme de démarrage de l'OS =
boot.efi et quitte. Le
boot.efi charge le
kernel en
RAM et lui injecte les extensions (opération signalée par la à l'écran) puis quitte. Le
kernel assure désormais tout seul la suite des opérations.
Donc les
15" en plus se situeraient dans la
phase d'injection des extensions dans le noyau chargé en
RAM. Pourquoi est-ce que je trouve bizarre cette rallonge temporelle ? C'est que le programme
boot.efi ne s'amuse pas, par défaut, à aller chercher l'
original du
kernel (at:
/System/Library/Kernels/kernel) pour le charger en
RAM > puis à aller aux 2 dossiers des extensions (
natives at:
/System/Library/Extensions et
tierces at:
/Library/Extensions) pour injecter
une à une chaque extension après avoir
vérifié son intégrité. Oh là là ! - mais ça prendrait un temps fou cette affaire...
Non ! - il existe un
cache de démarrage-Système nommé
prelinkedkernel (at:
/System/Library/Prelinkedkernels/ prelinkedkernel) qui est le cache de démarrage-Système utilisé directement par le
boot.efi --> il y trouve un clone du programme du
kernel à charger directement en
RAM > et le
tableau complet des extensions bien "emballées" dans un "fourre-tout" garanti conforme --> ce qui permet une
injection en bloc dans le
kernel et pas au goutte-à-goutte.
Si tu m'as suivi dans un de mes petits exposés labyrinthiques coutumiers --> tu ne peux manquer de sauter comme moi à la
conséquence logique nécessaire : par défaut > l'extension Apple chargée du
TRIM sur les SSD de tierce-partie (la
AppleDataSetManagement.kext) tenue en réserve dans le sous-dossier :
/System/Library/Filesystems > se trouve
copiée dans le dossier
/System/Library/Extensions par la commande
trimforce --> donc elle fait
partie du lot des extensions injectées par le
boot.efi dans le
kernel démarré. Pourquoi une extension (Apple) de
plus ou de moins dans le lot mangerait-elle
15" de temps de boot en ralentissant d'autant l'opération d'injection des extensions par le
boot.efi ?
La seule raison que j'y vois --> c'est que suite à l'
ajout de l'extension
AppleDataSetManagement.kext dans le dossier-Système des
Extensions --> le
timestamp (cachet de temps d'accès uniforme) apposé sur ce dossier aurait été
brisé sans être
restauré --> par suite le cache de démarrage-System
prelinkedkernel n'aurait pas pu être
mis à jour par le service qui en est en charge (= le
kextd daemon). Ce qui fait que le
boot.efi serait obligé de récupérer une
extension isolée hors-cache dans le dossier des
Extensions (la
AppleDataSetManagement.kext) --> pour l'
injecter isolément par après (tout ça sent le bogue à plein nez).
Comme tu le vois --> tout ça consiste en de la logique spéculative > mais que j'essaie toujours de garder dans les limites théoriques du « falsifiable » (comme aurait dit l'autre crétin d'épistémologue : Popper). Donc il te suffit de passer les 2 commandes (l'une après l'autre) -->
Bloc de code:
sudo touch /System/Library/Extensions
sudo kextcache -u /
- la 1ère met-à-jour le timestamp sur le dossier des Extensions (une façon de déclarer : temps d'accès ré-uniformisé à tous les éléments contenus dans le dossier parent > sans une seule tête d'ail qui dépasse)
- la 2è met-à-jour le cache de démarrage-Système prelinkedkernel pour lui intégrer le tableau complet des Extensions du dossier précédent - mise-à-jour conditionnée par le sceau d'un timestamp intégre sur le dossier
=> cela opéré > tu n'as plus qu'à aller à :
Menu >
Préférences Système >
Disque de démarrage > vérifier que ton volume
Macintosh HD est bien sélectionné comme appareil de démarrage automatique --> et à re-démarrer.
Tu vas vite voir si le démarrage échappe les
15" secondes excédentaires antérieures.
# note: si tu t'obstines à
activer FileVault --> ça ne peut pas accélérer le démarrage > puisqu'il faut le temps préalable du
déverrouillage du volume-Système avec un écran de login au départ. Si tu veux essayer de mettre de l'huile dans le processus de l'
EFI au démarrage > et à la condition que ton
High Sierra soit installé sur SSD en format
apfs --> alors la commande est :
Bloc de code:
sudo diskutil ap updatePreboot /
- qui met à jour les informations de boot pour l'EFI contenues dans le volume de pré-démarrage Preboot du Conteneur apfs.
