LINUX.ORG.RU

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

 


0

2

Приветствую! Вот, вкратце -после апдейта системы с 14.1 на 14.2 слаквари настала жопа софтверному райду на двух нжмд - то есть всё живое, но разделы начали обзыватся как md127, md126, md125 md124 вместо md1, md2, md3, md4. поскольку мд1 - это рут вместе с бутом, мд2- свап, а мд3 - хоум, то естественно всё перестало работать и даже загружатся. изначально в системе mdadm.conf ,то есть, всё в ём закомменчено. инитрамфс не использовалось. изначально стояла слака 14.1, сначала сделал апдейт её - поставилось новое ядро. после рестарта было всё ок. после апдейта на 14.2 - уже нет.

сделал mdadm.conf:

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
- после загрузки системы обнаружил, что md1 & md2 ( рут и свап) - всё ок, как и должно быть, а вот вместо md3 ( /home) & md4 (/Second) - md124 & md125 !!! как так-то???

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

df -h :

Filesystem Size Used Avail Use% Mounted on
/dev/root 99G 85G 9.3G 91% /
devtmpfs 3.8G 0 3.8G 0% /dev
tmpfs 3.8G 1008K 3.8G 1% /run
tmpfs 3.8G 0 3.8G 0% /dev/shm
cgroup_root 3.8G 0 3.8G 0% /sys/fs/cgroup
cgmfs 100K 0 100K 0% /run/cgmanager/fs
mount :
/dev/md1 on / type ext4 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
tmpfs on /dev/shm type tmpfs (rw)
dmesg | grep md :
[ 0.215951] amd_nb: Cannot enumerate AMD northbridges
[ 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.494385] md: linear personality registered for level -1
[ 3.494518] md: raid0 personality registered for level 0
[ 3.494649] md: raid1 personality registered for level 1
[ 3.494781] md: raid10 personality registered for level 10
[ 3.494956] md: raid6 personality registered for level 6
[ 3.495092] md: raid5 personality registered for level 5
[ 3.495223] md: raid4 personality registered for level 4
[ 3.495355] md: multipath personality registered for level -4
[ 3.825256] md: Waiting for all devices to be available before autodetect
[ 3.825390] md: If you don't use raid, use raid=noautodetect
[ 3.825718] md: Autodetecting RAID arrays.
[ 3.933280] md: Scanned 8 and added 8 devices.
[ 3.933422] md: autorun ...
[ 3.933550] md: considering sdb4 ...
[ 3.933683] md: adding sdb4 ...
[ 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
[ 3.934211] md: adding sda4 ...
[ 3.934340] md: sda3 has different UUID to sdb4
[ 3.934471] md: sda2 has different UUID to sdb4
[ 3.934602] md: sda1 has different UUID to sdb4
[ 3.934910] md: created md125
[ 3.935045] md: bind<sda4>
[ 3.935187] md: bind<sdb4>
[ 3.935327] md: running: <sdb4><sda4>
[ 3.935667] md/raid1:md125: active with 2 out of 2 mirrors
[ 3.935830] md125: detected capacity change from 0 to 514872442880
[ 3.935971] md: considering sdb3 ...
[ 3.936107] md: adding sdb3 ...
[ 3.936237] md: sdb2 has different UUID to sdb3
[ 3.936368] md: sdb1 has different UUID to sdb3
[ 3.936501] md: adding sda3 ...
[ 3.936630] md: sda2 has different UUID to sdb3
[ 3.936761] md: sda1 has different UUID to sdb3
[ 3.937055] md: created md124
[ 3.937183] md: bind<sda3>
[ 3.937323] md: bind<sdb3>
[ 3.937464] md: running: <sdb3><sda3>
[ 3.937787] md/raid1:md124: active with 2 out of 2 mirrors
[ 3.937941] md124: detected capacity change from 0 to 375809572864
[ 3.938087] md: considering sdb2 ...
[ 3.938219] md: adding sdb2 ...
[ 3.938349] md: sdb1 has different UUID to sdb2
[ 3.938481] md: adding sda2 ...
[ 3.938610] md: sda1 has different UUID to sdb2
[ 3.938902] md: created md2
[ 3.939035] md: bind<sda2>
[ 3.939176] md: bind<sdb2>
[ 3.939317] md: running: <sdb2><sda2>
[ 3.939646] md/raid1:md2: active with 2 out of 2 mirrors
[ 3.939799] md2: detected capacity change from 0 to 2147418112
[ 3.939938] md: considering sdb1 ...
[ 3.940076] md: adding sdb1 ...
[ 3.940207] md: adding sda1 ...
[ 3.940495] md: created md1
[ 3.940624] md: bind<sda1>
[ 3.940765] md: bind<sdb1>
[ 3.940905] md: running: <sdb1><sda1>
[ 3.941233] md/raid1:md1: active with 2 out of 2 mirrors
[ 3.941388] md1: detected capacity change from 0 to 107374116864
[ 3.941526] md: ... autorun DONE.
[ 3.943359] EXT4-fs (md1): couldn't mount as ext3 due to feature incompatibilities
[ 3.985138] EXT4-fs (md1): mounted filesystem with ordered data mode. Opts: (null)
[ 9.235215] Adding 2097084k swap on /dev/md2. Priority:-1 extents:1 across:2097084k
[ 9.998237] EXT4-fs (md1): re-mounted. Opts: (null)
[ 105.253940] md124: detected capacity change from 375809572864 to 0
[ 105.253950] md: md124 stopped.
[ 105.253959] md: unbind<sdb3>
[ 105.258033] md: export_rdev(sdb3)
[ 105.258083] md: unbind<sda3>
[ 105.262015] md: export_rdev(sda3)
[ 107.749713] md125: detected capacity change from 514872442880 to 0
[ 107.749723] md: md125 stopped.
[ 107.749733] md: unbind<sdb4>
[ 107.754051] md: export_rdev(sdb4)
[ 107.754084] md: unbind<sda4>
[ 107.759025] md: export_rdev(sda4)
[ 114.843287] md: md3 stopped.
[ 114.844140] md: bind<sdb3>
[ 114.844329] md: bind<sda3>
[ 114.850069] md/raid1:md3: active with 2 out of 2 mirrors
[ 114.850109] md3: detected capacity change from 0 to 375809572864
[ 114.910224] md: md4 stopped.
[ 114.911789] md: bind<sdb4>
[ 114.911992] md: bind<sda4>
[ 114.923705] md/raid1:md4: active with 2 out of 2 mirrors
[ 114.923745] md4: detected capacity change from 0 to 514872442880
uname -a :

Linux drago 4.4.29 #2 SMP Mon Oct 31 15:02:12 CDT 2016 x86_64 Intel(R) Core(TM)2 Duo CPU E4500 @ 2.20GHz GenuineIntel GNU/Linux drago.domain.com

mdadm -Es:

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

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

ponch ()

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

anonymous ()
[ 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

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

Radjah ★★★★★ ()
Ответ на: комментарий от anonymous

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

wisedraco ★★ ()
Ответ на: комментарий от Radjah

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

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

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

wisedraco ★★ ()

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

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
изменится что-либо?

bormant ★★★★★ ()
Ответ на: комментарий от wisedraco

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

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

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

bormant ★★★★★ ()
Последнее исправление: bormant (всего исправлений: 1)
Ответ на: комментарий от bormant

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

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

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

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

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

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

wisedraco ★★ ()
Ответ на: комментарий от wisedraco

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

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

bormant ★★★★★ ()
Последнее исправление: bormant (всего исправлений: 1)
Ответ на: комментарий от wisedraco

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

bormant ★★★★★ ()

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

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

Radjah ★★★★★ ()
Последнее исправление: Radjah (всего исправлений: 1)
Ответ на: комментарий от bormant

Homehost drago

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

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

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

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

wisedraco ★★ ()
Ответ на: комментарий от wisedraco

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

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

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

bormant ★★★★★ ()
Последнее исправление: bormant (всего исправлений: 1)
Ответ на: комментарий от bormant

так а энто вывод с 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.х есть? :-О

wisedraco ★★ ()
Ответ на: комментарий от bormant

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

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

wisedraco ★★ ()
Ответ на: комментарий от wisedraco

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

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

bormant ★★★★★ ()
Последнее исправление: bormant (всего исправлений: 1)
Ответ на: комментарий от bormant

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

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

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

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

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

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

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

wisedraco ★★ ()
Последнее исправление: wisedraco (всего исправлений: 1)
Ответ на: комментарий от wisedraco

вспомнил - у мну ж на работе тоже «райд». 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>

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

wisedraco ★★ ()
Ответ на: комментарий от wisedraco

как я и подозревал, 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!

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

wisedraco ★★ ()
Ответ на: комментарий от wisedraco

Поставил 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

Обновил до 14.2 по UPGRADE.TXT и CHANGES_AND_HINTS.TXT, RAID остался на месте...

Надо думать.

bormant ★★★★★ ()
Ответ на: комментарий от bormant

я свой без нейма строил - эт я точно помню. остальное - вроде как также. почитал сегодня ещё чутка документации, попробовал также смонтировать интереса ради хоум ( который у меня должен бы быть мд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 через фстаб также смонтировался нормально.

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

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

wisedraco ★★ ()
Ответ на: комментарий от wisedraco

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

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

bormant ★★★★★ ()
Последнее исправление: bormant (всего исправлений: 1)
Ответ на: комментарий от wisedraco

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

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

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

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

wisedraco ★★ ()
Ответ на: комментарий от bormant

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

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

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

wisedraco ★★ ()
Ответ на: комментарий от bormant

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

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

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

wisedraco ★★ ()

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

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

targitaj ★★★★★ ()
Ответ на: комментарий от wisedraco

загрузочные разделы в версии 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.

bormant ★★★★★ ()
Ответ на: комментарий от bormant

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

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

wisedraco ★★ ()
Ответ на: комментарий от targitaj

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

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

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

bormant ★★★★★ ()
Последнее исправление: bormant (всего исправлений: 1)
Ответ на: комментарий от bormant

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

targitaj ★★★★★ ()
Ответ на: комментарий от targitaj

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

bormant ★★★★★ ()
Последнее исправление: bormant (всего исправлений: 1)
Ответ на: комментарий от wisedraco

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

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

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

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

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

vel ★★★★★ ()
Ответ на: комментарий от vel

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

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

anc ★★★★★ ()
Ответ на: комментарий от vel

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

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

wisedraco ★★ ()
Ответ на: комментарий от wisedraco
[ 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 собирать все остально.

vel ★★★★★ ()

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

thesis ★★★★★ ()
Ответ на: комментарий от vel

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

wisedraco ★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.