Mdadm: no arrays found in config file or automatically

Support Debian
#1

Bonjour à toutes et tous.
Voilà mon problème.
Je suis sur debian 11.
J’ai changé mon dd interne pour un ssd. J’ai fais un clonage de mon dd. J’ai lu ensuite que pour les ssd, le swap n’était pas bon (écriture/réécriture). Alors, j’ai tout simplement supprimer ma partition swap avec Gparted.
Et là au redémarrage, voilà ce qu’il me dit :
« mdadm: No arrays found in config file or automatically », répété 20 fois (j’ai compté), puis « mdadm: error opening /dev/md?*: no such file or directory » (1 fois) et enfin à nouveau « mdadm: No arrays found in config file or automatically ».
Pour finir, « gave up waiting for suspend/resume device ».
il lance le démarrage avec un décompte de 1min30.
Quoiqu’il en soit, il démarre toujours sans problème particulier, mais c’est très lent.
Je suis assez novice dans le domaine.
Si quelqu’un a une idée pour revenir à la normale.

Bien cordialement

#2

Bonjour et bienvenue sur le forum,

Comment as-tu cloné le disque ?

Ce message, c’est probablement parce que tu as supprimé le swap, mais que celui-ci doit toujours exister dans le fichier /etc/fstab.

Par contre, je ne comprends pas pourquoi tu as ce message. Tu as du RAID sur ta machine ?

Oui, c’est vrai que ça peut user les SSD, mais la technologie a énormément évolué et il semble que ce soit relativement négligeable maintenant. Mais, tu pouvais aussi garder ton SSD et modifier la priorité du swap (« swappiness »).

#3

N’importe quoi. Soit le système a besoin de swap et il va moins bien fonctionner sans (lenteur, voire plantage), soit il n’en a pas besoin et n’y écrira pas. Au passage, seule l’écriture use un SSD, pas la lecture. Et sans swap, pas d’hibernation (mise en veille sur disque) possible.

Non, c’est parce que le swap reste référencé dans l’initramfs pour la sortie de l’hibernation. Si le choix de supprimer le swap est définitif, il faut mettre à jour le fichier /etc/initramfs-tools/conf.d/resume avec RESUME=none et reconstruire les initramfs avec update-initramfs -u -k all. Il faut aussi mettre à jour /etc/fstab pour éviter le délai suivant

Les messages de mdadm sont probablement causés par l’initramfs qui cherche frénétiquement le swap manquant sur tous les périphériques possibles, y compris d’éventuels ensembles RAID qui pourraient être un peu lents à s’assembler.

1 J'aime
#4

Merci pour vos réponses.
J’ai cloné mon dd avec Clonezilla.
Pour ce qui est du RAID, je ne sais pas ce que c’est, donc c’est possible.
Je pense supprimer définitivement mon swap, puisque j’ai 5 Go de ram. de ce fait, je pense que c’est inutile d’en avoir un.
Mon pc ne me sert que pour du traitement de texte ou visionner des vidéos. Je n’ai pas une activité gourmande.
Je vais essayer toutes vos propositions et je vous tiens au courant.
Encore merci à tous.

#5

Sur un prochain message, je vous mettrais un photo de l’écran de démarrage si cela peut aider.

Merci.

#6

Si tu ne sais pas ce que c’est, tu ne l’utilises pas. On ne peut pas utiliser du RAID logiciel à l’insu de son plein gré.
Le paquet mdadm a probablement été installé par dépendance ou recommandation d’un autre paquet. Tu peux le désinstaller si cela n’entraîne pas la désinstallation d’autres paquets.

#7

Si ton système est configuré pour utilisé un swap, si tu l’enlève il va moins bien fonctionner comme te le disais @PascalHambourg .
si en plus tu veux pouvoir mettre ta machine en hibernation, sans swap ce n’est pas possible.

#8

Entendons-nous bien. Même si le système est configuré pour utiliser un swap, ça ne veut pas forcément dire qu’il en a besoin. Pas besoin de swap si on n’utilise pas l’hibernation et si la quantité de RAM suffit pour faire fonctionner les programmes utilisés. Par contre il faut supprimer les référence aux swap dans toute la configuration (fstab et initramfs) pour éviter les lenteurs au démarrage.

1 J'aime
#9

c’est pas un peu théorique, ça ???
en ce moment, le gestionnaire de tâche me dit que j’ai 57% de ram utilisée (sur 8 Go) et 400 Mo de swap (sur 985 Mo).
et j’hiberne jamais…
du coup, à quoi servent les 400 Mo de swap ???

#10

Qu’est-ce qui est théorique ?
400 Mo sur 8 Go, c’est très peu, à peine 5%. Il peut s’agir de données « dormantes » et à un moment donné le gestionnaire de mémoire virtuelle a estimé qu’il avait mieux à faire avec la RAM et a décidé de les décharger dans le swap.
Quant à la quantité de RAM « utilisée », le problème est qu’il y a autant de formules pour la calculer que de programmes qui servent à l’afficher. Est-ce qu’on inclut les caches, et si oui, lesquels ? La seule valeur vraiment fiable, c’est la quantité de RAM « libre », celle qui n’est pas du tout utilisée.

#11

je disais « théorique » dans la mesure où, même avec beaucoup de RAM, le système peut être amené à utiliser le swap…
là, les 400 Mo, c’est 5% de la RAM, mais c’est aussi 50 % du swap.
pour en revenir à la problématique SSD, on ne sait pas non plus quelle est la dynamique de lecture/écriture sur ces 400Mo .
mais bon, si les SSD d’aujourd’hui sont vraiment aussi fiables que les mécaniques, la question n’a que peu d’intérêt :slight_smile:

#12

Autre petite question.
Si je réinstalle proprement ma partition swap que j’ai effacée, est-ce que ça peut résoudre « simplement » mon petit problème ?

#13

Je ne l’ai pas précisé, mais je pense que vous l’avez bien compris, quand j’ai installer ma débian, j’avais une partition swap pour mon dd.
De plus, je n’utilise pas l’hibernation. en fait, à chaque fois que j’ai voulu essayer, ça ne marchait pas, quelque soit la taille de ma partition swap. Alors, je ne m’en suis jamais servie, et je ne pense pas que ça changera.

#14

Cela peut arriver si, à un moment donné, la quantité de RAM libre descend sous un certain seuil, notamment sous l’effet du cache de fichiers (tout fichier lu ou écrit est gardé en cache en RAM tant que le système n’a pas besoin de récupérer de la mémoire pour autre chose). Quand le système a besoin de mémoire, il a deux choix : soit supprimer des fichiers du cache, soit décharger des données de processus dans le swap, et il choisit selon ce qui est le moins utilisé.

Et si tu avais 10 fois plus de swap ce serait 10 fois moins en pourcentage, la belle affaire. L’utilisation du swap ne dépend pas de sa taille, du moins tant qu’il n’est pas plein. De même que l’occupation de la mémoire par le cache de fichiers ne dépend pas de la taille du disque mais du volume de fichiers lus ou écrits.

C’est facile à afficher avec la commande vmstat.

Si par « proprement » tu veux dire avec le même UUID que celui figurant dans /etc/fstab, oui. En, revanche elle n’a pas besoin d’avoir la même taille.

C’est-à-dire ?
Il y actuellement a une situation connue où la reprise après hibernation est bloquée par conception : si le secure boot UEFI est activé.

#15

Ca doit être pour ça que ça bloque.

#16

Merci pour toutes ces précisions.
J’ai pas trop le temps de m’en charger opur le moment, mais dès que je peux, je vais faire au plus simple : réinstaller la partition swap avec le bon UUID.
En tout cas je vous teindrai au courant.

Encore merci à toutes et tous.

#17

Alors voilà.
J’ai pris le temps et j’ai réussit à réparer mon petit problème.
J’ai vérifié l’UUID de la partiton swap que j’avais effacé avec la commande cat /etc/fstab.
Ensuite, j’ai recréé, en root, une partition swap au même emplacement avec le même UUID que celui de fxtab, avec la commande
mkswap -U xxxxxx-xxxx-xxxx-xxx… /dev/volume
J’ai redémarré mon système et tout est revenu en place, comme si de rien n’était.

En tout cas merci à tous pour vos informations .