Раздел отсутствует в /dev

Question

У меня странная проблема с тех пор, как я перешел из Centos5 в Centos6. У меня есть три диска, первые два используются в качестве RAID1, а третий - автономный резервный диск, который не указан в /etc /fstab (он монтируется при необходимости, а затем отключается).

Моя проблема: после загрузки /dev /sdc существует, но /dev /sdc1 нет. Кроме того, ссылки в /dev /disk также отсутствуют для первого раздела sdc. С самим диском все в порядке, и если я удаляю его горячим образом и снова подключаю, /dev /sdc1 выглядит нормально, и все работает.

Мой вопрос: Какая подсистема управляет автообнаружением дисков, разделов и т.д. В процессе загрузки (например, что создает /dev /disk /by-label)? Как настроить его для сканирования /dev /sdc и создания всех соответствующих файлов и ссылок в /dev?

Изменить: Вот соответствующая часть вывода dmesg (единственное место, где появляется sdc). Он выводит список sdc1, но его нет в /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

Answer 1

Я наконец нашел причину этой проблемы. Диск был членом RAID-массива Intel, а сигнатура RAID Intel пережила переразметку и переформатирование на другом компьютере:

mdadm -Evvv /dev /sdc

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

mdadm выяснил, что этот диск принадлежит к чужому массиву RAID, и даже читает метаданные Intel: имя тома, уровни RAID и т. д. Конечно, все эти данные устарели и больше не соответствуют действительности.

Тот факт, что диск считался членом внешнего RAID-массива, был причиной того, что этот диск не получил свои разделы, назначенные в /dev.

Как исправить

mdadm - нулевой суперблок /dev /sdc

Замените ваше собственное устройство на /dev/sdc конечно. Это должно быть неразрушающим для файловой системы, уже находящейся на диске, по крайней мере, моя файловая система пережила это без каких-либо проблем. Суперблок RAID обычно находится в последнем секторе (ах) диска.

Мораль этой истории

Всегда, всегда очищайте диск перед тем, как вынуть его из RAID и использовать его где-нибудь еще! Интернет изобилует историями о том, что чужой диск собирается в живой массив, разрушая его в процессе. Мне повезло, и я получил эту очень незначительную проблему.

Обычно обнуления первого и последнего секторов достаточно. Вы должны сделать это в старой системе, где изначально использовался диск, или где-то еще, пока загружается в аварийный CD (если используется только программный RAID!).

Answer 2

У меня была такая же проблема на дисках Debian Squeeze и VMware, разделы для одного диска просто не были в /dev , но они были видны fdisk и в dmesg. Я обновил пакет udev с 164 (найден в стабильном) до 175 (найден в тестировании), и после перезагрузки все работает как надо.