[sisyphus] ОСТОРОЖНО! Противоестественный интеллект (systemd?) и эпичнейший баг

[Gleb Kulikov <glebus@asd.iao.ru>]

Столкнулся сегодня при настройке новой (наконец-то! :) ) рабочей машины.

С последнего образа была установлена система (вариант KDE4) и сразу-же 
обновлена до сегодняшнего Сизифа.

Мат плата Gigabyte Technology Co., Ltd. Z87X-UD5H/Z87X-UD5H-CF, BIOS F9 
03/18/2014


Было установлено 3 винчестера, все по 3Tb:
	1-ин  HGST HDN724030ALE640
	и 2-а WD RED (WDC WD30EFRX-68EUZN0)

Каких - либо сложностей с установкой не было, за исключением бага с 
intel_iommu=off (на момент установки, я об этом баге не знал, об этом позже)

По-видимому, важно, что на 1-ом диске выделены разделы под /boot, / и LVM; 
/usr и /var находятся на LVM-томах.

Файловая система на /boot = ext2, на / = ext4, на остальных, по большей части, 
XFS.

В момент установки система не "увидела" дисков WD Red (подключенных ко второму 
чипу SATA), поэтому средствами инсталлятора на них ничего не создавалось.

После установки и гугленья стало понятно, что диски не подцепляются из-за 
багов с ПДП. После передачи параметра intel_iommu=off, всё стало хорошо.

Первый звоночек раздался при попытке организовать рэйд-1 (средствами mdraid) 
на дисках WD: мол, дивайсы заняты, идите лесом.
После выполнения dmsetup remove_all, mdadm --create благополучно отработал.

На полученном raid-1 массиве был сделан LVM раздел и созданы LVM тома.

Второй звоночек прогремел, когда я попытался включить (/etc/fstab) 
автопроверку прнимонтированных разделов ( параметры ... 1 2). С некоторой 
вероятностью (> 1/2), systemd НЕ МОГ подмонтировать некоторые из указанных 
разделов (в основном, но не обязательно, лежащих на LVM//RAID). Загрузка 
системы останавливалась на поднятии сетевого стека (и больше ничего 
работающего, хотя на несмонтированных раздеах ещё вообще ничего не было, это 
не камешек, а просто скала в огород Поттеринга и Ко!).

Параметр nofail беде никак не помог, опыт показал, что скорее наоборот: 
ситуация усугубляется.

Что к чему, я ещё не понял и попробовал извернуться, добавив параметры  x-
systemd.automount,noauto и отключив автопроверку (... 0 0). Это помогло... На 
некоторое время.

Подошёл черёд переносить данные. Подключил первый диск (ST3500320AS), худо-
бедно, всё отработало нормально, данные перенёс.

Вот тут внимание: при подключении "нового-старого" диска, он "сел" на 
/dev/sda, на котором до того "висел" системный винчестер.

Заменил диск с данными на второй аналогичный ST3500320AS, и опс! Система не 
грузится с теми-же симптомами. Помогло systemd.automount,noauto второму LVM 
разделу.

Смонтировать диск НЕ ПОЛУЧИЛОСЬ: устройства заняты. Это уже сирена, но времени 
нет, плюнул, загрузился с флешки и в режиму live-cd прекрасно перенёс данные.

Подключаю третий диск. Всё. Теперь система не грузится никак и ни в какой 
позе. Только после отключения автопроверок везде, где можно, система 
загрузилась.

Вот тут только, как скачущий "небрат", я "стал что-то подозревать".

dmsetup info показал, что вновь подключаемые диски, находятся в multipath со 
штатными. Даже запись в /etc/multipath/wwids создалась. Это при том, что 
/etc/multipath.conf вообще, чистый.

Эксперимент показал, что любые подключаемые диски, садящиеся на /dev/sda, sdb, 
оказываются в multipath со штатными. Совершенно бессистемным образом.
То, что данные, НА ПЕРВЫЙ ВЗГЛЯД, не пострадали, считаю чистым везением.

Опять-же, прямой эксперимент показал, что после долгих и вдумчевых скачек с 
dmsetup remove, вновь подключаемые диски нормально монтируются.

СЛОВ НЕТ.

Что это было? Кто виноват и главное, ЧТО ДЕЛАТЬ?

Понятно, что эксплуатация системы, обладающей  такой могучей интуицией, это 
хуже, чем прогулка по минному полю. Надо понимать, что с eSata и прочими 
"горячими штучками", при таком раскладе, можно проститься навсегда?

PS: systemd-221-alt4

-- 
      Салют, /GLeb

UIN: 15341920
jabber://gleb@asd.iao.ru
sip://2387245@sipnet.ru			(telephony)
skype://gleb_kulikov.tomsk		(telephony)