Démarrage en réseau d’un Raspberry Pi 3 à partir d’un serveur Ubuntu – Bien choisir son serveur d impression

introduction Chez The Floow, nous utilisons Raspberry Pis en tant que clients de kiosque Chromium pour surveiller nos systèmes et notre infrastructure. Nous recherchons maintenant un amorçage réseau pour cela, ainsi que quelques autres utilisations (à venir, espérons-le bientôt), de manière à ce qu'ils soient faciles à gérer collectivement sans avoir besoin de flasher nombreuses cartes SD, et évite en outre la nécessité de s’inquiéter de la vie des cartes SD après de nombreuses opérations d’écriture. Cet article est initialement basé sur les guides suivants, mais il inclut un peu plus de détails et une procédure de dépannage: Il est également possible de démarrer en réseau un Raspberry Pi 2. Installer Le serveur Un HP Micro Server (G7 N54L) exécutant Ubuntu 16.04.3 LTS (effectuant diverses autres tâches également) Les clients) Raspberry Pi 3 modèle B (connecté via Ethernet câblé, ce processus ne fonctionne pas avec le WiFi) Le système d'exploitation cible Raspbian 9 Lite (non Lite devrait fonctionner aussi) Préparation du système de fichiers racine au démarrage Dans cette série d'étapes, nous allons copier une nouvelle installation Raspbian, avec quelques modifications sur notre serveur de démarrage, et l'exposer via un partage NFS. Étape 1: Carte SD Raspbian Lite Téléchargez l'image Raspbian Lite à partir d'ici. Flash sur une carte Micro SD, le moyen le plus simple consiste à utiliser Etcher (il prend même un zip directement et vérifie également le contenu après).

Étape 2: démarrez le Raspberry Pi à partir de la nouvelle carte SD Remarque: Pour cela, un écran, un clavier et un câble Ethernet (avec accès à Internet) doivent être connectés. Une fois que le pi démarre, connectez-vous avec les informations d'identification par défaut (pi / framboise). Étape 3: Activer SSH (facultatif) Courir sudo raspi-config, sélectionnez l’option 5 (Options d’interface), P2 (SSH) et sélectionnez Oui pour activer SSH. Vous pouvez ensuite quitter cet utilitaire et continuer les étapes suivantes via SSH, si vous préférez, ou continuer localement. L’IP est imprimé au démarrage mais peut également être visualisé en exécutant adresse ip: pi @ raspberrypi: ~ $ ip addr 1: lo: mtu 65536 qdisc noqueue state UNKNOWN groupe par défaut qlen 1     lien / bouclage 00: 00: 00: 00: 00: 00 petit-déjeuner: 00: 00: 00: 00: 00: 00     inet 127.0.0.1/8 portée hôte bas        valid_lft pour toujours Preferred_lft pour toujours     inet6 :: hôte de portée 1/128        valid_lft pour toujours Preferred_lft pour toujours 2: eth0: mtu 1500 qdisc état pfifo_fast UP groupe par défaut qlen 1000     lien / éther b8: 27: eb: 41: 8e: fa brd ff: ff: ff: ff: ff: ff     inet 192.168.1.135/24 brd 192.168.1.255 étendue globale eth0        valid_lft pour toujours Preferred_lft pour toujours     inet6 fe80 :: 2036: 591: lien de cef2: 341a / 64 scope        valid_lft pour toujours Preferred_lft pour toujours 3: wlan0: mtu 1500 qdisc état pfifo_fast groupe DOWN par défaut qlen 1000     link / ether b8: 27: eb: 14: db: af brd ff: ff: ff: ff: ff: ff

Dans ce cas, notre interface filaire est eth0, dont l'adresse est 192.168.1.135. Étape 4: Mettez à jour Debian Première exécution sudo apt-get update pour vous assurer que tous les fichiers d'index des paquets sont à jour. Puis, lancez sudo apt-get upgrade installer les dernières versions de tous les packages actuellement installés. Puis, lancez sudo apt-get dist-upgrade qui gère intelligemment les dépendances changeantes avec les nouvelles versions de paquets. Dans les deux cas, sur demande, vérifiez et confirmez que vous êtes satisfait des modifications proposées. Étape 5: désactiver l'échange sudo dphys-swapfile swapoff sudo dphys-swapfile désinstaller sudo update-rc.d dphys-swapfile supprimer

Étape 6: Mettre à jour le Pi (firmware) Certains fichiers du suivant branche de la rpi-firmware Un référentiel est requis pour que ce processus fonctionne. Cette étape est probablement optionnelle si bootcode.bin est utilisé à partir de GitHub dans les étapes TFTP ci-dessous. Modifier: J'ai également constaté que l'utilisation des fichiers img du noyau raspbian 'stock' pouvait provoquer des erreurs de démarrage désagréables. Courir branche sudo = prochaine mise à jour rpi. Modifier (2018-07-14): Attention, la prochaine branche semble être obsolète, la mise à jour depuis le maître (par défaut) fonctionne bien pour 3B +. Détails sur rpi-update peut être trouvé ici https://github.com/Hexxeh/rpi-update. Il est probable que cela se termine en disant: *** Un redémarrage est nécessaire pour activer le nouveau firmware

Alors, redémarrez maintenant avec redémarrage sudo. Étape 7: "Cloner" le système de fichiers Une fois que le Pi a redémarré, localement ou via SSH, lancez: sudo mkdir -p / nfs / client1 sudo apt-get install -y rsync sudo rsync -xa --progress --exclude / nfs / / nfs / client1

Remarque: Vous devez faire cela sur un Pi en cours d'exécution, la copie de la carte SDK sur un autre hôte ne semble pas fonctionner. Régénérez les clés d’hôte SSH (probablement optionnel): cd / nfs / client1 sudo mount --bind / dev dev sudo mount --bind / sys sys sudo mount --bind / proc proc sudo chroot. rm / etc / ssh / ssh_host_ * dpkg-reconfigure openssh-server sortie sudo umount dev sudo umount sys sudo umount proc

Supprimez le fichier d'échange dupliqué s'il existe: sudo rm / nfs / client1 / var / swap

Créez ensuite une archive tar du dossier nfs (vous pouvez le gziper mais le Pi n’est pas si puissant que ça n’en vaut probablement pas la peine par rapport au temps de transfert, mais c’est juste une hypothèse). le -p drapeau doit préserver les autorisations, etc. sudo tar -cpf /nfs.tar / nfs

Je me suis retrouvé avec un goudron de 1,2 Go: pi @ raspberrypi: ~ $ ls -alh /nfs.tar -rw-r - r-- 1 racine racine 1.2G 2 mars, 20h56 /nfs.tar

Enfin, cette archive doit se retrouver sur le serveur, ce qui importe peu – rsync, scp, ou prenez la carte et copiez-la … par exemple: pi @ raspberrypi: ~ $ scp /nfs.tar paul @ nas: /home/paul/nfs.tar nfs.tar 2% 24MB 12.9MB / s 01:25 ETA

Nous avons maintenant terminé avec ce Pi pour le moment, la carte SD sera utilisée plus tard. Il existe d'autres instructions ci-dessous pour "cloner" un Pi existant en utilisant rsync pour préserver les autorisations, ce qui peut être plus rapide si vous souhaitez cloner directement sur votre serveur. Activer le démarrage réseau Ces étapes activent le mode de démarrage USB (qui inclut PXE) sur le Pi. Étape 1: Carte SD Raspbian Lite Soit en répétant l’étape 1 ci-dessus, soit en réutilisant la carte laissée par la section précédente, redémarrez le Pi. Étape 2: Configuration de démarrage Nous devons activer le mode de démarrage USB (qui prend également en charge PXE). Ajouter program_usb_boot_mode = 1 à /boot/config.txt: echo programme_usb_boot_mode = 1 | sudo tee -a /boot/config.txt

Qui peut être vérifié avec tail /boot/config.txt: pi @ raspberrypi: ~ $ tail /boot/config.txt # dtparam = spi = on

# Décommenter ceci pour activer le module lirc-rpi # dtoverlay = lirc-rpi

# Les paramètres et les superpositions supplémentaires sont documentés / boot / overlays / README

# Activer l'audio (charge snd_bcm2835) dtparam = audio = on program_usb_boot_mode = 1

Puis redémarrez: redémarrage sudo Une fois que le Pi est rétabli, vérifiez que l’OTP a été programmé correctement avec vcgencmd otp_dump | grep 17:: pi @ raspberrypi: ~ $ vcgencmd otp_dump | grep 17: 17: 3020000a

Si la sortie se termine par 3020000a alors cela a fonctionné. Une fois de plus, nous avons fini avec les cartes Pi et SD pour le moment, vous pouvez inverser la /boot/config.txt changer si vous souhaitez continuer à utiliser la carte à d’autres fins, le reste de la /démarrage la partition sur la carte SD sera toujours nécessaire plus tard. En fait, le réseau démarre le Pi Dans cette série d'étapes, nous apportons les modifications requises côté serveur pour lui permettre de démarrer. Étape 1: DHCP Votre serveur DHCP local doit pouvoir envoyer quelques options DHCP spécifiques. Mon serveur exécute déjà le serveur DHCP ISC qui peut être installé avec sudo apt-get install isc-dhcp-server. Auparavant, ma configuration DHCP (/etc/dhcp/dhcpd.conf) servait des adresses IP de la plage 192.168.1.100-200, ainsi qu'un suffixe DNS local spécifique, des serveurs de noms et la passerelle, ainsi qu'un certain nombre de réservations IP (non incluses ci-dessous). : L'adresse de la directive next-server doit être ajoutée: serveur suivant 192.168.1.50;, ainsi que le nom du serveur TFTP: option tftp-nom-serveur "192.168.1.50";. Je n'ai pas rencontré le avoir besoin pour l'entrée tftp-nom-serveur avant le démarrage PXE des ordinateurs / serveurs standard (x86 / x64). Ce fil de discussion a permis d’affiner certaines des modifications de configuration requises pour isc-dhcp-server. Après toute modification, redémarrez le service: sudo service redémarrage du serveur isc-dhcp-server

L'activité DHCP peut être visualisée soit en finissant syslog tail -f / var / log / syslog | grep dhcpd: ->% tail -f / var / log / syslog | grep dhcpd 2 mars 21:48:17 nas dhcpd[825]: DHCPDISCOVER à partir de b8: 27: eb: 1b: 3c: 41 via em1 2 mars 21:48:17 nas dhcpd[825]: DHCPOFFER sur 192.168.1.58 à b8: 27: eb: 1b: 3c: 41 via em1 2 mars 21:48:27 nas dhcpd[825]: DHCPDISCOVER à partir de b8: 27: eb: 1b: 3c: 41 via em1 2 mars 21:48:27 nas dhcpd[825]: DHCPOFFER sur 192.168.1.58 à b8: 27: eb: 1b: 3c: 41 via em1

Ou en utilisant tcpdump: sudo tcpdump -i em1 port bootpc ->% sudo tcpdump -i em1 port bootpc 21: 48: 17.817689 IP 0.0.0.0.bootpc> 255.255.255.255.bootps: BOOTP / DHCP, Requête de b8: 27: eb: 1b: 3c: 41 (oui inconnue), longueur 320 21: 48: 17.818171 IP nas.home.ridgway.io.bootps> 192.168.1.58.bootpc: BOOTP / DHCP, Réponse, longueur 300 21: 48: 27.207000 IP 0.0.0.0.bootpc> 255.255.255.255.bootps: BOOTP / DHCP, Requête de b8: 27: eb: 1b: 3c: 41 (oui inconnue), longueur 320 21: 48: 27.207371 IP nas.home.ridgway.io.bootps> 192.168.1.58.bootpc: BOOTP / DHCP, Réponse, longueur 300

Lorsque le Pi est allumé après l'activation du mode de démarrage USB, vous pouvez le voir à la recherche d'une adresse IP. Étape 2: TFTP Installez le service TFTP (qui fonctionne avec xinetd): sudo apt-get install -y tftpd

Créer un fichier de configuration tftpd /etc/xinetd.d/tftp contenant: Et créer le / tftpboot dossier spécifié ci-dessus: sudo mkdir / tftpboot

Puis enfin redémarrez xinetd: sudo service xinetd restart

Pour afficher l’activité du syslog de fin de serveur TFTP avec tail -f / var / log / syslog | grep tftpd: Vérifiez la connectivité et la journalisation à partir d'un autre hôte: Client: paul @ box [21:54:00] [~] ->% tftp 192.168.1.50 tftp> se faire tester Code d'erreur 1: fichier non trouvé tftp>

Serveur: paul @ nas [21:53:48] [~] ->% tail -f / var / log / syslog | grep tftpd 2 mars 21:54:04 nas tftpd[1800]: tftpd: essayer d'obtenir le fichier: test 2 mars 21:54:04 nas tftpd[1800]: tftpd: fichier de desserte de / tftpboot

Maintenant, lorsque le Pi est démarré après les entrées DHCP, Syslog devrait afficher une activité TFTP: tftpd: essayant d'obtenir le fichier: bootsig.bin tftpd: fichier de desserte de / tftpboot

Remarque: Le journal n'indique pas d'échec car ce fichier n'existe pas encore. Copier tous les fichiers du /démarrage partition de la carte SD à la / tftpboot dossier. Si le micrologiciel Pi a été mis à jour de la manière décrite ci-dessus, il ne devrait pas y avoir de problème, mais le dernier bootcode.bin de GitHub n'est pas requis. par exemple: paul @ box [10:21:09] [/media/paul/boot] ->% 7z un boot.7z / media / paul / boot / * paul @ box [10:35:39] [/media/paul/boot] ->% scp boot.7z nas:

paul @ nas [10:21:30] [~/boot] ->% 7z x ../boot.7z paul @ nas [10:21:16] [~/boot] ->% sudo mv * / tftpboot

Remarque: Comme l'a noté un lecteur, la liaison de la racine TFTP au dossier de démarrage de l'arborescence NFS permet la mise à jour du microprogramme. La liaison ou la copie du contenu de boot vers NFS permet également à I2C et SPI de fonctionner, car les superpositions de / boot sont disponibles pour le système d'exploitation. Attention: Si d'autres fichiers de GitHub (éventuellement les fichiers start / fixup elf) sont utilisés, le Pi ne pourra PAS voir toutes les ressources disponibles telles que la RAM. Les journaux affichent les fichiers demandés. Un nettoyage peut donc être effectué si vous le souhaitez. tftpd: essayer d'obtenir le fichier: bootcode.bin essayer d'obtenir le fichier: bootsig.bin tftpd: essayant d'obtenir le fichier: ea1b3c41 / start.elf tftpd: essayer d'obtenir le fichier: autoboot.txt tftpd: essayer d'obtenir le fichier: config.txt tftpd: essayer d'obtenir le fichier: recovery.elf tftpd: essayer d'obtenir le fichier: start.elf tftpd: essayer de récupérer le fichier: fixup.dat tftpd: essayer d'obtenir le fichier: recovery.elf tftpd: essayer d'obtenir le fichier: config.txt tftpd: essayer d'obtenir le fichier: dt-blob.bin tftpd: essayer d'obtenir le fichier: recovery.elf tftpd: essayer d'obtenir le fichier: config.txt tftpd: essayant d'obtenir le fichier: bootcfg.txt tftpd: essayer d'obtenir le fichier: cmdline.txt tftpd: essayer d'obtenir le fichier: recovery8.img tftpd: essayant d'obtenir le fichier: recovery8-32.img tftpd: essayant d'obtenir le fichier: recovery7.img tftpd: essayer d'obtenir le fichier: recovery.img tftpd: essayant d'obtenir le fichier: kernel8.img tftpd: essayant d'obtenir le fichier: kernel8-32.img tftpd: essayant d'obtenir le fichier: kernel7.img tftpd: essayer d'obtenir le fichier: armstub8.bin tftpd: essayant d'obtenir le fichier: armstub8-32.bin tftpd: essayer d'obtenir le fichier: armstub7.bin tftpd: essayer d'obtenir le fichier: armstub.bin tftpd: essayant d'obtenir le fichier: kernel7.img tftpd: essayant d'obtenir le fichier: bcm2710-rpi-3-b.dtb tftpd: essayer d'obtenir le fichier: overlays / rpi-ft5406.dtbo tftpd: essayant d'obtenir un fichier: overlays / rpi-backlight.dtbo tftpd: essayer d'obtenir le fichier: config.txt

Tout va bien lorsque le PI démarre, il affichera d'abord l'écran de dégradé habituel: Et puis, semblent rester bloqués dans l’attente de la carte SD:

Si l'un des fichiers requis est manquant, DHCP n'est pas configuré correctement ou ne parvient pas à joindre TFTP. D'après mon expérience, vous n'obtiendrez même pas l'écran de dégradé. Étape 3: NFS Installez le serveur NFS: sudo apt-get install -y serveur nfs-kernel

Extrayez l'archive tar à partir des étapes ci-dessus. Encore une fois, pour préserver les autorisations sudo et - même propriétaire sont importants: sudo tar --same-owner -xvf nfs.tar

Et déplacez le dossier nfs à la racine: sudo mv nfs /

Et puis configurez l'exportation NFS, en redémarrant NFS après et en vous assurant qu'elle est activée: echo "/ nfs / client1 * (rw, sync, no_subtree_check, no_root_squash)" | sudo tee -a / etc / exports sudo systemctl enable rpcbind sudo systemctl redémarrer rpcbind sudo systemctl enable nfs-kernel-server sudo systemctl redémarrer nfs-kernel-server

Maintenant, il faut dire au Pi de démarrer à partir du serveur NFS, créer / éditer /tftpboot/cmdline.txt avec le contenu: selinux = 0 dwc_otg.lpm_enable = 0 console = tty1 rootwait rw nfsroot = 192.168.1.50: / nfs / client1, v3 ip = dhcp racine = / dev / nfs ascenseur = date-limite

Cela peut également être copié et édité à partir de la partition de démarrage de la carte SD. Enfin, supprimez toutes les autres entrées du fichier fstab / nfs / client1 / etc / fstab de sorte qu'il ne contienne que l'entrée proc: proc / proc proc par défaut 0 0

Le Pi devrait maintenant démarrer complètement. Vous pouvez éditer /nfs/client1/etc/rc.local pour préciser que le Pi a démarré sur le réseau: #! / bin / sh -e si [ "$_IP" ]; puis   printf "Mon adresse IP bloquée dans le réseau est% s n" "$ _IP" Fi

sortie 0

Pendant le processus de démarrage, les journaux indiquent la configuration du réseau et NFS, ce qui peut être utile pour résoudre les problèmes de débogage (les lignes d'IP-Config et suivantes):

Étape 4: Configuration par Pi (facultatif) J'ai un écran TFT pour le Pi qui est à l'envers par défaut:

La solution consiste à ajouter la ligne suivante à /boot/config.txt: lcd_rotate = 2

Si je fais ça dans /tftpboot/config.txt il s'appliquera à tous les PIS amorcés sur le réseau. Heureusement, le Pi vérifie d’abord un dossier en fonction de son adresse MAC (le numéro de série est indiqué ici), comme indiqué à la dernière ligne ci-dessous (copié à partir de la séquence de démarrage ci-dessus): 2 mars 22:21:19 nas tftpd[2579]: tftpd: essayer d'obtenir le fichier: bootcode.bin 2 mars 22:21:19 nas tftpd[2581]: tftpd: essayer d'obtenir le fichier: bootsig.bin 2 mars 22:21:19 nas tftpd[2583]: tftpd: essayant d'obtenir le fichier: ea1b3c41 / start.elf

Mon PI a le MAC de ea: 1b: 3c: 41 donc un dossier pour cela doit être créé: sudo mkdir / tftpboot / ea1b3c41

Si le PI trouve se lancer là, il recherchera tous les autres fichiers là aussi, pour économiser de l’espace, ils peuvent être liés symboliquement avec sudo ln -s / tftpboot / *. qui donne: paul @ nas [23:08:25] [/tftpboot/ea1b3c41] ->% ls -alh total 8.0K drwxr-xr-x 2 racine racine 4.0K 2 mars 23:08. drwxr-xr-x 3 racine racine 4.0K 2 mars 23:06 .. lrwxrwxrwx 1 racine racine 29 mars 2 23h07 bcm2708-rpi-0-w.dtb -> /tftpboot/bcm2708-rpi-0-w.dtb lrwxrwxrwx 1 racine racine 27 mars 2 23h07 bcm2708-rpi-b.dtb -> /tftpboot/bcm2708-rpi-b.dtb lrwxrwxrwx 1 racine racine 32 mars 2 23h07 bcm2708-rpi-b-plus.dtb -> /tftpboot/bcm2708-rpi-b-plus.dtb lrwxrwxrwx 1 racine racine 28 mars 2 23h07 bcm2708-rpi-cm.dtb -> /tftpboot/bcm2708-rpi-cm.dtb lrwxrwxrwx 1 racine racine 29 mars 2 23h07 bcm2709-rpi-2-b.dtb -> /tftpboot/bcm2709-rpi-2-b.dtb lrwxrwxrwx 1 racine racine 29 mars 2 23h07 bcm2710-rpi-3-b.dtb -> /tftpboot/bcm2710-rpi-3-b.dtb lrwxrwxrwx 1 racine racine 29 mars 2 23h07 bcm2710-rpi-cm3.dtb -> /tftpboot/bcm2710-rpi-cm3.dtb lrwxrwxrwx 1 racine racine 22 mars 2 23h07 bootcode.bin -> /tftpboot/bootcode.bin lrwxrwxrwx 1 racine racine 21 mars 2 23h07 cmdline.txt -> /tftpboot/cmdline.txt lrwxrwxrwx 1 racine racine 18 mars 2 23h08 ea1b3c41 -> / tftpboot / ea1b3c41 lrwxrwxrwx 1 racine racine 21 mars 2 23h07 kernel7.img -> /tftpboot/kernel7.img lrwxrwxrwx 1 racine racine 20 mars 2 23h07 kernel.img -> /tftpboot/kernel.img lrwxrwxrwx 1 racine racine 22 mars 2 23h07 start_cd.elf -> /tftpboot/start_cd.elf lrwxrwxrwx 1 racine racine 22 mars 2 23h07 start_db.elf -> /tftpboot/start_db.elf lrwxrwxrwx 1 racine racine 19 mars 2 23h07 start.elf -> /tftpboot/start.elf lrwxrwxrwx 1 racine racine 21 mars 2 23h07 start_x.elf -> /tftpboot/start_x.elf

Nous pouvons déplacer le lien d'auto-référencement nouvellement créé: sudo rm / tftpboot / ea1b3c41 / ea1b3c41

Désormais, lorsque Pi démarrera, il extraira tous les fichiers suivants de ce dossier: 2 mars 23:09:41 nas tftpd[5282]: tftpd: essayer d'obtenir le fichier: bootcode.bin 2 mars 23:09:41 nas tftpd[5284]: tftpd: essayer d'obtenir le fichier: bootsig.bin 2 mars 23:09:41 nas tftpd[5286]: tftpd: essayant d'obtenir le fichier: ea1b3c41 / start.elf 2 mars 23:09:41 nas tftpd[5288]: tftpd: essayant d'obtenir le fichier: ea1b3c41 / autoboot.txt 2 mars 23:09:41 nas tftpd[5290]: tftpd: essayant d’obtenir le fichier: ea1b3c41 / config. ...

Maintenant modifié config.txt peut être ajouté, soit copié de / tftpboot et changé, ou de la /démarrage partition d'une carte SD: paul @ nas [23:10:12] [/tftpboot/ea1b3c41] ->% ll total 4,0K lrwxrwxrwx 1 racine racine 29 mars 2 23h07 bcm2708-rpi-0-w.dtb -> /tftpboot/bcm2708-rpi-0-w.dtb lrwxrwxrwx 1 racine racine 27 mars 2 23h07 bcm2708-rpi-b.dtb -> /tftpboot/bcm2708-rpi-b.dtb lrwxrwxrwx 1 racine racine 32 mars 2 23h07 bcm2708-rpi-b-plus.dtb -> /tftpboot/bcm2708-rpi-b-plus.dtb lrwxrwxrwx 1 racine racine 28 mars 2 23h07 bcm2708-rpi-cm.dtb -> /tftpboot/bcm2708-rpi-cm.dtb lrwxrwxrwx 1 racine racine 29 mars 2 23h07 bcm2709-rpi-2-b.dtb -> /tftpboot/bcm2709-rpi-2-b.dtb lrwxrwxrwx 1 racine racine 29 mars 2 23h07 bcm2710-rpi-3-b.dtb -> /tftpboot/bcm2710-rpi-3-b.dtb lrwxrwxrwx 1 racine racine 29 mars 2 23h07 bcm2710-rpi-cm3.dtb -> /tftpboot/bcm2710-rpi-cm3.dtb lrwxrwxrwx 1 racine racine 22 mars 2 23h07 bootcode.bin -> /tftpboot/bootcode.bin lrwxrwxrwx 1 racine racine 21 mars 2 23h07 cmdline.txt -> /tftpboot/cmdline.txt -rw-r - r-- 1 racine racine 1.3K 2 mars 23:10 config.txt lrwxrwxrwx 1 racine racine 21 mars 2 23h07 kernel7.img -> /tftpboot/kernel7.img lrwxrwxrwx 1 racine racine 20 mars 2 23h07 kernel.img -> /tftpboot/kernel.img lrwxrwxrwx 1 racine racine 22 mars 2 23h07 start_cd.elf -> /tftpboot/start_cd.elf lrwxrwxrwx 1 racine racine 22 mars 2 23h07 start_db.elf -> /tftpboot/start_db.elf lrwxrwxrwx 1 racine racine 19 mars 2 23h07 start.elf -> /tftpboot/start.elf lrwxrwxrwx 1 racine racine 21 mars 2 23h07 start_x.elf -> /tftpboot/start_x.elf

Si config.txt était déjà symboliquement lié les supprimer en premier. Maintenant, cela commence avec l’écran dans le bon sens:

Carte d'activation / de vérification du mode de démarrage USB Les étapes ci-dessous décrivent comment créer une carte SD qui activera et vérifiera le mode de démarrage USB (PXE), ce qui facilitera la configuration d'un grand nombre de périphériques Pi 3 en une seule fois. Étape 1: Carte SD Raspbian Lite Soit en répétant l’étape 1 ci-dessus, soit en réutilisant la carte laissée par la section précédente, redémarrez le Pi. Dans les étapes suivantes, quelques fichiers sont édités, ce qui peut être fait sur un Pi ou une autre machine pouvant éditer /démarrage et rootfs systèmes de fichiers. Étape 2: Configuration de démarrage Comme ci-dessus, nous devons activer le mode de démarrage USB. Ajouter program_usb_boot_mode = 1 à /boot/config.txt: echo programme_usb_boot_mode = 1 | sudo tee -a /boot/config.txt

Qui peut être vérifié avec tail /boot/config.txt: pi @ raspberrypi: ~ $ tail /boot/config.txt # dtparam = spi = on

# Décommenter ceci pour activer le module lirc-rpi # dtoverlay = lirc-rpi

# Les paramètres et les superpositions supplémentaires sont documentés / boot / overlays / README

# Activer l'audio (charge snd_bcm2835) dtparam = audio = on program_usb_boot_mode = 1

Étape 3: Vérifiez au démarrage Avec un simple script, le Pi peut être vérifié au démarrage. L’exemple ci-dessous efface l’écran pour améliorer la lisibilité (ce qui n’est pas utile pour le débogage des problèmes d’amorçage), puis s’endormit pendant une longue période (24h), empêchant le Pi de s’amorcer complètement afin que la sortie soit clairement visible, de la couleur ou un autre formatage pouvant être ajouté. c'est plus évident! Créer /root/check-netboot.sh avec le contenu suivant: #! / bin / bash

clair

CHECK = $ (vcgencmd otp_dump | grep 17 :)

si [[ "$CHECK" == "17:3020000a" ]]; puis   echo "Mode de démarrage correct :) ($ CHECK)" autre   echo "!!! Le mode de démarrage a échoué, valeur: $ CHECK" Fi

dormir 86400

Assurez-vous de le rendre exécutable: sudo chmod + x /root/check-netboot.sh

modifier /etc/rc.local appeler check-netboot.sh:

#! / bin / sh -e

# Imprimer l'adresse IP _IP = $ (nom d'hôte -I) || vrai si [ "$_IP" ]; puis   printf "Mon adresse IP est% s n" "$ _IP" Fi

/root/check-netboot.sh

sortie 0

À partir de cette carte, chaque Pi 3 peut être initialisé une fois, ce qui doit activer le mode de démarrage USB (PXE) et le confirmer. Le script peut être mis à jour pour éteindre en cas de succès avec éteindre après le premier écho dans check-netboot.sh. Quelques notes Installation partagée Tous les périphériques ont un accès en lecture-écriture au système de fichiers NFS dans la configuration ci-dessus, de sorte que tous les packages ou modifications installés sur l'un d'entre eux sont disponibles pour tous. En outre, tout accès SSH ou clé d’hôte ainsi que le / etc / passwd Les fichiers sont tous partagés, ces modifications se propagent également. Bien que cela puisse faciliter les modifications globales (installation de paquets à partir d'apt), il est lent et j'ai parfois vu des erreurs, bien que cela ait été lié à des permissions avant que je trouve une solution à cela, il semble préférable de faire des modifications localement. et re-cloner le système de fichiers. Débogage NFS Initialement, pour tenter de comprendre si le Pi s’amorçait à partir du réseau, il était utile d’activer le débogage NFS avec rpcdebug -m nfsd -s proc qui rapporte assez verbalement à syslog. Ne désactiver l'exécution rpcdebug -m nfsd -c Plus de détails ici. Écran tactile Actuellement, il semble que l'écran tactile du Raspberry Pi ne soit pas détecté lors du démarrage du réseau. Résoudre cela est toujours un travail en cours … Mise à jour (2019-04-06): J'ai finalement eu le temps d'essayer atftp, qui semble avoir résolu le problème de détection de l'écran tactile. Configuration par appareil Les étapes ci-dessus pour activer chaque périphérique config.txt les options peuvent également être utilisées pour remplacer cmdline.txt (en supprimant d’abord la version liée par un lien symbolique) et spécifiez un autre chemin NFS. / etc / exports aurait également besoin d'être mis à jour. par exemple: root @ nas: / tftpboot / ea1b3c41 # rm cmdline.txt root @ nas: / tftpboot / ea1b3c41 # cp ../cmdline.txt. root @ nas: / tftpboot / ea1b3c41 # vi cmdline.txt

cmdline.txt maintenant contenu (note client 2): selinux = 0 dwc_otg.lpm_enable = 0 console = tty1 rootwait rw nfsroot = 192.168.1.50: / nfs / client2, v3 ip = dhcp racine = / dev / nfs ascenseur = date-limite

/ etc / exports contient: # / etc / exports: la liste de contrôle d'accès pour les systèmes de fichiers pouvant être exportés # aux clients NFS. Voir exportations (5). # # Exemple pour NFSv2 et NFSv3: # / srv / homes nom_hôte1 (rw, synchronisation, no_subtree_check) nom_hôte2 (ro, synchronisation, no_subtree_check) # # Exemple pour NFSv4: # / srv / nfs4 gss / krb5i (rw, sync, fsid = 0, crossmnt, no_subtree_check) # / srv / nfs4 / homes gss / krb5i (rw, sync, no_subtree_check) # / nfs / client1 * (rw, sync, no_subtree_check, no_root_squash) / nfs / client2 * (rw, sync, no_subtree_check, no_root_squash)

/ nfs / client2 est une copie de / nfs / client1 avec un modifié /etc/rc.local vérifier. Cloner un autre Pi avec rsync L’exécution à partir du serveur NFS clonera en tant que racine des deux côtés, ce qui devrait préserver les autorisations sans qu'il soit nécessaire de créer ou de tar / nfs dossier sur l'appareil. La première sudo permet à rsync de définir les autorisations et la propriété appropriées sur le système de fichiers local. le --rsync-path = "sudo rsync" exécute rsync en tant que root sur le Pi pour s’assurer qu’il a accès à tous les fichiers. Avec la configuration sudoers par défaut, rien ne sera demandé. pi mot de passe SSH de l'utilisateur. sudo rsync -xa --progress --rsync-path = "sudo rsync" --exclude '/ var / swap' --stats pi@192.168.1.59: / / nfs / client1

N'oubliez pas de modifier / etc / fstab dans le système de fichiers NFS par la suite, ainsi que la suppression / var / swap si ce n'était pas exclu. Un script simple pour le faire clone.sh: #! / bin / bash sudo rsync -xa --progress --rsync-path = "sudo rsync" --exclude '/ var / swap' --stats $ 1: / $ 2 grep proc $ 2 / etc / fstab> $ 2 / etc / fstab.new mv $ 2 / etc / fstab.new $ 2 / etc / fstab

Courir comme ./clone.sh pi@192.168.1.59 / nfs / clientX. Autorisations et Sudo Si vous n'utilisez pas rsync comme ci-dessus ou tar avec les indicateurs d'autorisations spécifiques décrits précédemment, après la création du système de fichiers NFS, les autorisations peuvent être héritées du chemin d'extraction ou similaire si les instructions tar spécifiques ci-dessus ne sont pas suivies: root @ nas: / nfs / client1 # ll total 88 drwxr-xr-x 22 paul paul 4096 2 mars 20:45 ./ drwxr-xr-x 4 paul paul 4096 3 mars 09:53 ../ drwxr-xr-x 2 paul paul 4096 2 mars 19:04 bin / drwxr-xr-x 2 paul paul 4096 1 janvier 1970 botte / drwxr-xr-x 3 paul paul 4096 1 janv. 1970 boot.bak / drwxr-xr-x 2 paul paul 4096 2 mars 20:39 dev / drwxr-xr-x 83 paul paul 4096 3 mars 09:59 etc / drwxr-xr-x 3 paul paul 4096 29 nov. 01:22 accueil / drwxr-xr-x 17 paul paul 4096 2 mars 19:12 lib / drwx ------ 2 paul paul 4096 29 nov. 02h35 perdus + trouvés / drwxr-xr-x 2 paul paul 4096 29 nov. 01:06 média / drwxr-xr-x 2 paul paul 4096 29 nov. 01:06 mnt / drwxr-xr-x 3 paul paul 4096 29 nov. 01:22 opt / dr-xr-xr-x 2 paul paul 4096 1 janv. 1970 proc / drwx ------ 2 paul paul 4096 2 mars 19:13 racine / drwxr-xr-x 2 paul paul 4096 2 mars 20:44 courir / drwxr-xr-x 2 paul paul 4096 2 mars 19:04 sbin / drwxr-xr-x 2 paul paul 4096 29 nov 01:06 srv / dr-xr-xr-x 2 paul paul 4096 1 janv. 1970 sys / drwxrwxrwt 8 racine racine 4096 3 mars 09:56 tmp / drwxr-xr-x 10 paul paul 4096 29 nov. 01:06 usr / drwxr-xr-x 11 paul paul 4096 3 mars 09:56 var /

Pour résoudre ce problème, attribuez la propriété racine à tous les fichiers sauf à la maison, notez l'utilisation de l'UID et du GID, car ils ne correspondent pas aux noms d'entité du serveur: root @ nas: / nfs / client1 # sudo chown root: root. -Rf root @ nas: / nfs / client1 # chown 1000: 1000 home / pi -Rf

Si essayant de sudo sur un réseau démarré Pi et obtenant l'erreur suivante: sudo: / usr / bin / sudo doit appartenir à uid 0 et avoir le bit setuid défini

Ensuite, assurez-vous que setuid le bit est mis: root @ nas: / nfs / client1 # chmod / usr / bin / sudo

Les autorisations peuvent être vérifiées par rapport à l'installation locale d'Ubuntu: root @ nas: / nfs / client1 # ls -alh / usr / bin / sudo -rwsr-xr-x 1 racine racine 140K 4 juillet 2017 / usr / bin / sudo root @ nas: / nfs / client1 # ls -alh usr / bin / sudo -rwsr-xr-x 1 racine racine 133K 5 juin 2017 usr / bin / sudo

Ceci n’est toujours pas parfait, il est donc fortement recommandé d’utiliser rsync ou tar comme décrit précédemment. Des sauvegardes La racine NFS peut facilement être sauvegardée: root @ nas: / nfs # cp client1 sauvegarde -Rf

Il serait sage de le sauvegarder avant d’apporter des modifications à la configuration matérielle ou au package, juste au cas où. Échecs de démarrage Si le Pi ne demande rien à TFTP, il pourrait s'agir d'un problème de configuration DHCP ou d'un problème d'accès TFTP. Si vous voyez le Pi faire peu ou pas plus loin que de demander bootcode.bin alors il est possible que la mauvaise version des fichiers se trouve dans le dossier tftp, assurez-vous que les prochaines versions de branche sont utilisées: 2 mars 23:11:31 nas tftpd[5385]: tftpd: essayer d'obtenir le fichier: bootcode.bin

Si cela va plus loin, mais se bloque comme indiqué ci-dessus, il pourrait s'agir d'un problème d'accès au système de fichiers / NFS. Attention au cache de fichiers TFTP Non prouvé. Cependant, lors du débogage du problème de RAM mal signalé, j'ai remplacé mon dossier de démarrage personnalisé (par de nouveaux liens symboliques), mais le Pi à écran tactile semblait toujours récupérer les anciens fichiers car il signalait une mémoire RAM inférieure. Après un redémarrage de xinetd, tout allait bien … Performance L'installation et la configuration de paquets, etc. vont naturellement être plus lentes car le Pi ne dispose que d'Ethernet à 100 Mbits et des frais généraux liés à l'utilisation d'un système de fichiers basé sur le réseau. Pour des raisons de rapidité, toutes les configurations pourraient être effectuées sur SD, puis copiées en suivant les étapes ci-dessus. Réservations DHCP Pour vous simplifier la vie, vous pouvez ajouter des réservations d’adresses DHCP dans le corps principal de la configuration DHCP afin que chaque adresse MAC reçoive la même adresse IP: {

  ...

  hôte pi3-1     Ethernet matériel b8: 27: eb: 41: 8e: fa;     adresse fixe 192.168.1.59;   

  hôte pi3-2     Ethernet matériel b8: 27: eb: 1b: 3c: 41;     adresse fixe 192.168.1.58;   

Nom d'hôte contrôlé par DHCP sur Raspbian En théorie, la configuration devrait être aussi simple que celle indiquée ci-dessous:

  ...

  hôte pi3-1     Ethernet matériel b8: 27: eb: 41: 8e: fa;     adresse fixe 192.168.1.59;     option nom-hôte "pi3-1";   

  hôte pi3-2     Ethernet matériel b8: 27: eb: 1b: 3c: 41;     adresse fixe 192.168.1.58;     option nom-hôte "pi3-2";   

Cependant, il semble que cela soit ignoré, cet article fournit une solution qui semble fonctionner et ne modifie pas la / etc / hostname fichier dans la racine NFS. En tant que root: echo localhost> / etc / hostname

Ensuite: echo unset old_host_name> /etc/dhcp/dhclient-enter-hooks.d/unset_old_hostname

Ce qui semble fonctionner:

Click to rate this post! [Total: 0 Average: 0]