Software RAID1 becomes as md125, md126 after system update....?

после того, как обновил mdadm.conf - не забудь обновить initramfs

я на той машине не использую initramfs.

Зачем люди пишут заголовки тем на языке, которым не владеют?

[ 3.933812] md: sdb3 has different UUID to sdb4
[ 3.933943] md: sdb2 has different UUID to sdb4
[ 3.934078] md: sdb1 has different UUID to sdb4

Что-то ты не договариваешь.

ну ты молодец! отличный каммент! я и русским не владею - так что, на родном тут писать, чтоли? Так моим родным тут никто, сдаётся мне, не владеет.... вобщем - если по теме нечего сказать, неумничай уже, чтоли....:D

Что-то ты не договариваешь.

да нет, всё честно. сей момент меня самого смутил, но изменял перед выкладываением на сайт только т хостнейм в оутпуте uname UUIDкоторые прописал в mdadm.conf, и которые выдаёт

mdadm -Es - каждый сам могет сравнить. вроде совпадает. при этом первые два монтируются, и с ююид там вроде как всё ок, а мд3 \ 4 - нет? как такое может быть-то? %-О

Ежели поменять последнюю пару строк на

ARRAY /dev/md3 metadata=0.90 UUID=f0bc71fc:8467ef54:208cdb8d:9e23b04b name=3
ARRAY /dev/md4 metadata=0.90 UUID=3f4daae2:cbf37a2a:208cdb8d:9e23b04b name=4

сэнкс, вечером, как буду дома - попробую и отпишусь.

Хотя, name — это из 1.2, скорее просто не соберётся.

Имя хоста не могло поменяться? оно для 0.9 в UUID кодировано.
mdadm -D /dev/md124 | grep UUID
mdadm -D /dev/md125 | grep UUID
совпадает?

На generic и initrd не желаете переехать?

в смысле -нэйм тока в 1.2 работает?

читал сей мегаопус: https://bugzilla.redhat.com/show_bug.cgi?id=606481

там про такое не упомянуто. имя хоста не менялось, более того - весь райд собирался в одно время, если бы какие общие косяки - то и мд1 и мд2 не должны были бы собиратся. это меня более всего удивляет - аррэи одинаковые, но половина из них переходят в мд1 \ мд2 и соу, а вторая половина - хрен.

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

и- главное - раньше ж работало совершенно без проблем! и даже после апдейта ядра ( которое вышло в связи с дирти коу апдейтом) - всё вроде отработало нормально... а сапгрейдился через слакпкг на 14.2 - и нате вам - получите ваще куй....

при этом сначала у мну и в лило чтото до конца не отработалось - ядро до конца не загружалось, и по причине всех этих мд126 я и загрузившись с лайвсиди немог лилу апдейтнуть, ибо там как рут мд1 прописана. дошёл до сего, и щас просто низхера непонять - почему половина работает, а половина - нет? если б ничего нераьотало, было бы понятнее....логичнее.

name есть начиная с метаданных версии 1, так что и пробовать не стоит.

Если дописать в начало mdadm.conf
HOMEHOST drago
или
HOMEHOST <ignore>
что-то изменится?

Может оказаться, что на момент сборки 125, 124 хостнейм ещё не был установлен и не совпал с кодированным в UUID, а вторая пара собрана чуть позже и хостнейм уже совпал...

На правах бреда.

А монтирование разделов по UUID сделано или /dev/md*?

Homehost drago

делал, потом убрал. без изменений. кстати, когда делал райд, помню, сначала сделал на 1.2 версии ( дефолтной), но чтото там было, что делало невозможным загружатся с такого райда...?

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

кстати, а как можно посмотреть, какой хост в аррэе прописан?

монтирование по /dev/md в фстабе.

как можно посмотреть, какой хост в аррэе прописан?

Выше показывал, mdadm -D массив даст подробные сведения о массиве, в строке с UUID будет и имя хоста.

Переходите на generic+initrd, это проще всего.

так а энто вывод с mdadm -Db :

ARRAY /dev/md1 metadata=0.90 UUID=7cc47bea:832f8260:208cdb8d:9e23b04b
ARRAY /dev/md2 metadata=0.90 UUID=cce81d3a:78965aa5:208cdb8d:9e23b04b
ARRAY /dev/md3 metadata=0.90 UUID=f0bc71fc:8467ef54:208cdb8d:9e23b04b
ARRAY /dev/md4 metadata=0.90 UUID=3f4daae2:cbf37a2a:208cdb8d:9e23b04b

получается, хостнейм в моих арреях не содержится? он, так же как и нэйм, только с версий 1.х есть? :-О

Без «b» что выводит-то?

этак вы мне предложите и на systemd тож перейти, чтобы «проще».... я хочу рпазобратся с текущей ситуацией, и я уверен, что нормальный линукс должен работать с райдами и без инитрамов - и раньше я воочию наблюдал, что это работает. если всё это напрочь поломали, то это ещё одна причина переползать на макось, имхо... но я таки сперва попытаюсь поборотся...:)

ПС. что без «б» выводит - опять же гляну вечером, и отпишусь :) сэнкс за помошь!

Вы просто подумайте, на какой стадии идёт автосборка рейда при вкомпилированном модуле md (до монтирования корня) и доступен ли на тот момент /etc/mdadm.conf (конечно нет)... Ядру доступна толко информация из метаданных. Это потом можно не-корневые разделы переподключить. А вот с некорневых метку автосборки стоило бы снять, если это возможно. Остальное цеплять mdadm-ом по конфигу.

С инитрд будет mdadm-ом по конфигу.

так....это понятно, что автосборка идёт перед тем, как будет виден конфигфайл мдадмовский - но ведь раньше работало всё энто? и даже сейчас как-то, почему-то работает, но что удивительно - только наполовину.

третий и четвёртый мд у меня отображается как 125-ый и 124-ый - а это значит, что с самого начала мд1 был 127, и мд2 - 126, или наоборот - не суть важно - поскольку, если рэйд не дефинирован, и собирается ядром «сдуру», нумерация идёт от числа 127 и вниз. при этом к моменту когда ядро должно монтировать корень - мд1 и мд2 были уже на «правильной цифре», а вот мд3 и 4 почему-то так и остались, «неправильными»...почему? непонятно совершенно...

кстати, как можно снять метку автосборки для конкретных разделов?

то что с инитом он сразу с самого старта будет иметь мдадм конф и должен при этом правильно массивы нумеровать - это понятно....

и почему и что там с версией 1.2 - почему на ей загрузочный том нельзя делать?

побольше бы информации о этом тёмном и дивном звере, глядишь, и получится чтото понять....

ПС и чего это «Ви, Ми»....? я чем-то обидел? или мы все когда-то в фидо не состояли, ась? :)

вспомнил - у мну ж на работе тоже «райд». 14.2 нативно.

bash-4.3# mdadm -D /dev/md1
/dev/md1:
        Version : 0.90
  Creation Time : Mon Jul 25 15:39:00 2016
     Raid Level : raid1
     Array Size : 8388544 (8.00 GiB 8.59 GB)
  Used Dev Size : 8388544 (8.00 GiB 8.59 GB)
   Raid Devices : 2
  Total Devices : 1
Preferred Minor : 1
    Persistence : Superblock is persistent

    Update Time : Mon Jul 25 15:39:00 2016
          State : clean, degraded 
 Active Devices : 1
Working Devices : 1
 Failed Devices : 0
  Spare Devices : 0

           UUID : 7d7a25c8:25544be5:208cdb8d:9e23b04b
         Events : 0.1

    Number   Major   Minor   RaidDevice State
       0       8        2        0      active sync   /dev/sda2
       2       0        0        2      removed
bash-4.3# 

дома, значт,с : HOMEHOST <ignore>

поэеспериментирую, но не думаю, что оно чтото даст. других идей, в каком направлении копать - ни у кого нет?

как я и подозревал, homehost ignore ничего не меняет. кстати, команда mdadm -E -s должна давать реальное состояние райда - тоесть собранные массивы? дело в том, что её вывод у меня в ходе копаний с райдами, их остановке, и сбора посредством mdadm -As - не соответсвует действительному положению дел. т е mdadm -E -s показывает мне что есть /dev/md124, например, но при попытке mdadm -D /dev/md124 я получаю сообщение, что

mdadm: cannot open /dev/md124 - no such file or directory!

эт как такое вообще возможно?

Поставил Slackware64-14.1 в VirtualBox на 4 md RAID1:

# for p in 1 2 3 4; do mdadm --create /dev/md$p --name=$p --level=1 --raid-devices 2 /dev/sda$p /dev/sdb$p --metadata=0.90; done

я свой без нейма строил - эт я точно помню. остальное - вроде как также. почитал сегодня ещё чутка документации, попробовал также смонтировать интереса ради хоум ( который у меня должен бы быть мд3) в фстабе через UUID.

UUID взял из вывода mdadm -E -s. так вот - этот UUID не тот же, что можно увидеть в /dev/disk/by-uuid/

!

соответсвенно, нифига после рестарта не смонтровалось.

ну что - глянул я что за UUID в /dev/disk/by-uuid/ соотвествует моей партиции / аррэю, прописал этим ууид в фстабе.

мд4 в фстабе оставил как есть, для контроля.

перезагрузился. да, мд3 и 4 как обычно - отсутсвуют, но тот раздел, что должен быть мд3 ( а есть - мд125), по ууид в фстабе подмонтировался, тоесть такой воркароунд вроде как работает, если что.

также узрел, что в /dev/disk/by-uuid/ эти ююид стоят как симлинки - то есть в мс на них курсор наводишь - видно на какой md номер они идут. и информация сия -актуальна, в отличии он того, что каждый раз выдаёт mdadm -E -s ! полез дальше поигратся - перед загрузкой ядра указал опцию не монтировать райд автоматом:

raid=noautodetect

raid=noautodetect md=1,/dev/sda1,dev/sdb1

тоесть райд первого уровня состоящий из соотвествующих партиций.

всё загрузилось, все райд-девайсы правильно названы - md1, md2, md3, md4, md4 через фстаб также смонтировался нормально.

но - всётаки я хочу понять, почему без всех этих допопций райд первый и второй массивы называет правильно автодетектом, а третий и четвёртый - хрен....

осення подозрительно всё энто....:)

Виноваты метаданные?
На худой конец, можно и по исходникам попробовать понять, что не срастается. Но пока лучше по документации предпринять, что возможно.

С initrd всё будет проще, зачем упорствовать?

Только что рестартанул всё это дело. кернелу ничего дополнительно не указывал, то есть ситуация должна была быть такая, как перед экспериментами с указыванием опций ядру.

и что вы думаете? да, она таки не такая же. мне линукс начинает напоминать винду с её анекдотичными «выйдите из машины, и зайдите снова, возможно теперь она заведётся!».

итого - щас всё собралось как надо - md1, md2 (это ожидалось) md3, md4 ( а вот этого не должно было быть! ). почему так? есть подозрение что система чтото пишет в суперблоки устройства - какой то преферред номер? который пишется только если массив смонтирован «правильно» при старте?

это всё - мои догадки на основе того, как система в ходе попытки решения проблемы себя вела.... есть какие мысли, что и как тут можно бы проверить, дабы наконец то понять - что там и как, и почему?

С initrd всё будет проще, зачем упорствовать?

это не упорствование, это вопрос принципа. система должна подчинятся логике и быть предсказуемой. Винда такой не является, и это одна из причин, почему я от неё ушёл лет десять назад, и крайне рад этому. принцип неопределённости и квантовая механика не должна проявлятся в макромире, и уж тем более в компьютерной системе.

теперь бы ещё понять что и как там с этими метаданными, что это вообще такое, как их можно считать.... :)

что и как там с этими метаданными, что это вообще такое

https://raid.wiki.kernel.org/index.php/RAID_superblock_formats

никакой конкретики, полезной конечному юзеру, который не программист, к сожалению.

а что по формату 1.2 и загрузочному тому можешь сказать?

есть какие советы по загрузочному райду? или как и прежде, загрузочные разделы в версии 0.90 луще делать?

то есть всё живое, но разделы начали обзыватся как md127, md126, md125 md124 вместо md1, md2, md3, md4

это не имеет никакого значения и вообще никого не интересует

загрузочные разделы в версии 0.90 луще делать?

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

Тем не менее,

https://raid.wiki.kernel.org/index.php/RAID_superblock_formats
Current Linux kernels (as of 2.6.28) can only autodetect (based on partition type being set to FD) arrays with superblock version 0.90.
The boot-loader LILO also can only boot from the version 0.90 superblock arrays. Alternative boot loaders, GRUB specifically, probably don't have this particular limitation.

да мне неспешно - просто для того чтобы знать. И большое тебе спасибо за помощь! слака рулит! :)

по «тем не менее» - да, получается что если раздел загрузочный, вариантов кроме 0.90 особо невидно. ну, ничего.... пойду писать хауту, а то и сам через пару недель всю эту эпопею в нюансах забуду....:)

это не имеет никакого значения и вообще никого не интересует

ровно до момента обработки /etc/fstab.
Если некорневые разделы указаны по UUID= или по LABEL= — да, не интересует, если по имени устройства, то «ой».
Корневой раздел ядру по UUID= или по LABEL= может быть указан только при наличии initrd.

Повторюсь, initrd — самый прямой вариант...

Ну если есть идиоты, которые в fstab монтируют по имени устройства, то это сугубо их личные сексуальные проблемы. Если уж на то пошло, то просто одиночные диски при каждой загрузке имеют рандомные имена. Если их несколько. Давно уже. Не имеет значения. С разморозкой, в общем.

Как там райд ядро собирает, по мажор-минорам али по UUID? мне сейчас негде посмотреть.

initrd решает часть таких задач где конфигурацию нельзя передать в виде параметров ядру.

Проблема в том, что ядро не знает про твой mdadm.conf - оно еще не смонтировало корень. Это как раз такой случай.

Есть подозрение, что очередность нахождения дисков (порядок инициализация драйверов в ядре) влияет на «искуственный» интелект raid autodetect.

С другой стороны привязка к именам устройтв - прошлый век :)

fstab по меткам или по UUID.

С другой стороны привязка к именам устройтв - прошлый век :)

Не всегда. Точнее так, иногда бывает удобнее использовать имя а не UUID.

Есть подозрение, что очередность нахождения дисков (порядок инициализация драйверов в ядре) влияет на «искуственный» интелект raid autodetect.

не вписывается в логику. порядок инициации драйверов в ядре не мог поменятся от того, что я один раз загрузился с кернел параметром «noautodetect». а вот поведение сборки райда после этого поменялась - автосборкой третый и четвёртый массив стал собиратся как третия и четвёртый, вместо 124-го и 125-го, как перед этим.... мне думается, там чтото в суперблоках прописывается на ходу...

[ 0.316910] ata7: PATA max UDMA/100 cmd 0x2018 ctl 0x2024 bmdma 0x2000 irq 17
[ 0.318177] ata9: PATA max PIO4 cmd 0x1f0 ctl 0x3f6 irq 14
[ 3.335294] ata10: PATA max PIO4 cmd 0x170 ctl 0x376 irq 15

Где 3 секунды ? Что оно там искало ?

На порядок обнаружения дисков может влиять CONFIG_SCSI_SCAN_ASYNC

Нужно гарантировать сбор райда с rootfs, а потом оттуда с mdadm.conf собирать все остально.

А почему тебе не пофиг, как называется устройство?

это вывод дмесга через grep md возможно в промежутке ядро чем то другим занималось....