# Problème RAID 1 **URL:** \ **Category:** Support Debian\ **Tags:** raid\ **Created:** [Avril 21, 2020, 5:50 UTC](https://www.debian-fr.org/t/probleme-raid-1/81867 "2020-04-21T17:50:44Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![Bubzy\_h](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/b/a5b964/32.png) [@Bubzy\_h](https://www.debian-fr.org/u/Bubzy_h)\ **Post date:** [Avril 21, 2020, 5:50 UTC](https://www.debian-fr.org/t/probleme-raid-1/81867/1 "2020-04-21T17:50:44Z")
Bonjour, j’ai un soucis avec mon NAS sous debian 9.11. Je suivais le tuto suivant : [https://www.howtoforge.com/tutorial/how-to-install-nextcloud-15-on-debian-9/](https://www.howtoforge.com/tutorial/how-to-install-nextcloud-15-on-debian-9/) quand je me suis rendu compte que mon raid 1 n’était plus reconnu. Je ne sais pas à quelle étape c’est arrivé (ça n’a peut être rien à voir…) J’ai essayé de le remonter, mais j’ai le message suivant !: ```nohighlight home/nas/nas-privee# mount /dev/md1 /home/nas/nas-privee mount: mauvais type de système de fichiers, option erronée, superbloc erroné sur /dev/md1, page de code ou programme auxiliaire manquant, ou autre erreur Dans certains cas des renseignements utiles sont dans le journal système — essayez « dmesg | tail » ou quelque chose du genre. ``` Je ne sais pas quoi faire à mon niveau, j’ai peur de perdre les 3 To de données sur mes disques… Merci ---
**Author:** ![Bubzy\_h](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/b/a5b964/32.png) [@Bubzy\_h](https://www.debian-fr.org/u/Bubzy_h)\ **Post date:** [Avril 21, 2020, 6:41 UTC](https://www.debian-fr.org/t/probleme-raid-1/81867/2 "2020-04-21T18:41:35Z")
Après m’être calmé un peu, j’ai lancé la commande suivante avec ça pour résultat. Je ne sais pas trop encore comment « réactiver » le raid sans créer d’autres problèmes… ```nohighlight root@NAS:/dev# cat /proc/mdstat Personalities : [raid6] [raid5] [raid4] md1 : inactive sdd[0] sdc[1] <--- le raid en question 5860271024 blocks super 1.2 md0 : active raid5 sda1[0] sdf1[3] sde1[2] sdb1[1] 5860147200 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU] bitmap: 0/15 pages [0KB], 65536KB chunk ``` ---
**Author:** ![anon61356901](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/cab0a1/32.png) [@anon61356901](https://www.debian-fr.org/u/anon61356901)\ **Post date:** [Avril 21, 2020, 7:03 UTC](https://www.debian-fr.org/t/probleme-raid-1/81867/3 "2020-04-21T19:03:38Z")
Bonjour @Bubzy_h La grappe en RAID1 `/dev/md1` semble utiliser des disques entiers, contrairement à la grappe en RAID5 `/dev/md0` qui utilise des partitions. Tu peux commencer par lancer ces commandes pour examiner les disques qui composent le RAID1 ```nohighlight sudo mdadm --examine /dev/sdc sudo mdadm --examine /dev/sdd ``` ---
**Author:** ![Bubzy\_h](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/b/a5b964/32.png) [@Bubzy\_h](https://www.debian-fr.org/u/Bubzy_h)\ **Post date:** [Avril 21, 2020, 7:13 UTC](https://www.debian-fr.org/t/probleme-raid-1/81867/4 "2020-04-21T19:13:28Z")
Bonjour @anon61356901 et merci pour ton aide. Voila, dans l’ordre, la réponse à ces commandes : ```nohighlight mdadm --examine /dev/sdc /dev/sdc: Magic : a92b4efc Version : 1.2 Feature Map : 0x1 Array UUID : f0f98ac9:19cba40a:558a7562:761dac7f Name : NAS:1 (local to host NAS) Creation Time : Mon Jul 2 16:40:35 2018 Raid Level : raid1 Raid Devices : 2 Avail Dev Size : 5860271024 (2794.39 GiB 3000.46 GB) Array Size : 2930135488 (2794.39 GiB 3000.46 GB) Used Dev Size : 5860270976 (2794.39 GiB 3000.46 GB) Data Offset : 262144 sectors Super Offset : 8 sectors Unused Space : before=262056 sectors, after=48 sectors State : clean Device UUID : 7e721eb6:6ccc8fff:b8513707:73fe36b6 Internal Bitmap : 8 sectors from superblock Update Time : Tue Apr 21 16:51:19 2020 Bad Block Log : 512 entries available at offset 72 sectors Checksum : 812da64c - correct Events : 36935 Device Role : Active device 1 Array State : AA ('A' == active, '.' == missing, 'R' == replacing) ``` et pour la seconde : ```nohighlight mdadm --examine /dev/sdd /dev/sdd: Magic : a92b4efc Version : 1.2 Feature Map : 0x1 Array UUID : f0f98ac9:19cba40a:558a7562:761dac7f Name : NAS:1 (local to host NAS) Creation Time : Mon Jul 2 16:40:35 2018 Raid Level : raid1 Raid Devices : 2 Avail Dev Size : 5860271024 (2794.39 GiB 3000.46 GB) Array Size : 2930135488 (2794.39 GiB 3000.46 GB) Used Dev Size : 5860270976 (2794.39 GiB 3000.46 GB) Data Offset : 262144 sectors Super Offset : 8 sectors Unused Space : before=262056 sectors, after=48 sectors State : clean Device UUID : 9d12250a:26f579df:a0c64790:da207e29 Internal Bitmap : 8 sectors from superblock Update Time : Tue Apr 21 16:51:19 2020 Bad Block Log : 512 entries available at offset 72 sectors Checksum : b1760672 - correct Events : 36935 Device Role : Active device 0 Array State : AA ('A' == active, '.' == missing, 'R' == replacing) ``` Les disques ne semblent pas avoir de soucis à ce que je comprends. Je pense que j’ai désactiver le raid 1 suite à une fausse manip (mais je ne vois pas laquelle). Le raid 5 est toujours fonctionnel. ---
**Author:** ![anon61356901](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/cab0a1/32.png) [@anon61356901](https://www.debian-fr.org/u/anon61356901)\ **Post date:** [Avril 21, 2020, 7:19 UTC](https://www.debian-fr.org/t/probleme-raid-1/81867/5 "2020-04-21T19:19:01Z")
Oui, les bonnes nouvelles sont : > State : clean > Checksum : correct > Array State : AA Il faut maintenant essayer d’assembler le RAID1 avec une méthode automatique, en premier lieu : ```plaintext sudo mdadm --assemble --scan ``` Si la méthode automatique échoue, tu peux utiliser la méthode manuelle : ```plaintext sudo mdadm --assemble /dev/md1 /dev/sdc /dev/sdd ``` ---
**Author:** ![Bubzy\_h](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/b/a5b964/32.png) [@Bubzy\_h](https://www.debian-fr.org/u/Bubzy_h)\ **Post date:** [Avril 21, 2020, 7:32 UTC](https://www.debian-fr.org/t/probleme-raid-1/81867/6 "2020-04-21T19:32:22Z")
@anon61356901 merci encore après tentative de la méthode auto : ```nohighlight root@NAS:/dev# mdadm --assemble --scan root@NAS:/dev# cat /proc/mdstat Personalities : [raid6] [raid5] [raid4] md1 : inactive sdd[0] sdc[1] 5860271024 blocks super 1.2 md0 : active raid5 sda1[0] sdf1[3] sde1[2] sdb1[1] 5860147200 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU] bitmap: 0/15 pages [0KB], 65536KB chunk unused devices: ``` et ensuite avec la manuelle : ```nohighlight root@NAS:/dev# mdadm --assemble /dev/md1 /dev/sdc /dev/sdd mdadm: /dev/sdc is busy - skipping mdadm: /dev/sdd is busy - skipping ``` J’entends mes disques tourner, je pense que la méthode auto fait quelque chose, mais ça ne se voit pas… ---
**Author:** ![anon61356901](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/cab0a1/32.png) [@anon61356901](https://www.debian-fr.org/u/anon61356901)\ **Post date:** [Avril 21, 2020, 7:38 UTC](https://www.debian-fr.org/t/probleme-raid-1/81867/7 "2020-04-21T19:38:12Z")
> [@Bubzy\_h](#): > > is busy - skipping Il faut savoir par quoi ou comment ces disques sont occupés. Je ne connais pas la commande pour trouver directement la source qui les rend occupés. Je croyais que cela pouvait être simple… Je ne connais pas assez `mdadm` sous Debian bien que j’aie un RAID6. Il va probablement falloir que tu attendes une aide plus experte. À mon avis, ça doit pas être bien sorcier. ---
**Author:** ![Bubzy\_h](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/b/a5b964/32.png) [@Bubzy\_h](https://www.debian-fr.org/u/Bubzy_h)\ **Post date:** [Avril 21, 2020, 7:54 UTC](https://www.debian-fr.org/t/probleme-raid-1/81867/8 "2020-04-21T19:54:34Z")
J’ai encore la possibilité de recréer le raid ou de restaurer une backup système (debian est installer sur une clée usb). Sinon je pense avoir vu des erreurs "**`[FAILED]`**"au démarrage de ma machine, mais je n’ai pas le temps de voir ce qu’il y avait écrit car le texte défile trop vite. Je pense que je vais attendre avant de faire quoi que ce soit, merci tout de même pour ton aide. ---
**Author:** ![anon61356901](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/cab0a1/32.png) [@anon61356901](https://www.debian-fr.org/u/anon61356901)\ **Post date:** [Avril 21, 2020, 8:43 UTC](https://www.debian-fr.org/t/probleme-raid-1/81867/9 "2020-04-21T20:43:48Z")
Tu as raison d’attendre. Ce serait trop bête de casser le RAID en essayant des trucs sans être sûr. ---
**Author:** ![Bubzy\_h](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/b/a5b964/32.png) [@Bubzy\_h](https://www.debian-fr.org/u/Bubzy_h)\ **Post date:** [Avril 21, 2020, 9:24 UTC](https://www.debian-fr.org/t/probleme-raid-1/81867/10 "2020-04-21T21:24:55Z")
J’ai eu quelque info supplémentaire en rebootant . c’était un peu prêt ça: ```nohighlight dependency failed for /dev/md1 ``` ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Avril 22, 2020, 12:54 UTC](https://www.debian-fr.org/t/probleme-raid-1/81867/12 "2020-04-22T12:54:28Z")
> [@anon61356901](#): > > La grappe en RAID1 `/dev/md1` semble utiliser des disques entiers Et c’est une mauvaise idée pour diverses raisons, notamment risque de conflit avec une table de partition. Dans ton dernier message supprimé, tu suggérais d’examiner les tables de partition des disques. C’était une bonne idée. > [@anon61356901](#): > > Oui, les bonnes nouvelles sont : Sans oublier : ``` Update Time : Tue Apr 21 16:51:19 2020 Events : 36935 ``` identiques sur les deux disques, indiquant l’absence de désynchronisation. > [@anon61356901](#): > > Il faut savoir par quoi ou comment ces disques sont occupés. Probablement par /dev/md1 qui est déjà assemblé comme indiqué dans /proc/mdstat. Ce n’est pas un problème d’assemblage mais d’activation. On peut regarder dans les logs du noyau avec `dmesg` les messages relatifs à cet ensemble et ses deux membres. On peut essayer de forcer l’activation pour voir ce que çe donne : ``` mdadm --run /dev/md1 ``` Ou bien d’arrêter l’ensemble et de le réassembler et voir ce qui se passe : ``` mdadm --stop /dev/md1 ``` mdadm --assemble --run /dev/md1 /dev/sdc /dev/sdd ---
**Author:** ![Bubzy\_h](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/b/a5b964/32.png) [@Bubzy\_h](https://www.debian-fr.org/u/Bubzy_h)\ **Post date:** [Avril 22, 2020, 1:17 UTC](https://www.debian-fr.org/t/probleme-raid-1/81867/13 "2020-04-22T13:17:56Z")
> [@PascalHambourg](#): > > identiques sur les deux disques, indiquant l’absence de désynchronisation. Du coup mes données n’ont pas de soucis, je suis rassuré 😁 Maintenant il faut juste y accéder ^^’ ```plaintext mdadm: stopped /dev/md1 root@NAS:/home/nas# mdadm --assemble --run /dev/md1 /dev/sdc /dev/sdd mdadm: failed to RUN_ARRAY /dev/md1: Invalid argument ``` la commande `run` n’a visiblement rien fait. Maintenant je ne vois plus Raid1 avec cat /proc/mdstat… Pour dmesg je copie l’intégralité des messages ? (car il y en a beaucoup) ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Avril 22, 2020, 1:28 UTC](https://www.debian-fr.org/t/probleme-raid-1/81867/14 "2020-04-22T13:28:11Z")
Uniquement ce qui se rapporte au RAID (md). ---
**Author:** ![Bubzy\_h](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/b/a5b964/32.png) [@Bubzy\_h](https://www.debian-fr.org/u/Bubzy_h)\ **Post date:** [Avril 22, 2020, 1:35 UTC](https://www.debian-fr.org/t/probleme-raid-1/81867/15 "2020-04-22T13:35:16Z")
```nohighlight [2.470468] md: md0 stopped. [2.472572] md: bind [2.472806] md: bind [2.473046] md: bind [2.473294] md: bind [2.544186] raid6: sse2x1 4843 MB/s [2.612140] raid6: sse2x2 5697 MB/s [2.680103] raid6: sse2x4 6380 MB/s [2.680105] raid6: using algorithm sse2x4 (6380 MB/s) [2.680106] raid6: using ssse3x2 recovery algorithm [2.683498] xor: measuring software checksum speed [2.720078] prefetch64-sse: 8121.000 MB/sec [2.760057] generic_sse: 7165.000 MB/sec [2.760059] xor: using function: prefetch64-sse (8121.000 MB/sec) [2.763503] async_tx: api initialized (async) [2.775162] md: raid6 personality registered for level 6 [2.775166] md: raid5 personality registered for level 5 [2.775167] md: raid4 personality registered for level 4 [2.776926] md/raid:md0: device sda1 operational as raid disk 0 [2.776930] md/raid:md0: device sdf1 operational as raid disk 3 [2.776932] md/raid:md0: device sde1 operational as raid disk 2 [2.776934] md/raid:md0: device sdb1 operational as raid disk 1 [2.777696] md/raid:md0: allocated 0kB [2.777961] md/raid:md0: raid level 5 active with 4 out of 4 devices, algorithm 2 [2.777964] RAID conf printout: [2.777965] --- level:5 rd:4 wd:4 [2.777967] disk 0, o:1, dev:sda1 [2.777969] disk 1, o:1, dev:sdb1 [2.777971] disk 2, o:1, dev:sde1 [2.777972] disk 3, o:1, dev:sdf1 [2.778166] created bitmap (15 pages) for device md0 [2.778683] md0: bitmap initialized from disk: read 1 pages, set 0 of 29807 bits [2.787080] md0: detected capacity change from 0 to 6000790732800 [2.789540] md0: unknown partition table [......] [7.326202] md: bind [7.327693] md: bind [7.330203] md: personality for level 1 is not loaded! [.....] [57291.936637] md: md1 stopped. [57291.936648] md: unbind [57291.961947] md: export_rdev(sdc) [57291.961965] md: unbind [57291.995837] md: export_rdev(sdd) [57313.864559] md: md1 stopped. [57313.866067] md: bind [57313.866297] md: bind [57313.867892] md: personality for level 1 is not loaded! [57313.867989] md: md1 stopped. [57313.867996] md: unbind [57313.887788] md: export_rdev(sdd) [57313.887799] md: unbind [57313.914023] md: export_rdev(sdc) ``` ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Avril 22, 2020, 2:33 UTC](https://www.debian-fr.org/t/probleme-raid-1/81867/16 "2020-04-22T14:33:26Z")
> [@Bubzy\_h](#): > > md: personality for level 1 is not loaded! Forcément, sans la gestion du RAID 1 ça va marcher beaucoup moins bien. J’aurais dû le voir dans /proc/mdstat. C’est le noyau normal de Debian ? ``` uname -a modinfo raid1 ``` Que donne le chargement manuel du module raid1 ? modprobe raid1 lsmod | grep raid dmesg | tail ---
**Author:** ![Bubzy\_h](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/b/a5b964/32.png) [@Bubzy\_h](https://www.debian-fr.org/u/Bubzy_h)\ **Post date:** [Avril 22, 2020, 2:42 UTC](https://www.debian-fr.org/t/probleme-raid-1/81867/17 "2020-04-22T14:42:24Z")
```plaintext uname -a Linux NAS 3.16.0-4-amd64 #1 SMP Debian 3.16.43-2+deb8u2 (2017-06-26) x86_64 GNU/Linux ``` ```plaintext root@NAS:/home/nas# modinfo raid1 libkmod: ERROR ../libkmod/libkmod-module.c:192 kmod_module_parse_depline: ctx=0x55eb2d310010 path=/lib/modules/3.16.0-4-amd64/kernel/drivers/md/md-mod.ko error=No such file or directory filename: /lib/modules/3.16.0-4-amd64/kernel/drivers/md/raid1.ko modinfo: ERROR: could not get modinfo from 'raid1': No such file or directory ``` ```plaintext root@NAS:/home/nas# modprobe raid1 modprobe: ERROR: ../libkmod/libkmod-module.c:192 kmod_module_parse_depline() ctx=0x5630d99a3010 path=/lib/modules/3.16.0-4-amd64/kernel/drivers/md/md-mod.ko error=No such file or directory modprobe: ERROR: ../libkmod/libkmod-module.c:192 kmod_module_parse_depline() ctx=0x5630d99a3010 path=/lib/modules/3.16.0-4-amd64/kernel/drivers/md/md-mod.ko error=No such file or directory modprobe: ERROR: could not insert 'raid1': Unknown symbol in module, or unknown parameter (see dmesg) ``` ```plaintext root@NAS:/home/nas# lsmod | grep raid raid456 77553 1 async_raid6_recov 16626 1 raid456 async_memcpy 12394 2 raid456,async_raid6_recov async_pq 12561 2 raid456,async_raid6_recov async_xor 12429 3 async_pq,raid456,async_raid6_recov async_tx 12566 5 async_pq,raid456,async_xor,async_memcpy,async_raid6_recov raid6_pq 95238 2 async_pq,async_raid6_recov md_mod 107672 2 raid456 ``` ```plaintext root@NAS:/home/nas# dmesg | tail [57291.995837] md: export_rdev(sdd) [57313.864559] md: md1 stopped. [57313.866067] md: bind [57313.866297] md: bind [57313.867892] md: personality for level 1 is not loaded! [57313.867989] md: md1 stopped. [57313.867996] md: unbind [57313.887788] md: export_rdev(sdd) [57313.887799] md: unbind [57313.914023] md: export_rdev(sdc) (c'est les même messages j'ai l'impression) ``` s > [@PascalHambourg](#): > > … Forcément, sans la gestion du RAID 1 ça va marcher beaucoup moins bien. … Une mise à jour peut être responsable de ça? ^^’ ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Avril 22, 2020, 3:12 UTC](https://www.debian-fr.org/t/probleme-raid-1/81867/18 "2020-04-22T15:12:18Z")
Oui, notamment si le noyau a été mise à jour et le système n’a pas été redémarré ou l’initramfs n’a pas été regénéré correctement. Mais je ne comprends pas bien les messages d’erreur. Je ne comprends pas si le module raid1.ko ou md-mod.ko est manquant, ou s’il y a une incompatibilité entre les deux. On peut voir le contenu de ``` ls -l /lib/modules/3.16.0-4-amd64/kernel/drivers/md ls -l /boot ``` Pour info, le dernier noyau disponible de jessie est le 3.16.0-10, le tien est beaucoup plus ancien. ---
**Author:** ![Bubzy\_h](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/b/a5b964/32.png) [@Bubzy\_h](https://www.debian-fr.org/u/Bubzy_h)\ **Post date:** [Avril 22, 2020, 3:21 UTC](https://www.debian-fr.org/t/probleme-raid-1/81867/19 "2020-04-22T15:21:02Z")
```plaintext root@NAS:/home/nas# ls -l /lib/modules/3.16.0-4-amd64/kernel/drivers/md ls: impossible d'accéder à '/lib/modules/3.16.0-4-amd64/kernel/drivers/md': Aucun fichier ou dossier de ce type ``` ```plaintext root@NAS:/home/nas# ls -l /boot total 52252 -rw-r--r-- 1 root root 186696 janv. 20 19:38 config-4.9.0-12-amd64 -rw-r--r-- 1 root root 186574 août 11 2019 config-4.9.0-9-amd64 drwxr-xr-x 5 root root 4096 avril 21 17:01 grub -rw-r--r-- 1 root root 19110728 avril 10 10:05 initrd.img-4.9.0-12-amd64 -rw-r--r-- 1 root root 19093849 janv. 11 16:45 initrd.img-4.9.0-9-amd64 -rw-r--r-- 1 root root 3206712 janv. 20 19:38 System.map-4.9.0-12-amd64 -rw-r--r-- 1 root root 3200950 août 11 2019 System.map-4.9.0-9-amd64 -rw-r--r-- 1 root root 4261664 janv. 20 19:38 vmlinuz-4.9.0-12-amd64 -rw-r--r-- 1 root root 4241184 août 11 2019 vmlinuz-4.9.0-9-amd64 ``` > [@PascalHambourg](#): > > … le tien est beaucoup plus ancien. … J’ai quelque soucis de mise à jours (des liens manquant etc). 😅 ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Avril 22, 2020, 3:32 UTC](https://www.debian-fr.org/t/probleme-raid-1/81867/20 "2020-04-22T15:32:05Z")
Quelle version de Debian est-ce ? Comment cette machine peut-elle tourner avec un noyau 3.16 (jessie) alors qu’il ne semble pas installé (pas dans /boot en tout cas) ? C’est un conteneur ou une machine physique ? Il y a du multiboot ? Le répertoire /lib/modules/3.16.0-4-amd64 existe-t-il ? Si oui, que contient-il ? ---
**Author:** ![Bubzy\_h](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/b/a5b964/32.png) [@Bubzy\_h](https://www.debian-fr.org/u/Bubzy_h)\ **Post date:** [Avril 22, 2020, 3:41 UTC](https://www.debian-fr.org/t/probleme-raid-1/81867/21 "2020-04-22T15:41:08Z")
De base c’était debian 8 que j’ai passé en debian 9 avec un tutoriel (il y a un an, et ça marché bien jusqu’à là). C’est une machine physique normal. et il n’y a pas de multiboot ```nohighlight root@NAS:/home/nas# ls -l /lib/modules/3.16.0-4-amd64 total 3596 -rw-r--r-- 1 root root 914324 févr. 27 2019 modules.alias -rw-r--r-- 1 root root 885995 févr. 27 2019 modules.alias.bin -rw-r--r-- 1 root root 4256 févr. 27 2019 modules.builtin.bin -rw-r--r-- 1 root root 372602 févr. 27 2019 modules.dep -rw-r--r-- 1 root root 509032 févr. 27 2019 modules.dep.bin -rw-r--r-- 1 root root 402 févr. 27 2019 modules.devname -rw-r--r-- 1 root root 210 févr. 27 2019 modules.softdep -rw-r--r-- 1 root root 430109 févr. 27 2019 modules.symbols -rw-r--r-- 1 root root 537994 févr. 27 2019 modules.symbols.bin ``` [Page suivante](https://www.debian-fr.org/t/probleme-raid-1/81867.md?page=2)