2 votes

Partition manquante dans /dev

J'ai un problème étrange depuis que je suis passé de Centos5 à Centos6. J'ai trois disques, les deux premiers sont utilisés comme RAID1, et le troisième est un disque de sauvegarde autonome qui n'est pas listé dans /etc/fstab (il est mis en tas en cas de besoin, puis démonté).

Mon problème : Après un démarrage, /dev/sdc existe mais /dev/sdc1 ne le fait pas. De même, les liens dans /dev/disks sont également absents pour la première partition de sdc . Le disque lui-même est en bon état, et si je le retire à chaud et que je le rebranche, /dev/sdc1 semble correct et tout fonctionne.

Ma question : Quel sous-système gère la découverte automatique des disques, des partitions, etc. au cours du processus de démarrage (par exemple, ce qui crée le système d'exploitation) ? /dev/disks/by-label ) ? Comment le configurer pour qu'il scanne /dev/sdc et créer tous les fichiers et liens pertinents dans /dev ?

Editer : Voici la partie pertinente de la sortie de dmesg (le seul endroit où l'on peut lire sdc apparaît). Il énumère sdc1 mais il n'est pas dans /dev !

sd 1:0:0:0: \[sdb\] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB)
sd 3:0:0:0: \[sdc\] 976773168 512-byte logical blocks: (500 GB/465 GiB)
sd 1:0:0:0: \[sdb\] Write Protect is off
sd 1:0:0:0: \[sdb\] Mode Sense: 00 3a 00 00
sd 1:0:0:0: \[sdb\] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sd 3:0:0:0: \[sdc\] Write Protect is off
sd 3:0:0:0: \[sdc\] Mode Sense: 00 3a 00 00
sd 3:0:0:0: \[sdc\] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
 sdb:
 sdc:
sd 0:0:0:0: \[sda\] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB)
sd 0:0:0:0: \[sda\] Write Protect is off
sd 0:0:0:0: \[sda\] Mode Sense: 00 3a 00 00
sd 0:0:0:0: \[sda\] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
 sda:
DMAR:\[DMA Read\] Request device \[00:1e.0\] fault addr 361bc000 
DMAR:\[fault reason 06\] PTE Read access is not set
 sdb1 sdb2 sdb3
 sdc1
 sda1
sd 1:0:0:0: \[sdb\] Attached SCSI disk
sd 3:0:0:0: \[sdc\] Attached SCSI disk
 sda2 sda3
sd 0:0:0:0: \[sda\] Attached SCSI disk

3voto

haimg Points 21323

J'ai enfin trouvé la raison de ce problème. Le disque a été membre d'une matrice RAID d'Intel, et la signature RAID d'Intel a survécu au re-partitionnement et au reformatage sur un autre ordinateur :

mdadm -Evvvv /dev/sdc

              Magic : Intel Raid ISM Cfg Sig.
        Version : 1.1.00
.................................................
[Archive Volume]:
           UUID : xxxx
     RAID Level : 1
        Members : 2
          Slots : [UU]

mdadm a compris que ce disque appartient à une matrice RAID étrangère, et a même lu les métadonnées d'Intel : nom du volume, niveaux RAID, etc. Bien sûr, toutes ces données sont périmées et ne sont plus vraies.

Le fait que le disque soit considéré comme un membre d'un RAID étranger est la raison pour laquelle les partitions de ce disque ne sont pas assignées dans /dev.

Comment réparer

mdadm --zero-superblock /dev/sdc

Remplacez votre propre appareil par /dev/sdc bien sûr. La présente debe ne pas détruire le système de fichiers déjà présent sur le disque, du moins mon système de fichiers y a survécu sans problème. Le superbloc RAID se trouve généralement dans le(s) dernier(s) secteur(s) du disque.

Morale de cette histoire

Toujours, toujours nettoyer le disque avant de le retirer du RAID et de le réutiliser ailleurs ! Internet regorge d'histoires de disques étrangers qui ont été assemblés dans un réseau vivant et qui l'ont détruit au cours du processus. J'ai eu de la chance et j'ai rencontré ce problème très mineur.

En général, la mise à zéro du premier et des derniers secteurs suffit. Vous devez le faire dans l'ancien système où le disque a été utilisé à l'origine, ou ailleurs lorsque vous démarrez sur un CD de secours (si vous utilisez un RAID logiciel uniquement !).

0voto

Ash Points 497

J'ai eu le même problème sur les disques Debian Squeeze et VMware, les partitions d'un disque n'étaient tout simplement pas dans la liste des partitions. /dev mais elles étaient visibles par fdisk et dans dmesg. J'ai mis à jour udev de 164 (trouvé dans stable) à 175 (trouvé dans testing) et après le redémarrage tout fonctionne comme il se doit.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X