Démarrer Linux depuis Google Drive

• Une expérience consistant à démarrer Arch Linux en utilisant Google Drive comme système de fichiers racine, au lieu d’un disque local ou de NFS
• Montage d’un système de fichiers FUSE à l’étape initramfs, puis création avec Dracut d’une image EFI personnalisée incluant le réseau et les binaires nécessaires
• Après avoir d’abord validé le concept avec S3 et s3fs, contournement des échecs de switch_root et pivot_root en exécutant chroot en tant que PID 1
• Lors du passage à Google Drive, google-drive-ocamlfuse a été utilisé, mais les limitations sur les liens symboliques, liens physiques, permissions, attributs et performances ont nécessité des corrections manuelles et des ajustements de timeouts
• Au final, même un ordinateur portable sans périphérique de stockage a démarré grâce à un fichier EFI unifié sur USB et à un pilote réseau filaire ; l’approche est peu pratique, mais montre des variantes possibles comme une racine basée sur SSHFS ou Git

---

Utiliser Google Drive comme système de fichiers racine

• Après avoir vu un exemple de démarrage de Linux depuis NFS, tentative d’un objectif plus difficile : un démarrage avec Google Drive comme racine
• Comme l’objectif était une architecture autonome, sans machine auxiliaire séparée, choix de FUSE, qui fonctionne en espace utilisateur comme un pilote de système de fichiers
• Les conditions essentielles consistent à placer le programme FUSE et la configuration réseau dans l’initramfs, à monter le système de fichiers racine distant, puis à poursuivre le démarrage normal

Où intervenir dans le processus de démarrage de Linux

• Le flux de démarrage de Linux se divise globalement en plusieurs étapes
  • Le firmware BIOS/UEFI lance le bootloader
  • Le bootloader charge le noyau
  • Le noyau décompresse en RAM initramfs, un système de fichiers temporaire, et utilise les outils qui monteront le vrai système de fichiers
  • Le noyau bascule vers le vrai système de fichiers et exécute le système init du nouveau système de fichiers
• En montant un système de fichiers FUSE à la troisième étape, on peut continuer le démarrage tout en utilisant un stockage distant comme racine

Preuve de concept S3 avec Dracut

• Dracut est utilisé pour générer un initramfs personnalisé
• Arch Linux est choisi comme distribution de base, car relativement légère et familière
• Le module Dracut inclut des binaires liés à FUSE, comme fusermount, fuseiso et mkisofs
• Une image EFI est créée avec dracut.sh puis exécutée dans QEMU ; après un avertissement indiquant l’absence d’argument root=, un shell de débogage s’ouvre
• Dans le shell de débogage, les tâches nécessaires au démarrage sont effectuées manuellement
  • Chargement des pilotes avec modprobe fuse et modprobe e1000
  • Configuration du réseau avec dhclient eth0 et des paramètres de routage
  • Montage d’un bucket S3 local sur /sysroot avec s3fs

Échec de switch_root et contournement avec chroot

• La racine Arch Linux était visible dans /sysroot, mais switch_root /sysroot /sbin/init échouait avec Input/output error
• pivot_root ne pouvait pas non plus être utilisé depuis le rootfs de l’initramfs et renvoyait Invalid argument
• D’après une réponse Stack Exchange consultée, sur le rootfs de l’initramfs, pivot_root et le démontage sont impossibles ; il faut donc monter la nouvelle racine par-dessus, faire un chroot, puis lancer init
• Si l’on exécute simplement chroot /sysroot /sbin/init depuis le shell, systemd ne démarre pas correctement car il n’est pas le PID 1
• Le démarrage depuis une racine S3 a réussi en modifiant le init.sh de Dracut pour y ajouter la configuration réseau, le montage s3fs, les montages bind de /sys, /dev et /proc, puis exécuter à la fin exec chroot /sysroot /sbin/init

Problème DNS révélé par la racine S3

• Après le démarrage, le résultat de mount confirme que / est monté avec le type s3fs
• Lors de l’exécution de pacman -Sy fastfetch, l’opération échoue car les hôtes des miroirs de paquets, comme geo.mirror.pkgbuild.com, ne peuvent pas être résolus
• Comme le système de fichiers racine se trouve sur S3, il était possible de monter cette racine depuis une autre machine et d’y entrer avec chroot pour installer des outils
• systemd-resolved ne se lançait pas à cause d’un problème de permissions lié à la connexion stdout du socket journal ; le DNS a été contourné en ajoutant nameserver 1.1.1.1 dans /etc/resolv.conf

Passage à Google Drive

• google-drive-ocamlfuse est utilisé comme implémentation FUSE pour Google Drive
• Après avoir créé des secrets OAuth2 dans un compte Google et activé l’API, le paquet AUR est installé dans une VM Arch Linux
• Une fois Google Drive monté, les fichiers Arch Linux sont copiés vers Drive via une longue opération rsync
• Avec une racine basée sur Google Drive, les différences de comportement du système de fichiers posent continuellement problème
  • Les liens symboliques pointant vers des liens symboliques ne fonctionnent pas, ce qui crée des problèmes sur des éléments liés à /usr/lib
  • Les liens physiques ne fonctionnent pas
  • Les liens symboliques relatifs ne fonctionnent pas
  • Les liens symboliques cassés ne sont pas autorisés
  • Les liens symboliques pointant hors de Google Drive ne fonctionnent pas
  • Les permissions et attributs ne fonctionnent pas
  • Les performances sont très lentes
• Pour conserver la contrainte de ne pas modifier le pilote FUSE ni le noyau, des liens symboliques manuels sont créés à partir des journaux d’échec de rsync

Modification de l’initramfs pour Google Drive

• L’initramfs inclut le fichier de jeton généré sur l’ordinateur portable, le binaire FUSE pour Google Drive et les certificats SSL
• Les fichiers liés à /.gdfuse/default/config, /.gdfuse/default/state, /etc/ssl et /etc/ca-certificates sont ajoutés à l’image Dracut
• Au démarrage avec une racine Google Drive, l’erreur chroot: /sbin/init: File not found apparaît
• Même si le fichier existe réellement, Linux peut renvoyer File not found lorsqu’il manque des bibliothèques de dépendance ou le chemin du linker dynamique
• À cause du problème des liens symboliques relatifs, le noyau se retrouvait à chercher à nouveau /sysroot/sysroot à l’intérieur de /sysroot ; le problème est résolu en créant /sysroot/sysroot, puis en montant /sysroot en bind à cet emplacement
• Même après cela, le démarrage reste très lent
  • La régénération du cache du linker dynamique prend environ 5 minutes
  • Chaque unité systemd prend environ 1 minute
  • Le démarrage se bloque à cause du timeout d’attente sur /dev/ttyS0
• Pour éviter les timeouts de connexion, JobTimeoutSec=infinity est défini dans /etc/systemd/system/dev-ttyS0.device, et LOGIN_TIMEOUT est remplacé par 0 dans /etc/login.defs
• Une fois le cache constitué, la lecture des fichiers devient moins lente qu’au début

Exécution sur un ordinateur portable sans stockage

• Tentative de démarrage sur matériel réel avec un ordinateur portable de réserve dépourvu de périphérique de stockage
• Quelques éléments de la configuration prévue pour QEMU sont modifiés pour correspondre au matériel
  • Utilisation du pilote r8169 pour le port Ethernet de l’ordinateur portable, au lieu du e1000 par défaut
  • Pas d’utilisation d’un affichage série
  • Modification de la configuration réseau pour l’adapter à la topologie du réseau domestique
• Powerline est utilisé au lieu d’un long câble Ethernet
• Un fichier EFI unifié est construit, placé dans le chemin de démarrage EFI d’une clé USB, puis démarré sur l’ordinateur portable
• Les directives modprobe pour le clavier intégré n’ayant pas été trouvées, hid_usb est chargé et le réseau est configuré avec un clavier externe
• Le résultat final est un « Cloud Native Computer » fonctionnant sans périphérique de stockage, avec une racine basée sur Google Drive

Variantes possibles et limites

• Le projet lui-même a un caractère largement ludique, mais la même méthode permet de démarrer Linux sur SSHFS
• Avec gitfs, il serait aussi possible de démarrer Linux depuis un dépôt Git et de suivre les modifications avec Git
• Les possibilités sont nombreuses, mais l’intérêt pratique reste limité
• Nix est envisagé comme prochain candidat d’expérimentation