-
Notifications
You must be signed in to change notification settings - Fork 0
Home
Cette page va être plus propre très bientôt
-
The board is powered on and starts its firmware
-
The firmware starts a network bootloader1 stored on its local disk or flash device
-
The network bootloader runs its DHCP client procedure in order to get its IP address + the address of the TFTP server The type of node is passed to the DHCP server by using the VCI2 (vendor class identifier) or UCI3 (user class identifier) field of the DHCP request
-
The DHCP server (on the walt server) has a hook allowing to detect a lease has been delivered. When this happens, a python executable called walt-dhcp-event is run (with mac, ip and vci/uci as parameters). This allows to send a node registration request to walt-server-daemon
-
If the node is new:
walt-server-daemon ensures the default image for this model of node is downloaded and mounted. (This step may last a long time if it involves downloading an image from the docker hub.)
when the image is ready and mounted, a symlink4<tftp_root>/nodes/{mac_address} -> <tftp_root>/images/<docker_image>/fs
, that is to the corresponding filesystem, is created. -
The network bootloader loads and executes a second stage script stored in
<tftp_root>/boot/
using tftp Having such a second boot stage script stored on the server will allow to update the boot procedure when we update the server, if needed in the future. -
The network bootloader tries to load the kernel5
<tftp_root>/nodes/{mac_address}/{node_model}/kernel
using tftp, or reboots if it fails (supposedly the walt image is not ready yet) -
The network bootloader starts the kernel (with the optional dtb), with the following kernel options
init=<tftp_root>/bin/walt-init ip=dhcp root=/dev/nfs nfsroot=<server_ip>:/var/lib/walt/nodes/{mac_address},nfsvers=3
and others6 -
The kernel starts, mounts the NFS share and then calls
/usr/local/bin/walt-init
, which is the intermediate init system7 -
walt-init starts the NFS watchdog process (to periodically check that the NFS share is accessible and reboot otherwise)
-
walt-init starts the minimal network service (to handle soft reboot & blink requests)
-
walt-init mounts a union of the NFS root and a virtual filesystem in RAM (to keep the NFS share read-only)
-
walt-init calls the init system8
/sbin/init
in a chroot on top of the union -
The walt image OS starts up
1 pc nodes require an intermediate grub2 bootloader, which launches ipxe network bootloader executable, compiled as a linux kernel. rpi nodes use directly u-boot. ↩
2 u-boot uses vci to indicate the model of rpi↩
3 ipxe uses uci to indicate that the type of node is pc↩
4 For compatibility issues with different bootloaders symlinks are stored in two forms: xx:xx:xx:xx:xx:xx and xx-xx-xx-xx-xx-xx↩
5 u-boot also tries to load <tftp_root>/nodes/{mac_address}/{node_model}/dtb
. If it fails, u-boot tries to load <tftp_root>/nodes/{mac_address}/{node_model}/nodtb
, which is an empty file indicating the absence of associated with the image kernel device tree blob. If this also fails, the node reboots↩
6 Other kernel arguments are as follows : for pc-x86-64 : walt.node.model=pc-x86-64 panic=30
; for rpi : console=ttyAMA0,115200 console=tty1 smsc95xx.macaddr={ethaddr} walt.node.model={rpi_model} panic=15
↩
7 walt requires an intermediate init system to launch some specific monitoring and management services ↩
8 This is the real init system corresponding to the booted image↩