[sisyphus] ОСТОРОЖНО! Противоестественный интеллект (systemd?) и эпичнейший баг
Gleb Kulikov
glebus на asd.iao.ru
Чт Июл 9 19:59:35 MSK 2015
Столкнулся сегодня при настройке новой (наконец-то! :) ) рабочей машины.
С последнего образа была установлена система (вариант 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)
Подробная информация о списке рассылки Sisyphus