# Raid 0 logiciel innaccessible, partition non montable **URL:** \ **Category:** Support Debian\ **Created:** [Avril 2, 2022, 8:59 UTC](https://www.debian-fr.org/t/raid-0-logiciel-innaccessible-partition-non-montable/86333 "2022-04-02T08:59:43Z")\ **Posts on this page:** 15\ **Page:** 1
**Author:** ![eforminfo](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/e/74df32/32.png) [@eforminfo](https://www.debian-fr.org/u/eforminfo)\ **Post date:** [Avril 2, 2022, 8:59 UTC](https://www.debian-fr.org/t/raid-0-logiciel-innaccessible-partition-non-montable/86333/1 "2022-04-02T08:59:43Z")
Bonjour, Je me permets de vous écrire aujourd’hui car je rencontre quelques soucis sur mon Raid 0 Jbod logiciel 2x2To J’avais opté pour du jbod en me disant que si un des deux disques crève, je récupère les données au moins de l’autre. Évidemment, ça fait 5 mois que ça tournais, j’ai pas fait de Backup, s’était sur ma liste de chose à faire Voici le tuto que j’avais partiellement utilisé pour créer mon raid 0 : > **[\[Tuto/HowTo\] \[Debian/Ubuntu\] Créer un JBOD (raid0 non strip) avec mdadm -...](https://linuxfr.org/wiki/tuto-howto-debian-ubuntu-creer-un-jbod-raid0-non-strip-avec-mdadm)** > > \[Tuto/HowTo\] \[Debian/Ubuntu\] Créer un JBOD (raid0 non strip) avec mdadm Aujourd’hui, leur état de santé est bon d’après disks niveau smart, mais pas moyen d’accéder à la partition du raid. Ce qui à changer c’est que j’ai sorti un nouveau SSD SATA pour installer Debian 11 sur mon serveur et pouvoir tout réinstaller sans rien perdre … Je précise aussi, je sentais que mon ancien SSD était à la ramasse, j’en est changer pour ça, il est encore accessible, mais plus moyen de booter dessus, n’est plus détecté comme un volume bootable uefi. - Mon ancien SSD est en GPT UEFI - le nouveau je l’ai fait en MBR, j’ai plus confiance pour un boot en l’uefi lol Sur mon nouveau Debian via l’utilitaire de disques (disks), je vois un de mes deux raids, mais celui qui m’intéresse n’est pas montable … Je vous précise que mon niveau en linux n’est pas encore super bon, mais je veux m’améliorer, je suis motivé. Je vous ai joint une capture d’écran de l’utilitaire disks et suis preneur de vos conseils pour rétablir la situation. ![2022-04-02 10_41_19-192.168.1.250_4832 - Connexion Bureau à distance](https://www.debian-fr.org/uploads/default/original/2X/8/897e797975cf40c8cb72f34137f3e3ba6823b03c.png) ---
**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 2, 2022, 9:32 UTC](https://www.debian-fr.org/t/raid-0-logiciel-innaccessible-partition-non-montable/86333/2 "2022-04-02T09:32:22Z")
> [@eforminfo](#): > > je rencontre quelques soucis sur mon Raid 0 Jbod logiciel RAID 0 et JBOD, ce n’est pas la même chose. JBOD n’a de sens qu’avec un contrôleur RAID matériel (lorsque les disques sont accessibles indépendamment et pas en grappes RAID), pas en RAID logiciel ou par définition les disques sont accessibles indépendamment. > [@eforminfo](#): > > en me disant que si un des deux disques crève, je récupère les données au moins de l’autre. Non, le RAID 0 n’offre aucune redondance et si un disque meurt tout est perdu car ce qui reste sur l’autre disque est inutilisable. > [@eforminfo](#): > > Voici le tuto que j’avais partiellement utilisé pour créer mon raid 0 : Ce truc est un ramassis de conneries, et ça commence dès le titre « JBOD (raid0 non strip) ». Ça n’a aucun sens, JBOD n’est pas du RAID et le RAID 0 est du RAID en bandes par définition. Quelles parties as-tu utilisées ? Si tu as utilisé le script de démarrage de l’ensemble RAID avec les noms de disques en dur, ce qui est une grosse connerie car ils ne sont pas stables, pas étonnant que ça pète après l’ajout d’un autre disque. « Taille 0 octet », ça peut vouloir dire que l’ensemble RAID n’est pas démarré. On peut voir la sortie de (en root puis copier-coller du texte, pas d’image) ``` cat /proc/mdstat cat /etc/mdadm/mdadm.conf mdadm --detail /dev/md127 blkid lsblk ``` ---
**Author:** ![eforminfo](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/e/74df32/32.png) [@eforminfo](https://www.debian-fr.org/u/eforminfo)\ **Post date:** [Avril 2, 2022, 9:59 UTC](https://www.debian-fr.org/t/raid-0-logiciel-innaccessible-partition-non-montable/86333/3 "2022-04-02T09:59:18Z")
> [@PascalHambourg](#): > > Ce truc est un ramassis de conneries, et ça commende dès le titre Je comprend bien, mais je n’ai pas le niveau pour m’en rendre compte. Poser la question au forum est une bonne chose, notamment pour ça je m’en rend compte, mais j’essaye de ne pas aller systématiquement embêter quelqu’un si je peux trouver l’information. En ce sens là, aurais-tu, au delà du forum, un endroit ou je peux être bien renseigner sur le raid logiciel sous debian ? En attendant voici le résultat des diverses commandes, en te remerciant pour le temps que tu y consacre : Cat /proc/mdstat : ``` Personalities : [raid0] [linear] [multipath] [raid1] [raid6] [raid5] [raid4] [raid10] md126 : active raid0 sda1[0] sdb1[1] 7813769216 blocks super 1.2 512k chunks md127 : inactive sdd1[1] sdc1[0] 3906761728 blocks super 1.2 unused devices: ``` 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 # instruct the monitoring daemon where to send mail alerts MAILADDR root # definitions of existing MD arrays ARRAY /dev/md/raidGA metadata=1.2 UUID=4136c8cb:75030801:1e330467:5ff97e85 name=PiBox:raidGA ARRAY /dev/md/raid0 metadata=1.2 UUID=9de28592:dc62fa41:d88e7a04:2f4d4b4b name=PiBox:raid0 # This configuration was auto-generated on Fri, 01 Apr 2022 20:21:20 +0200 by mkconf ``` mdadm --detail /dev/md127 : ``` Version : 1.2 Creation Time : Wed Oct 27 21:41:58 2021 Raid Level : raid0 Raid Devices : 2 Total Devices : 2 Persistence : Superblock is persistent Update Time : Wed Oct 27 21:41:58 2021 State : active, FAILED, Not Started Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Layout : -unknown- Chunk Size : 512K Consistency Policy : unknown Name : PiBox:raidGA (local to host PiBox) UUID : 4136c8cb:75030801:1e330467:5ff97e85 Events : 0 Number Major Minor RaidDevice State - 0 0 0 removed - 0 0 1 removed - 8 49 1 sync /dev/sdd1 - 8 33 0 sync /dev/sdc1 ``` ---
**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 2, 2022, 10:27 UTC](https://www.debian-fr.org/t/raid-0-logiciel-innaccessible-partition-non-montable/86333/4 "2022-04-02T10:27:14Z")
Il manque la sortie de blkid et lsblk. Tu peux ajouter la sortie de ``` mdadm --examine /dev/sdc1 /dev/sdd1 ``` ---
**Author:** ![eforminfo](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/e/74df32/32.png) [@eforminfo](https://www.debian-fr.org/u/eforminfo)\ **Post date:** [Avril 2, 2022, 11:01 UTC](https://www.debian-fr.org/t/raid-0-logiciel-innaccessible-partition-non-montable/86333/5 "2022-04-02T11:01:35Z")
J’ai trouvé ! Je me suis rappeler que j’avais eu des soucis suite au montage de ce deuxième Raid. Du coup, j’ai fais des recherches dans mon historique, j’ai trouver ça, et j’ai remis en place cette solution : [https://serverfault.com/questions/1017257/mdadm-error-524-when-assembling-array-configuration-reset-after-reboot](https://serverfault.com/questions/1017257/mdadm-error-524-when-assembling-array-configuration-reset-after-reboot) En revanche, modifier le fichier de grub c’est une chose, mettre à jour grub aussi, mais pourquoi devoir en venir à ça pour que ma partition s’ouvre, ça j’ai rien compris. Peut être saura tu m’expliquer ? ou me dire ou je peux trouver des infos fiable pour l’avenir sur le raid, le montage, 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 2, 2022, 12:01 UTC](https://www.debian-fr.org/t/raid-0-logiciel-innaccessible-partition-non-montable/86333/6 "2022-04-02T12:01:41Z")
Les explications du lien, notamment celles du blog, me semblent claires. Il y a aussi des explications dans les pages de manuel de mdadm à la description de l’option --layout et md à la section RAID0. Un changement dans le noyau Linux 3.14 (c’est donc très ancien) et suivants a modifié par inadvertance la disposition (layout) des données sur les disques en RAID 0 de tailles différentes. Un patch a été introduit dans le noyau 5.4 (soit bien plus tard, et rétroporté dans le noyau 4.19 de Debian buster, mais pas dans le noyau 4.9 de stretch) ajoutant le paramètre default\_layout au module raid0 pour spécifier quelle est la disposition par défaut à utiliser selon que les ensembles RAID 0 ont été créés avec un noyau antérieur ou postérieur à 3.14, et empêchant d’activer un ensemble RAID 0 de ce type créé par un noyau non patché si la disposition n’est pas spécifiée car cela pourrait provoquer une corruption des données. Concernant la valeur 1 ou 2 à donner au paramètre raid0.default\_layout, elle dépend si l’ensemble RAID a été créé (ou plutôt formaté/utilisé) avec un noyau inférieur ou supérieur ou égal à 3.14. Vu la date de création de ton ensemble, c’était probablement avec un noyau supérieur. Mais de toute façon dans le cas d’un ensemble RAID 0 à seulement deux disques, il me semble qu’il n’y a aucune ambiguïté donc peu importe. D’après la page de manuel de mdadm de bullseye il est possible d’enregistrer la disposition dans les superblocs lors de l’assemblage avec l’option --update pour que le paramètre raid0.default\_layout ne soit plus nécessaire mais cela rendra l’ensemble RAID incompatible avec les noyaux anciens non patchés. Quelle est la version de Debian sur cette machine ? Buster est un cas particulier car son noyau est patché mais sa version de mdadm ne permet pas de mettre à jour le layout à l’assemblage, donc il faut utiliser le paramètre du module raid0. Mais a priori ce problème n’affecte que les ensembles RAID 0 dont les membres ont des tailles différentes. Or d’après ta copie d’écran les deux disques sont du même modèle donc devraient avoir la même taille, à moins que les partitions n’aient pas la même taille. ``` fdisk -l /dev/sdc fdisk -l /dev/sdd mdadm --examine /dev/sdc1 /dev/sdd1 ``` ---
**Author:** ![eforminfo](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/e/74df32/32.png) [@eforminfo](https://www.debian-fr.org/u/eforminfo)\ **Post date:** [Avril 2, 2022, 1:45 UTC](https://www.debian-fr.org/t/raid-0-logiciel-innaccessible-partition-non-montable/86333/7 "2022-04-02T13:45:10Z")
ARGGG, y’a un truc aussi qui m’énerve, depuis un moment les commandes de bases reconnu normalement à la saisie dans un terminal ne fonctionne plus. Je suis OBLIGÉ de me rendre ou la commande se trouve et faire un ./ devant. Tu aurais une idée aussi ? La pour te faire fdisk, je suis aller dans /usr/sbin/ et ./fdisk -l /dev/sdc grrrr … ``` Disque /dev/sdc : 1,82 TiB, 2000397852160 octets, 3907027055 secteurs Modèle de disque : WDC WD20EFRX-68A 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 : 7E0DF9FD-9728-40AA-B490-C461E68448B6 Périphérique Début Fin Secteurs Taille Type /dev/sdc1 2048 3907026943 3907024896 1,8T Système de fichiers Linux ``` ./fdisk -l /dev/sdd : ``` Disque /dev/sdd : 1,82 TiB, 2000398934016 octets, 3907029168 secteurs Modèle de disque : WDC WD20EFRX-68A 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 : 90CCDA62-456F-43E6-9C99-03E621EB3ECC Périphérique Début Fin Secteurs Taille Type /dev/sdd1 2048 3907028991 3907026944 1,8T Système de fichiers Linux root@PiBox:/usr/sbin# ./fdisk -l /dev/sdd Disque /dev/sdd : 1,82 TiB, 2000398934016 octets, 3907029168 secteurs Modèle de disque : WDC WD20EFRX-68A 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 : 90CCDA62-456F-43E6-9C99-03E621EB3ECC Périphérique Début Fin Secteurs Taille Type /dev/sdd1 2048 3907028991 3907026944 1,8T Système de fichiers Linux ``` enfin mdadm --examine /dev/sdc1 /dev/sdd1 ``` /dev/sdc1 2048 3907026943 3907024896 1,8T Système de fichiers Linux root@PiBox:/usr/sbin# ./mdadm --examine /dev/sdc1 /dev/sdd1 /dev/sdc1: Magic : a92b4efc Version : 1.2 Feature Map : 0x0 Array UUID : 4136c8cb:75030801:1e330467:5ff97e85 Name : PiBox:raidGA (local to host PiBox) Creation Time : Wed Oct 27 21:41:58 2021 Raid Level : raid0 Raid Devices : 2 Avail Dev Size : 3906760704 (1862.89 GiB 2000.26 GB) Data Offset : 264192 sectors Super Offset : 8 sectors Unused Space : before=264112 sectors, after=0 sectors State : clean Device UUID : 0baf1b8f:4a87d06e:1b87313a:01aff774 Update Time : Wed Oct 27 21:41:58 2021 Bad Block Log : 512 entries available at offset 8 sectors Checksum : cd6cfd76 - correct Events : 0 Chunk Size : 512K Device Role : Active device 0 Array State : AA ('A' == active, '.' == missing, 'R' == replacing) /dev/sdd1: Magic : a92b4efc Version : 1.2 Feature Map : 0x0 Array UUID : 4136c8cb:75030801:1e330467:5ff97e85 Name : PiBox:raidGA (local to host PiBox) Creation Time : Wed Oct 27 21:41:58 2021 Raid Level : raid0 Raid Devices : 2 Avail Dev Size : 3906762752 (1862.89 GiB 2000.26 GB) Data Offset : 264192 sectors Super Offset : 8 sectors Unused Space : before=264112 sectors, after=0 sectors State : clean Device UUID : 9bc8e97d:1a2b31f5:f8b3f3c8:188a4815 Update Time : Wed Oct 27 21:41:58 2021 Bad Block Log : 512 entries available at offset 8 sectors Checksum : 71aecacc - correct Events : 0 Chunk Size : 512K Device Role : Active device 1 Array State : AA ('A' == active, '.' == missing, 'R' == replacing) ``` ---
**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 2, 2022, 2:35 UTC](https://www.debian-fr.org/t/raid-0-logiciel-innaccessible-partition-non-montable/86333/8 "2022-04-02T14:35:16Z")
Vacherie, les deux disques sont du même modèle mais ont une différence de capacité de 1 Mio (de même que leurs partitions respectives), ce qui suffit à les faire considérer comme de tailles différentes pour le RAID0. Il aurait suffi que les deux partitions aient exactement la même taille pour que le problème ne se produise pas. Le layout n’est pas défini dans les superblocs RAID, d’où la nécessité de passer le paramètre du noyau. Si tu es sûr de ne jamais utiliser cet ensemble RAID avec un noyau antérieur non patché tu peux définir le layout une fois pour toutes lors d’un assemblage manuel, ça évitera de devoir spécifier le paramètre du noyau à chaque fois. ``` mdadm --stop /dev/md127 mdadm --assemble /dev/md/raidGA /dev/sdc1 /dev/sdd1 --update=layout-alternate ``` > [@eforminfo](#): > > les commandes de bases reconnu normalement à la saisie dans un terminal ne fonctionne plus. > > Je suis OBLIGÉ de me rendre ou la commande se trouve et faire un ./ devant. $PATH incomplet. Tu ne passerais pas root avec « su » au lieu de « su - » ? ---
**Author:** ![eforminfo](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/e/74df32/32.png) [@eforminfo](https://www.debian-fr.org/u/eforminfo)\ **Post date:** [Avril 4, 2022, 6:08 UTC](https://www.debian-fr.org/t/raid-0-logiciel-innaccessible-partition-non-montable/86333/9 "2022-04-04T06:08:16Z")
Déjà, je te remercie pour le temps consacré à mes diverses demandes. J’ai fais quelque recherche sur su et su -, il s’avère qu’en toute logique si je charge pas les variables d’environnement, forcément je vais pas savoir si certaines commandes existent, merci de m’avoir fait remarquer qu’en su - ça fonctionne. Aussi, je sais pourquoi ça à finit comme ça, j’ai ressorti certaines factures de disques, et TADA, un des deux disque de 2To est parti en garanti 1 ans après la vente. Ce qui fait que, ils n’ont pas le même âge, et que bien qu’ils soient sur le papier du même modèle … ^^, visiblement pas, à 1 Mio prêt. J’avais créer ce raid sous Buster, aujourd’hui je suis sous Bullseye. Je vais m’occuper cet après midi de définir le layout au niveau des superbloc. Si je comprend bien, définir le layout dans les superbloc sous entend, définir que un disque va nécessairement avec l’autre, ceci sur chacun des disques ? ---
**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 4, 2022, 7:06 UTC](https://www.debian-fr.org/t/raid-0-logiciel-innaccessible-partition-non-montable/86333/10 "2022-04-04T07:06:37Z")
> [@eforminfo](#): > > définir le layout dans les superbloc sous entend, définir que un disque va nécessairement avec l’autre, ceci sur chacun des disques ? Non, le fait que les deux disques font partie d’un ensemble RAID0 est déjà enregistré dans les superblocs. Définir le layout consiste à indiquer quelle est la disposition des blocs dans les zones supplémentaires des disques dont la taille est supérieure à celles des autres. On peut enregistrer le layout directement dans les superblocs à la création de l’ensemble ou lors de l’assemblage avec mdadm, ou bien spécifier un layout par défaut dans le paramètre default\_layout du module raid0. Exemple (pas forcément réaliste) avec trois disques A, B et C : - un disque A de taille 1 To - deux disques B et C de taille 2 To - taille totale de l’ensemble RAID0 = 1 + 2 + 2 = 5 To L’ensemble RAID0 de 5 To est donc divisé en deux zones : - une zone répartie sur 1 To des trois disque (3 To au total) - une zone répartie sur le To restant des disques B et C (2 To au total) Dans la première zone, il n’y a pas d’ambiguïté sur la disposition des blocs entre les trois disques. Par contre dans la seconde zone, il y a deux dispositions possibles selon que l’ensemble RAID0 a été créé avec un noyau pré ou post-3.14 : - un bloc sur B puis le bloc suivant sur C et ainsi de suite - ou bien un bloc sur C puis le bloc suivant sur B et ainsi de suite Si on indique le mauvais layout, les blocs de la deuxième zone vont être recherchés sur le mauvais disque. Ce que je trouve un peu dommage, c’est que dans le cas où un seul disque est plus grand que les autres (et notamment quand il n’y a que deux disques), le layout est sans objet puisque tous les blocs supplémentaires sont forcément sur ce disque. Il me semble que le code aurait pu être optimisé pour ne pas exiger un layout explicite dans les cas où il n’y a pas d’ambiguïté. ---
**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 14, 2022, 9:08 UTC](https://www.debian-fr.org/t/raid-0-logiciel-innaccessible-partition-non-montable/86333/11 "2022-04-14T21:08:24Z")
> [@PascalHambourg](#): > > Ce que je trouve un peu dommage, c’est que dans le cas où un seul disque est plus grand que les autres (et notamment quand il n’y a que deux disques), le layout est sans objet puisque tous les blocs supplémentaires sont forcément sur ce disque. Il me semble que le code aurait pu être optimisé pour ne pas exiger un layout explicite dans les cas où il n’y a pas d’ambiguïté. J’ai posé la question à l’auteur du patch qui a introduit le layout en RAID0, il a été d’accord avec moi et m’a suggéré de soumettre un patch. Mon modeste patch vient d’être accepté par le mainteneur du RAID logiciel (md) du noyau. [https://git.kernel.org/pub/scm/linux/kernel/git/song/md.git/commit/?h=md-next&id=190a901246c69d79dadd1ab574022548da612724](https://git.kernel.org/pub/scm/linux/kernel/git/song/md.git/commit/?h=md-next&id=190a901246c69d79dadd1ab574022548da612724) Par contre ce patch sera seulement inclus dans une future version du noyau (a priori 5.19, la version 5.18 étant déjà en phase rc), il faudra ensuite demander de le rétroporter dans les séries stables encore maintenues, dont la série 5.10 de bullseye. ---
**Author:** ![eforminfo](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/e/74df32/32.png) [@eforminfo](https://www.debian-fr.org/u/eforminfo)\ **Post date:** [Avril 17, 2022, 4:22 UTC](https://www.debian-fr.org/t/raid-0-logiciel-innaccessible-partition-non-montable/86333/12 "2022-04-17T04:22:20Z")
Et bah je te remercie, je sais que c’est open source mais j’ai pour l’instant pas le niveau de proposer un patch ou même de lire du code sur des petits bouts comme ça. J’ai lu ton correctif pour autant, il semble que ce soit du C++ ? J’ai bien assemblé les disques et vérifier que ça marche, j’ai supprimer les paramètres de lancement du kernel sur ce point. ---
**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 17, 2022, 7:20 UTC](https://www.debian-fr.org/t/raid-0-logiciel-innaccessible-partition-non-montable/86333/13 "2022-04-17T07:20:12Z")
La majeure partie du code source du noyau Linux est écrite en langage C, pas en C++. Certaines parties spécifiques aux architectures des processeurs ou devant être optimisées sont écrites en assembleur. Le patch lui-même est au format « diff »(du nom de la commande traditionnelle qui le génère) et contient les différences entre le code originel et le code modifié., et peut être appliqué avec la commande « patch ». Je n’ai pas non plus le niveau pour proposer autre chose que des patchs triviaux comme celui-ci. S’il a l’air si gros, c’est en fait parce que j’ai dû déplacer tout un bloc de code existant, mais l’ajout de code effectif ne porte que sur une ligne. C’était plus un exercice de style qu’autre chose pour moi ; le plus important était de signaler la régression introduite par le changement originel, n’importe quel développeur du noyau aurait ensuite pu écrire le patch. Je pense que tu peux marquer le sujet comme résolu avec la case à cocher correspondante. ---
**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:** [Juin 18, 2022, 8:39 UTC](https://www.debian-fr.org/t/raid-0-logiciel-innaccessible-partition-non-montable/86333/14 "2022-06-18T08:39:35Z")
> [@PascalHambourg](#): > > Par contre ce patch sera seulement inclus dans une future version du noyau (a priori 5.19, la version 5.18 étant déjà en phase rc), il faudra ensuite demander de le rétroporter dans les séries stables encore maintenues, dont la série 5.10 de bullseye. Le patch a bien été inclus dans la nouvelle version 5.19 et vient d’être rétroporté dans les séries stables/longterm maintenues, dont 4.19 (4.19.247) et 5.10 (5.10.122). Il devrait donc être inclus dans de futures mises à jour des noyaux de buster et bullseye basés sur ces séries. C’est d’autant plus utile pour buster dont la version de mdadm ne gère pas le layout RAID0. ---
**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:** [Juillet 9, 2022, 2:47 UTC](https://www.debian-fr.org/t/raid-0-logiciel-innaccessible-partition-non-montable/86333/15 "2022-07-09T14:47:18Z")
Ça y est : - noyau 4.19.0-21 publié récemment pour Buster comme mise à jour de sécurité DSA 5173-1 - noyau 5.10.0-16 publié aujourd’hui pour Bullseye avec la mise à niveau 11.4