Vous POUVEZ faire exécuter du code en jouant avec la ligne de commande du noyau. La méthode la plus évidente consiste à remplacer init par autre chose. L'application la plus courante consiste à lancer un shell très tôt dans le processus de démarrage, généralement parce que vous devez réparer quelque chose ou parce que tout le reste est très mal cassé, par exemple:
init=/bin/bash
Gardez à l'esprit qu'à ce stade du processus de démarrage, les systèmes de fichiers sont toujours montés en lecture seule. De plus, il y a tout un tas de choses qui ne fonctionnent pas correctement. Parce que vous n'avez pas de véritable init en cours d'exécution, l'arrêt et le redémarrage ne fonctionneront pas. Vous devez remonter manuellement le système de fichiers racine en lecture seule et appeler reboot -fpour redémarrer, par exemple.
Je n'ai aucune idée si vous pouvez passer des arguments à bash de cette manière. Je n'ai jamais essayé. En théorie, si vous pouvez passer -cà bash, vous pouvez dire à ce processus bash de faire quoi que ce soit. Mais cela pourrait se transformer en un argument assez long, et je ne sais pas si le noyau permettrait de telles choses.
Deuxième chose que vous pouvez faire. Vous pouvez copier un ramfs initial (initramfs) dans le système de fichiers et configurer le chargeur de démarrage pour l'utiliser dans config.txt. Il y a plusieurs façons d'obtenir des scripts dans un initramfs pour faire des choses spéciales. Vous devrez cependant préparer un initramfs spécial à cet effet (voir initramfs-tools (8)), donc je ne suis pas sûr que ce soit une meilleure solution qu'une image personnalisée.
Vous pouvez inclure le script dans / boot (j'ai ri de votre suggestion à propos des machines "normales", mais ce serait le bit auquel vous pouvez accéder à partir de ces machines) et essayez de le lancer en utilisant la ligne d'initialisation du noyau, mais les fichiers sur les systèmes de fichiers dos ne sont pas n'est pas exécutable, sauf si vous le faites pour l'ensemble du système de fichiers.
Si c'était moi, je ferais une image personnalisée qui utilise DHCP pour configurer le réseau et qui contient un script personnalisé qui s'exécute au démarrage. Ce script recherche un fichier spécifique qui agit comme indicateur. Si le fichier existe, ne faites rien. Sinon, configurez les choses, puis créez le fichier indicateur.
Votre script de configuration pourrait même tirer la vraie chose d'un serveur http. Cela signifie que vous n'avez pas à créer une nouvelle image si vous devez modifier quelque chose.
Cela devrait être la solution la moins stressante.
Une dernière possibilité, mais vous devrez le faire sur une machine "non régulière" :-) Vous pouvez monter le système de fichiers ext4 sur un périphérique en boucle et y copier des fichiers sans l'écrire d'abord sur sdcard. Pour une image Raspbian Jessie standard, ce serait quelque chose comme ceci:
sudo losetup /dev/loop0 /tmp/gw.img -o 62914560
sudo mount /dev/loop0 /mnt
sudo cp /my/superduper/script.sh /mnt
sudo umount /dev/loop0
sudo fsck -f /dev/loop0 # This is optional
sudo losetup -d /dev/loop0
J'aime faire un fsck forcé sur mes systèmes de fichiers avant de faire des images. Définit le nombre de montages à zéro au premier démarrage :-)
EDIT : Après plusieurs mois et plus d'expérience. Vous voulez regarder u-boot. Remplacez le chargeur de démarrage par u-boot. Cela peut être fait à partir d'une "machine ordinaire". Une fois que vous avez u-boot en place, vous pouvez soit démarrer en réseau une distribution à partir de laquelle vous pouvez facilement flasher la carte sd, soit théoriquement flasher la carte directement, bien que je ne sache pas à quel point ce serait difficile.
Essentiellement, u-boot apporte un démarrage réseau au Raspberry Pi, quelque chose qu'il ne prend pas en charge seul.