Нет. Абсолютно. fdisk никакого криминало показывать не хочет. Более того, почитал dmesg:

[    1.048391] dracut: dracut-018-105.git20120927.fc17
[    1.068791] dracut: rd.luks=0: removing cryptoluks activation
[    1.126075] dracut: Starting plymouth daemon
[    1.243990] dracut: rd.md=0: removing MD RAID activation
[    1.498044] dracut: Scanning devices sda2 sdb2  for LVM logical volumes vg_tom/LV_ROOT vg_tom/LV_SWAP
[    1.511581] dracut: Found duplicate PV iyxfFkeP7IQNwSbJnt5ykY4m7l3lwkAp: using /dev/sdb2 not /dev/sda2
[    1.513135] dracut: inactive '/dev/vg_tom/LV_SWAP' [1.97 GiB] inherit
[    1.513232] dracut: inactive '/dev/vg_tom/LV_ROOT' [15.62 GiB] inherit
[    1.513324] dracut: inactive '/dev/vg_tom/LV_DRBD' [32.00 GiB] inherit
[    1.513418] dracut: inactive '/dev/vg_tom/LV_FIRMDOCS' [200.00 GiB] inherit
[    1.513509] dracut: inactive '/dev/vg_tom/LV_ISCSI' [100.00 GiB] inherit
[    1.513601] dracut: inactive '/dev/vg_tom/LV_DATA' [114.62 GiB] inherit
[    1.530670] dracut: Found duplicate PV iyxfFkeP7IQNwSbJnt5ykY4m7l3lwkAp: using /dev/sdb2 not /dev/sda2
[    1.759086] EXT4-fs (dm-1): mounted filesystem with ordered data mode. Opts: (null)
[    1.846575] dracut: Checking ext4: /dev/mapper/vg_tom-LV_ROOT
[    1.846865] dracut: issuing e2fsck -a  /dev/mapper/vg_tom-LV_ROOT
[    1.881526] dracut: /dev/mapper/vg_tom-LV_ROOT: clean, 167142/1024000 files, 1289380/4096000 blocks
[    1.882358] dracut: Remounting /dev/mapper/vg_tom-LV_ROOT with -o ro
[    1.907533] EXT4-fs (dm-1): mounted filesystem with ordered data mode. Opts: (null)
[    1.958155] dracut: Mounted root filesystem /dev/mapper/vg_tom-LV_ROOT
[    2.078599] dracut: Switching root

Он, сволочь находит все правильно, действительно есть два диска, sda2 и sdb2, на которых лежит аппаратный RAID с LVM-разделом. Эти разделы имеют одинаковую метку. Так вместо того, чтобы сделать правильный вывод о том, что это RAID-1 и начать работать с ним через /dev/mapper/ddf-XXXXXX он берет в рассмотрение только диск sdb2,  и так далее. Хорошо, если это только по чтению берет. А если и по записи? Тогда - полная задница...
Вот вывод  dmesg на ту же тему на аналогичном сервере, под Fedora-12:

dracut: dracut-005-5.fc13
dracut: rd_NO_LUKS: removing cryptoluks activation
dracut: Starting plymouth daemon
dracut: rd_NO_MDIMSM: no MD RAID for imsm/isw raids
dracut: rd_NO_MD: removing MD RAID activation
dracut: rd_NO_MDIMSM: no MD RAID for imsm/isw raids
dracut: Scanning for dmraid devices ddf1_4c5349202020202080862925000000004711471100001450 
dracut: Found dmraid sets:
dracut: ddf1_4c5349202020202080862925000000004711471100001450
dracut: Activating ddf1_4c5349202020202080862925000000004711471100001450
dracut: RAID set "ddf1_4c5349202020202080862925000000004711471100001450" was activated
dracut: RAID set "ddf1_4c5349202020202080862925000000004711471100001450" was not activated
dracut: Scanning devices dm-2 sdc1  for LVM logical volumes vg_dbserver/lv_root 
dracut: inactive '/dev/vg_sdc/LV_DRBD' [32.00 GiB] inherit
dracut: inactive '/dev/vg_sdc/LV_WORK' [433.76 GiB] inherit
dracut: inactive '/dev/vg_dbserver/lv_root' [100.00 GiB] inherit
dracut: inactive '/dev/vg_dbserver/lv_data' [328.09 GiB] inherit
dracut: Mounted root filesystem /dev/mapper/vg_dbserver-lv_root
dracut: Loading SELinux policy
dracut: /sbin/load_policy: Невозможно загрузить политику: Нет такого файла или каталога
dracut: Switching root
 

Здесь он четко разобрался и сделал _правильный_ вывод. Зацепил dmraid и вперед через него... Если это бага, то она - на мой взгляд - весма критическая. Так как чревата внезапной потерей данных.

и вот еще немного непонятности:
На исправном сервере:

Беда еще в том, что на тех серверах, где я это обнаружил RAID-1 строится аппаратно (на полутерабайтных дисках) очень неспешно. Часов 10-12 сервер в "отключке" стоит... Можно, конечно, развалить аппаратный RAID, перейти на программный. Но это - лишняя нагрузка на не слишком мощные процессоры будет. Не нравится мне это...

Вытащу завтра. Хотя мне иных дел хватает... Программный делать сам не хочу.
Вполне возможно, что загрузчик не может нужный UUID ядру передать. В строке груба параметр есть, а ядро его не получает... Точнее - получает, но обработать не может:

На двух серверах. Работали они себе спокойно по управлением стареньких федор, 12-13. И там всё было четко, диски лежали на /dev/mapper/ddf.... Но, решил на них поднять кластер на pacemaker'е. Кувыркания на стенде (в виртуалках) показало, что CentOS 6.3 весьма сильно сопротивляется этому делу. Всё чего-то не хватало. В тоже время на Федоре - завелось как доктор прописал. Сборка-разборка почти без проблем. Поэтому обновляю ось на этих серверах, при обновлении явно вижу, что ставимся в аппаратный RAID. А вот дальше... В процессе работы идут в логи малоприятные собщения. И я не знаю, как относится аппаратный RAID при записи на один диск, на sda, дублирует ли эту запись на sdb или нет.

Да, сервера (проблемные) идентичны. Интеловские. Рабочий похож, только отличается процессором, матерью, под тот процессор (пара ксеонов) и объемом памяти. Дисковая подсистема, контроллеры скорее всего идентичны.  Имена их, серверов, на память не скажу. Завтра загружусь с флешки с RFR-14 и посмотрю, что она увидит. А заодно посмотрю - на какой именно диск идет запись. Если на оба - то и фиг с ним. А если на один... То очередной мне гимор... Ведь рутовый раздел я поместил в LVM.

Извините за грубое слово, но мне гораздо лучше чем Вам известен состав моег железа. Которое уже не первый год в эксплуатации. И если я говорю, что у меня - сервер, то это именно сервер (в данном случае в RACK-исполнении) а не писюк голимый, используемый в качестве сервака. Если я говорю, что там именно аппаратный RAID, то именно так оно и есть. Мои сервера несут на борту интеловские RAID-контроллеры.
Это первое.
Второе. Меня всегда удивляла особенность федоры (12,13,14) показывать не только dmraid-овские диски, которые она получает от этого контроллера, но и сами первоисточники, sda и sdb. Но показ не страшен. Пусть показывает, благо ничего с ними она делать не давала. Вся работа шла через опознанный при загрузке как RAID дисковый массив, через /dev/mappwe/ddf=XXXXX. А вот на федоре 17 - полная задница. Анаконда при установке поняла, что массив RAID-овский. Поставила ось именно на райдовский массив. А вот после перезагрузки (первой) вместо райдовского массива подхватился диск /dev/sdb2, в котром лежит большой LVM-массив. Со всеми данными, с корнем и так далее.
Третье - аппаратный котроллер совершенно не ожидал такой подлости и если заись шла не через dmraid, а напрямую, в /dev/sda2 - пропускал её спокойно. То есть аппаратное зеркало - разрушено. Это было проверено путем заггрузки CentOS 6.3. CentOS увидела dmraid-диск. Причем именно в виде перед первой перезагрузкой. В девстенно чистом состоянии sda2.   Кстати, CentOS (в отличие от федоры) не показал ни sda, ни sdb. Этих дисков для него не существут. Есть только то, что получено от dmraid'а
И, к моему великому сожелению, после того, как я поработал с Центоосью - система с диски отказалась загружаться вообще. Кернел-паник приходит по причине ненахождения диска. Мгновенно...

Есть какие идеи? Мне нужна именно Федора на сервере, так как эксперименты с pacemaker'ом на CentOC 6.3 кончились неудачно. А на федоре оно беспроблемно заводится и работает по написанному руководству.

И тем не менее - на федорах от 12 до 14й версий именно через него шла работа с интеловским RAID массивом. Логи я показывал выше. А вот на 17-й федоре этот массив увидела только анаконда, когда ось на него накатывала. А вот дальше - процесс правильной загрузки накрывается медным тазом. И вместо работы с RAID-1 через /dev/mapper/ddf-XXXX система цепляется к одному из физических дисков и работает в обход этого интеловского RAID-массива. Причем настолько в обход, что попытки поиграть с ключами загрузки типа rd.md и rd.dm разрушают систему полностью. Вроде выяснил, что стоит поставить параметры rd.md=1 rd.dm=auto (массив поднялся зеркально), но попытка записать эти параметры в конфиг груба грубо разрушает RAID. Полностью. Настолько, что его можно только в биосе проинициализировать. На первой машине я удивился этому, вторая - подтвердила разрушение. То есть эффект повторяем. Отсюда - Fedora 17 абсолютно непригодна для работы на интеловских серверах с интеловскими RAID-контроллерами.
Меня задолбал этот трах (лучи поноса от меня в мозг разработчиков дракута, до седьмого их колена),  поставил CentOS 6.3. Там RAID-1 массив прекрасно опозналя и завелся как положено. Вот лог загрузки:

Я очень сильно разочарован в федоре.

Да не работает... У меня цель не просто запустить в работу сервера, а постоить на них HA-кластер. Причем не на heartbeat, он только на двух нодах умеет, а на pacemaker-e. У меня в кластере должно стоять три сервера. А вот pacemaker на CentOS 6.3 я за две недели предновогоднего траха на виртуалках завести так и не смог. А на федоре он поднимается на раз-два, делай по книжке и всё получится.

Обидно, что целую неделю потерял на этом долбаном дракуте с RAIDом. Мог бы дано уже отдыхать и пиво пьянствовать. А тут уще целый сервер витруализации переделывать надо. И закончить всё надо 8-го числа. 9-го всё должно работать как часы...

А если свежеустановленной федоре скормить этим параметры (rd.md=1 rd.dm=auto) во время первой загрузки? Или так тоже пробовали?
А потом уже (если всё будет ок) - в конфиг груба записать

Программа не того уровня, чтобы зависеть от виртуальности. Там тривиальное расхождение версий pacemaker'а и corosinc'а. Причем некоторые нужные для работы программы исчезли в тумане, нету там основной программы crm. Вот всё начинающееся с этих букв есть, а самого менеджера - нету, выпилили. Как выпилили поддержку heartbeat'а и так далее... Вобщем, не сладно в pacemaker'е для Центоси 6.3.

Сейчас там стоит CentOS.
На одном сервере (два диска в RAID стоят, один, третий, отдельно) 

Значит интел на своих платформах фейки устраивает? И при загрузке компа (когда БИОС инициализируется) так явственно пишет про RAID-овость дисков, что массив стоит у него в онлайне... Три года с этими серверами жил и всегда думал, что там честный RAID.

Ну, фейк, так фейк. Беда не в этом. Беда в том, что до 14-й федоры оси спокойно этот фейк переваривали. И у меня даже и мысли не возникало об фейковости. А вот решил поставить федору 17 (с прицелом на кластер, на pacemaker, на стенде всё замечательно прокачалось) и обломался. Половину праздников (планировал неспешную работу) - псу под хвост... Наплясался на этой грабле. И хорошо, что заметить успел, что система живет на не на 2-х, а только (не хочет А-17 на фековом райде работать, игнорирует его) на одном диске . Они у меня летят быстро, живут года полтора, от силы - два. Потом замена по гарантии :-). И как бы я на ту замену вышел, когда диск рабочий колом бы встал со всеми данными? Ну, данные ладно, они на drbd, на glusterfs'e, но вот весь приклад.... Все настройки - псу под хвост. А где сервер? А нетути...
Ладно, успел весь основной функционал   поднять и протестировать. Но устравивать такие гонки - врагу не пожелаешь...

И вопрос - а как должен выглядеть нефейковый, а честный RAID-массив?

если бы у меня было по доллару за каждый раз когда клиент говорил "но до сих пор оно работало"...

насколько я знаю, линукс движется от поддержки dmraid, потому что преимуществ нет никаких, а управлять софтовым рейдом проще и надежнее. Так что выбор простой - или софт или железо, полумеры ни к чему

как один диск, сколько бы там физически не было

пример:

# cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 32 Lun: 00
  Vendor: DP       Model: BACKPLANE        Rev: 1.10
  Type:   Enclosure                        ANSI  SCSI revision: 05
Host: scsi0 Channel: 02 Id: 00 Lun: 00
  Vendor: DELL     Model: PERC H700        Rev: 2.10
  Type:   Direct-Access                    ANSI  SCSI revision: 05
Host: scsi0 Channel: 02 Id: 01 Lun: 00
  Vendor: DELL     Model: PERC H700        Rev: 2.10
  Type:   Direct-Access                    ANSI  SCSI revision: 05
Host: scsi7 Channel: 00 Id: 00 Lun: 00
  Vendor: iDRAC    Model: LCDRIVE          Rev: 0323
  Type:   Direct-Access                    ANSI  SCSI revision: 00
Host: scsi8 Channel: 00 Id: 00 Lun: 00
  Vendor: iDRAC    Model: Virtual CD       Rev: 0323
  Type:   CD-ROM                           ANSI  SCSI revision: 00
Host: scsi8 Channel: 00 Id: 00 Lun: 01
  Vendor: iDRAC    Model: Virtual Floppy   Rev: 0323
  Type:   Direct-Access                    ANSI  SCSI revision: 00

тут два массива - пятый рейд на 12 дисков плюс первый на два

Но, тем не менее - оно работало и проблем не доставляло. Более того, мне каждое утро приходили от сервера отчеты от состоянии дисков (smartctl). Была видна тенденция по битым секторам. По каждому конкретному диску. А если их не видно, то как мониторить их? Очень не хотелось бы оказаться у внезапно "разбитого" диска.

Один раз я момент пропустил, и умерший внезапно (действительно внезапно, несколько месяцев битых секторов было устойчиво полтора десятка, а потом - за день - несколько тыщ) диск поставил колом всю систему. Остановил внезапно, то есть. Но пара движений отверткой и система снова заработала на выжившем диске.

А то, что линукс отходит от dm-raid - как то оно для меня (и для анаконды) внезапно произошло. анаконда сделала стандартную dm-raid'овскую строку загрузчику, и поставила систему именно на dm-raid. А вот dracut эту стандартную запись понимать отказался.

Посмотрел спецификации на сервера моего уровня - действительно, на подавляющем большинстве таких серверов intel ставит софтовый RAID 0-1-10.   

Ладно, сейчас работает на серверах CentOS 6.3. Он про такую беду не знает и эти софтовые диски поддерживает как RAID. А поскольку 6-той центос (как я понимаю) будет поддерживаться года так до 2017-го, то эти сервера к тому сроку станут совсем "дряхлыми" и будут с ним и списаны.
Ну, или напрягу фирму на модернизацию серверов. На покупку честных RAID-контороллеров. Если слишком сильно будет дисковый канал тормозить. А пока этого (на моих объемах данных и на имеющейся загрузке серверов) нет.