web-dev-qa-db-fra.com

installation de serveur avec raid1 intentionnellement incomplet

Je suis en train de mettre à jour un serveur 16.04 actuel vers 18.04. Les partitions / et /boot sont mises en miroir (simple mdadmname__). Pour éviter le risque d'une installation défaillante, j'ai cassé (--fail puis --remove) le miroir et j'essaie d'installer 18.04.1 sur les partitions que j'ai supprimées du miroir.

Connexes: installation du serveur Ubuntu sur une partition existante , Ubuntu interdit spécifiquement la possibilité d’utiliser des partitions préexistantes (utilisées depuis des années), ne sachant pas pourquoi cette fonctionnalité a été supprimée de manière intentionnelle, mais elle semble pouvoir le faire plus difficile d'effectuer des mises à niveau.

Pour contourner ce problème, j'ai supprimé les partitions existantes de / et /boot, en espérant utiliser le "logiciel de création de RAID (md)" de l'installateur. Toutefois, le lecteur souhaité (c’est le seul lecteur pour lequel un espace non partitionné est disponible) n’est pas répertorié dans la fenêtre contextuelle "RAID", et une étiquette rouge en bas indique qu’il nécessite au moins 2 périphériques actifs.

Peut-être qu'il me manque quelque chose, mais il est parfaitement légal de créer un tableau miroir raid1 avec une seule partition et missingname__, suggérant un espace réservé pour un futur périphérique.

mdadm --create /dev/md/0 --level=1 --raid-devices=2 /dev/sdh1 missing
mdadm --create /dev/md/2 --level=1 --raid-devices=2 /dev/sdh3 missing

Mon intention est d’élever cette nouvelle version 18.04 et, une fois que j’ai réussi à la mettre à jour et que je me suis prouvé que tout irait bien, ce n’est qu’alors que j’ajouterai les partitions raid1 de l’autre lecteur et reconstruirai les miroirs. l'installation du 16.04).

Peut-être que la seule façon de faire fonctionner ceci ici est de faire une installation de Vanilla (aucune copie en miroir), puis de jongler avec les partitions où je déplace des fichiers, configurer une partition en miroir, mettre à jour grub, déplacer à nouveau les fichiers, configurer deuxième partition en miroir, et mettre à jour grub à nouveau. Semble inutile.

partitioningsystem-installationraidmdadm
3
r2evans

Ok, la recherche fournit plus de contexte et d’options.

  1. https://wiki.ubuntu.com/BionicBeaver/ReleaseNotes#Ubuntu_Server états (l'emphase mienne):

    NB: Si vous avez besoin d'un cryptage sur plusieurs trajets, sur disque complet ou pour pouvoir réutiliser des partitions existantes , vous souhaiterez continuer à utiliser le programme d'installation alternatif. qui peut être téléchargé à partir de http://cdimage.ubuntu.com/releases/18.04/release/ À compter du 18.04.1, le programme d'installation du serveur Subiquity prend désormais en charge LVM, RAID, les réseaux virtuels et les liaisons.

  2. La question connexe liée mentionnée bug 1751656 est prétendument une copie de la subiquité bug 1680245 . Cette deuxième page de bogue fait référence à un autre installateur Debian pour pouvoir utiliser les partitions existantes (non testées).

  3. Une autre option de mon premier plan (effectuer une nouvelle installation sur le second lecteur) consiste bien entendu à tenter une mise à niveau sur place à l'aide de Sudo do-release-upgrade. Si je n'avais pas neutralisé les partitions en miroir lors de mon dépannage/première tentative, cela serait beaucoup plus facile pour moi d'essayer ... Ce n'est pas un mauvais moment pour "pratiquer" la guérison/reconstruction de ces deux partitions.

  4. La dernière option que je vais noter est ce que j’ai commenté ci-dessus et probablement ce que je finirai par faire si la mise à niveau échoue du tout: décompressez tout le lecteur qui contient les miroirs pour / et /boot, créez une partition minimale, redémarrez le 16.04 plus ancien, puis mélangez de nouveau en créant de nouvelles partitions raid1 pour que 18.04 soit installé sur le schéma de partition souhaité. (Cela pourrait également être fait avec encore un autre lecteur qui est par ailleurs inutilisé/disponible.)

Ma précédente plainte concernant "cette fonctionnalité a été volontairement supprimée" était prématurée, bien sûr: elle n'a pas été supprimée de l'installateur secondaire, elle n'a tout simplement pas été implémentée dans le nouvel installateur, "subiquité". Je soutiens toujours (et beaucoup sur les pages de bogues le font aussi) qu'il s'agit d'un problème important car on pourrait en déduire que l'effacement des données est le seul moyen d'aller de l'avant, mais ce n'est pas aussi efficace que je le croyais à l'origine. .

Merci pour votre temps.

3
r2evans