Démarrage en réseau d’un Raspberry Pi 3 à partir d’un serveur Ubuntu – Bien choisir son serveur d impression
Sommaire
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:
Commentaires
Laisser un commentaire