URL: https://linuxfr.org/users/steph1978/journaux/migration-coreos-vers-debian-in-situ Title: Migration CoreOS vers Debian in situ Authors: steph1978 Date: 2026年02月09日T18:36:51+01:00 License: CC By-SA Tags: devops, migration, debian et linux Score: 28 Ce journal raconte comment j'ai migré une machine depuis un système CoreOS4 vers système Debian 13 Trixie sans réinstallation et en conservant les données. # contexte Je loue depuis quelques années une petite machine dans un centre de données OVH. J'avais opté à l'époque pour le système d'exploitation [CoreOS](https://en.wikipedia.org/wiki/Container_Linux) car il présentait plusieurs avantages : - image proposée par OVH pour initialiser le système - système minimaliste : noyau Linux + Docker/containerd - système orienté container (docker) ce qui correspond à la façon dont je gère mes services - système à double partitions système permettant la mise en jour en arrière-plan et le rollback Pour expliciter ce dernier point : Il y a deux partitions système, de 1GB chacune. Chaque partition stocke l'image noyau à démarrer et le dossier `/usr` (`/bin` pointant sur `/usr/bin` et `/lib` sur `/usr/lib`). Ces partitions sont lecture seule. Le système démarre sur l'une des partition, dite active. Quand une mise à jour système (eg: nouvelle version du noyau) est disponible, la mise à jour est faite sur la partition inactive (ie, celle qui n'a pas servie au boot). Et au reboot, le système démarre sur cette partition mise à jour. Si tout se passe bien, on repart pour un cycle (le rôle des partitions s'étant inversé) sinon, le système effectue un retour arrière sur la partition qui n'a pas la mise à jour défaillante. Seulement depuis *quelque* temps, les mises à jour ne se font plus. Je suis coincé sur un vieux noyau 4x et sur un vieux docker. Ça craint. Le projet n'est pourtant pas mort puisqu'une release a été faite début février. Mais il y a eu une [rupture](https://docs.fedoraproject.org/en-US/fedora-coreos/migrate-cl/) des mise à jour quand CoreOS Inc a été racheté par RedHat et je n'ai trouvé aucune documentation pour faire la migration. Mon besoin est donc de migrer sur un OS à jour. Je pourrais louer une autre machine, faire une installation propre et migrer les données. Seulement la machine que j'ai actuellement est 1/ vraiment pas chère, il est très difficile d'en trouver une à ce prix, 2/ possède un disque de 2TB quasi plein alors qu'elle correspond à une offre 1TB (erreur de la banque en ma faveur). Je veux donc faire une migration in situ et sans abîmer les données. Je décris la procédure que j'ai suivie à titre pédagogique. N'ayant fait l'opération qu'une fois et par essai erreurs, je ne peux pas certifier que toutes les étapes sont nécessaires, exactes, exhaustives, dans l'ordre, les plus optimales. Globalement, la procédure repose sur `deboostrap` et `chroot`. # procédure détaillée ## rescue mode Comme tout bon hébergeur, OVH fourni un mode "rescue" qui permet de démarrer la machine sur le réseau avec un accès root ssh. Les disques sont alors visibles, mais non montés. Le système rescue de OVH est une Debian 12. ## montage des partitions * partitions de l'ancien système : ``` Device Start End Sectors Size Type /dev/sda1 4096 266239 262144 128M EFI System <= vfat, mouted as /boot /dev/sda2 266240 270335 4096 2M BIOS boot /dev/sda3 270336 2367487 2097152 1G unknown <= ext4, mouted as /usr overlay alternatively /dev/sda4 2367488 4464639 2097152 1G unknown <= ext4, mouted as /usr overlay alternatively /dev/sda6 4464640 4726783 262144 128M Linux filesystem /dev/sda7 4726784 4857855 131072 64M unknown /dev/sda9 4857856 3907029134 3902171279 1.8T unknown <= ext4, mouted as / ``` sda1 va rester notre `/boot` EFI, sda9 va rester notre `/`, sda2 sda3 sda4 sda6 et sda7 ne nous servirons plus. ```bash alias ll='ls -al' # required by my muscle memory mount /dev/sda9 /mnt mount /dev/sda1 /mnt/boot mount --bind /dev /mnt/dev mount --bind /dev/pts /mnt/dev/pts mount --bind /proc /mnt/proc mount --bind /sys /mnt/sys mount --bind /run /mnt/run ``` ## debootstrap et chroot ```bash apt-get install debootstrap #debootstrap trixie /mnt http://deb.debian.org/debian # takes several minutes and fails # because of : E: Tried to extract package, but file already exists. Exit... debootstrap trixie /altroot http://deb.debian.org/debian # takes several minutes tar c -C /altroot . | tar x -C /mnt/ chroot /mnt ``` À partir de là, nous ne sommes plus sur le système rescue en RAM, mais dans le futur système de la machine, sur son disque dur. ## locales et packages On installe les paquets logiciels supplémentaires que l'on veut, on pourra toujours en installer plus tard. Par contre `locales` est nécessaire pour ... fixer la locale et éviter plein de warnings. ```bash echo "en_US.UTF-8 UTF-8"> /etc/locale.gen apt-get update apt-get install -y \ locales \ zip sudo ssh net-tools bash-completion rsync \ screen mosh htop iotop file ``` ## serveur ssh et user d'admin ```bash apt-get install openssh-server sed -i.bak /etc/ssh/sshd_config << EEE 92c X11Forwarding no . 33c PermitRootLogin no . 14c Port 26549 . EEE adduser --disabled-password --shell /bin/bash admin usermod -aG sudo admin su - admin echo 'ecdsa-sha2-nistp521 AAAA.....== user@host'>> ~/.ssh/authorized_keys exit ``` ## noyau et grub ```bash apt install linux-image-amd64 firmware-linux-free grub-pc network-manager update-grub ## UNSURE if necessary, should not hurt ``` ## fstab ```bash cat << EEE> /etc/fstab # UUID=0759a5ae-05da-11f1-8250-8f4b18f15fdb / ext4 defaults 0 1 UUID=9876-7FAB /boot vfat umask=0077 0 0 EEE ``` ## réseau ```bash echo lamachine> /etc/hostname echo '127.0.1.1 lamachine.ip-1-23-45.eu lamachine'>> /etc/hosts systemctl enable systemd-networkd ``` ## profit ! Configurer le boot disque chez l'hébergeur puis : ```bash reboot ``` À partir de là, j'ai une machine sous Debian Trixie accessible en SSH avec mes clés. Je n'aurais pas forcément parié dessus au départ. J'ai ensuite installé docker tel que [recommandé par l'éditeur](https://docs.docker.com/engine/install/debian/#install-using-the-repository). Et j'ai relancé les services un par un à coup de `docker compose up -d` qui ont retrouvé leurs données stockées dans les volumes. Je n'aurais pas forcément parié dessus non plus. Back to business. # conclusion * on n'est jamais à l'abri d'une bonne surprise * sysadmin c'est quand même plus facile que neurochirurgien * ne pas rester avec un vieux système * accepter le risque de perdre une machine, les sauvegardes sont là pour ça * si tu installes autre chose que 💕Debian💕 sur une machine, tu fais sûrement une connerie

AltStyle によって変換されたページ (->オリジナル) /