RAID 1 (mdam) qui disparait après le boot Debian 10 Buster (résolu)

mum1989 · 28-06-2019 20:22:40

Bonjour,
j'ai fraîchement installé une nouvelle config sous Debian Buster, il sort dans quelque jours donc j'ai en profité,
de plus j'ai du matos récent et neuf.
ASROCK B450 GAMING-ITX/AC + Athlon 200GE(Ryzen) + 8Go de ram DDR4
2 x 4 To 2.5" Seagate (RAID 1) + SSD 120Go pour l'os debian.

première déception, le RAID matériel de la carte mère n'est même pas reconnu nativement par debian 10 ...

Du coup après installation je me suis rabattu sur le RAID logiciel, avec MDADM .
j'ai créé 3 fois un RAID 1 en suivant cette procédure :
https://www.digitalocean.com/community/ … id-1-array

mais à chaque fois, au reboot, le RAID disparaît, je ne vois pas ce que j'ai loupé à moins qu'ils s'agisse d'un bug ?

$  cat /proc/mdstat

Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]

unused devices: <none>

$ cat /etc/fstab

# /etc/fstab: static file system information.

#

# Use 'blkid' to print the universally unique identifier for a

# device; this may be used with UUID= as a more robust way to name devices

# that works even if disks are added and removed. See fstab(5).

#

# <file system> <mount point>   <type>  <options>       <dump>  <pass>

/dev/mapper/vgcent-vlracine /               ext4    errors=remount-ro 0       1

# /boot/efi was on /dev/sda1 during installation

UUID=B2C1-23B2  /boot/efi       vfat    umask=0077      0       1

/dev/mapper/vgcent-vldata /home           ext4    defaults        0       2

/dev/mapper/vgcent-vlswap none            swap    sw              0       0

/dev/md0 /mnt/data ext4 defaults,nofail,discard,noatime,nodiratime 0 0

$ cat /etc/mdadm/mdadm.conf

# mdadm.conf

#

# !NB! Run update-initramfs -u after updating this file.

# !NB! This will ensure that initramfs has an uptodate copy.

#

# Please refer to mdadm.conf(5) for information about this file.

#

# by default (built-in), scan all partitions (/proc/partitions) and all

# containers for MD superblocks. alternatively, specify devices to scan, using

# wildcards if desired.

#DEVICE partitions containers

# automatically tag new arrays as belonging to the local system

HOMEHOST <system>

# instruct the monitoring daemon where to send mail alerts

MAILADDR root

# definitions of existing MD arrays

# This configuration was auto-generated on Sun, 23 Jun 2019 18:19:36 +0200 by mkconf

ARRAY /dev/md0 metadata=1.2 name=miniryzen:0 UUID=c6a996c1:94f8d74c:7d72512d:9a173f41

bloc à supprimer si la commande n’affiche rien

Dernière modification par mum1989 (30-06-2019 08:44:48)

raleur · 28-06-2019 21:24:50

mum1989 a écrit :

le RAID matériel de la carte mère n'est même pas reconnu nativement par debian 10

Si c'est une carte mère de "gaming" comme le suggère sa dénomination, elle n'a probablement pas de vrai RAID matériel mais un "fake RAID" qui est en fait un RAID logiciel géré par le BIOS. Pour que l'installateur Debian puisse l'utiliser, il faut passer le paramètre "dmraid=true", cf. https://wiki.debian.org/DebianInstaller/SataRaid. Mais sauf impératif il vaut mieux utiliser le RAID logiciel de Linux que ce fake RAID.

Tu as bien désactivé le RAID dans le BIOS ?
Qu'affichent ces commandes ?

blkid

fdisk -l

mdadm --examine --scan --verbose

Dernière modification par raleur (28-06-2019 21:26:10)

mum1989 · 29-06-2019 09:40:45

# /usr/sbin/blkid

/dev/sdd1: LABEL="data" UUID="5c3cd36c-b4a4-4843-8901-003c06dab012" TYPE="ext4" PARTUUID="638da8ac-b385-422b-b9f1-5c80b1912056"

/dev/sdb: PTUUID="7b16bd2f-861c-49d1-b159-13743d406fe1" PTTYPE="gpt"

/dev/sdc: PTUUID="2861f2af-4889-4bc4-b600-f5ea8bc9ff73" PTTYPE="gpt"

/dev/sda1: UUID="B2C1-23B2" TYPE="vfat" PARTUUID="02e0ebbf-e89b-4bf2-99c9-73e30c14e53b"

/dev/sda2: UUID="m3gZkT-spjr-e8g3-3AeX-o21k-mJb9-zAcZ1D" TYPE="LVM2_member" PARTUUID="bb89f513-b808-485c-a709-2b0d9c9a74b0"

/dev/mapper/vgcent-vlracine: UUID="b536c1f7-b7a3-45c6-85e5-a2f5f633f9c9" TYPE="ext4"

/dev/mapper/vgcent-vlswap: UUID="3d8eb050-ab4f-4352-9d1c-c43ce3ba63ae" TYPE="swap"

/dev/mapper/vgcent-vldata: UUID="ce97192d-3c54-4245-bdb6-500bd5cebbcf" TYPE="ext4"

# /usr/sbin/fdisk -l

Disque /dev/sdd : 1,8 TiB, 2000398934016 octets, 3907029168 secteurs

Modèle de disque : ST2000LM003 HN-M

Unités : secteur de 1 × 512 = 512 octets

Taille de secteur (logique / physique) : 512 octets / 4096 octets

taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets

Type d'étiquette de disque : gpt

Identifiant de disque : F2DD37E7-F3FC-430E-956E-11A41BB2FE42

Périphérique Début        Fin   Secteurs Taille Type

/dev/sdd1     2048 3907028991 3907026944   1,8T Système de fichiers Linux

Disque /dev/sdb : 3,7 TiB, 4000787030016 octets, 7814037168 secteurs

Modèle de disque : ST4000LM024-2AN1

Unités : secteur de 1 × 512 = 512 octets

Taille de secteur (logique / physique) : 512 octets / 4096 octets

taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets

Type d'étiquette de disque : gpt

Identifiant de disque : 7B16BD2F-861C-49D1-B159-13743D406FE1

Disque /dev/sdc : 3,7 TiB, 4000787030016 octets, 7814037168 secteurs

Modèle de disque : ST4000LM024-2AN1

Unités : secteur de 1 × 512 = 512 octets

Taille de secteur (logique / physique) : 512 octets / 4096 octets

taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets

Type d'étiquette de disque : gpt

Identifiant de disque : 2861F2AF-4889-4BC4-B600-F5EA8BC9FF73

Disque /dev/sda : 111,8 GiB, 120034123776 octets, 234441648 secteurs

Modèle de disque : PNY CS900 120GB

Unités : secteur de 1 × 512 = 512 octets

Taille de secteur (logique / physique) : 512 octets / 512 octets

taille d'E/S (minimale / optimale) : 512 octets / 512 octets

Type d'étiquette de disque : gpt

Identifiant de disque : FB63EA84-AD26-4BCA-9947-F86ABACABF69

Périphérique   Début       Fin  Secteurs Taille Type

/dev/sda1       2048   1953791   1951744   953M Système EFI

/dev/sda2    1953792 234440703 232486912 110,9G LVM Linux

Disque /dev/mapper/vgcent-vlracine : 14 GiB, 15028191232 octets, 29351936 secteurs

Unités : secteur de 1 × 512 = 512 octets

Taille de secteur (logique / physique) : 512 octets / 512 octets

taille d'E/S (minimale / optimale) : 512 octets / 512 octets

Disque /dev/mapper/vgcent-vlswap : 3,7 GiB, 3997171712 octets, 7806976 secteurs

Unités : secteur de 1 × 512 = 512 octets

Taille de secteur (logique / physique) : 512 octets / 512 octets

taille d'E/S (minimale / optimale) : 512 octets / 512 octets

Disque /dev/mapper/vgcent-vldata : 93,1 GiB, 100004790272 octets, 195321856 secteurs

Unités : secteur de 1 × 512 = 512 octets

Taille de secteur (logique / physique) : 512 octets / 512 octets

taille d'E/S (minimale / optimale) : 512 octets / 512 octets

et la dernière commande renvoie rien

mdadm --examine --scan --verbose

 

J'ai bien revérifié, le contrôleur sata est bien en mode AHCI et non RAID, (j'avais aussi supprimé tout le RAID AMD).

Edit :
pour info j'ai aussi la dernière version du BIOS.

Dernière modification par mum1989 (29-06-2019 09:49:46)

raleur · 29-06-2019 10:05:21

Je suppose que les disques en RAID sont /dev/sdb et /dev/sdc ?
Par curiosité, on peut voir la sortie de

mdadm --examine /dev/sd[bc]

wipefs /dev/sdb

wipefs /dev/sdc

Mon avis :

1) N'en déplaise à l'auteur du tutoriel que tu as suivi, utiliser un disque entier non partitionné comme membre de RAID logiciel est une mauvaise idée.
2) C'est encore plus une mauvaise idée si le disque a une table de partition qui risque d'interférer avec le superbloc RAID.

Tu as deux options :

a) Supprimer la table de partition sur les deux disques RAID.
b) Créer une partition de type RAID sur chaque disque et utiliser ces partitions /dev/sdb1 et /dev/sdc1 comme membres de l'ensemble RAID au lieu des disques entiers. C'est cette option que je recommande.

mum1989 · 29-06-2019 11:26:57

mdadm --examine /dev/sdb

/dev/sdb:

   MBR Magic : aa55

Partition[0] :   4294967295 sectors at            1 (type ee)

mdadm --examine /dev/sdc

/dev/sdc:

   MBR Magic : aa55

Partition[0] :   4294967295 sectors at            1 (type ee)

wipefs /dev/sdb

DEVICE OFFSET        TYPE UUID LABEL

sdb    0x200         gpt

sdb    0x3a3817d5e00 gpt

sdb    0x1fe         PMBR

wipefs /dev/sdc

DEVICE OFFSET        TYPE UUID LABEL

sdc    0x200         gpt

sdc    0x3a3817d5e00 gpt

sdc    0x1fe         PMBR

ah ... d'accord.
je vais tenter la b)
donc.
les manips à faire
formater en "type RAID" par exemple avec fdisk,
et créer des partitions, puis remonter le raid ?
Merci.

Dernière modification par mum1989 (29-06-2019 11:28:05)

raleur · 29-06-2019 11:37:10

Aucune des deux commandes ci-dessus ne détecte les superblocs RAID, seulement les MBR et tables de partition.

On ne formate pas avec fdisk, on partitionne.

Remarque : /mnt n'est pas approprié pour les montages permanents.

Dernière modification par raleur (29-06-2019 11:43:04)

mum1989 · 29-06-2019 11:56:42

je le met dans /media/ par exemple ?

c'est quoi la recommandation ?

Merci

raleur · 29-06-2019 12:26:58

Non plus. /media est normalement réservé au montage des supports amovibles.

La recommandation est de faire comme d'habitude : on monte un système de fichiers là où son contenu est censé se trouver. Donc ça dépend du contenu. Pour les emplacements standard, consulter https://fr.wikipedia.org/wiki/Filesyste … y_Standard et

man hier

Par exemple ton volume logique /dev/mapper/vgcent-vldata est monté sur /home parce qu'il contient ce qu'on est censé trouver dans /home, indépendamment du fait que ce soit un volume logique LVM, une partition normale ou un ensemble RAID...

Tu peux aussi te demander s'il vaut mieux utiliser l'ensemble RAID comme un unique système de fichiers de 4 To ou bien le diviser en plusieurs volumes pour des usages différents.

PS : Je vois que tu as alloué tout l'espace de ton groupe de volume LVM sur le SSD. C'est la mauvaise façon d'utiliser LVM. Si un jour le volume racine est à l'étroit, ça va être plus compliqué de l'agrandir que si tu avais laissé de l'espace libre dans le groupe. Avais-tu besoin d'un volume de 100 Go pour /home immédiatement ?

Dernière modification par raleur (29-06-2019 13:08:40)

mum1989 · 29-06-2019 14:45:36

mais j'ai déjà le /home utilisé par l'SSD

mais je pourrais créer le raid et le monter sur par exemple /home/red ?

j'y mettrais des fichiers en partages SMB sur ce HDD de 4to principalement, un peu de musiques, et voila.

effectivement ce n'était pas être pas le meilleur choix, je n'ai pas trop de visibilité,
mais je mettrai mes dockers sur la partition de 100go, et 1 à 4 VM.
non je n'avais pas besoin des 100go.

raleur · 29-06-2019 15:09:14

mum1989 a écrit :

mais j'ai déjà le /home utilisé par l'SSD

C'était un exemple pour illustrer le principe.

mum1989 a écrit :

mais je pourrais créer le raid et le monter sur par exemple /home/red ?

Oui, d'autant plus si ce sont des données utilisateur. J'émets néanmoins une réserve sur le choix du nom "red" dont je ne vois pas en quoi il informe sur le contenu comme il le devrait.

mum1989 a écrit :

j'y mettrais des fichiers en partages SMB

S'il s'agit des données d'un service comme un partage réseau ou un site web, alors d'après le FHS l'emplacement approprié est /srv.

Dernière modification par raleur (29-06-2019 15:14:07)

mum1989 · 29-06-2019 15:21:54

red=raid ^^'

ok

raleur · 29-06-2019 15:39:24

Pour nommer le point de montage, peu importe que ce soit du RAID. L'important, c'est le contenu.

mum1989 · 30-06-2019 08:35:02

Bonjour,
cette fois ci ça a l'air bon après 2 reboot, le Raid1 est toujours présent.
Merci, je vais pouvoir le mettre en résolu.

Je pense que je n'avais pas du attendre la fin de la construction du raid à un moment.

raleur · 30-06-2019 09:31:43

Non, il n'est pas nécessaire d'attendre la fin de la construction du RAID. La construction du RAID peut être interrompue et reprendre au redémarrage.

mum1989 · 30-06-2019 09:34:39

ah bon ok
donc peut être c'est le fait d'avoir mis une partition et de l'avoir taggué en RAID.

Merci beaucoup en tout cas.

raleur · 30-06-2019 09:36:56

C'est surtout le fait d'avoir utilisé une partition sur un disque ayant une table de partition. Le type RAID est purement informatif, ça permet de voir au premier coup d'oeil qu'il s'agit d'une partition RAID mais mdadm ne se base pas dessus.

mum1989 · 30-06-2019 09:38:08

d'accord, ok

Debian-facile

#1 28-06-2019 20:22:40

RAID 1 (mdam) qui disparait après le boot Debian 10 Buster (résolu)

#2 28-06-2019 21:24:50

Re : RAID 1 (mdam) qui disparait après le boot Debian 10 Buster (résolu)

#3 29-06-2019 09:40:45

Re : RAID 1 (mdam) qui disparait après le boot Debian 10 Buster (résolu)

#4 29-06-2019 10:05:21

Re : RAID 1 (mdam) qui disparait après le boot Debian 10 Buster (résolu)

#5 29-06-2019 11:26:57

Re : RAID 1 (mdam) qui disparait après le boot Debian 10 Buster (résolu)

#6 29-06-2019 11:37:10

Re : RAID 1 (mdam) qui disparait après le boot Debian 10 Buster (résolu)

#7 29-06-2019 11:56:42

Re : RAID 1 (mdam) qui disparait après le boot Debian 10 Buster (résolu)

#8 29-06-2019 12:26:58

Re : RAID 1 (mdam) qui disparait après le boot Debian 10 Buster (résolu)

#9 29-06-2019 14:45:36

Re : RAID 1 (mdam) qui disparait après le boot Debian 10 Buster (résolu)

#10 29-06-2019 15:09:14

Re : RAID 1 (mdam) qui disparait après le boot Debian 10 Buster (résolu)

#11 29-06-2019 15:21:54

Re : RAID 1 (mdam) qui disparait après le boot Debian 10 Buster (résolu)

#12 29-06-2019 15:39:24

Re : RAID 1 (mdam) qui disparait après le boot Debian 10 Buster (résolu)

#13 30-06-2019 08:35:02

Re : RAID 1 (mdam) qui disparait après le boot Debian 10 Buster (résolu)

#14 30-06-2019 09:31:43

Re : RAID 1 (mdam) qui disparait après le boot Debian 10 Buster (résolu)

#15 30-06-2019 09:34:39

Re : RAID 1 (mdam) qui disparait après le boot Debian 10 Buster (résolu)

#16 30-06-2019 09:36:56

Re : RAID 1 (mdam) qui disparait après le boot Debian 10 Buster (résolu)

#17 30-06-2019 09:38:08

Re : RAID 1 (mdam) qui disparait après le boot Debian 10 Buster (résolu)

Pied de page des forums