<p dir="ltr">а) удалите multipath, если не используете.<br>
б) рассмотрите современные варианты. Например lvm сам умеет raid, mdadm не нужен. Так же raid умеет btrfs. </p>
<p dir="ltr">9 июля 2015 г. 19:59 пользователь "Gleb Kulikov" <<a href="mailto:glebus@asd.iao.ru">glebus@asd.iao.ru</a>> написал:<br>
><br>
><br>
> Столкнулся сегодня при настройке новой (наконец-то! :) ) рабочей машины.<br>
><br>
> С последнего образа была установлена система (вариант KDE4) и сразу-же<br>
> обновлена до сегодняшнего Сизифа.<br>
><br>
> Мат плата Gigabyte Technology Co., Ltd. Z87X-UD5H/Z87X-UD5H-CF, BIOS F9<br>
> 03/18/2014<br>
><br>
><br>
> Было установлено 3 винчестера, все по 3Tb:<br>
> 1-ин HGST HDN724030ALE640<br>
> и 2-а WD RED (WDC WD30EFRX-68EUZN0)<br>
><br>
> Каких - либо сложностей с установкой не было, за исключением бага с<br>
> intel_iommu=off (на момент установки, я об этом баге не знал, об этом позже)<br>
><br>
> По-видимому, важно, что на 1-ом диске выделены разделы под /boot, / и LVM;<br>
> /usr и /var находятся на LVM-томах.<br>
><br>
> Файловая система на /boot = ext2, на / = ext4, на остальных, по большей части,<br>
> XFS.<br>
><br>
> В момент установки система не "увидела" дисков WD Red (подключенных ко второму<br>
> чипу SATA), поэтому средствами инсталлятора на них ничего не создавалось.<br>
><br>
> После установки и гугленья стало понятно, что диски не подцепляются из-за<br>
> багов с ПДП. После передачи параметра intel_iommu=off, всё стало хорошо.<br>
><br>
> Первый звоночек раздался при попытке организовать рэйд-1 (средствами mdraid)<br>
> на дисках WD: мол, дивайсы заняты, идите лесом.<br>
> После выполнения dmsetup remove_all, mdadm --create благополучно отработал.<br>
><br>
> На полученном raid-1 массиве был сделан LVM раздел и созданы LVM тома.<br>
><br>
> Второй звоночек прогремел, когда я попытался включить (/etc/fstab)<br>
> автопроверку прнимонтированных разделов ( параметры ... 1 2). С некоторой<br>
> вероятностью (> 1/2), systemd НЕ МОГ подмонтировать некоторые из указанных<br>
> разделов (в основном, но не обязательно, лежащих на LVM//RAID). Загрузка<br>
> системы останавливалась на поднятии сетевого стека (и больше ничего<br>
> работающего, хотя на несмонтированных раздеах ещё вообще ничего не было, это<br>
> не камешек, а просто скала в огород Поттеринга и Ко!).<br>
><br>
> Параметр nofail беде никак не помог, опыт показал, что скорее наоборот:<br>
> ситуация усугубляется.<br>
><br>
> Что к чему, я ещё не понял и попробовал извернуться, добавив параметры x-<br>
> systemd.automount,noauto и отключив автопроверку (... 0 0). Это помогло... На<br>
> некоторое время.<br>
><br>
> Подошёл черёд переносить данные. Подключил первый диск (ST3500320AS), худо-<br>
> бедно, всё отработало нормально, данные перенёс.<br>
><br>
> Вот тут внимание: при подключении "нового-старого" диска, он "сел" на<br>
> /dev/sda, на котором до того "висел" системный винчестер.<br>
><br>
> Заменил диск с данными на второй аналогичный ST3500320AS, и опс! Система не<br>
> грузится с теми-же симптомами. Помогло systemd.automount,noauto второму LVM<br>
> разделу.<br>
><br>
> Смонтировать диск НЕ ПОЛУЧИЛОСЬ: устройства заняты. Это уже сирена, но времени<br>
> нет, плюнул, загрузился с флешки и в режиму live-cd прекрасно перенёс данные.<br>
><br>
> Подключаю третий диск. Всё. Теперь система не грузится никак и ни в какой<br>
> позе. Только после отключения автопроверок везде, где можно, система<br>
> загрузилась.<br>
><br>
> Вот тут только, как скачущий "небрат", я "стал что-то подозревать".<br>
><br>
> dmsetup info показал, что вновь подключаемые диски, находятся в multipath со<br>
> штатными. Даже запись в /etc/multipath/wwids создалась. Это при том, что<br>
> /etc/multipath.conf вообще, чистый.<br>
><br>
> Эксперимент показал, что любые подключаемые диски, садящиеся на /dev/sda, sdb,<br>
> оказываются в multipath со штатными. Совершенно бессистемным образом.<br>
> То, что данные, НА ПЕРВЫЙ ВЗГЛЯД, не пострадали, считаю чистым везением.<br>
><br>
> Опять-же, прямой эксперимент показал, что после долгих и вдумчевых скачек с<br>
> dmsetup remove, вновь подключаемые диски нормально монтируются.<br>
><br>
> СЛОВ НЕТ.<br>
><br>
> Что это было? Кто виноват и главное, ЧТО ДЕЛАТЬ?<br>
><br>
> Понятно, что эксплуатация системы, обладающей такой могучей интуицией, это<br>
> хуже, чем прогулка по минному полю. Надо понимать, что с eSata и прочими<br>
> "горячими штучками", при таком раскладе, можно проститься навсегда?<br>
><br>
> PS: systemd-221-alt4<br>
><br>
> --<br>
> Салют, /GLeb<br>
><br>
> UIN: 15341920<br>
> jabber://<a href="mailto:gleb@asd.iao.ru">gleb@asd.iao.ru</a><br>
> sip://<a href="mailto:2387245@sipnet.ru">2387245@sipnet.ru</a> (telephony)<br>
> skype://gleb_kulikov.tomsk (telephony)<br>
><br>
> _______________________________________________<br>
> Sisyphus mailing list<br>
> <a href="mailto:Sisyphus@lists.altlinux.org">Sisyphus@lists.altlinux.org</a><br>
> <a href="https://lists.altlinux.org/mailman/listinfo/sisyphus">https://lists.altlinux.org/mailman/listinfo/sisyphus</a></p>