# Disque en lecture seule

**URL:** <https://www.debian-fr.org/t/disque-en-lecture-seule/77606>\
**Category:** Support Debian\
**Created:** [Septembre 24, 2018, 11:54 UTC](https://www.debian-fr.org/t/disque-en-lecture-seule/77606 "2018-09-24T11:54:09Z")\
**Posts on this page:** 14\
**Page:** 2

<div class="post-metadata">

**Author:** ![yfi](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/y/c57346/32.png) [@yfi](https://www.debian-fr.org/u/yfi)\
**Post date:** [Septembre 28, 2018, 7:23 UTC](https://www.debian-fr.org/t/disque-en-lecture-seule/77606/21 "2018-09-28T07:23:58Z")

</div>

Merci pour vous deux, malheureusement je n’ai rien fait pour le moment, je suis un peu chargé, le serveur est en mode dégradé, marche avec charge CPU élevée.  
Il y a eu le changement de disque `sdb` (500G, même taille que sda) et j’ai reconstruit le raid. le disque est en mode lecture/écriture mais il me reste à corriger la taille.  
Dans les logs de karnel il y a les warnings ci-dessous qui recommandent de faire `e2fsck` mais je ne sais pas si ça ferra quelque chose vu que j’ai déjà passé cette commande avant changement de disque et elle n’a pas réglé le problème et l’erreur suivante persiste :

```nohighlight
kernel: [140621.072462] attempt to access beyond end of device
kernel: [140621.076419] md1: rw=0, want=486139248, limit=486139136

```

Erreur kernel :

```nohighlight
[10.175284] Adding 1023420k swap on /dev/md2. Priority:-1 extents:1 across:1023420k
[10.191655] EXT3-fs (md1): warning: mounting fs with errors, running e2fsck is recommended
[10.205392] EXT3-fs (md1): using internal journal
[11.842170] EXT2-fs (md0): warning: mounting unchecked fs, running e2fsck is recommended

```

---

<div class="post-metadata">

**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:** [Septembre 28, 2018, 1:06 UTC](https://www.debian-fr.org/t/disque-en-lecture-seule/77606/22 "2018-09-28T13:06:30Z")

</div>

> [@anon97446390](#):
>
> pourquoi cette mention ?
> 
> ```auto
> If you created or changed a DOS partition, /dev/foo7, say, then use dd(1) to zero the first 512 bytes
> 
> ```

Cela efface le secteur d’amorce de la partition, mais franchement, je ne sais même pas ce qu’est une «&nbsp;partition DOS&nbsp;». Partition FAT ? Partition FAT contenant un système MS-DOS ? Partition d’un disque partitionné au format DOS ?  
Le secteur d’amorce d’une partition FAT contient en outre des méta-données sur le système de fichiers FAT, mais je ne vois pas pourquoi en faire un cas particulier.

> [@anon97446390](#):
>
> Il faudra bien installer Grub sur le nouveau `sdb` ?

Dans le MBR de /dev/sdb, pas dans le secteur d’amorce d’une des partitions.

> [@anon97446390](#):
>
> > ```auto
> > Warning: partition does not start / end at a cylinder boundary
> > 
> > ```
> 
> C’est pas important ? On peut l’ignorer ? Ça implique quoi ?

Pas important. On peut l’ignorer. L’alignement en cylindres est obsolète.

> [@anon97446390](#):
>
> > Il faut corriger la taille de la partition, c’est-à-dire la position du secteur de fin de celle-ci.
> 
> Elle a bien été corrigée par la duplication du schéma de partitionnement ?

Non puisque la taille des partitions et ensembles RAID n’a pas changé.

> [@anon97446390](#):
>
> édition : ça ne change en rien le contenant RAID md1 demeurant plus petit que les partitions sda3 / sdb3.

En effet.

> [@anon97446390](#):
>
> Je ne vois pas vraiment comment agrandir sda3 et sdb3 avec le système en fonctionnement

Les agrandir ne pose pas de problème même si elles sont utilisées (les réduire, en revanche…). Avec parted (ou {c|s}fdisk + partprobe), on peut à la fois modifier la table de partition et faire prendre en compte ces modifications par le noyau sans redémarrer.  
Par contre il est impératif d’agrandir l’ensemble RAID immédiatement après sans redémarrer, car les superblocs RAID 0.90 qui sont normalement situés à la fin des partitions ne seraient plus à la fin, et si le système était redémarré avant, l’ensemble RAID ne serait plus reconnu.

> [@anon97446390](#):
>
> > Tu peux en profiter pour utiliser tout l’espace libre non alloué des disques si tu veux
> 
> Pour ça, il faut bien que le nouveau disque sdb ait exactement la même taille que `sda` ?

Non, pas nécessairement. L’ensemble RAID sera agrandi en fonction de la plus petite partition membre.

---

<div class="post-metadata">

**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:** [Septembre 28, 2018, 1:20 UTC](https://www.debian-fr.org/t/disque-en-lecture-seule/77606/23 "2018-09-28T13:20:01Z")

</div>

> [@yfi](#):
>
> j’ai reconstruit le raid

Tu veux dire que les partitions du nouveau disque ont été intégrées aux ensembles RAID qui sont à nouveau complets (donc pas dégradés) ? C’est une bonne chose. A vérifier dans /proc/mdstat.

fsck ne règlera pas le problème de la taille.

Par contre je vois que les messages sont produits par les pilotes ext2 et ext3. Or depuis le noyau de Jessie (Debian 8), ces pilotes ne sont plus présents et c’est le pilote ext4 qui gère aussi les systèmes de fichiers ext2 et ext3, et refuse de monter un système de fichier qui se déclare plus grand que son contenant. Cela pourrait expliquer pourquoi ton serveur parvient à le monter malgré tout.

Quelle est la version de Debian installée sur ce serveur, et quel est le noyau actif ? S’agit-il d’une version antérieure à Jessie, comme Wheezy (Debian 7) avec un noyau 3.2 ?

```
lsb_release -a
uname -a

```

Cette information peut être importante pour tester si la procédure pour agrandir l’ensemble RAID est applicable à cette version.

---

<div class="post-metadata">

**Author:** ![yfi](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/y/c57346/32.png) [@yfi](https://www.debian-fr.org/u/yfi)\
**Post date:** [Septembre 28, 2018, 1:39 UTC](https://www.debian-fr.org/t/disque-en-lecture-seule/77606/24 "2018-09-28T13:39:14Z")

</div>

> [@PascalHambourg](#):
>
> Tu veux dire que les partitions du nouveau disque ont été intégrées aux ensembles RAID qui sont à nouveau complets (donc pas dégradés) ? C’est une bonne chose. A vérifier dans /proc/mdstat.

Oui, et le serveur marche :

```
$ cat /proc/mdstat
Personalities : [raid1]
md2 : active raid1 sdb2[2] sda2[1]
      1023424 blocks super 1.2 [2/2] [UU]

md0 : active raid1 sdb1[1] sda1[0]
      102272 blocks [2/2] [UU]

md1 : active raid1 sdb3[1] sda3[0]
      243069568 blocks [2/2] [UU]

```

> [@PascalHambourg](#):
>
> fsck ne règlera pas le problème de la taille.

suivi de **resize2fs**?

> [@PascalHambourg](#):
>
> Par contre je vois que les messages sont produits par les pilotes ext2 et ext3. Or depuis le noyau de Jessie (Debian 8), ces pilotes ne sont plus présents et c’est le pilote ext4 qui gère aussi les systèmes de fichiers ext2 et ext3, et refuse de monter un système de fichier qui se déclare plus grand que son contenant. Cela pourrait expliquer pourquoi ton serveur parvient à le monter malgré tout.

Effectivement, le serveur est debian7 avec le noyau v3.2. et le serveur a pu démarré et monter le fs.  
et merci bcp pour ta remarque, elle est importante car je dois migrer vers debian8 dans les jours qui viennes. donc il faut absolument corriger la taille du raid avant migration.  
Avez vous la procédure pour correction de la taille de file système du raid (sans augmenter les partitions sda3 et sdb3, je n’ai pas vraiment besoin de plus de taille en disque) ?

merci encore.

---

<div class="post-metadata">

**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:** [Septembre 28, 2018, 2:02 UTC](https://www.debian-fr.org/t/disque-en-lecture-seule/77606/25 "2018-09-28T14:02:08Z")

</div>

Il faut que je teste ma procédure sur Wheezy (pas avant ce soir), car si elle ne fonctionne pas jusqu’au bout, le système ne pourra plus démarrer.  
Sinon, il y a la méthode longue :

- retirer une des deux partitions de l’ensemble RAID
- agrandir la partition
- réintégrer la partition dans l’ensemble RAID
- attendre la fin de la resynchronisation
- recommencer avec l’autre partition

La suite de la procédure est commune aux deux méthodes :

- agrandir l’ensemble RAID
- agrandir le système de fichiers

Il faudrait aussi vérifier si les deux autres ensembles RAID n’ont pas le même défaut qui serait passé inaperçu jusqu’ici. J’avais demandé la sortie des commandes suivantes, je ne crois pas l’avoir vue :

```
tune2fs -l /dev/md0
cat /proc/swaps
df -hT
```

---

<div class="post-metadata">

**Author:** ![yfi](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/y/c57346/32.png) [@yfi](https://www.debian-fr.org/u/yfi)\
**Post date:** [Septembre 28, 2018, 2:37 UTC](https://www.debian-fr.org/t/disque-en-lecture-seule/77606/26 "2018-09-28T14:37:12Z")

</div>

```
# tune2fs -l /dev/md0
tune2fs 1.42.5 (29-Jul-2012)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: fc246c90-3f2d-4c2a-b726-58d0eb5406f2
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: filetype sparse_super
Default mount options: (none)
Filesystem state: not clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 25688
Block count: 102396
Reserved block count: 5119
Free blocks: 38732
Free inodes: 25630
First block: 1
Block size: 1024
Fragment size: 1024
Blocks per group: 8192
Fragments per group: 8192
Inodes per group: 1976
Inode blocks per group: 247
Filesystem created: Fri Feb 1 18:16:28 2013
Last mount time: Fri Feb 1 20:34:05 2013
Last write time: Thu Sep 27 09:53:19 2018
Mount count: 29
Maximum mount count: 30
Last checked: Fri Feb 1 18:16:28 2013
Check interval: 15552000 (6 months)
Next check after: Wed Jul 31 19:16:28 2013
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Default directory hash: tea
Directory Hash Seed: da20b55e-76de-49f5-898d-807ac3b89ff9

tune2fs -l /dev/md1
tune2fs 1.42.5 (29-Jul-2012)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: 0f2b6dc0-2821-437f-8954-4c280e5143a3
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal filetype needs_recovery sparse_super large_file
Filesystem flags: signed_directory_hash
Default mount options: (none)
Filesystem state: clean with errors
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 30392320
Block count: 60767408
Reserved block count: 3038370
Free blocks: 35740913
Free inodes: 30187009
First block: 0
Block size: 4096
Fragment size: 4096
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 16384
Inode blocks per group: 512
Filesystem created: Fri Feb 1 18:16:29 2013
Last mount time: Thu Sep 27 01:17:15 2018
Last write time: Fri Sep 21 14:28:53 2018
Mount count: 4
Maximum mount count: 28
Last checked: Fri Sep 21 14:21:05 2018
Check interval: 15552000 (6 months)
Next check after: Wed Mar 20 13:21:05 2019
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Journal inode: 8
First orphan inode: 12746773
Default directory hash: tea
Directory Hash Seed: fac808b4-2d04-4cad-9e56-c3798b242883
Journal backup: inode blocks

# cat /proc/swaps
Filename Type Size Used Priority
/dev/md2 partition 1023420 21160 -1

# df -hT
Sys. fich. Type Taille Util. Dispo Uti% Monté sur
rootfs rootfs 229G 91G 127G 42% /
udev devtmpfs 10M 0 10M 0% /dev
tmpfs tmpfs 801M 220K 801M 1% /run
/dev/md1 ext3 229G 91G 127G 42% /
tmpfs tmpfs 5,0M 0 5,0M 0% /run/lock
tmpfs tmpfs 4,0G 0 4,0G 0% /dev/shm
none tmpfs 4,0G 0 4,0G 0% /dev/shm
/dev/md0 ext2 97M 59M 33M 65% /boot

```

comment peut-on interpréter :

```auto
Filesystem features : .....

```

---

<div class="post-metadata">

**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:** [Septembre 28, 2018, 4:10 UTC](https://www.debian-fr.org/t/disque-en-lecture-seule/77606/27 "2018-09-28T16:10:50Z")

</div>

La ligne “filesystem features” liste les fonctionnalités actives du système de fichiers. Leur description se trouve dans la page de manuel ext2, ext3 ou ext4.

Comme je le craignais, la taille définie dans le système de fichiers ext2 de /dev/md0 (102396 Kio) qui est monté sur /boot est supérieure à la taille du volume /dev/md0 (102272 Kio). Comme avec /dev/md1, elle est presque égale à la taille des partitions sous-jacentes /dev/sda1 et /dev/sdb1 (102399 Kio). Le même problème pourrait donc se produire en cas d’ajout de fichiers dans /boot, typiquement avec l’installation d’un nouveau noyau lors de la migration vers Jessie (environ +15 Mo).

Par contre la taille du swap dans /dev/md2 (1023420 Kio) est inférieure à la taille de /dev/md2 (1024000 Kio).

En l’état, on ne peut pas agrandir /dev/md0 car il n’y a pas d’espace libre sur les disques entre les partitions sd[ab]1 et sd[ab]2 pour les agrandir. Ou bien il faudrait réduire le swap en recréant les partitions sd[ab]2 une par une pour placer leur début un peu plus loin. L’autre solution tire parti de la possibilité de démonter /boot dont le contenu n’est pas utile pour le fonctionnement courant du système. Une fois le système de fichiers démonté, il serait possible de le réduire à la taille de l’ensemble RAID. Mais avant il faut que je vérifie si ça fonctionne sous Wheezy car dans mes souvenirs il me semble que ça ne fonctionnait pas.

Autre problématique liée à /boot : le chargeur d’amorçage. Sais-tu quel est le chargeur d’amorçage installé ? GRUB 1, GRUB 2 ou LILO ?  
Les partitions sd[ab]1 commencent au secteur 1 donc il n’y a aucun espace libre entre le MBR et elles pour l’embarquage de GRUB 2. Or il me semble que GRUB 2 exige l’embarquage lorsque /boot est en RAID. Cela l’exclut a priori. Reste GRUB 1 (obsolète) ou LILO. Que ce soit l’un ou l’autre, il faudrait impérativement le réinstaller après toute manipulation sur md0.

---

<div class="post-metadata">

**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:** [Septembre 29, 2018, 8:21 UTC](https://www.debian-fr.org/t/disque-en-lecture-seule/77606/28 "2018-09-29T08:21:47Z")

</div>

J’ai fait des tests avec le dernier système Wheezy qui me reste.

1. Je confirme que les pilotes ext2 et ext3 du noyau 3.2 de Debian 7/Wheezy acceptent de monter un système de fichiers plus grand que le périphérique de stockage qui le contient, contrairement au pilote ext4 du noyau 3.16 de Debian 8/Jessie.

2. Je confirme également que le message du noyau " `attempt to access beyond end of device`" rapporté dans ton message initial se produit lorsqu’on remplit le système de fichiers à fond.

3. Mauvaise nouvelle : la version du gestionnaire de partitions `parted` incluse dans Debian 7 ne permet pas d’agrandir une partition. Sa commande “`resize`” est buggée et a été remplacée par la commande “`resizepart`” dans les versions suivantes. Il faudra donc utiliser `{|c|f|s}disk` pour supprimer et recréer la partition avec les mêmes numéro et secteur de début.

4. Autre mauvaise nouvelle : contrairement à Debian 8, il n’est pas possible de faire prendre en compte le changement de taille d’une partition en cours d’utilisation. C’est peut-être dû au fait que le redimensionnement via `parted` (qui informe le noyau du changement de taille) n’étant pas possible, j’ai utilisé `partprobe` pour informer le noyau des changements de partitions. Je n’ai pas testé plus en détail. La conséquence est que la méthode rapide que j’avais testée avec succès sur Debian 8 n’est pas applicable. Il faudra donc appliquer la méthode longue décrite dans mon message n° 25.

5. En revanche la réduction d’un système de fichiers ext2 trop grand non monté a fonctionné comme avec Debian 8. Cela peut servir pour /dev/md0 utilisé comme /boot. Cependant je n’y toucherais pas avant d’avoir fait le point sur le chargeur d’amorçage, au risque de casser l’amorçage.

---

<div class="post-metadata">

**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:** [Septembre 30, 2018, 11:04 UTC](https://www.debian-fr.org/t/disque-en-lecture-seule/77606/29 "2018-09-30T11:04:53Z")

</div>

Voici ma procédure pour agrandir /dev/md1, en espérant n’avoir pas fait d’erreur ni d’oubli.

1° Installer le paquet parted s’il ne l’est pas déjà :

```
apt-get install parted

```

2° Agrandir la partition /dev/sdb3 d’au moins 256 secteurs  
Retirer la partition /dev/sdb3 de l’ensemble RAID /dev/md1 :

```
mdadm --fail /dev/md1 /dev/sdb3
mdadm --remove /dev/md1 /dev/sdb3

```

Si tu ne l’as pas conservé, recréer le fichier dump de la table de partition sda.out précédemment créé par :

```
sfdisk -d /dev/sda > sda.out

```

(ou sdb, peu importe, les tables de partition sont identiques)  
Editer le fichier sda.out.  
Augmenter la taille de la partition n° 3 à au moins 486139265+256=486139521.  
Fichier original :

```
# partition table of /dev/sda
unit: sectors

/dev/sda1 : start= 1, size= 204799, Id=83, bootable
/dev/sda2 : start= 204800, size= 2048000, Id=82
/dev/sda3 : start= 2252800, size=486139265, Id=83
/dev/sda4 : start= 0, size= 0, Id= 0

```

Fichier modifié :

```
# partition table of /dev/sda
unit: sectors

/dev/sda1 : start= 1, size= 204799, Id=83, bootable
/dev/sda2 : start= 204800, size= 2048000, Id=82
/dev/sda3 : start= 2252800, size=486139521, Id=83
/dev/sda4 : start= 0, size= 0, Id= 0

```

Appliquer le fichier modifié au disque /dev/sdb :

```
sfdisk /dev/sdb < sda.out

```

Si tu préfères utiliser fdisk, cfdisk ou parted interactivement à la place de sfdisk :

- supprimer la partition n° 3
- recréer la partition n° 3 avec le même secteur de début 2252800 et un secteur de fin au moins 256 plus loin qu’initialement (488392064+256=488392320)
- type de partition : primaire
- numéro de partition : 3
- secteur de début : 2252800
- secteur de fin : 488392320 ou plus
- identifiant de type : 83 (Linux)
- écrire les changements sur le disque et quitter.

Un message d’erreur disant que le noyau n’a pas pu prendre en compte la nouvelle table de partition parce que le disque est en cours d’utilisation est normal. Dans ce cas, informer le noyau du changement de taille par une autre méthode :

```
partprobe /dev/sdb

```

Ajouter la partition /dev/sdb3 à l’ensemble RAID /dev/md1 :

```
mdadm --add /dev/md1 /dev/sdb3

```

Attendre la fin de la synchronisation dans /proc/mdstat.

3° Agrandir la partition /dev/sda3  
Retirer la partition /dev/sda3 de l’ensemble RAID /dev/md1 :

```
mdadm --fail /dev/md1 /dev/sda3
mdadm --remove /dev/md1 /dev/sda3

```

Appliquer le fichier de table de partition modifié au disque /dev/sda (ou utiliser fdisk, cfdisk…) :

```
sfdisk /dev/sda < sda.out

```

Informer le noyau du changement de taille :

```
partprobe /dev/sda

```

Ajouter la partition /dev/sda3 à l’ensemble RAID /dev/md1 :

```
mdadm --add /dev/md1 /dev/sda3

```

Attendre la fin de la synchronisation dans /proc/mdstat

4° Agrandir l’ensemble RAID :

```
mdadm --grow /dev/md1 --size=max

```

5° Agrandir le système de fichiers ext3 dans /dev/md1 en ligne :

```
resize2fs /dev/md1

```

Note : Avant et après l’agrandissement de chaque partition (+partprobe) et de l’ensemble RAID, on peut vérifier que la nouvelle taille est bien prise en compte en affichant le contenu de /proc/partitions ou avec la commande `lsblk -b`.

---

<div class="post-metadata">

**Author:** ![anon97446390](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/b4bc9f/32.png) [@anon97446390](https://www.debian-fr.org/u/anon97446390)\
**Post date:** [Octobre 1, 2018, 1:22 UTC](https://www.debian-fr.org/t/disque-en-lecture-seule/77606/30 "2018-10-01T01:22:49Z")

</div>

> [@PascalHambourg](#):
>
> en espérant n’avoir pas fait d’erreur ni d’oubli.

J’ai lu attentivement 4 fois avant ma sieste et de nouveau 3 fois maintenant ;  
je ne vois rien qui ne va pas, c’est clair et parfaitement compréhensible.

Je n’aurai pas su trouver la valeur minimale de 256 secteurs à ajouter.

J’ajoute une répétition : ne pas redémarrer de toute la procédure de 1° à 5° accomplie.

> [@PascalHambourg](#):
>
> _post #22 :_ … il est impératif d’agrandir l’ensemble RAID immédiatement après sans redémarrer, car les superblocs RAID 0.90 qui sont normalement situés à la fin des partitions ne seraient plus à la fin, et si le système était redémarré avant, l’ensemble RAID ne serait plus reconnu.

---

<div class="post-metadata">

**Author:** ![yfi](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/y/c57346/32.png) [@yfi](https://www.debian-fr.org/u/yfi)\
**Post date:** [Octobre 1, 2018, 8:28 UTC](https://www.debian-fr.org/t/disque-en-lecture-seule/77606/31 "2018-10-01T08:28:36Z")

</div>

@PascalHambourg, je te remercie infiniment, c’est vraiment claire.

J’ai juste une question, **512** c’est la taille d’un secteur, pourquoi **256** minimum ? moi j’ai cru qu’il faut ajouter au minimum la taille d’un secteur ou un multiple d’un secteur ?

---

<div class="post-metadata">

**Author:** ![anon97446390](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/b4bc9f/32.png) [@anon97446390](https://www.debian-fr.org/u/anon97446390)\
**Post date:** [Octobre 1, 2018, 8:40 UTC](https://www.debian-fr.org/t/disque-en-lecture-seule/77606/32 "2018-10-01T08:40:03Z")

</div>

Bonjour,

La taille d’un secteur est de 512 bytes ;

> [@yfi](#):
>
> Units = sectors of 512 bytes, counting from 0

PascalHambourg indique d’augmenter de 256 secteurs au minimum ; soit 256\*512 = 131072 bytes.

---

<div class="post-metadata">

**Author:** ![yfi](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/y/c57346/32.png) [@yfi](https://www.debian-fr.org/u/yfi)\
**Post date:** [Octobre 1, 2018, 8:44 UTC](https://www.debian-fr.org/t/disque-en-lecture-seule/77606/33 "2018-10-01T08:44:20Z")

</div>

> [@anon97446390](#):
>
> 256

désolé j’ai lu de travers, j’ai lu 256 byte et pas 256 secteur, je retire ce que j’ai dit dans le message précèdent 😉

---

<div class="post-metadata">

**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:** [Octobre 1, 2018, 9:43 UTC](https://www.debian-fr.org/t/disque-en-lecture-seule/77606/34 "2018-10-01T09:43:45Z")

</div>

> [@anon97446390](#):
>
> J’ajoute une répétition : ne pas redémarrer de toute la procédure de 1° à 5° accomplie.

En fait c’était impératif avec la méthode rapide que j’envisageais initialement mais qui n’est pas possible avec Wheezy. Avec la méthode longue, redémarrer en cours de procédure ne devrait pas être aussi catastrophique. Mais je recommande d’éviter quand même.

> [@anon97446390](#):
>
> Je n’aurai pas su trouver la valeur minimale de 256 secteurs à ajouter.

Il s’agit de l’espace maximum occupé par le superbloc RAID 0.90 situé à la fin de la partition, qui est décrit ici : [RAID superblock formats - Linux Raid Wiki](https://raid.wiki.kernel.org/index.php/RAID_superblock_formats#The_version-0.90_Superblock_Format)  
128 Kio = 256 secteurs de 512 octets.

[Page précédente](https://www.debian-fr.org/t/disque-en-lecture-seule/77606.md?page=1)