Peux-tu poster la sortie de lsblk ?
Un petit retour en bon et du forme entre autre de mon service 
:
Nous vous prions de nous excuser pour les soucis rencontrés et prenons bonne note des éléments évoqués dans ce fil afin d’apporter et clarifier nos configurations.
En tant qu’hébergeur des choix technologiques doivent être faits afin d’uniformiser et répondre aux demandes les plus communément formulées par nos clients. La présence de LVM et cette topologie de partitionnement et de RAID vont justement en ce sens.Comme indiqué Debian 10 est techniquement disponible depuis une dizaine de jours mais pas encore présent à la commande, ce qui ne saurait tarder. Les équipes Support se basant sur la disponibilité commerciale elles n’ont, en effet, pas pu répondre à votre demande.
Suite à votre retour, une clarification a été apportée à nos équipes support concernant les périphériques d’installation de grub (en effet, il faut installer sur les disques physiques /dev/sda et /dev/sdb et non /dev/dm-0 comme cela vous a été indiqué)
Pour répondre à vos différentes interrogations :
/dev/dm-0 est en double
C’est normal puisque /dev/dm-0 = VolGroup00-system_root qui est le volume logique LVM répliqué par le RAID1 /dev/md1/dev/md0 ne fait que 1072 Mo
Il s’agit de la mise en RAID de la partition /boot (hors LVM). La taille d’1Go est un compromis mis en place +par défaut+ (mais ajustement via la demande d’un “partitionnement personnalisé”, j’y reviendrais).
Sous Debian, ça parait beaucoup mais sous d’autres distributions comme CentOS /boot, les 100Mo que nous mettions historiquement se retrouvaient vite remplis.Pour résumer, nous avons, par défaut et quelle que soit la distribution choisie en cas de raid logiciel : /dev/sda (GPT) partitionné comme tel :
- Hors LVM : 1 partition bios_grub de 2M (pour GrUB2)
- Hors LVM : 1 partition /boot de 1Go en ext2 (historiquement pas d’intérêt de journaliser /boot) -> si raid, membre de /dev/md0
- Hors LVM : 1 partition de swap de 1Go par défaut quant au choix de ne pas mettre de RAID il y a plusieurs écoles, beaucoup de nos clients préféraient bénéficier d’une swap par disque physique et craignaient une perte de rapidité d’écriture si swap en RAID.
- Partition LVM pour contenir VG+LVs (à minima “system_root” qui utilisera 100% de l’espace disponible +par défaut+) -> si raid, membre de /dev/md1
Dans le cas de multiples disques avec RAID : tables de partitions clonée de sda avec regen des UUIDs + installation de grub à la fin du processus
La question de fournir un LV “racine” de petite taille pour laisser libre court au client quant à la création d’autres volumes s’est posée mais nous avons de nombreux clients qui n’ont pas votre niveau technique et auraient été surpris de ne voir que “xGo” alors qu’ils en ont commandé “yG”, vous voyez l’idée.
Du coup de base on fournit ce que le client s’attend à avoir comme espace utile.
Via un ticket support (nous travaillons à intégrer cette possibilité au moment de la commande mais c’est complexe) il est tout à fait possible de demander le partitionnement et les systèmes de fichier (ext2/3/4, xfs, btrfs, fat, …) de votre choix.Et oui, je confirme, le processus de remise à zéro d’un serveur est automatique et peut-être initié par le client depuis son Extranet.
Enfin, concernant votre dernier retour, oui, les partitions de swap peuvent tout à fait être mises en raid par l’utilisateur final et la capacité de swap augmentée par l’usage de swapfiles par exemple.
Comme indiqué précédemment je vous rejoins sur le manque d’intérêt d’un unique LV à 100% côté LVM mais je vous invite à en consulter les raisons évoquées à r2mi.
Concernant la mention de “scsi” pour grub-pc/install_devices elle est tout à fait normale puisque le sous-système de gestion des disques GNU/Linux a tendance à tout uniformiser sous la notion d’scsi, par exemple sur un serveur Debian 9 avec un raid matériel :
# debconf-show grub-pc | grep 'install_devices:'
* grub-pc/install_devices: /dev/disk/by-id/scsi-36a4badb032fff2001b184e511aabac49
# parted -l | grep 'Model:'
Model: DELL PERC 6/i (scsi)
Ou encore une VM sous Debian 10 :
# debconf-show grub-pc | grep 'install_devices:'
* grub-pc/install_devices: /dev/disk/by-id/scsi-3600224809b4565fcbdbfa7164d7ceba4
# parted -l | grep 'Model:'
Model: Msft Virtual Disk (scsi)
L’important c’est surtout que le chemin correspond bien au disque attendu :
# file /dev/disk/by-id/scsi-3600224809b4565fcbdbfa7164d7ceba4
/dev/disk/by-id/scsi-3600224809b4565fcbdbfa7164d7ceba4: symbolic link to ../../sda -> soit /dev/sda
Pour le reste :
-
Vous êtes plusieurs a avoir signalé des labels induisant en erreur, entre autre la partition labellisée EFI, cette dernière résulte d’une uniformisation des systèmes pour les machines ne pouvant démarrer qu’en UEFI : ces dernières nécessitent la présence de cette partition qui a été créée de type “EF00” comme documenté ici par exemple :
https://wiki.archlinux.fr/GRUB#Tables_de_partition_GPT. -
Concernant la partition LVM c est un nom GPT qui est mis en place indépendamment de la présence du RAID, il ne remet pas en cause la présence des flags raid_autodetect et lvm sur la-dite partition.
-
Enfin, concernant l utilisation d une table de partition MS-DOS, pourquoi se limiter à un système désuet ne pouvant pas aller au delà de 2To et ayant une limitation sur le nombre de partitions primaires alors que GPT fait mieux et est tout aussi standardisé ?
1 J'aime
Merci Clochette pour ce post très instructif (il faut maintenant que je digère toutes ces informations).
Maintenant tout semble ok pour Grub, en tout cas on ne voit plus les disques SCSI mais uniquement les 2 disques ATA (Toshiba):
root@fatmike:/var/lib/tomcat9/webapps$debconf-show grub-pc * grub-pc/install_devices: /dev/disk/by-id/ata-TOSHIBA_DT01ACA100_971YDUVNS, /dev/disk/by-id/ata-TOSHIBA_DT01ACA100_27G7140FS * grub2/linux_cmdline_default: quiet grub-pc/postrm_purge_boot_grub: false grub-pc/disk_description: * grub-pc/install_devices_disks_changed: /dev/disk/by-id/ata-TOSHIBA_DT01ACA100_971YDUVNS, /dev/disk/by-id/ata-TOSHIBA_DT01ACA100_27G7140FS grub-pc/install_devices_failed: false * grub2/linux_cmdline: net.ifnames=0 biosdevname=0 grub-pc/install_devices_empty: false grub-pc/mixed_legacy_and_grub2: true grub-pc/partition_description: grub-pc/install_devices_failed_upgrade: true grub-pc/hidden_timeout: false grub2/device_map_regenerated: grub2/update_nvram: true grub2/kfreebsd_cmdline_default: quiet grub2/kfreebsd_cmdline: grub-pc/kopt_extracted: false grub-pc/chainload_from_menu.lst: true grub-pc/timeout: 5 grub2/force_efi_extra_removable: false
root@fatmike:/var/lib/tomcat9/webapps$lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 931,5G 0 disk ├─sda1 8:1 0 2M 0 part ├─sda2 8:2 0 1G 0 part │ └─md0 9:0 0 1023M 0 raid1 /boot ├─sda3 8:3 0 1G 0 part [SWAP] └─sda4 8:4 0 929,5G 0 part └─md1 9:1 0 929,4G 0 raid1 └─VolGroup00-system_root 253:0 0 929,4G 0 lvm / sdb 8:16 0 931,5G 0 disk ├─sdb1 8:17 0 2M 0 part ├─sdb2 8:18 0 1G 0 part │ └─md0 9:0 0 1023M 0 raid1 /boot ├─sdb3 8:19 0 1G 0 part [SWAP] └─sdb4 8:20 0 929,5G 0 part └─md1 9:1 0 929,4G 0 raid1 └─VolGroup00-system_root 253:0 0 929,4G 0 lvm /
Elle est chouette cette commande avec sa sortie qui résume parfaitement pour un novice !
Donc mis à part le fait que le partitionnement devrait être affiné (au moins pour séparer /home et /var ) pensez vous que je peux considérer que mon système est à priori sain et que je n’ai plus penser à une nouvelle installation ?
Et peut on résumer mes soucis à simplement une mauvaise installation initiale de Grub qui avait “mémorisé” des mauvais disques ?
Merci, Vincent.
Merci pour ces réponses argumentées.
Désolé mais je ne vois pas en quoi c’est normal qu’un périphérique quel qu’il soit listé deux fois. A ce niveau, le fait que ce soit un volume logique LVM dont le volume physique est un ensemble RAID logiciel devrait être transparent.
J’ai l’impression que c’est un bug du script de configuration du paquet grub-pc, par exemple qui se baserait sur une sortie mal filtrée de lsblk (où un ensemble RAID et ce qu’il contient est listé sous chacun de ses membres.
Alors pourquoi veulent-ils que le reste soit redondé par RAID ?
La redondance par RAID a pour but d’assurer de la disponibilité : si un disque tombe, le système peut continuer à tourner. Mais si le swap n’est pas en RAID, le système peut crasher.
Au mieux on peut relancer le système grâce à la redondance du reste plus rapidement que s’il fallait restaurer le système. Mais il faut quand même attendre le remplacement du disque défaillant donc c’est une disponibilité dégradée. Si ça suffit à ces utilisateurs, pourquoi pas, mais en ont-ils conscience ?
D’autre part je trouve que 1 ou 2 Go de swap pour une machine avec 8 Go de RAM, ça fait un peu gadget. Quant à l’idée d’utiliser un fichier de swap si ça ne suffit pas, j’ai déjà écrit ici et là ce que j’en pense : c’est de la bidouille sale car ça viole la séparation des couches du système de fichiers (d’ailleurs ça ne marche pas avec tous les types de systèmes de fichiers) donc c’est une mauvaise idée. A réserver à un besoin ponctuel pour dépanner.
Ça ne s’applique pas au nommage des liens symboliques créés dans /dev/disk/by-id/ ; les disques ATA et USB ont beau être gérés comme des disques SCSI à un certain niveau, ces noms commencent par “ata” “usb” respectivement. Seuls les vrais disques présentés par leur pilote comme des disques SCSI natifs (comme les disques virtuels SCSI émulés par certains hyperviseurs, ou ce contrôleur RAID matériel) ont “scsi”.
Oui, et ce n’était pas le cas dans le système installé automatiquement.
Question bête : où est la partition ou l’ensemble RAID /boot dans ce cas ?
Ce n’est pas moi qui est critiqué le choix de GPT, bien au contraire. Mais si je devais faire preuve d’esprit de contradiction, je pourrais rétorquer que ces disques ont une capacité inférieure à 2 To et que le partitionnement standard adopté ne compte que 4 partitions.
Cf. la partie de mon message précédent sur le swap, la redondance et la disponibilité.
Bonjour,
Merci pour vos réponses et explications.
C’est un bel effort de communication.
Vous vous êtes adressé à nous en détail mais je ne peux en faire autant.
J’ai eu beau lire et relire et même dormir dessus avant de recommencer ma lecture.
Je me range derrière l’avis argumenté de @PascalHambourg.
C’est plus facile et c’est pour moi un avis d’expert.
J’en conclus que le client peut vous demander une segmentation différente et personnalisée
des disques pour recommencer son installation si il le souhaite ?
Dans ces termes, votre offre me semble se situer en bonne place.
En ayant bien compris mon inexpérience du marché des serveurs dédiés.
Dans l’état actuel des choses, ce n’est pas forcément une mince affaire.
Il y a une réflexion à avoir et du travail d’administration.
Bon s’il n’y a “que” ça je pense que ça devrait aller car mes services n’ont pas besoin d’avoir une disponibilité parfaite, loin de là…
Ah je pensais que justement grâce à LVM il serait “facile” de pouvoir repartionner après coup…
1 J'aime
C’est facile quand il y a suffisamment d’espace libre dans le VG pour créer les nouveaux volumes, beaucoup moins quand tout l’espace est alloué dans un unique volume. Dans ce cas, il faut réduire le volume. En soi, réduire un volume est facile, tout comme réduire une partition. Mais avant il faut réduire le système de fichiers qu’il contient, et c’est là que réside la difficulté, variable selon son type et son utilisation. Par exemple ext4 supporte seulement la réduction à froid (démonté), Btrfs supporte la réduction à chaud, XFS ne supporte pas la réduction du tout. Si le système de fichiers est en ext4, il faut le démonter pour le réduire. Mais si c’est la racine, on ne peut pas le démonter. Il faut donc le faire depuis un autre système avec une autre racine (système de maintenance de l"hébergeur par exemple, ou système minimal à installer sur la partition /boot). Si c’est /home, qu’on peut démonter assez facilement, c’est plus simple.
1 J'aime
Une façon
Comme une autre
Je remarque que tu es satisfait du dédié et c’est une bonne chose 
Je ne m’inquiète pas du fait que tu mélanges la partie système et la partie applicative.
Je ne m’inquiète pas non plus pour ce petit hic dans la gestion du swap.
Comprend plutôt que je pense que cela ne va pas te créer de souci amha.
Il ne me semble pas encore que tu sois décidé et prêt pour procéder à ces manœuvres.
Elles pourraient rendre tes services indisponibles pour un temps ou plusieurs.
Alors que tu viens juste de les remettre en ligne.
Nous avons probablement le besoin de faire un break pour le moment.
Je ne suis peut-être pas moi-même encore prêt pour aider à te faire effectuer
ce relativement lourd travail d’administration.
Et cela commence par le plan de segmentation qu’il te reste à établir
plus précisément qu’un « /var et /home »
La deuxième façon - repartir de zéro avec une netinstall en mode expert -
est peut-être moins complexe. (Avantages LVM - littlejohn75)
C’est également à partir de zéro avec une netinstall en mode expert que
tu peux faire une installation avec un partitionnement statique.
Quand tu seras décidé pour un changement, il restera du monde ici pour t’aider.
Belle journée
Bonne soirée
LVM c’est bien !
Mais quand tu ne peux pas réduire à chaud : ce n’est pas le même topo 
j’avais pas vue ça passer 
ce dit en passant le problème rencontré n’a été remonté à mon service qu’une fois c’est que l’on doit pas être trop nul non plus …
Juger sur aussi peu d’information n’est pas terrible non plus et quelque soit l’hébergeur.
Sinon réponse officielle de mon service :
Merci à vous pour l’ensemble de vos avis constructifs sur notre gamme de serveurs dédiés GNU/Linux.
C’est avec beaucoup d’humilité que nous prenons note de vos remontées et aviserons sur les modifications éventuelles à apporter au regard de ces dernières.
Quelques ultimes éléments en réponse aux derniers message afin d’être exhaustif :
Concernant le retour de debconf nous avons, en effet, identifié une régression très récente (liée à “Buster”) dans notre script de remise à zéro et l’avons corrigé.
La commande “echo PURGE | debconf-communicate grub-pc” était utilisée pour remettre à zéro les données debconf du paquet grub-pc n’a pas été exécutée avec succès (c’est maintenant corrigé).
@PascalHambourg :
Au sujet du contenu “debconf” et “/dev/disks/by-id/scsi-*” il est probable que nous ayons fait erreur en effet. Merci de nous l’avoir signalé.
Concernant la sortie de lsblk ce que nous voulions dire est que même si elle ne correspond pas à toutes les logiques elle n’est pas erronée en soit. Dans tous les cas c’est un comportement du binaire indépendant de notre volonté.
Pour la swap, sans revenir sur les explications concernant sa taille, nous sommes en train d’évaluer la possibilité de la configurer un peu plus “dynamiquement”, à savoir : égale à la quantité de RAM dans la limite de 8Go.
Concernant sa mise en RAID nous étudions également la quantité de développement nécessaire pour le proposer et effectuerons ensuite un sondage pour avoir une vue actualisée sur la préférence des utilisateurs à ce sujet.
A vos yeux : RAID = haute disponibilité mais nous ne partageons pas ce point de vue (même s’il est tout à fait légitime et c’est la raison de notre réévaluation de cette problématique).
RAID = redondance/réplication des données (tout du moins en niveau 1) par sécurité et, pour la plupart de nos clients, la swap est une donnée volatile dont la perte n’est pas critique.
Ceux qui veulent de la haute-disponibilité opterons, à minima, pour une solution de RAID matériel incluant une batterie pour atteindre un niveau de performances et de redondance autrement supérieur.
Ce point de vue est sûrement influencé par l’aspect hébergement au travers duquel nous cherchons à proposer une gamme segmentée afin de répondre à tous les besoins.
Concernant votre question sur la partition /boot, nous ne l’avons pas compris puisque la partition /boot correspond au volume /dev/md1 composé de /dev/sda2 et /dev/sdb2 (hors LVM), la partition “bios_grub” est indépendante de cette dernière.
Enfin, et pour contredire votre esprit de contradiction (;)), concernant la table de partitions : Oui, le serveur dont il est question ici ne comporte pas de disque de plus de 2To ou plus de 4 partitions primaires mais ce n’est pas le cas de l’ensemble de notre parc.
Il serait idéal que chaque serveur soit configuré de manière absolument optimale par rapport à sa pile applicative et ces spécifications matérielles mais malheureusement cela rendrait ardues les tâches de support et d’automatisation postérieures à l’installation.
@Vinz :
Vous pouvez donc corriger définitivement votre souci via l’exécution de cette commande : “echo PURGE | debconf-communicate grub-pc”
@anon44391915 :
Tout à fait, Vinz peux demander une remise à zéro de son serveur à nos équipes support (directement en Debian 10 maintenant, je me suis assuré que l’ensemble des équipes étaient informées de la disponibilité de l’image).
Nous avons bien conscience qu’il serait idéal de proposer cette possibilité dès la commande mais son intégration est complexe étant donné la multiplicité des OS et configurations possibles.
Je suis d’accord avec toi. Sur le moment, il arrive d’exagérer dans ses propos ou ses écrits.
Ma remarque est légèrement tronquée.
Merci pour les bonnes nouvelles @Clochette
Au bas mot : c’est génial !
Oui final je suis quand même bien content car j’ai maintenant un serveur avec une Debian 10 toute fraîche et qui est bien plus rapide que mon ancien… et qui en plus me coûte moins cher !
Le seul truc qui me semble dommage c’est que je ne peux pas facilement repartionner car mon VG est déjà complètement occupé par un LV si j’ai bien compris.
Maintenant je compte faire un break comme le suggère r2mi parce que bon c’est pas mon métier et tout ça est censé être juste pour mon plaisir.
Ah mais je dois encore lancer cette commande alors que la sortie de
debconf-show grub-pc
a l’air ok (plus de disques SCSI) ?
Suite à ma remarque sur le fait que les partitions de l’ensemble RAID /boot étaient de type “système EFI”, vous avez répondu que ces partitions pouvaient servir de partition système EFI sur les machines amorçables uniquement en mode EFI. Fort bien. Mais dans ce cas, que devient la partition ou l’ensemble RAID /boot séparé(e) pour les systèmes comme Debian qui ne montent pas la partition système EFI sur /boot mais sur /boot/efi ?
Tu ne peux pas le faire si le type du système de fichiers monté comme racine ne supporte pas la réduction à chaud (ext4). Tu peux le faire si le type supporte la réduction à chaud (Btrfs) ou si le serveur peut démarrer dans un mode de maintenance qui ne monte pas le système de fichiers à réduire comme racine.
Non, surtout pas.
Nullement si grub-pc est correct.
Oui et non c’est une histoire d’une heure pour refaire une partition à côté à l’aide d’un netboot en prenant son temps.
Le netboot en question est un sysrescuecd et son système de fichier est en ext4.