Conseils Mac: Dépannage du processus NetBoot

Le démarrage réseau d’un ordinateur est une tâche assez simple, mais complexe, qui fait appel à de nombreuses technologies différentes. En tant que tel, le dépannage peut être difficile. Dans cet article, je présente les étapes du processus Netboot sur les clients Mac OS X et indique quelles technologies sont impliquées à chaque étape, comment elles pourraient échouer et comment résoudre le problème.

1-19-06 Mise à jour: Le 10 janvier, Apple a annoncé
nouveaux Mac à processeur Intel. Au lieu de Open Firmware, les Mac Intel utilisent D'Intel
Interface de micrologiciel extensible (EFI). Alors que la plupart des NetBoot
processus est exactement le même pour les Mac basés sur EFI, je signalerai tout
différences entre les deux
plates-formes tout au long de l'article. Ces modifications seront marquées par
"† (EFI)". Dans les cas où EFI et Open Firmware se comportent
De même, j'ai remplacé le langage spécifique à la plate-forme par simplement "machine".
firmware ".

Voici un bref aperçu de ce qui se passe lorsque vous démarrez Netboot sur un client et de ce que vous verrez à l’écran lorsque cela se produit.

1. Carillons de l'ordinateur lorsque vous l'allumez
   L'ordinateur exécute un test automatique et charge le micrologiciel de la machine.
2. Un globe clignotant apparaît.
   L'ordinateur demande une adresse IP et des informations sur Netboot et commence à télécharger un fichier de démarrage.
3. Le logo gris de Apple et un petit globe en rotation apparaissent
   L'ordinateur charge le fichier de démarrage, qui télécharge et charge le noyau et le cache d'extension du noyau.
4. Le globe en rotation se transforme en un indicateur de progression circulaire
   L'ordinateur a chargé le noyau et le processus de démarrage a commencé. Le noyau monte l'image disque Netboot via NFS et charge le cache d'extension du noyau. Le reste du processus de démarrage est généralement identique à un démarrage standard à disque local.

Il s'agit du "POST" standard, ou test automatique à la mise sous tension, qui se produit quelle que soit la façon dont vous envisagez de démarrer le client. Si vous n'entendez pas de carillon et que vous êtes certain que le son de la machine fonctionne et n'est pas mis en sourdine, vous avez probablement un problème matériel.

Après le carillon, le microprogramme de la machine se charge, lit les paramètres de démarrage,
et dans le cas de Netboot, démarre un DHCP et BSDP (découverte du service de démarrage
protocole)
processus de découverte. Il est important de faire une distinction entre les deux.
Les deux protocoles ont un comportement très similaire et peuvent être administrés
par le processus bootpd sur Mac OS X Server. Il n'est toutefois pas nécessaire
pour qu'un client obtienne les informations DHCP et BSDP d'un serveur, ni
est-il nécessaire qu'ils viennent même d'un serveur Mac OS X (bien que
la configuration d’un autre système d’exploitation pour la distribution d’informations BSDP spécifiques à un Mac n’est pas nécessaire.
une tâche facile – telle est la valeur de Mac OS X Server).

† (EFI): EFI fournit des graphiques beaucoup plus riches
support que Open Firmware – le globe clignotant a plus de détails
et n'est plus sur un fond de bouton carré. De plus, les charges EFI
beaucoup plus rapide que OF, 10 à 15 secondes sont économisées sur le processus de démarrage.

Conditions requises pour cette étape pour continuer:

• Un serveur DHCP doit répondre avec une adresse IP dans le sous-réseau du serveur Netboot.
• Un serveur Netboot doit répondre avec un "ACK BSDP[SELECT]"- un accusé de réception que ce sera le serveur pour ce client

Ce que vous verrez dans le journal du serveur:

netboot_server: ~ root # tail -f /var/log/system.log
bootpd[456]: BSDP DECOUVRIR [en0] 1,0: a: 95: c4: 21: 9c arch = ppc sysid = PowerMac7,2
bootpd[456]: DHCP DECOUVRIR [en0]: 1,0: a: 95: c4: 21: 9c
bootpd[456]: OFFRE envoyée 10.0.1.7 taille 300
bootpd[456]: DEMANDE DHCP [en0]: 1,0: a: 95: c4: 21: 9c
bootpd[456]: ACK envoyé 10.0.1.7 taille 300

Ci-dessus, le client a simultanément effectué des requêtes DHCP et BSDP distinctes. Le serveur (dans ce cas, exécutant Netboot et DHCP) répond en premier avec une réponse DHCP. Vous voyez le type typique de DISCOVER-OFFER-REQUEST-ACK.

† (EFI): Maintenant qu’il existe plusieurs architectures (ppc et i386),
il est important de souligner qu'un client NetBooting inclut son architecture
dans
le BSDP DECOUVRIR. Par exemple, VC: "AAPLBSDPC / i386 / iMac4,1".
Ce que le serveur NetBoot fait avec ces informations sera expliqué plus en détail
détail dans la section "Architectures".

bootpd[456]: BSDP INFORM [en0] 1,0: a: 95: c4: 21: 9c arch = ppc sysid = PowerMac7,2
bootpd[456]: NetBoot: [1,0:a:95:c4:21:9c] BSDP ACK[LIST] envoyé 10.0.1.7 pktsize 300
bootpd[456]: DHCP INFORM [en0]: 1,0: a: 95: c4: 21: 9c
bootpd[456]: ACK envoyé 10.0.1.7 taille 300
bootpd[456]: BSDP INFORM [en0] 1,0: a: 95: c4: 21: 9c arch = ppc sysid = PowerMac7,2
bootpd[456]: NetBoot: [1,0:a:95:c4:21:9c] BSDP ACK[SELECT] envoyé 10.0.1.7 pktsize 364
bootpd[456]: DHCP INFORM [en0]: 1,0: a: 95: c4: 21: 9c
bootpd[456]: ACK envoyé 10.0.1.7 taille 300

Et maintenant, le client a traité une réponse BSDP. Les pièces clés ici sont BSDP INFORM-BSDP ACK[LIST]-BSDP INFORM-BSDP ACK[SELECT]. Si vous ne voyez que des parties de cette "conversation", vérifiez qu'il n'y a pas un autre serveur Netboot sur le réseau qui répond à votre client. Une trace de paquet peut aider à éliminer ce problème (décrit ci-dessous).

La dernière chose qui se passe alors que vous voyez toujours l'icône représentant un globe clignotant est que le client télécharge le fichier "booter" que vous pouvez voir dans le jeu NetBoot image.nbi (/Library/NetBoot/NetBootSP0/nom_image.nbi). Le fichier de démarrage est simplement une copie du fichier "BootX" que vous pouvez trouver dans / System / Library / CoreServices sur n'importe quelle installation Mac OS X. Ce fichier est responsable de la toute première étape du démarrage de la machine, il charge le fichier du noyau Mac OS X.

† (EFI): EFI utilise un fichier de démarrage différent. La source se trouve dans /usr/standalone/i386/boot.efi.
Sur un volume béni, vous trouverez ce fichier à l’adresse /System/Library/CoreServices/boot.efi.
De plus, le fichier "booter" pour EFI doit être stocké dans un répertoire spécifique à l’architecture.
répertoire dans l’ensemble NetBoot. Ceci sera décrit plus en détail dans
la section "Architectures".

Dans le cas de Netboot, l'emplacement du fichier est annoncé dans le BSDP
réponse. Si vous faites une trace de paquet, vous verrez un paquet semblable à ceci:

16: 23: 19.979291 IP (tos 0x0, ttl 255, id 58694, offset 0, drapeaux) [none], longueur: 382) 10.0.1.1.bootps> 0.0.0.0.bootpc: [udp sum ok] BOOTP / DHCP, réponse, longueur: 354, xid: 0x4149, drapeaux: [none] (0x0000)
IP du serveur: 10.0.1.1
Adresse Ethernet du client: 00: 0a: 95: c4: 21: 9c
sname "xserve.apple.edu"
fichier "/ private / tftpboot / NetBoot / NetBootSP0 / Serveur Panther.nbi / booter"
Vendeur-rfc1048:
DHCP: OFFRE
SID: 10.0.1.1
VC: "AAPLBSDPC"
RP: "nfs: 10.0.1.1: / Bibliothèque / NetBoot / NetBootSP0: Serveur Panther.nbi / Install.dmg"
VO: 8.4.129.0.1.145.130.10.78.101.116.66.111.111.116.48.48.50

Le micrologiciel a un client TFTP très léger (FTP trivial) qui
il utilise pour télécharger ce fichier. Une fois le fichier téléchargé, il est exécuté
et
la
Le processus de démarrage est transféré du micrologiciel vers le fichier de démarrage.

Problèmes potentiels
Si votre client ne dépasse pas l’icône du globe clignotant, recherchez les problèmes suivants. Comme le processus Netboot est assez difficile à résoudre à ce stade, examinez les journaux du serveur Netboot et DHCP et effectuez une trace des paquets pour voir quelles informations sont envoyées au client. Ces méthodes sont décrites à la fin de cet article.

Problème: Le client ne reçoit pas d'adresse IP

Les caractéristiques: Il est possible que DHCP DISCOVER apparaisse dans le journal de votre serveur, mais pas dans une offre DHCP ou ACK. Vous pouvez également voir BSDP SELECT[ACK]s dans vos journaux, mais le client ne continue pas. Une trace de paquet révélera qu'aucune diffusion OFFER n'est envoyée au client.

Cause: Un serveur DHCP n'est pas disponible ou n'a aucune adresse IP disponible

Solution: Résoudre le problème DHCP. Vérifiez toujours que votre client peut obtenir une adresse DHCP lors du démarrage à partir d'un système typique avant le démarrage par le réseau.

Autres suggestions: Assurez-vous qu'il n'y a pas de délais de connectivité réseau au démarrage. "Délai de connectivité initial" est le terme général utilisé pour décrire un court délai imposé par le routeur à la connectivité réseau. Sur un commutateur géré, plusieurs fonctionnalités empêchent des choses telles que la boucle de réseau, qui peut détruire un réseau (par exemple, branchez les deux extrémités d'un câble Ethernet sur un commutateur – que se passe-t-il? Astuce: rien de bon). Ces protocoles analysent le périphérique connecté lorsqu'une connexion est détectée pour la première fois sur le port et prennent souvent entre 15 et 30 secondes avant d'autoriser le trafic sur le port. Certains des termes que vous pouvez voir en relation avec le délai de connectivité initial sont "PortFast", "Spanning Tree Protocol", "Etherchanneling" et "Trunking". Il y en a d'autres, mais ce sont ceux que vous verrez le plus souvent. Ce ne sont pas des "mauvais" protocoles, ils sont en fait assez importants pour un environnement réseau géré. Cependant, ils ne sont généralement pas nécessaires sur les ports auxquels des hôtes (ordinateurs) sont connectés.

Le délai de connectivité initial peut tuer la fonctionnalité Netboot – un démarrage sur réseau
Le client doit avoir une connectivité réseau immédiate. Si vous remarquez que
la disparition du globe clignotant prend beaucoup de temps, ou
ne le faites jamais et vous êtes sûr que DHCP et Netboot sont configurés correctement, essayez d'isoler
votre serveur et client à un réseau privé sur un commutateur muet. Si performance
est bien sur le commutateur muet, avoir une discussion avec votre administrateur réseau
sur "la configuration des ports auxquels les ordinateurs sont connectés pour la configuration de l'hôte".
La plupart des routeurs actuels ont des macros pour effectuer facilement ce changement. Finalement. référer
à ce
Article de Cisco sur les retards de connectivité initiaux et la manière de les atténuer
leur (applicable également aux équipements réseau non Cisco)

Problème: Client découvre et offres serveur DHCP, mais le client ne
DEMANDEZ l'adresse IP proposée.

Les caractéristiques: Le journal du serveur DHCP indique un DHCP DISCOVER et les suivants
OFFRE, mais pas de requêtes DHCP. Le commutateur Ethernet est un périphérique Cisco relativement nouveau.

Cause: À l'époque où ils étaient classés par l'IANA comme options "spécifiques à un site",
Apple utilisait à l'origine les options DHCP 220 et 221 à des fins NetBoot. Récemment, ces options ont été
reclassé pour «usage général» et Cisco l’a demandé. Maintenant, Cisco les utilise sur son serveur DHCP:

• cisco-subnet-allocation 220 Allocation de sous-réseau Cisco
• Identifiant VPN Cisco cisco-vpn-id 221

Solution: L’utilisation de ces options étant intégrée à Open Firmware,
ce n'est pas nécessairement un problème trivial à résoudre du point de vue Apple. Là
Il existe cependant deux solutions simples à ce problème:

Au bureau d'enregistrement réseau Cisco:

1. Désactiver la communication vpn au niveau du serveur DHCP ou utiliser les options ignore-cisco
   Attribut de serveur DHCP pour que le serveur DHCP CNR ignore "cisco-vpn-id" et / ou "vpn-id".

Ou, à chaque client Mac unique:

2. Exécutez la commande suivante dans le terminal pour désactiver l'utilisation de ces options.
   dans Open Firmware:

   sudo nvram default-bootp-vexts = "% 00"

   Puis redémarrez le client. Ce changement sera effectif jusqu'à ce que vous zappiez le PRAM. Aussi, au lieu
   d’exécuter la commande sur chaque client, vous pouvez utiliser Apple Remote Desktop pour "Envoyer la commande UNIX"
   à plusieurs machines simultanément.

Problème: Le client établit la liaison DHCP, mais ne parvient pas à obtenir un ACK BSDP[SELECT]

Les caractéristiques: Le journal du serveur affiche un BSDP DECOUVERTE, mais aucun ACK BSDP[LIST]s. Une trace de paquet révélera qu'aucun ACK BSDP[SELECT] la diffusion est envoyée au client.

Cause: Cela pourrait être un serveur Netboot mal configuré. Avez-vous une image Netboot activée? Cela pourrait également être un problème pour ne pas obtenir une adresse IP dans la même plage de sous-réseau que le serveur. Les requêtes DHCP et BSDP et les réponses initiales se font par diffusion. Par conséquent, vous devez indiquer que le serveur et le client se trouvent dans le même sous-réseau ou que vos routeurs sont configurés pour gérer ce trafic, spécialement pour faciliter DHCP et Netbooting. Enfin, cela pourrait simplement être un problème de timing. Parfois, le processus bootpd doit être redémarré avant de reconnaître les modifications de configuration.

† (EFI): Cela peut également se produire si votre image NetBoot ne prend pas en charge l'architecture.
de la machine que vous essayez de démarrer. Voir la section "Architectures" pour
plus de détails.

Solution: Vérifiez qu'une image Netboot est activée sur votre serveur. Essayez de redémarrer le service Netboot dans Admin Serveur. Vérifiez que vous pouvez voir l’image Netboot dans le volet des préférences de la disquette de démarrage lors du démarrage à partir du système d’exploitation typique du client (vérifiez également que le client est configuré pour DHCP tout en procédant ainsi!).

Problème: Le client obtient les informations DHCP et BSDP, mais ne parvient pas à télécharger le fichier de démarrage

Les caractéristiques: Vous voyez dans les journaux de votre serveur que votre client reçoit une adresse IP dans le même sous-réseau que le serveur Netboot et qu'il négocie un ensemble Netboot défini avec le serveur Netboot, mais que le client n'obtient pas le logo gris Apple. Vous pouvez également voir un point d’interrogation clignotant sous Mac OS 9.

Cause: Vérifiez d’abord que votre serveur DHCP fournit votre client
avec une adresse de routeur pingable. Souvent, les gens vont omettre l'adresse du routeur
pour un réseau de test isolé à sous-réseau unique, mais cela entraînera certainement
le processus NetBoot à échouer à ce stade. Même si un routeur n'existe pas,
vous devez spécifier une adresse IP que le client pourra utiliser pour ARP. En précisant
L'adresse IP du serveur DHCP est dans ce cas la meilleure approche.
Vous pouvez déterminer si votre client reçoit une adresse de routeur par défaut en examinant
une trace de paquet (plus d'informations sur les traces de paquet ci-dessous):

Votre IP: 10.0.1.7
IP du serveur: 10.0.1.1
Adresse Ethernet du client: 00: 0a: 95: c4: 21: 9c
sname "roscoe.bombich.com"
Vendeur-rfc1048:
DHCP: OFFRE
SID: 10.0.1.1
LT: 1197504
SM: 255.255.0.0
DG: 10.0.1.1

Si vous avez confirmé que votre client reçoit une adresse IP pingable pour
le routeur par défaut, c’est probablement un problème avec tftp. Après vérification
que votre ensemble Netboot a réellement un fichier de démarrage,
tester
cette
votre
service tftp
est
travail.
À
un autre
client,
courir
cette commande dans le terminal, en substituant le nom d’hôte de votre serveur et votre
Nom de l'ensemble Netboot:

[admin:~/Desktop] tftp 10.0.1.21
tftp> obtenir NetBoot / NetBootSP0 / NetRestore.nbi / booter
Reçu 174997 octets en 0,2 seconde
tftp>

Remarque: ce test échouera si votre ensemble Netboot comporte des espaces dans son nom. En général, cependant, il est correct d'avoir des espaces dans le nom de votre ensemble Netboot.

Si vous obtenez une erreur, vous avez probablement un problème de configuration de TFTP.

Autres suggestions:

• Vérifiez que les paramètres de pare-feu de votre serveur autorisent le trafic sur le port 69
• Vérifiez que tftp est activé dans /etc/xinetd.d/tftp (Panther) ou dans / System / Library / LaunchDaemons/tftp.plist (Tiger).
• Vérifiez que le fichier "booter" existe dans votre ensemble NetBoot et est lisible (dispose des privilèges de lecture pour "tout le monde")
• Vérifiez que votre client peut au moins envoyer une requête ping à l'adresse du routeur renvoyée par votre serveur DHCP.

Lorsque vous voyez le logo Apple gris, cela signifie que le fichier de démarrage a été téléchargé et exécuté. Dans le cas de Netboot, le fichier de démarrage télécharge ensuite deux fichiers supplémentaires via tftp: les fichiers mach.macosx et mach.macosx.mkext. Le fichier mach.macosx est simplement une copie du fichier / mach_kernel situé à la racine de tout système de fichiers Mac OS X. Le fichier mach.macos.mkext est un cache d'extensions de noyau – un fichier contenant toutes les extensions de noyau importantes pour un démarrage réseau de base. Pendant le téléchargement de ces fichiers, l’icône du petit globe tourne. Une fois les téléchargements de fichiers terminés, le fichier de démarrage charge le noyau et le noyau poursuit le processus de démarrage.

† (EFI): les fichiers de cache du noyau et de kext sont très dépendants de l'architecture.
Depuis la version 10.4.4, ces fichiers sont des fichiers "en gras mais extraits". C'est, ils
contient des informations d’en-tête décrivant les fichiers binaires disponibles pour
chaque architecture dans le fichier, mais les fichiers binaires spécifiques à l'architecture
ont été extraits pour réduire la taille globale des fichiers. Cette volonté
être expliqué plus en détail dans la section "Architectures".

Il est assez rare de rencontrer des problèmes à cette étape de la Netboot
processus, cependant, il existe quelques problèmes spécifiques qui peuvent causer le noyau
panique à ce stade. Les problèmes possibles seraient:

• Ne pas avoir un fichier mach.macosx et mach.macosx.mkext dans votre ensemble Netboot
• L'un ou l'autre de ces fichiers est corrompu ou inaccessible
• Le fichier mach.macosx (noyau) ne contient pas le binaire du client.
  architecture ou est autrement incompatible
• Le fichier mach.macosx.mkext (cache d'extension de noyau) ne contient pas
  extensions de noyau requises pour la machine

Ces fichiers occupent environ 12-15 Mo d'espace disque, cela devrait donc prendre quelques secondes
(ou plusieurs secondes pour de nombreuses machines) pour que cette étape soit terminée. Si vous rencontrez
problèmes à ce stade du processus, résoudre le problème est assez trivial:

1. Redémarrez l'ordinateur client affecté à partir d'un lecteur local contenant le dernier système d'exploitation disponible.
   La version du système d'exploitation doit également correspondre à la version du système d'exploitation de votre image disque NetBoot. Si le système d'exploitation sur le
   L’image disque NetBoot étant plus ancienne que celle de votre ordinateur client affecté, vous devez recréer votre image disque NetBoot.
   Il est primordial que le système d'exploitation de l'image disque NetBoot soit plus récent (ou identique) que le système d'exploitation fourni avec la machine.
2. Montez via AFP le point de partage NetBoot du serveur NetBoot contenant le jeu NetBoot affecté.
3. Recréez les fichiers mach.macosx et / ou mach.macosx.mkext. Voir la section "Architectures" pour plus de détails.

Si tout échoue, il vous suffit de recréer l’ensemble du jeu NetBoot sur le matériel affecté. Assurez-vous de supprimer (ou de quitter le point de partage NetBoot) tous les ensembles NetBoot non fonctionnels.

Une fois le noyau chargé, l’icône du globe en rotation devient indéterminée,
indicateur de progression circulaire, et le processus de démarrage fonctionne généralement le même
en tant que processus de démarrage standard. Si vous mainteniez les touches Commande + V enfoncées pendant le démarrage
up, vous obtiendrez le démarrage prolixe à ce stade. Deux choses intéressantes se passent
ici qui sont pertinents pour le dépannage de Netboot. Premièrement, le noyau se charge
le cache d'extension de noyau pour donner au jeune système d'exploitation les fonctionnalités dont il a besoin
pour effectuer une communication réseau avancée, monter des disques, etc. avant le reste
des charges de l'OS.

Deuxièmement, le noyau exécute le script de démarrage /etc/rc.netboot. Ce
Le script tente de monter l’image de disque dans votre ensemble Netboot via NFS.
Le chemin d'accès à cette image disque est obtenu à partir de la réponse BSDP et maintenu
dans
mémoire (un peu comme votre paquet DHCP est maintenu et accessible via le ipconfig
commander). Si vous faites une trace de paquet, vous verrez un paquet semblable à ceci:

IP du serveur: 10.0.1.1
Adresse Ethernet du client: 00: 0a: 95: c4: 21: 9c
sname "xserve.apple.edu"
fichier "/ private / tftpboot / NetBoot / NetBootSP0 / Serveur Panther.nbi / booter"
Vendeur-rfc1048:
DHCP: OFFRE
SID: 10.0.1.1
VC: "AAPLBSDPC"
RP: "nfs: 10.0.1.1: / Bibliothèque / NetBoot / NetBootSP0: Serveur Panther.nbi / Install.dmg"
VO: 8.4.129.0.1.145.130.10.78.101.116.66.111.111.116.48.48.50

Une fois que cela se produit, le noyau lance les scripts /etc/rc.boot et / ou /etc/rc.cdrom qui complètent le processus de démarrage. Finalement, l'écran devient bleu au chargement de WindowServer et vous commencez à voir les parties les plus familières du processus de démarrage.

Problèmes potentiels

Problème: Peu après que l'indicateur de progression circulaire apparaisse sous le
logo Apple gris, des lignes blanches horizontales apparaissent à l'écran et la progression
indicateur cesse de tourner.

Cause: Il s’agit probablement d’une panique du noyau, qui résulte probablement de l’essai de la machine qui tente de monter l’image disque hébergée par NFS et qui échoue.

Suggestions:

• Vérifiez que vous avez paniqué le noyau en maintenant la touche Commande + V enfoncée pendant le redémarrage du client. Il devrait y avoir une indication de panique.
• Vérifiez que NFS est en cours d'exécution sur le serveur
• Vérifiez que le point de partage NetBootSPx est valide et accessible. Rappelez-vous que le partage NetBoot devrait ressembler à ceci:

cd / Bibliothèque / NetBoot
ls -la

.sharepoint -> NetBootSP0
.clients -> NetBootClients0
NetBootSP0
NetBootClients0

Si ce n'est pas le cas, vous pouvez le réparer manuellement ou exécuter cette commande:

/ Système / Bibliothèque / ServerSetup / NetBoot

Ou vous pouvez réinitialiser les points de partage NetBoot dans Admin Serveur:

1. Accédez à NetBoot> Paramètres> Général dans Admin Serveur.
2. Désélectionnez toutes les cases à cocher dans le volet inférieur ("Sélectionnez l'emplacement où placer les images et les données client").
3. Sauvegarder les modifications
4. Resélectionnez les volumes souhaités pour stocker des images et des données client
5. Sauvegarder les modifications

Problème: Le système redémarre environ dix secondes environ après l'affichage de l'indicateur de progression circulaire

Cause: Pour vraiment déterminer la cause, vous devriez faire un démarrage prolixe
et essayez d’attraper le message d’erreur indiqué à l’écran. Plus souvent que
non, le problème vient d'un cache d'extension de noyau incompatible. La machine
essayé de charger le cache, mais il manquait un élément important et
l'ordinateur n'a pas pu continuer à démarrer.

Solution: Reconstruisez votre image Netboot définie sur une machine que vous feriez
tiens à démarrer à partir de cet ensemble. Cela signifie généralement que vous souhaitez utiliser votre
dernière et meilleure machine pour créer des ensembles Netboot. Apple nouvellement publié
le matériel * toujours * ne parvient pas à démarrer à partir du jeu Netboot de l'année dernière. Gardez votre Netboot
images fraîches et vous ne devriez pas courir dans cela.

Problème: Le système ne progresse jamais au-delà de l'indicateur de progression circulaire

Cause: Encore une fois, pour vraiment déterminer la cause, vous devriez faire un commentaire
démarrer et pour voir les messages d’erreur spécifiques indiqués à l’écran. Souvent cela
une mauvaise configuration
NFS sur le serveur, caractérisés par des messages tels que "délai d'attente RPC pour
serveur ". Parfois, il est dû à des bugs dans
les scripts de démarrage (tiers).

Solution: Dépannage NFS de base – commencez par réinitialiser NetBoot
points de partage dans Admin Serveur comme indiqué ci-dessus. Vérifiez que votre pare-feu est
ne bloque pas les ports requis par NFS: 111 (UDP), 989 (UDP), 2049 (UDP et TCP). Aussi, utilisez les commandes "showmount"
et "mount_nfs" pour vérifier que NFS fonctionne. D'un client
démarré à partir de son propre disque dur, exécutez ces commandes:

montrez-e

mkdir / tmp / mnt
mount_nfs : / Bibliothèque / NetBoot / NetBootSP0 / tmp / mnt

La commande "showmount" indiquera quels points de partage NFS sont
disponible sur votre serveur NetBoot. Si vous ne voyez pas votre point de partage NetBoot,
réinitialiser le point de partage NetBoot dans Admin Serveur. La commande mount_nfs
fait des tentatives
monter le sharepoint NFS.

• Commencez simplement avec l'utilitaire System Image de Apple
• Isolez votre serveur et votre client sur un réseau privé via un commutateur passif
• Recréer le set Netboot
• Essayez de démarrer verbalement pour voir si des messages d'erreur vous orientent dans la bonne direction.
• Vérifiez que vous obtenez une adresse IP dans la plage de sous-réseau de votre serveur Netboot.

Cette trace de paquet peut être vraiment utile (réalisée sur le serveur Netboot):

sudo tcpdump -i en0 -s 0 -nvX port bootps ou port bootpc ou port tftp

ou si vous envisagez d'envoyer les résultats à quelqu'un d'autre:

sudo tcpdump -i en0 -s 0 -w ~ / Desktop / packets.trace port bootps ou port bootpc ou port tftp

Que signifient les arguments:
-i en0: Ecoute de la circulation sur en0
-s 0: ne pas tronquer les paquets
-n: ne convertit pas les adresses IP en noms
-v: sortie verbeuse (donnez-moi un joli résumé de la signification du paquet)
-X: Affiche le contenu du paquet en ASCII et en hexadécimal.
-x: affiche le contenu du paquet en hexadécimal
-A: imprime le contenu du paquet en ASCII
-w: écrit les paquets dans un fichier au lieu de les afficher

Il y a beaucoup d'informations dans les traces de paquets, et il peut être fastidieux de comprendre ce que cela signifie. Vous pouvez également télécharger mon paquet de traces de paquets annotées pour référence. La chose la plus importante à savoir sur les traces de paquets est de savoir comment les faire. Même si vous ne savez pas quoi extraire de la trace, le confier à quelqu'un d'autre peut faciliter le dépannage.

Si vous modifiez votre ensemble Netboot pour fournir un shell au début du processus de démarrage, vous pouvez voir les informations BSDP que votre client obtient du serveur à l'aide des commandes suivantes:

ipconfig netbootoption shadow_mount_path
ipconfig netbootoption shadow_file_path
ipconfig netbootoption nom_ordinateur

Une image NetBoot sans disque est exactement la même chose qu'une image sans disque (vous ne faites pas ce choix lors de la création d'image SIU, n'est-ce pas?). Lorsque vous choisissez de créer un jeu d'images sans disque dans Admin Serveur, la seule modification apportée est: made est sur la clé "SupportsDiskless" dans le fichier NBInfo.plist du répertoire .nbi.

La magie se produit lorsque vous démarrez le client. Une partie de la réponse BSDP au client inclut des informations sur l'emplacement de tout point de montage réseau pour les fichiers shadow. Par exemple, en utilisant le conseil précédent, vous pouvez obtenir les données suivantes à partir du paquet BSDP:

% ipconfig netbootoption shadow_mount_path
afp: // netboot001:[email protected]/ NetBootClients3

% ipconfig netbootoption shadow_file_path
NetBoot001 / Shadow

% ipconfig netbootoption nom_ordinateur
NetBoot001

En examinant le script de démarrage /etc/rc.netboot, vous pouvez voir comment fonctionne le Netbooting sans disque. Par défaut, un client Netboot essaiera de monter un fichier shadow au chemin shadow_mount_path. Si cela échoue cependant (par exemple, si shadow_mount_path n'est pas défini par le serveur Netboot), il utilisera le lecteur local à la place. Par conséquent, Netboot sans disque dépend entièrement de la capacité du client à monter un fichier reflet au chemin de montage AFP renvoyé par le serveur Netboot dans la réponse BSDP.

Notez que bien que NetInstall ne nécessite pas de lecteur interne, ce n'est * pas * "netboot sans disque". NetInstall n'utilise pas du tout un fichier shadow. Par conséquent, aucun fichier shadow réseau n'est requis ou renvoyé dans la réponse BSDP. C’est aussi la raison pour laquelle la case à cocher "Sans disque" est désactivée dans les ensembles d’images Admin Serveur pour NetInstall. Les ensembles NetInstall utilisent des disques RAM selon les besoins pour l'espace en écriture.

Lorsque vous maintenez la touche "N" enfoncée au démarrage, votre ordinateur démarrera à partir du jeu d'images que vous avez identifié comme étant le jeu "par défaut" dans Admin Serveur. Lorsque vous choisissez un disque de démarrage réseau dans le volet des préférences de disque de démarrage, le serveur garde trace de votre sélection et vous êtes toujours lié à ce serveur et à cet ensemble Netboot jusqu'à ce que vous fassiez un autre choix. Cela signifie que si vous modifiez le jeu par défaut sur le serveur, puis maintenez la touche N enfoncée au démarrage sur ce client qui avait choisi un autre jeu Netboot, le client ne démarrera pas à partir de votre jeu par défaut, il le sera toujours à partir du jeu. précédemment choisi (même si vous avez depuis réinitialisé le disque de démarrage sur un disque local).

† (EFI): maintenez les touches Option + N enfoncées pour démarrer à partir de l'image NetBoot par défaut.

Bien que cela fonctionne techniquement comme prévu, cela ne fonctionne pas nécessairement comme prévu. Le serveur Netboot conserve ces paramètres de choix dans / var / db / bsdpd_clients. Il est sûr de supprimer ce fichier pour permettre à vos clients de redémarrer avec le jeu d'images par défaut. En outre, les séries de commandes suivantes ont tendance à résoudre les problèmes causés par la définition d'un choix de disque de démarrage réseau spécifique sur un client, puis par la suppression de cet ensemble Netboot.

sudo rm / var / db / bsdpd_clients
sudo killall bootpd
sudo killall -HUP xinetd
sudo lookupd -flushcache
sudo serveradmin stop netboot
sudo serveradmin start netboot

Netboot exige que le client puisse obtenir les informations DHCP et BSDP par diffusion. Cela nécessite généralement que le serveur Netboot et les clients résident sur le même sous-réseau, car les routeurs ne transmettent généralement pas d'informations de diffusion entre les sous-réseaux. Cependant, les informations DHCP sont gérées spécialement par les routeurs, vous n’avez donc pas besoin d’un serveur DHCP sur chaque segment de votre réseau. Ceci est géré par ce que l'on appelle généralement "les tables d'assistance DHCP" (ou plus généralement, le relais DHCP) dans la configuration de votre routeur. Fondamentalement, il ne s'agit que d'une liste d'adresses IP vers lesquelles les paquets de diffusion DHCP doivent être relayés.

Comme le protocole BSDP est très similaire à DHCP, la configuration du routeur pour un serveur BSDP est la même que pour DHCP. Par conséquent, si vous souhaitez Netboot sur plusieurs sous-réseaux, ou plus techniquement, si vous souhaitez que les informations de diffusion BSDP soient relayées via vos routeurs, vous devez ajouter l'adresse IP de votre serveur Netboot à la table d'assistance DHCP de votre routeur.

Les administrateurs réseau craignent souvent que cela interfère avec le traitement de DHCP par d'autres serveurs. Cependant, même si le processus bootpd est en cours d'exécution sur votre serveur Netboot, si le service DHCP n'est pas activé, il ne distribuera pas d'adresses IP. En fait, il ignorera complètement toutes les requêtes DHCP. De même, votre autre serveur DHCP ignorera complètement les diffusions BSDP qui lui sont relayées par le routeur.

En résumé, si vous souhaitez effectuer une installation sur plusieurs sous-réseaux, utilisez votre réseau.
administrateur pour configurer vos routeurs pour envoyer des diffusions BSDP vers votre Netboot
serveur. Ce n'est pas une demande déraisonnable ou une tâche difficile, et grandement
réduit vos coûts d'infrastructure et de gestion.

Quand
un client Macintosh commence le processus NetBoot, il envoie une demande de diffusion
pour un serveur NetBoot. Dans cette demande se trouvent trois très importants
informations: identifiant client (adresse MAC), architecture,
et identificateur de système (modèle de machine). Lorsqu'un serveur (Tiger +) NetBoot
voit une requête BSDP en diffusion, launchd lance bootpd pour gérer le
demande. Le NetBoot
serveur vérifie son fichier / var / db / bsdpd_clients pour déterminer si le client
a déjà sélectionné une image NetBoot sur le serveur. Si un record pour
le client existe sur le serveur, le serveur renverra le message associé.
Les informations d'image NetBoot et le client NetBoot préfèreront cela
serveur sur tout autre serveur NetBoot du réseau. Si une association
n'existe pas encore, le serveur renvoie une liste d'images NetBoot qui
sont disponibles pour le client particulier. Quand le client choisit finalement
une image, le serveur crée un enregistrement d’association client dans / var / db / bsdpd_clients.

Le serveur NetBoot filtrera une image NetBoot de la liste renvoyée au client si:

1. Il est spécifiquement interdit à l’adresse MAC du client d’accéder aux images sur le serveur (filtres NetBoot)
2. L'image NetBoot ne prend pas en charge l'architecture de la machine cliente.
3. L'image NetBoot n'est pas activée pour le modèle d'ordinateur.

Reportez-vous à la documentation de Mac OS X Server pour plus de détails sur le filtrage NetBoot.

Le support d'architecture est défini de deux manières. À partir de 10.4.4, il y a
est une clé supplémentaire dans le fichier NBImageInfo.plist nommée "Architectures".
Cet attribut contient un tableau des architectures prises en charge,
par exemple {ppc}
ou {ppc, i386}. De plus, le jeu NetBoot doit contenir un booter,
mach.macosx et mach.macosx.mkext pour chaque architecture prise en charge.
Pour assurer la compatibilité ascendante, les fichiers de démarrage ppc peuvent résider à la
niveau racine du jeu NetBoot ou dans un dossier nommé "ppc" à
le niveau racine de l'ensemble NetBoot. Les fichiers de démarrage spécifiques à Intel doivent
réside dans un dossier nommé "i386" au niveau racine du
Ensemble NetBoot. Par conséquent, vous pourriez avoir un ensemble Universal NetBoot (compatible
de démarrer
ppc ou i386) avec la structure suivante:

NetBoot.nbi /
booter
i386 /
booter
mach.macosx
mach.macosx.mkext
mach.macosx
mach.macosx.mkext
NBImageInfo.plist
System.dmg

Lorsque le serveur NetBoot reçoit une requête BSDP d’une architecture particulière,
il détermine si $ {arch} / booter existe. Si c'est le cas, il renvoie le chemin d'accès à
ce fichier dans la réponse BSDP. Si ce n'est pas le cas, et arch = ppc, il retourne
le chemin d'accès à booter (au niveau racine du nbi) s'il existe. Si le booter
n'existe pas pour l'architecture, non seulement le client ne démarrera pas à partir de
jeu NetBoot, mais l’image NetBoot n’apparaîtra même pas en tant que disque d’amorçage disponible
client.

Génération de fichiers de démarrage spécifiques à la plate-forme:

1. Créez le fichier mach.macosx avec une commande similaire à la suivante, en remplaçant le chemin d'accès au jeu NetBoot par vos propres informations:

idem / mach_kernel /Volumes/NetBootSP0/NetRestore.nbi/mach.macosx

ou, si le noyau est fat, vous pouvez extraire le binaire spécifique à l'architecture directement dans le dossier nbi:

lipo-extrait ppc -output /Volumes/NetBootSP0/NetRestore.nbi/mach.macosx / mach_kernel

2. Créez le cache d'extension du noyau avec une commande similaire à la suivante, en remplaçant le chemin d'accès au jeu NetBoot par vos propres informations:

sudo kextcache -a ppc -s -l -n -z -m / tmp / mkext / Système / Bibliothèque / Extensions
idem / tmp / mkext / Volumes / NetBootSP0 / NetRestore.nbi/mach.macosx.mkext

ou, pour un Mac à processeur Intel:

sudo kextcache -a i386 -s -l -n -z -m / tmp / mkext / Système / Bibliothèque / Extensions
idem / tmp / mkext / Volumes / NetBootSP0 / NetRestore.nbi/i386/mach.macosx.mkext

3. Add the booter files. PowerPC:

ditto /usr/standalone/ppc/bootx.bootinfo /Volumes/NetBootSP0/NetRestore.nbi/booter

Intel-based Mac:

ditto /usr/standalone/i386/boot.efi /Volumes/NetBootSP0/NetRestore.nbi/i386/booter

Références:
Cisco article on DHCP Relay configuration
Apple Kbase: Netbooting across subnets
Alternative method of Netbooting across subnets
Kernelthread.com: Booting Mac OS X
Apple Documentation of the Mac OS X boot process
How to enable NetBoot 1.0 for older NetBoot client computers