La réponse courte est non.
La réponse la plus longue est que ce serait très très fascinant Vous pouvez essayer de copier tout ce qui se trouve sur un disque RAM tmpfs, de basculer / sur ce disque, puis de démonter le système de fichiers du disque dur et de fonctionner entièrement à partir de la RAM pendant que vous réparez le système de fichiers du disque.
Je ne suis pas le premier à avoir pensé à ça, j'ai trouvé ce fil mais aucune information ne permet de savoir si le système a réellement fonctionné. Puisque le but était d'effacer le disque, ils n'ont pas pris la peine de le démonter.
Pour ce faire, créez un répertoire et mount -t tmpfs none /some/directory Ensuite, commencez à le remplir avec une copie des bits importants de votre système (sshd, mount,umount, outils xfs, un Shell, et toutes les bibliothèques nécessaires pour l'exécuter, probablement tout le /etc pour être sûr, et enfin init... la création de chroot jail Shell aiderait ici, tout comme avoir environ 4 Go de RAM. Montez une copie de proc dans celui-ci et si vous utilisez devfs, montez également une copie de devfs. En utilisant la copie de /etc/ssh/sshd_config, configurez sshd pour qu'il démarre sur un port différent. Faites un chroot sur votre ramdisk et assurez-vous que tout fonctionne et qu'il n'y a pas de bibliothèques manquantes, puis lancez sshd dans le ramdisk (sur le port alternatif) pour qu'il y soit chrooté. Vérifiez que vous pouvez vous y connecter (cela peut nécessiter de copier votre répertoire /home à cet endroit également) (et d'ouvrir le port sur tout pare-feu que vous pourriez avoir).
Maintenant, la magie commence : au lieu de chrooter vers ce tmpfs, vous devez trouver un utilitaire appelé pivot_root . Son seul but dans la vie est d'appeler pivot_root() . C'est dans util-linux sur Debian. Le but de pivot_root() est essentiellement de chrooter tous les processus en même temps . Utilisé à l'origine pour déplacer / d'une image ramdisk initrd vers le lecteur réel, si cela fonctionne, vous allez déplacer / du lecteur réel vers une image ramdisk. Donc, disons que vous avez fait mkdir /mnt/tmpfs; mount -t tmpfs none /mnt/tmpfs Après avoir copié tout ce dont vous avez besoin à l'intérieur, l'étape suivante consiste à mkdir /mnt/tmpfs/oldroot; pivot_root /mnt/tmpfs /oldroot (Si vous avez manqué d'espace pour copier des choses, démontez /mnt/tmpfs et montez-le à nouveau, cette fois avec -o size=... puisque le défaut est de n'autoriser que la moitié de votre mémoire).
La dernière étape consiste à démonter /oldroot. Vous devrez démonter /oldroot/sysfs /oldroot/proc et ainsi de suite (vérifiez /proc/mounts). Si vous obtenez toujours le message "filesystem is busy", vous pouvez essayer de le forcer, ou au moins de retrouver tout ce qui a des fichiers ouverts en regardant dans le fichier ls -l /proc/*/cwd /proc/*/fd/ | grep /oldroot/ et en tuant tout ce qui s'y réfère encore (cela inclut probablement le serveur ssh qui n'était pas chrooté. Assurez-vous d'être connecté à ce sshd alternatif avant de commencer à tuer les choses). Évidemment, ne tuez pas le processus 1 (init). Si vous ne pouvez pas forcer umount avec init en cours d'exécution, vous devrez utiliser chroot /oldroot /sbin/telinit u2 ( 2=niveau d'exécution sur lequel vous êtes actuellement ou init va probablement tout tuer et ensuite vous redémarrez et recommencez. ) pour que init fasse une "mise à jour" en exécutant le "nouvel" init que vous avez sur le disque RAM. Vous devrez le chrooter vers /oldroot afin qu'il utilise /oldroot/dev/initctl (le /dev/initctl du ramdisk n'est pas le même) (notez que telinit utilisera [/oldroot]/dev/initctl pour parler au processus init existant qui a été pivot_rooté vers le ramdisk, donc l'init qu'il lancera sera sur le ramdisk, pas /oldroot).
Je ne suis pas prêt d'essayer ça sur un serveur de production ici. Je vais peut-être l'essayer à la maison ce week-end.
