Disque en lecture seule

Support Debian
#21

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 :

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

Erreur kernel :

[   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
#22

Cela efface le secteur d’amorce de la partition, mais franchement, je ne sais même pas ce qu’est une “partition DOS”. 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.

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

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

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

En effet.

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.

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

#23

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.

#24

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]

suivi de resize2fs ?

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.

#25

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
#26 
# 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 :

Filesystem features : .....
#27

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.

#28

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.

#29

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.

1 J'aime
#30

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.

#31

@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 ?

#32

Bonjour,

La taille d’un secteur est de 512 bytes ;

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

#33

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 :wink:

#34

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.

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 : https://raid.wiki.kernel.org/index.php/RAID_superblock_formats#The_version-0.90_Superblock_Format
128 Kio = 256 secteurs de 512 octets.