<!-- L'article a été rédigé le 2018-10-22 mais Jekyll n'aime pas cette date, allez savoir -->
# Contexte
J'aime beaucoup tester des trucs sur mon serveur, notamment avec le système de fichiers BTRFS.
Sauf que j'ai fait l'erreur de [compresser `/boot` avec une méthode que Grub ne supporte pas](https://askubuntu.com/q/1056396/342879), et après un [reboot malencontreux](https://oc.todon.fr/@GeoffreyFrogeye/100938592425275062) mon système ne peux plus booter.
Qu'à cela ne tienne, je me pointe vers mon panel OVH et démarre en rescue avec une image d'Arch.
Sauf que le mode rescue utilise la clef SSH que j'ai utilisé pour créer le serveur et que j'ai détruite depuis le temps, et [impossible de la changer](https://twitter.com/GeoffreyFrogeye/status/1054315898566250496).
Ma seule option est donc de démarrer sur l'image de rescue « Made in OVH », dont le noyau n'est pas suffisament récent pour monter ma partition BTRFS (à jouer avec le feu...).
Plutôt que de recompiler un noyaux linux avec les bonnes options, je préfère plutôt monter le disque à distance depuis mon laptop et réparer mes dégâts d'ici (ça implique une bonne connexion).
# Réalisation
> **Avertissement :** Je vous donne ma méthode quick'n'dirty à défaut d'avoir trouvé quelque chose qui expliquait ce que je voulais faire simplement, mais je vous renvoie à la documentation si vous souhaitez utiliser ça de manière propre.
> Je ne sais d'ailleurs aucunement si il y a une méthode de correction d'erreur, donc à vos risques et périls (et évitez le Wi-Fi).
> Personnellement j'ai joué la carte du «Qui va trouver et exploiter la vulnérabilité en 10 minutes sérieux? » mais je vous renvoie au manuel de `nbd-server` pour ajouter au moins un filtrage IP.
Vous devriez obtenir un message vous informant que vous avez créé le périphérique `/dev/nbd0`, que vous pouvez désormais monter comme si vous étiez sur la machine distante.
