[LINUX] Distributed environment construction with Raspberry PI series (7: tftp route setting and startup test for each Raspberry Pi)
Introduction (serialization list)
- Construction of distributed environment with Raspberry PI series (Part 1: Summary of availability of diskless client by model)
- Building a distributed environment with Raspberry PI series (Part 2: Analysis of PiServer and design of alternative system)
- Building a distributed environment with Raspberry PI series (Part 3: Installing and setting dnsmasq)
- Building a distributed environment with Raspberry PI series (Part 4: Build NFS server and import OS for clients)
- Building a distributed environment with the Raspberry PI series (Part 5: Customizing the Raspberry PI OS for cluster nodes (1))
- Building a distributed environment with Raspberry PI series (Part 6: Customization of Raspberry PI OS for cluster nodes (2))
- Building a distributed environment with Raspberry PI series (7: tftp route setting and startup test for each Raspberry Pi)
This article is part 7.
Last time uses qemu-user-static installed on an NFS (or PXE) server to customize the OS image for clients copied to an NFS machine. However, this time I will do a boot test as a tftp root by creating a symbolic link to the / boot directory of this OS image (this time it is short).
Reference (author's environment)
Actual work
Describe the NFS server and PXE server as separate.
1. Mount the NFS server shared directory from the PXE server
1.1. Create and mount a mount point on the PXE server
- NFS server IP dt>
- 192.168.172.17 dd>
- Shared directory name dt>
- / exports / os4pi dd>
If you have qemu-user-static installed on both NFS / PXE servers and want to customize the OS for Raspberry Pi from either, set it to rw, but if you don't need to customize it on the PXE server, you can use ro. ..
# mkdir /mnt/os4pi
# mount -t nfs -o proto=tcp,vers=3,rw,noatime 192.168.172.17:/exports/os4pi /mnt/os4pi
1.2. Add a line to / etc / fstab on the PXE server to persist
192.168.172.17:/exports/os4pi /mnt/os4pi nfs tcp,vers=3,rw,noatime,_netdev 0 0
2. Create a symbolic link to the tftp route set in dnsmasq
conditions
- tftp root (reference directory) dt>
- / srv / tftp dd>
- MAC address of Raspberry Pi 2B dt>
- b8-27-eb-GG-HH-II dd>
- Fixed IP assigned to Raspberry Pi 2B dt>
- 192.168.172.32 dd>
- OS / boot location for Raspberry Pi 2B dt>
- / mnt / os4pi / raspbian / armhf / boot dd>
- MAC address of Raspberry Pi 3B dt>
- b8-27-eb-XX-YY-ZZ dd>
- Fixed IP assigned to Raspberry Pi 3B dt>
- 192.168.172.33 dd>
- OS / boot location for Raspberry Pi 3B dt>
- / mnt / os4pi / raspbian / armhf_64 / boot dd>
- MAC address of Raspberry Pi 4B dt>
- dc-a6-32-PP-QQ-RR dd>
- Fixed IP assigned to Raspberry Pi 4B dt>
- 192.168.172.34 dd>
- OS / boot location for Raspberry Pi 4B dt>
- / mnt / os4pi / raspbian / aarch64 / boot dd>
# cd /srv/tftp
# rm -Rf b8-27-eb-GG-HH-II
# ln -sf /mnt/os4pi/raspbian/armhf/boot b8-27-eb-GG-HH-II
# ln -sf /mnt/os4pi/raspbian/armhf/boot 192.168.172.32
# rm -Rf b8-27-eb-XX-YY-ZZ
# ln -sf /mnt/os4pi/raspbian/armhf_64/boot b8-27-eb-XX-YY-ZZ
# ln -sf /mnt/os4pi/raspbian/armhf_64/boot 192.168.172.33
# rm -Rf dc-a6-32-PP-QQ-RR
# ln -sf /mnt/os4pi/raspbian/aarch64/boot dc-a6-32-PP-QQ-RR
# ln -sf /mnt/os4pi/raspbian/aarch64/boot 192.168.172.34
Notes
- Please change the IP / MAC address to the actual address of your Raspberry Pi.
For + 3B / 3B +, there is no problem with aarch64
- Before creating the symbolic link, the empty folder created in Part 3 is deleted.
- Make a link even with a fixed IP. If you do this, you can respond even if you change the dnsmasq setting to "Distribute tftp routes by IP".
3. Raspberry Pi test launch
3.0. Preparation
- Turn on the power in the order of NFS server → PXE server. Wait until you can log in.
- Refer to Part 1 and make each model ready for diskless boot.
3.1. For Raspberry PI 2B
- Copy only the bootcode.bin file from the latest RaspberryPI OS installer image to an empty microSD (which can be small) with the first partition FAT formatted and insert it into the Raspberry Pi
- Connect HDMI, keyboard, LAN
- Connect USB (power supply)
- Confirm that the bootcode.bin on the microSD has been read and the color gradation appears on the monitor. If you don't see it, either the microSD is dead (including if it's not in FAT format), the Raspberry Pi's microSD drive is bad, or the bootcode.bin file copy failed.
- Confirm that the LAN access lamp lights up. If it doesn't light up, it's possible that your Raspberry Pi's GPU / SoC is out of order or your network connection isn't working properly.
- Confirm that the rasp pie logo and boot log appear on the screen (it means that tftp settings are OK). If the screen remains black and does not proceed, there is a misconfiguration of the tftp server itself or a misconfiguration of the config.txt file on the tftp server.
- Confirm that you can log in. If it stops in the middle, it may be due to a misconfiguration of cmdline.txt on the tftp server, a misconfiguration of the NFS server, or a misconfiguration of the / etc / fstab file.
3.2. For Raspberry PI 3B / 3B +
- Unplug the microSD
- Connect HDMI, keyboard, LAN
- Connect USB (power supply)
- Confirm that the LAN access lamp lights up. If it doesn't light up, it's possible that 3B-specific preparations haven't been made, the network isn't properly connected, or the GPU / SoC is bad. [^ Bad]
- Confirm that the color gradation is displayed on the monitor. If you can confirm this, it is OK to download bootcode.bin from the tftp server. If you don't see the color gradient, it's possible that your tftp server is misconfigured.
- Confirm that the Raspeye logo and boot log appear on the screen. If the screen remains black and does not proceed, there is a misconfiguration in the config.txt file on the tftp server.
- Confirm that you can log in. If it stops in the middle, it may be due to a misconfiguration of cmdline.txt on the tftp server, a misconfiguration of the NFS server, or a misconfiguration of the / etc / fstab file.
[^ Bad]: In fact, I had one 3B individual that often caused the microSD to fail to boot immediately after purchase. I always thought "microSD is dead / incompatible", but while testing diskless boot, I realized that "this is an initial failure". Initial failure that I noticed for the first time 4 years after purchase ...
3.3. For Raspberry PI 4B
- Unplug the microSD
- Connect HDMI, keyboard, LAN
- Connect USB (power supply)
- Confirm that the LAN access lamp lights up. If it does not light up, it may be due to unprepared, poorly connected networks, or a bad EEPROM / SoC.
- Confirm that the color gradation is displayed on the monitor and blacked out. It can be confirmed that there is no initial failure of the EEPROM.
- Confirm that the Raspeye logo and boot log appear on the screen. If the screen remains black and does not proceed, there is a misconfiguration in the config.txt file on the tftp server.
- Confirm that you can log in. If it stops in the middle, it may be due to a misconfiguration of cmdline.txt on the tftp server, a misconfiguration of the NFS server, or a misconfiguration of the / etc / fstab file.
Next time preview
That's all for this time. Next time, I would like to build the simplest distributed environment, a load distribution (redundant) web server using Apache.