* Re: [make-initrd] [degraded md-raid] make-initrd в p9 и в Сизифе
2020-02-17 15:23 ` Alexey Gladkov
@ 2020-02-17 15:28 ` Michael Shigorin
2020-02-18 0:51 ` Leonid Krivoshein
2020-02-17 15:59 ` Leonid Krivoshein
` (2 subsequent siblings)
3 siblings, 1 reply; 21+ messages in thread
From: Michael Shigorin @ 2020-02-17 15:28 UTC (permalink / raw)
To: make-initrd
Cc: Alexey Shabalin, Leonid Krivoshein,
Андрей
Черепанов
On Mon, Feb 17, 2020 at 04:23:13PM +0100, Alexey Gladkov wrote:
> Нужно будет написать тест про degraded raid. Я примерно понимаю
> как это должно выглядеть. А вот с read-auto сложнее. Что это ?
Это делаешь зеркало и выдёргиваешь из него один из дисков
(что выдрав из железки/виртуалки, что сказав нечто вроде
mdadm /dev/md0 --fail /dev/sdb), cat /proc/mdstat и reboot.
--
---- WBR, Michael Shigorin / http://altlinux.org
------ http://opennet.ru / http://anna-news.info
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: [make-initrd] [degraded md-raid] make-initrd в p9 и в Сизифе
2020-02-17 15:28 ` Michael Shigorin
@ 2020-02-18 0:51 ` Leonid Krivoshein
0 siblings, 0 replies; 21+ messages in thread
From: Leonid Krivoshein @ 2020-02-18 0:51 UTC (permalink / raw)
To: make-initrd
17.02.2020 18:28, Michael Shigorin пишет:
> On Mon, Feb 17, 2020 at 04:23:13PM +0100, Alexey Gladkov wrote:
>> Нужно будет написать тест про degraded raid. Я примерно понимаю
>> как это должно выглядеть. А вот с read-auto сложнее. Что это ?
> Это делаешь зеркало и выдёргиваешь из него один из дисков
> (что выдрав из железки/виртуалки, что сказав нечто вроде
> mdadm /dev/md0 --fail /dev/sdb), cat /proc/mdstat и reboot.
>
Первое -- ДА. Второе -- похоже на mdadm -o /dev/md0 , но лишь чуточку
похоже. Руками read-auto вроде как нельзя добиться. Руками получится
состояние read-only. А read-auto делает само ядро в тех случаях, когда
массив не был остановлен при выключении/перезагрузке хоста, но при этом
нет dirty-флага. То есть, это штатная ситуация для корня и свопа на
рейде или LVM поверх рейда, потому что старт-стоповые скрипты обычно не
в состоянии корректно остановить такой рейд. И дефолтые правила udev
должны по идее нормально такой массив собирать при включении, переключая
его обратно в read-write.
P.S.: Мне кажется, можно попробовать добиться состояния read-auto
отправкой "u" > /proc/sysrq-trigger , что собственно и делает наш
инсталлятор с недавних пор, даже если не удастся отмонтировать всё
корректно и остановить raid перед этим.
--
Best regards,
Leonid Krivoshein.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [make-initrd] [degraded md-raid] make-initrd в p9 и в Сизифе
2020-02-17 15:23 ` Alexey Gladkov
2020-02-17 15:28 ` Michael Shigorin
@ 2020-02-17 15:59 ` Leonid Krivoshein
2020-02-17 19:21 ` Leonid Krivoshein
2020-02-27 20:10 ` Alex Gladkov
3 siblings, 0 replies; 21+ messages in thread
From: Leonid Krivoshein @ 2020-02-17 15:59 UTC (permalink / raw)
To: Michael Shigorin, Alexey Shabalin,
Андрей
Черепанов,
make-initrd
17.02.2020 18:23, Alexey Gladkov пишет:
> On Mon, Feb 17, 2020 at 02:27:30PM +0300, Leonid Krivoshein wrote:
>> Привет, Алексей, ещё раз! :-)
>>
>>
>> 17.02.2020 13:42, Alexey Gladkov пишет:
>>> On Sun, Feb 16, 2020 at 08:31:37PM +0300, Leonid Krivoshein wrote:
>>>> Всем привет!
>>>>
>>>>
>>>> На p8 была попытка исправить проблему загрузки с деградированного массива:
>>>>
>>>> http://git.altlinux.org/gears/m/make-initrd.git?p=make-initrd.git;a=commitdiff;h=9f1bee4172c43ae7208855c6cb991e0e415d7f08
>>>>
>>>> В коде исправлялось сразу две проблемных ситуации (inactive и read-auto),
>>>> но, если не ошибаюсь, исправить удалось только одну из них, вторую надо было
>>>> лечить где-то в другом месте. Однако в новом коде такого файла (050-mdstart)
>>>> больше нет, есть только это:
>>>>
>>>> http://git.altlinux.org/gears/m/make-initrd.git?p=make-initrd.git;a=blob;f=features/mdadm/data/lib/uevent/extenders/100-mdstart;h=3df8f9ea40654d2eeb5551ad14f7358834c03396;hb=c52b3398d8547c8d00412c153c0679968af8a58a
>>>>
>>>> Две ситуации исправляются руками тривиально: в случае inactive одного из
>>>> дисков просто mdadn -IRs разово, в случае read-auto (что типично для корня
>>>> или свопа на рейде) -- перевести его обратно в режим чтения/записи командой
>>>> mdadm -w /dev/MDDEV. В старом коде make-initrd была задержка в 1/3 времени
>>>> таймаута, то есть, 1 минута, которая запускает этот траблешуттер, если
>>>> корень не обнаружился. В новом -- я вообще не понимаю, как должно работать,
>>>> но по факту никак не работает. Система не грузится даже с только что
>>>> созданного рейда, который не досинхронизирован до конца. Плюс к тому: shaba@
>>>> что-то говорил, что в новом LVM другой принцип обработки обнаруженных томов
>>>> (это уже про ситуацию, когда LVM поверх MD).
>>>>
>>>> Ещё такой момент: ситуацию хорошо бы исправлять для всех дисков на раннем
>>>> этапе, а не только если корень не нашёлся. Да и неправильно это ждать минуту
>>>> не пойми чего, когда диск который часть рейда или LVM нашёлся, о нём уже всё
>>>> известно. Есть какие-нибудь идеи, камрады?
>>> Вы много написали, но я явно не в контекте. Давайте по порядку.
>>>
>>> Есть features/mdadm/data/lib/uevent/extenders/100-mdstart.
>>>
>>> Он решает проблему и не решает какую проблему ?
>>> Какие ещё проблемы есть ?
>> Не решает ни одну из двух проблем:
> ok. Значит он перестал работать совсем.
Не уверен. У меня пока не получилось воспроизвести то, что получилось в
пятницу. Сейчас шаг за шагом проверяю, тут ещё и в грабе обнаружилась
коряква, просто немного отвлекли...
> Нужно будет написать тест про degraded raid. Я примерно понимаю как это
> должно выглядеть. А вот с read-auto сложнее. Что это ?
После установки машина не грузится, но можно загрузиться в ALT Rescue,
да посмотреть, как это выглядит и починить:
[root@localhost ~]# cat /proc/mdstat
Personalities : [raid1]
md126 : active (auto-read-only) raid1 sdb3[1] sda3[0]
2304755704 blocks super 1.0 [2/2] [UU]
resync=PENDING
md127 : active (auto-read-only) raid1 sdb2[1] sda2[0]
2097088 blocks [2/2] [UU]
unused devices: <none>
[root@localhost ~]# mdadm -w /dev/md127
[root@localhost ~]# mdadm -w /dev/md126
[root@localhost ~]# cat /proc/mdstat
Personalities : [raid1]
md126 : active raid1 sdb3[1] sda3[0]
2304755704 blocks super 1.0 [2/2] [UU]
[>....................] resync = 0.6% (15523904/2304755704)
finish=340.8min speed=111936K/sec
md127 : active raid1 sdb2[1] sda2[0]
2097088 blocks [2/2] [UU]
Вуаля. В данном примере обе проблемы на лицо.
> Можно тебя попросить написать тест (я готов ответить на любые вопросы про
> новые end-to-end тесты) ?
Вот тут я не очень понял, но как воспроизвести, и как починить, точно
могу написать.
>> - не "чинит" MD-устройства в состоянии "read-auto", поэтому после перехода в
>> stage2 корень на RAID нельзя перемонтировать в режим чтения-записи.
>>
>> - по сравнению с make-initrd0.8.x, теперь вообще нельзя загрузиться с
>> MD-RAID, который в состоянии "degraded", хотя для больших дисков это норма
>> сразу после инсталляции -- они просто ещё не успели до-синхронизироваться. В
>> старой версии отрабатывал troubleshutter by mike@, который я перетянул из
>> p7/c7 в p8 и c8/c8.1. Во времена p7 ты утянул этот troubleshutter в
>> тогдашний Сизиф, но видимо теперь оно совсем нерабочее.
>>
>> В идеале решать обе проблемы в новом make-initrd2 для любых обнаруживаемых
>> блочных дисков, а не только для тех, на которых корень, аккуратно пытаться
>> исправить приведёнными командами. Очевидно, обработка должна находиться не
>> здесь, а где-то ещё.
>>
>> Сейчас я воспроизведу на виртуалке и отпишу более детально...
> Было бы здорово, если бы ты выложил это куда-нибудь, чтобы мне можно тоже
> было посмотреть.
Чтобы не успело просинхронизироваться, приходится делать большие
виртуальные диски (>2Tb каждый), такое нет смысла тащить, а доступ к PVE
снаружи у нас, к сожалению, прикрыли.
--
С уважением,
Леонид Кривошеин.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [make-initrd] [degraded md-raid] make-initrd в p9 и в Сизифе
2020-02-17 15:23 ` Alexey Gladkov
2020-02-17 15:28 ` Michael Shigorin
2020-02-17 15:59 ` Leonid Krivoshein
@ 2020-02-17 19:21 ` Leonid Krivoshein
2020-02-27 20:10 ` Alex Gladkov
3 siblings, 1 reply; 21+ messages in thread
From: Leonid Krivoshein @ 2020-02-17 19:21 UTC (permalink / raw)
To: Michael Shigorin, Alexey Shabalin,
Андрей
Черепанов,
make-initrd
17.02.2020 18:23, Alexey Gladkov пишет:
> [...]
> Нужно будет написать тест про degraded raid. Я примерно понимаю как это
> должно выглядеть. А вот с read-auto сложнее. Что это ?
Вот как это выглядит чисто технически:
mdadm --detail /dev/md127
...
State : clean, resyncing (PENDING)
...
cat /sys/block/md127/md/array_state
read-auto
Мне не удалось пока воспроизвести проблему с make-initrd в конфигурации
с RAID+LVM. Зато по ходу нашёл ещё два бага, один с grub и один
alterator-vm. make-initrd в обоих случаях совсем не при делах. Поздно
уже, завтра продолжу...
--
С уважением,
Леонид Кривошеин.
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: [make-initrd] [degraded md-raid] make-initrd в p9 и в Сизифе
2020-02-17 15:23 ` Alexey Gladkov
` (2 preceding siblings ...)
2020-02-17 19:21 ` Leonid Krivoshein
@ 2020-02-27 20:10 ` Alex Gladkov
2020-02-27 20:30 ` Michael A. Kangin
2020-02-27 21:26 ` Leonid Krivoshein
3 siblings, 2 replies; 21+ messages in thread
From: Alex Gladkov @ 2020-02-27 20:10 UTC (permalink / raw)
To: Leonid Krivoshein, Michael Shigorin, Alexey Shabalin,
Андрей
Черепанов,
make-initrd
On Mon, Feb 17, 2020 at 04:23:13PM +0100, Alexey Gladkov wrote:
> On Mon, Feb 17, 2020 at 02:27:30PM +0300, Leonid Krivoshein wrote:
> > Привет, Алексей, ещё раз! :-)
Я попытался исправить проблему с таймаутом при медленной инициализации
дисков [1]. Эта проблема может как-то затрагивает и описанное здесь.
Суть фикса [2] это использовать не фиксированный таймаут для инициализации
рейдовых дисков, а сделать его скользящим. Таймаут отчитывается от
появления последнего raid-member. По умолчанию новый таймаут выставлен в
10 секунд т.е. если через 10 секунд после появления последнего
raid-member есть рейды в состоянии inactive, то выполняется mdadm -IRs.
Также бага [1] открыла ещё одну проблему, которую не очень понятно как
лечить автоматически: если в /etc/mdadm.conf описан не только корень, а
целый букет разных рейдов, то все они попадут в initrd, но при этом initrd
не будет ждать сборки их всех. Пока лучшей идеи, чем указание кастомного
mdadm.conf в такой ситуации у меня нет.
Не могли бы заинтересованные люди потестировать фикс [2] на реальном
железе ? У меня есть возможность протестировать в qemu, что не есть айс в
этой ситуации.
[1] https://bugzilla.altlinux.org/show_bug.cgi?id=37737
[2] http://git.altlinux.org/people/legion/packages/make-initrd.git?p=make-initrd.git;a=shortlog;h=refs/heads/fix-mdadm-timeout
> >
> > 17.02.2020 13:42, Alexey Gladkov пишет:
> > > On Sun, Feb 16, 2020 at 08:31:37PM +0300, Leonid Krivoshein wrote:
> > > > Всем привет!
> > > >
> > > >
> > > > На p8 была попытка исправить проблему загрузки с деградированного массива:
> > > >
> > > > http://git.altlinux.org/gears/m/make-initrd.git?p=make-initrd.git;a=commitdiff;h=9f1bee4172c43ae7208855c6cb991e0e415d7f08
> > > >
> > > > В коде исправлялось сразу две проблемных ситуации (inactive и read-auto),
> > > > но, если не ошибаюсь, исправить удалось только одну из них, вторую надо было
> > > > лечить где-то в другом месте. Однако в новом коде такого файла (050-mdstart)
> > > > больше нет, есть только это:
> > > >
> > > > http://git.altlinux.org/gears/m/make-initrd.git?p=make-initrd.git;a=blob;f=features/mdadm/data/lib/uevent/extenders/100-mdstart;h=3df8f9ea40654d2eeb5551ad14f7358834c03396;hb=c52b3398d8547c8d00412c153c0679968af8a58a
> > > >
> > > > Две ситуации исправляются руками тривиально: в случае inactive одного из
> > > > дисков просто mdadn -IRs разово, в случае read-auto (что типично для корня
> > > > или свопа на рейде) -- перевести его обратно в режим чтения/записи командой
> > > > mdadm -w /dev/MDDEV. В старом коде make-initrd была задержка в 1/3 времени
> > > > таймаута, то есть, 1 минута, которая запускает этот траблешуттер, если
> > > > корень не обнаружился. В новом -- я вообще не понимаю, как должно работать,
> > > > но по факту никак не работает. Система не грузится даже с только что
> > > > созданного рейда, который не досинхронизирован до конца. Плюс к тому: shaba@
> > > > что-то говорил, что в новом LVM другой принцип обработки обнаруженных томов
> > > > (это уже про ситуацию, когда LVM поверх MD).
> > > >
> > > > Ещё такой момент: ситуацию хорошо бы исправлять для всех дисков на раннем
> > > > этапе, а не только если корень не нашёлся. Да и неправильно это ждать минуту
> > > > не пойми чего, когда диск который часть рейда или LVM нашёлся, о нём уже всё
> > > > известно. Есть какие-нибудь идеи, камрады?
> > > Вы много написали, но я явно не в контекте. Давайте по порядку.
> > >
> > > Есть features/mdadm/data/lib/uevent/extenders/100-mdstart.
> > >
> > > Он решает проблему и не решает какую проблему ?
> > > Какие ещё проблемы есть ?
> >
> > Не решает ни одну из двух проблем:
>
> ok. Значит он перестал работать совсем.
>
> Нужно будет написать тест про degraded raid. Я примерно понимаю как это
> должно выглядеть. А вот с read-auto сложнее. Что это ?
>
> Можно тебя попросить написать тест (я готов ответить на любые вопросы про
> новые end-to-end тесты) ?
>
> > - не "чинит" MD-устройства в состоянии "read-auto", поэтому после перехода в
> > stage2 корень на RAID нельзя перемонтировать в режим чтения-записи.
> >
> > - по сравнению с make-initrd0.8.x, теперь вообще нельзя загрузиться с
> > MD-RAID, который в состоянии "degraded", хотя для больших дисков это норма
> > сразу после инсталляции -- они просто ещё не успели до-синхронизироваться. В
> > старой версии отрабатывал troubleshutter by mike@, который я перетянул из
> > p7/c7 в p8 и c8/c8.1. Во времена p7 ты утянул этот troubleshutter в
> > тогдашний Сизиф, но видимо теперь оно совсем нерабочее.
> >
> > В идеале решать обе проблемы в новом make-initrd2 для любых обнаруживаемых
> > блочных дисков, а не только для тех, на которых корень, аккуратно пытаться
> > исправить приведёнными командами. Очевидно, обработка должна находиться не
> > здесь, а где-то ещё.
> >
> > Сейчас я воспроизведу на виртуалке и отпишу более детально...
>
> Было бы здорово, если бы ты выложил это куда-нибудь, чтобы мне можно тоже
> было посмотреть.
>
> --
> Rgrds, legion
>
> _______________________________________________
> Make-initrd mailing list
> Make-initrd@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/make-initrd
--
Rgrds, agladkov
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: [make-initrd] [degraded md-raid] make-initrd в p9 и в Сизифе
2020-02-27 20:10 ` Alex Gladkov
@ 2020-02-27 20:30 ` Michael A. Kangin
2020-02-27 21:35 ` Leonid Krivoshein
` (2 more replies)
2020-02-27 21:26 ` Leonid Krivoshein
1 sibling, 3 replies; 21+ messages in thread
From: Michael A. Kangin @ 2020-02-27 20:30 UTC (permalink / raw)
To: make-initrd
On 2/27/20 9:10 PM, Alex Gladkov wrote:
> Также бага [1] открыла ещё одну проблему, которую не очень понятно как
> лечить автоматически: если в /etc/mdadm.conf описан не только корень, а
> целый букет разных рейдов, то все они попадут в initrd, но при этом initrd
> не будет ждать сборки их всех. Пока лучшей идеи, чем указание кастомного
> mdadm.conf в такой ситуации у меня нет.
не знаю, насколько кривенько, но можно распарсить вывод:
lsblk -psr $(mount |grep ' on / ' |cut -f1 -d' ')
найдя искомое md-устройство, и дальше грепнуть только его из mdadm.conf
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: [make-initrd] [degraded md-raid] make-initrd в p9 и в Сизифе
2020-02-27 20:30 ` Michael A. Kangin
@ 2020-02-27 21:35 ` Leonid Krivoshein
2020-02-27 22:05 ` Alexey Gladkov
2020-03-06 20:32 ` Michael Shigorin
2 siblings, 0 replies; 21+ messages in thread
From: Leonid Krivoshein @ 2020-02-27 21:35 UTC (permalink / raw)
To: make-initrd
27.02.2020 23:30, Michael A. Kangin пишет:
> On 2/27/20 9:10 PM, Alex Gladkov wrote:
>
>> Также бага [1] открыла ещё одну проблему, которую не очень понятно как
>> лечить автоматически: если в /etc/mdadm.conf описан не только корень, а
>> целый букет разных рейдов, то все они попадут в initrd, но при этом
>> initrd
>> не будет ждать сборки их всех. Пока лучшей идеи, чем указание кастомного
>> mdadm.conf в такой ситуации у меня нет.
>
> не знаю, насколько кривенько, но можно распарсить вывод:
> lsblk -psr $(mount |grep ' on / ' |cut -f1 -d' ')
>
> найдя искомое md-устройство, и дальше грепнуть только его из mdadm.conf
>
Мне кажется, все рейды должны быть собраны и починены полностью до
перехода в stage2.
Забыл ещё сказать, что именно перед переходом в stage2, когда они
наконец собрались, можно попробовать полечить состояние read-auto.
--
Best regards,
Leonid Krivoshein.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [make-initrd] [degraded md-raid] make-initrd в p9 и в Сизифе
2020-02-27 20:30 ` Michael A. Kangin
2020-02-27 21:35 ` Leonid Krivoshein
@ 2020-02-27 22:05 ` Alexey Gladkov
2020-02-27 22:12 ` Michael A. Kangin
2020-03-06 20:32 ` Michael Shigorin
2 siblings, 1 reply; 21+ messages in thread
From: Alexey Gladkov @ 2020-02-27 22:05 UTC (permalink / raw)
To: make-initrd
On Thu, Feb 27, 2020 at 09:30:53PM +0100, Michael A. Kangin wrote:
> On 2/27/20 9:10 PM, Alex Gladkov wrote:
>
> > Также бага [1] открыла ещё одну проблему, которую не очень понятно как
> > лечить автоматически: если в /etc/mdadm.conf описан не только корень, а
> > целый букет разных рейдов, то все они попадут в initrd, но при этом initrd
> > не будет ждать сборки их всех. Пока лучшей идеи, чем указание кастомного
> > mdadm.conf в такой ситуации у меня нет.
>
> не знаю, насколько кривенько, но можно распарсить вывод:
> lsblk -psr $(mount |grep ' on / ' |cut -f1 -d' ')
Нет проблем найти имя рутового устройства и определить, что это рейд.
> найдя искомое md-устройство, и дальше грепнуть только его из mdadm.conf
mdadm.conf это не только ARRAY. Есть DEVICE, POLICY и так далее. У меня
нет уверенности, что можно выделить/сгенерировать конфиг mdadm.conf для
рутового устройства.
--
Rgrds, legion
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [make-initrd] [degraded md-raid] make-initrd в p9 и в Сизифе
2020-02-27 22:05 ` Alexey Gladkov
@ 2020-02-27 22:12 ` Michael A. Kangin
2020-02-27 23:34 ` Alexey Gladkov
0 siblings, 1 reply; 21+ messages in thread
From: Michael A. Kangin @ 2020-02-27 22:12 UTC (permalink / raw)
To: make-initrd
On 2/27/20 11:05 PM, Alexey Gladkov wrote:
> Нет проблем найти имя рутового устройства и определить, что это рейд.
рейд на зашифрованном разделе поверх lvm поверх bcache поверх md - норм? ;)
>> найдя искомое md-устройство, и дальше грепнуть только его из mdadm.conf
>
> mdadm.conf это не только ARRAY. Есть DEVICE, POLICY и так далее. У меня
> нет уверенности, что можно выделить/сгенерировать конфиг mdadm.conf для
> рутового устройства.
А будет проблемой, если попадёт лишнее, но кроме ARRAY?
типа,
grep -v "^ARRAY" /etc/mdadm.conf
grep "^ARRAY $MY_MD_DEVICE" /etc/mdadm.conf
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [make-initrd] [degraded md-raid] make-initrd в p9 и в Сизифе
2020-02-27 22:12 ` Michael A. Kangin
@ 2020-02-27 23:34 ` Alexey Gladkov
0 siblings, 0 replies; 21+ messages in thread
From: Alexey Gladkov @ 2020-02-27 23:34 UTC (permalink / raw)
To: make-initrd
On Thu, Feb 27, 2020 at 11:12:28PM +0100, Michael A. Kangin wrote:
> On 2/27/20 11:05 PM, Alexey Gladkov wrote:
>
> > Нет проблем найти имя рутового устройства и определить, что это рейд.
>
> рейд на зашифрованном разделе поверх lvm поверх bcache поверх md - норм? ;)
bcache не поддерживается [1]. А usb->raid->lvm->luks->... да, норм.
Вы, видимо, не знаете как работает make-initrd.
[1] https://bugzilla.altlinux.org/show_bug.cgi?id=29561
> > > найдя искомое md-устройство, и дальше грепнуть только его из mdadm.conf
> >
> > mdadm.conf это не только ARRAY. Есть DEVICE, POLICY и так далее. У меня
> > нет уверенности, что можно выделить/сгенерировать конфиг mdadm.conf для
> > рутового устройства.
>
> А будет проблемой, если попадёт лишнее, но кроме ARRAY?
> типа,
> grep -v "^ARRAY" /etc/mdadm.conf
> grep "^ARRAY $MY_MD_DEVICE" /etc/mdadm.conf
Я об этом и писал. Да, я боюсь это будет проблемой. Если я ошибаюсь, это
нужно проверять.
--
Rgrds, legion
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [make-initrd] [degraded md-raid] make-initrd в p9 и в Сизифе
2020-02-27 20:30 ` Michael A. Kangin
2020-02-27 21:35 ` Leonid Krivoshein
2020-02-27 22:05 ` Alexey Gladkov
@ 2020-03-06 20:32 ` Michael Shigorin
2 siblings, 0 replies; 21+ messages in thread
From: Michael Shigorin @ 2020-03-06 20:32 UTC (permalink / raw)
To: make-initrd
On Thu, Feb 27, 2020 at 09:30:53PM +0100, Michael A. Kangin wrote:
> lsblk -psr $(mount |grep ' on / ' |cut -f1 -d' ')
В подобных случаях порой разбираю вывод чего-то вроде df / :)
Ну и вместо mount| скорее смотрю в /proc/mounts, если уж.
--
---- WBR, Michael Shigorin / http://altlinux.org
------ http://opennet.ru / http://anna-news.info
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [make-initrd] [degraded md-raid] make-initrd в p9 и в Сизифе
2020-02-27 20:10 ` Alex Gladkov
2020-02-27 20:30 ` Michael A. Kangin
@ 2020-02-27 21:26 ` Leonid Krivoshein
2020-02-27 23:27 ` Alexey Gladkov
1 sibling, 1 reply; 21+ messages in thread
From: Leonid Krivoshein @ 2020-02-27 21:26 UTC (permalink / raw)
To: make-initrd
Доброй ночи!
27.02.2020 23:10, Alex Gladkov пишет:
> On Mon, Feb 17, 2020 at 04:23:13PM +0100, Alexey Gladkov wrote:
>> On Mon, Feb 17, 2020 at 02:27:30PM +0300, Leonid Krivoshein wrote:
>>> Привет, Алексей, ещё раз! :-)
> Я попытался исправить проблему с таймаутом при медленной инициализации
> дисков [1]. Эта проблема может как-то затрагивает и описанное здесь.
Ух-ты, не ожидал столь скорых подвижек!
> Суть фикса [2] это использовать не фиксированный таймаут для инициализации
> рейдовых дисков, а сделать его скользящим. Таймаут отчитывается от
> появления последнего raid-member. По умолчанию новый таймаут выставлен в
> 10 секунд т.е. если через 10 секунд после появления последнего
> raid-member есть рейды в состоянии inactive, то выполняется mdadm -IRs.
Хорошая идея. И задержка разумная. Но по реализации 100-timeout есть
сомнения: использован RTC вместо твоего же MONOTONIC TIMESTAMP (а время
в этой стадии точно не может скакануть?), перезатирается $tsfile вторым
экземпляром (по идее, надо сначала проверять наличие PID-файла), и вот
этот код в самом конце -- вызов mdadm -IRs в цикле (если имелась ввиду
повторная обработка после изменения структуры /sys/block/md*/, то её не
будет, но будет вероятно избыточные вызовы mdadm -IRs для каждого
массива, хотя достаточно одного на все).
> Также бага [1] открыла ещё одну проблему, которую не очень понятно как
> лечить автоматически: если в /etc/mdadm.conf описан не только корень, а
> целый букет разных рейдов, то все они попадут в initrd, но при этом initrd
> не будет ждать сборки их всех. Пока лучшей идеи, чем указание кастомного
> mdadm.conf в такой ситуации у меня нет.
Виталий там написал, почему идея не очень: действительно имена md будут
другими. Пока хороших идей нет. В идеале иметь возможность указывать
некий target (чего должен ждать init), и чтобы этим target'ом мог бы
быть даже некий кастомный скрипт, который определяет условие завершения
работы. Тогда можно будет обеспечить выход после обнаружения всех
массивов, нескольких сетевых карт, итд.
> Не могли бы заинтересованные люди потестировать фикс [2] на реальном
> железе ? У меня есть возможность протестировать в qemu, что не есть айс в
> этой ситуации.
>
> [1] https://bugzilla.altlinux.org/show_bug.cgi?id=37737
> [2] http://git.altlinux.org/people/legion/packages/make-initrd.git?p=make-initrd.git;a=shortlog;h=refs/heads/fix-mdadm-timeout
>
На железе точно нет. А на PVE тот же qemu. Есть ещё VirtualBox.
>>> 17.02.2020 13:42, Alexey Gladkov пишет:
>>>> On Sun, Feb 16, 2020 at 08:31:37PM +0300, Leonid Krivoshein wrote:
>>>>> Всем привет!
>>>>>
>>>>>
>>>>> На p8 была попытка исправить проблему загрузки с деградированного массива:
>>>>>
>>>>> http://git.altlinux.org/gears/m/make-initrd.git?p=make-initrd.git;a=commitdiff;h=9f1bee4172c43ae7208855c6cb991e0e415d7f08
>>>>>
>>>>> В коде исправлялось сразу две проблемных ситуации (inactive и read-auto),
>>>>> но, если не ошибаюсь, исправить удалось только одну из них, вторую надо было
>>>>> лечить где-то в другом месте. Однако в новом коде такого файла (050-mdstart)
>>>>> больше нет, есть только это:
>>>>>
>>>>> http://git.altlinux.org/gears/m/make-initrd.git?p=make-initrd.git;a=blob;f=features/mdadm/data/lib/uevent/extenders/100-mdstart;h=3df8f9ea40654d2eeb5551ad14f7358834c03396;hb=c52b3398d8547c8d00412c153c0679968af8a58a
>>>>>
>>>>> Две ситуации исправляются руками тривиально: в случае inactive одного из
>>>>> дисков просто mdadn -IRs разово, в случае read-auto (что типично для корня
>>>>> или свопа на рейде) -- перевести его обратно в режим чтения/записи командой
>>>>> mdadm -w /dev/MDDEV. В старом коде make-initrd была задержка в 1/3 времени
>>>>> таймаута, то есть, 1 минута, которая запускает этот траблешуттер, если
>>>>> корень не обнаружился. В новом -- я вообще не понимаю, как должно работать,
>>>>> но по факту никак не работает. Система не грузится даже с только что
>>>>> созданного рейда, который не досинхронизирован до конца. Плюс к тому: shaba@
>>>>> что-то говорил, что в новом LVM другой принцип обработки обнаруженных томов
>>>>> (это уже про ситуацию, когда LVM поверх MD).
>>>>>
>>>>> Ещё такой момент: ситуацию хорошо бы исправлять для всех дисков на раннем
>>>>> этапе, а не только если корень не нашёлся. Да и неправильно это ждать минуту
>>>>> не пойми чего, когда диск который часть рейда или LVM нашёлся, о нём уже всё
>>>>> известно. Есть какие-нибудь идеи, камрады?
>>>> Вы много написали, но я явно не в контекте. Давайте по порядку.
>>>>
>>>> Есть features/mdadm/data/lib/uevent/extenders/100-mdstart.
>>>>
>>>> Он решает проблему и не решает какую проблему ?
>>>> Какие ещё проблемы есть ?
>>> Не решает ни одну из двух проблем:
>> ok. Значит он перестал работать совсем.
>>
>> Нужно будет написать тест про degraded raid. Я примерно понимаю как это
>> должно выглядеть. А вот с read-auto сложнее. Что это ?
>>
>> Можно тебя попросить написать тест (я готов ответить на любые вопросы про
>> новые end-to-end тесты) ?
>>
>>> - не "чинит" MD-устройства в состоянии "read-auto", поэтому после перехода в
>>> stage2 корень на RAID нельзя перемонтировать в режим чтения-записи.
>>>
>>> - по сравнению с make-initrd0.8.x, теперь вообще нельзя загрузиться с
>>> MD-RAID, который в состоянии "degraded", хотя для больших дисков это норма
>>> сразу после инсталляции -- они просто ещё не успели до-синхронизироваться. В
>>> старой версии отрабатывал troubleshutter by mike@, который я перетянул из
>>> p7/c7 в p8 и c8/c8.1. Во времена p7 ты утянул этот troubleshutter в
>>> тогдашний Сизиф, но видимо теперь оно совсем нерабочее.
>>>
>>> В идеале решать обе проблемы в новом make-initrd2 для любых обнаруживаемых
>>> блочных дисков, а не только для тех, на которых корень, аккуратно пытаться
>>> исправить приведёнными командами. Очевидно, обработка должна находиться не
>>> здесь, а где-то ещё.
>>>
>>> Сейчас я воспроизведу на виртуалке и отпишу более детально...
>> Было бы здорово, если бы ты выложил это куда-нибудь, чтобы мне можно тоже
>> было посмотреть.
>>
>> --
>> Rgrds, legion
>>
>> _______________________________________________
>> Make-initrd mailing list
>> Make-initrd@lists.altlinux.org
>> https://lists.altlinux.org/mailman/listinfo/make-initrd
--
Best regards,
Leonid Krivoshein.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [make-initrd] [degraded md-raid] make-initrd в p9 и в Сизифе
2020-02-27 21:26 ` Leonid Krivoshein
@ 2020-02-27 23:27 ` Alexey Gladkov
2020-02-28 0:17 ` Leonid Krivoshein
0 siblings, 1 reply; 21+ messages in thread
From: Alexey Gladkov @ 2020-02-27 23:27 UTC (permalink / raw)
To: make-initrd
On Fri, Feb 28, 2020 at 12:26:17AM +0300, Leonid Krivoshein wrote:
> > Суть фикса [2] это использовать не фиксированный таймаут для инициализации
> > рейдовых дисков, а сделать его скользящим. Таймаут отчитывается от
> > появления последнего raid-member. По умолчанию новый таймаут выставлен в
> > 10 секунд т.е. если через 10 секунд после появления последнего
> > raid-member есть рейды в состоянии inactive, то выполняется mdadm -IRs.
>
> Хорошая идея. И задержка разумная. Но по реализации 100-timeout есть
> сомнения: использован RTC вместо твоего же MONOTONIC TIMESTAMP (а время в
> этой стадии точно не может скакануть?)
Время может прыгнуть лишь в виртуалке и с определёнными настройками
виртуалки. touch здесь используется для сериализации смещения таймаута.
> перезатирается $tsfile вторым экземпляром (по идее, надо сначала
> проверять наличие PID-файла)
Кажется ты не понял назначение $tsfile. Его содержимое не важно, кроме
того я его не перезаписываю. Важен его mtime, который меняет touch. Этот
touch не под проверкой на наличие PID-файла, потому что 100-timeout может
выполнятся конкурентно и каждый процесс будет сдвигать таймаут
относительно $now.
Проверка pidfile нужна для того, чтобы запустить проверку таймаута лишь
один раз.
Я понимаю, что в этом коде есть рейс между проверкой и созданием pidfile.
Я думаю это изменить в следующем патче.
> и вот этот код в самом конце -- вызов mdadm -IRs в цикле (если имелась
> ввиду повторная обработка после изменения структуры /sys/block/md*/, то
> её не будет, но будет вероятно избыточные вызовы mdadm -IRs для каждого
> массива, хотя достаточно одного на все).
Да, mdadm нужно выполнять только если что-то из /sys/block/md* изменилось.
Этот патч решал проблему таймаута. Этот код мигрировал из
/lib/uevent/extenders/100-mdstart.
> > Также бага [1] открыла ещё одну проблему, которую не очень понятно как
> > лечить автоматически: если в /etc/mdadm.conf описан не только корень, а
> > целый букет разных рейдов, то все они попадут в initrd, но при этом initrd
> > не будет ждать сборки их всех. Пока лучшей идеи, чем указание кастомного
> > mdadm.conf в такой ситуации у меня нет.
>
> Виталий там написал, почему идея не очень: действительно имена md будут
> другими.
Я не понял этого аргумента в тогда, так не пониманию сейчас (может ты
объяснишь). Зачем вам стабильные имена этих девайсов ?
> В идеале иметь возможность указывать некий target (чего должен ждать
> init), и чтобы этим target'ом мог бы быть даже некий кастомный скрипт,
> который определяет условие завершения работы.
Это уже есть.
> Тогда можно будет обеспечить выход после обнаружения всех массивов,
> нескольких сетевых карт, итд.
В целом, можно, но это мягко говоря замедлит загрузку. В принципе initrd
уже умеет ждать несколько точек монтирования. Можно попробовать ждать и не
только рутовый девайс.
Меня беспокоит, что в этом случае любая проблема с любым рейдом в системе
может привезти к невозможности загрузки.
> На железе точно нет. А на PVE тот же qemu. Есть ещё VirtualBox.
Ну это не очень интересно.
--
Rgrds, legion
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [make-initrd] [degraded md-raid] make-initrd в p9 и в Сизифе
2020-02-27 23:27 ` Alexey Gladkov
@ 2020-02-28 0:17 ` Leonid Krivoshein
2020-02-28 13:33 ` Alexey Gladkov
0 siblings, 1 reply; 21+ messages in thread
From: Leonid Krivoshein @ 2020-02-28 0:17 UTC (permalink / raw)
To: make-initrd
28.02.2020 2:27, Alexey Gladkov пишет:
> On Fri, Feb 28, 2020 at 12:26:17AM +0300, Leonid Krivoshein wrote:
>>> Суть фикса [2] это использовать не фиксированный таймаут для инициализации
>>> рейдовых дисков, а сделать его скользящим. Таймаут отчитывается от
>>> появления последнего raid-member. По умолчанию новый таймаут выставлен в
>>> 10 секунд т.е. если через 10 секунд после появления последнего
>>> raid-member есть рейды в состоянии inactive, то выполняется mdadm -IRs.
>> Хорошая идея. И задержка разумная. Но по реализации 100-timeout есть
>> сомнения: использован RTC вместо твоего же MONOTONIC TIMESTAMP (а время в
>> этой стадии точно не может скакануть?)
> Время может прыгнуть лишь в виртуалке и с определёнными настройками
> виртуалки. touch здесь используется для сериализации смещения таймаута.
>
>> перезатирается $tsfile вторым экземпляром (по идее, надо сначала
>> проверять наличие PID-файла)
> Кажется ты не понял назначение $tsfile. Его содержимое не важно, кроме
> того я его не перезаписываю. Важен его mtime, который меняет touch. Этот
> touch не под проверкой на наличие PID-файла, потому что 100-timeout может
> выполнятся конкурентно и каждый процесс будет сдвигать таймаут
> относительно $now.
Видимо я этого не понял, да. Потому что вижу, что конкуренции нет: после
проверки на существование PID-файла, сразу выход. Но до выхода он
успевает дотронутся до файла. Так что ли и задумывалось?
> Проверка pidfile нужна для того, чтобы запустить проверку таймаута лишь
> один раз.
>
> Я понимаю, что в этом коде есть рейс между проверкой и созданием pidfile.
> Я думаю это изменить в следующем патче.
>
>> и вот этот код в самом конце -- вызов mdadm -IRs в цикле (если имелась
>> ввиду повторная обработка после изменения структуры /sys/block/md*/, то
>> её не будет, но будет вероятно избыточные вызовы mdadm -IRs для каждого
>> массива, хотя достаточно одного на все).
> Да, mdadm нужно выполнять только если что-то из /sys/block/md* изменилось.
> Этот патч решал проблему таймаута. Этот код мигрировал из
> /lib/uevent/extenders/100-mdstart.
>
Понятно, но я имел ввиду это:
http://git.altlinux.org/gears/m/make-initrd.git?p=make-initrd.git;a=blob;f=features/mdadm/data/lib/initrd/trouble/050-mdstart;h=e594a0663695ac71c19a042c468d3f4339e2aaeb;hb=9f1bee4172c43ae7208855c6cb991e0e415d7f08
(строки #4-13)
>>> Также бага [1] открыла ещё одну проблему, которую не очень понятно как
>>> лечить автоматически: если в /etc/mdadm.conf описан не только корень, а
>>> целый букет разных рейдов, то все они попадут в initrd, но при этом initrd
>>> не будет ждать сборки их всех. Пока лучшей идеи, чем указание кастомного
>>> mdadm.conf в такой ситуации у меня нет.
>> Виталий там написал, почему идея не очень: действительно имена md будут
>> другими.
> Я не понял этого аргумента в тогда, так не пониманию сейчас (может ты
> объяснишь). Зачем вам стабильные имена этих девайсов ?
Некоторые прописывают ноды девайсов в /etc/fstab. Потом не забывай, что
это только у тебя systemd нет, у большинства пользователей альта он
работает и динамически создаёт девайс-таргеты. Ну и, может, где ещё
ссылки на /dev/mdX есть, не знаю. Многие предпочитают /dev/md0 вместо
/dev/md127. Но главный аргумент в другом: желательно собрать рейды до
перехода в корень и сразу починить ситуацию с read-auto. Если этого не
сделать, всё равно нормально система не загрузится. Даже если
загрузится, как показали мои предыдущие эксперименты, уже не нормально,
что SWAP в состоянии read-only и по сути отключен. Это значит, что
несмотря на удачную загрузку, в каких-то конфигурациях прилетит
нежданчиик ООМ.
>> В идеале иметь возможность указывать некий target (чего должен ждать
>> init), и чтобы этим target'ом мог бы быть даже некий кастомный скрипт,
>> который определяет условие завершения работы.
> Это уже есть.
Отлично!
>> Тогда можно будет обеспечить выход после обнаружения всех массивов,
>> нескольких сетевых карт, итд.
> В целом, можно, но это мягко говоря замедлит загрузку. В принципе initrd
> уже умеет ждать несколько точек монтирования. Можно попробовать ждать и не
> только рутовый девайс.
>
> Меня беспокоит, что в этом случае любая проблема с любым рейдом в системе
> может привезти к невозможности загрузки.
Если ставить целью перейти как можно быстрее в корень, как только для
этого образуется любая возможность, то да. Но, мне кажется, это неверная
цель, и не надо беспокоиться о невозможности загрузки рейдов на этой
стадии. Как раз наоборот. Либо всё починили и грузимся, либо бестолку
грузиться, поскольку ещё неизвестно, что там поломано и как оно себя
поведёт. Рабочий корень это ещё не средство для ремонта. Но если уж так
совсем боязно, можно предусмотреть загрузочную опцию типа NO_REPAIR=1 и
писать о ней в конце при невозможности авто-ремонта.
>> На железе точно нет. А на PVE тот же qemu. Есть ещё VirtualBox.
> Ну это не очень интересно.
--
Best regards,
Leonid Krivoshein.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [make-initrd] [degraded md-raid] make-initrd в p9 и в Сизифе
2020-02-28 0:17 ` Leonid Krivoshein
@ 2020-02-28 13:33 ` Alexey Gladkov
2020-02-28 21:43 ` Leonid Krivoshein
0 siblings, 1 reply; 21+ messages in thread
From: Alexey Gladkov @ 2020-02-28 13:33 UTC (permalink / raw)
To: make-initrd
On Fri, Feb 28, 2020 at 03:17:12AM +0300, Leonid Krivoshein wrote:
> > Кажется ты не понял назначение $tsfile. Его содержимое не важно, кроме
> > того я его не перезаписываю. Важен его mtime, который меняет touch. Этот
> > touch не под проверкой на наличие PID-файла, потому что 100-timeout может
> > выполнятся конкурентно и каждый процесс будет сдвигать таймаут
> > относительно $now.
>
> Видимо я этого не понял, да. Потому что вижу, что конкуренции нет: после
> проверки на существование PID-файла, сразу выход. Но до выхода он успевает
> дотронутся до файла. Так что ли и задумывалось?
Да. В этом месте и предусмотрена конкуренция. Если скрипт будет выполнен
параллельно (одновременно), то они сделают touch now+delay на $tsfile т.е.
mtime этого файла будет сдвинут примерно на одно значение. Блокировки на
изменение mtime будет делать ядро.
> > Да, mdadm нужно выполнять только если что-то из /sys/block/md* изменилось.
> > Этот патч решал проблему таймаута. Этот код мигрировал из
> > /lib/uevent/extenders/100-mdstart.
> >
>
> Понятно, но я имел ввиду это:
>
> http://git.altlinux.org/gears/m/make-initrd.git?p=make-initrd.git;a=blob;f=features/mdadm/data/lib/initrd/trouble/050-mdstart;h=e594a0663695ac71c19a042c468d3f4339e2aaeb;hb=9f1bee4172c43ae7208855c6cb991e0e415d7f08
>
> (строки #4-13)
Этот код не предлагался для master. Поэтому я его не использовал. Да,
нужно сделать так или даже ещё хитрее.
> > > Виталий там написал, почему идея не очень: действительно имена md будут
> > > другими.
> > Я не понял этого аргумента в тогда, так не пониманию сейчас (может ты
> > объяснишь). Зачем вам стабильные имена этих девайсов ?
>
> Некоторые прописывают ноды девайсов в /etc/fstab.
Ну это совсем не аргумент. Эти некоторые должны понимать, что имена могут
меняться. Для этого уже давно есть UUID= и LABEL= для отвязки от имён
девайсов. Если есть вероятность, что имя может измениться (например как в
этом случае), то нужно использовать UUID.
Вспомни про историю с именами сетевых интерфейсов.
> Потом не забывай, что это только у тебя systemd нет, у большинства
> пользователей альта он работает и динамически создаёт девайс-таргеты.
Я творение моих коллег даже обсуждать не хочу. Если в systemd проблемы, то
и решаться они должны там.
> Ну и, может, где ещё ссылки на /dev/mdX есть, не знаю. Многие
> предпочитают /dev/md0 вместо /dev/md127.
Так и делается. Посмотри в /dev/disk/*. Вот их и нужно использовать.
> Но главный аргумент в другом: желательно собрать рейды до перехода в
> корень и сразу починить ситуацию с read-auto. Если этого не сделать, всё
> равно нормально система не загрузится.
Если корень собран, то загрузится. Если в корне лежит не всё, что нужно
для закрузки, то это неправильная конфигурация.
Кстати, make-initrd умеет ждать не только рут, но и другие точки
монтирования. Для этого можно либо добавить точку монтирования в
MOUNTPOINTS, либо добавить x-initrd-mount в опции точки монтирования в
fstab.
> Даже если загрузится, как показали мои предыдущие
> эксперименты, уже не нормально, что SWAP в состоянии read-only и по сути
> отключен. Это значит, что несмотря на удачную загрузку, в каких-то
> конфигурациях прилетит нежданчиик ООМ.
Зачем swap на рейд ?! Не делай так.
> > Меня беспокоит, что в этом случае любая проблема с любым рейдом в системе
> > может привезти к невозможности загрузки.
>
> Если ставить целью перейти как можно быстрее в корень, как только для этого
> образуется любая возможность, то да. Но, мне кажется, это неверная цель, и
> не надо беспокоиться о невозможности загрузки рейдов на этой стадии. Как раз
> наоборот. Либо всё починили и грузимся, либо бестолку грузиться, поскольку
> ещё неизвестно, что там поломано и как оно себя поведёт.
Рейд как раз и нужен для того чтобы загрузится если диск вылетел. Ты,
видимо, никогда не чинил сервера удалённо через суппорт сервис ...
> Рабочий корень это ещё не средство для ремонта.
Ты ошибаешься. Для этого у нас есть деление на /bin, /sbin и /usr .
Только не нужно мне рассказывать о моих коллегах, которые всё
перенесли в /usr.
> Но если уж так совсем боязно, можно
> предусмотреть загрузочную опцию типа NO_REPAIR=1 и писать о ней в конце при
> невозможности авто-ремонта.
Вот подумай, как ты сможешь ввести этот параметр, если ты _уже_ не смог
загрузиться ? Поедешь не площадку к серверу, чтобы этот параметр ввести ?
--
Rgrds, legion
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [make-initrd] [degraded md-raid] make-initrd в p9 и в Сизифе
2020-02-28 13:33 ` Alexey Gladkov
@ 2020-02-28 21:43 ` Leonid Krivoshein
2020-02-28 23:39 ` Alexey Gladkov
0 siblings, 1 reply; 21+ messages in thread
From: Leonid Krivoshein @ 2020-02-28 21:43 UTC (permalink / raw)
To: make-initrd
28.02.2020 16:33, Alexey Gladkov пишет:
> On Fri, Feb 28, 2020 at 03:17:12AM +0300, Leonid Krivoshein wrote:
>>> [...]
>> Но главный аргумент в другом: желательно собрать рейды до перехода в
>> корень и сразу починить ситуацию с read-auto. Если этого не сделать, всё
>> равно нормально система не загрузится.
> Если корень собран, то загрузится. Если в корне лежит не всё, что нужно
> для закрузки, то это неправильная конфигурация.
В корне есть всё, чтобы начать процесс загрузки. ELF, которому ты
передаёшь управления по выходу из stage1 (ну хорошо, ядро передаёт) --
это пресловутый systemd, а о том, что в конфигурации что-то не так,
админ узнает только когда отъедет рейд. И не факт, что к этому моменту
будет сеть или запущен ssh. Я это частенько вижу -- есть только
локальный рутовый доступ и страшная сага о невозможности запуска
некоторой службы.
> Кстати, make-initrd умеет ждать не только рут, но и другие точки
> монтирования. Для этого можно либо добавить точку монтирования в
> MOUNTPOINTS, либо добавить x-initrd-mount в опции точки монтирования в
> fstab.
Отлично, уже хлеб!
>> Даже если загрузится, как показали мои предыдущие
>> эксперименты, уже не нормально, что SWAP в состоянии read-only и по сути
>> отключен. Это значит, что несмотря на удачную загрузку, в каких-то
>> конфигурациях прилетит нежданчиик ООМ.
> Зачем swap на рейд ?! Не делай так.
Это почему же? Так делают многие. Рейд, в отличие от одиночного диска,
нужен для избыточности, и чтобы в случае выхода одного диска из строя,
всё не встало колом.
>>> Меня беспокоит, что в этом случае любая проблема с любым рейдом в системе
>>> может привезти к невозможности загрузки.
>> Если ставить целью перейти как можно быстрее в корень, как только для этого
>> образуется любая возможность, то да. Но, мне кажется, это неверная цель, и
>> не надо беспокоиться о невозможности загрузки рейдов на этой стадии. Как раз
>> наоборот. Либо всё починили и грузимся, либо бестолку грузиться, поскольку
>> ещё неизвестно, что там поломано и как оно себя поведёт.
> Рейд как раз и нужен для того чтобы загрузится если диск вылетел.
Так а по факту сейчас получается наоборот. Бери в расчёт не стадию
выхода из stage1, а хотя бы ту стадию, когда будет доступен вход снаружи
по ssh. Это ещё не конец загрузки, но при отъезде рейдов, и до неё можно
не дотянуть.
> Ты, видимо, никогда не чинил сервера удалённо через суппорт сервис ...
Слава богу! Но в данном случае лучше попробовать починить сборку рейдов
в stage1, чем застрять в самом начале stage2. Иначе шансы иметь дело с
удалённым саппортом будут намного выше.
>> Рабочий корень это ещё не средство для ремонта.
> Ты ошибаешься. Для этого у нас есть деление на /bin, /sbin и /usr .
Я имел ввиду, что рабочий корень ещё не панацея, с него нельзя починить
все мыслимые поломки в дисковой подсистеме. Для удалённых ремонтов
сейчас есть IPMI, BMC, iLO и прочие приблуды, в конце концов.
> Только не нужно мне рассказывать о моих коллегах, которые всё
> перенесли в /usr.
>
>> Но если уж так совсем боязно, можно
>> предусмотреть загрузочную опцию типа NO_REPAIR=1 и писать о ней в конце при
>> невозможности авто-ремонта.
> Вот подумай, как ты сможешь ввести этот параметр, если ты _уже_ не смог
> загрузиться ? Поедешь не площадку к серверу, чтобы этот параметр ввести ?
Нужна рабочая консоль. Хоть локальная, хоть удалённая. На современных
серверах этого добра хватает.
--
Best regards,
Leonid Krivoshein.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [make-initrd] [degraded md-raid] make-initrd в p9 и в Сизифе
2020-02-28 21:43 ` Leonid Krivoshein
@ 2020-02-28 23:39 ` Alexey Gladkov
0 siblings, 0 replies; 21+ messages in thread
From: Alexey Gladkov @ 2020-02-28 23:39 UTC (permalink / raw)
To: make-initrd
On Sat, Feb 29, 2020 at 12:43:37AM +0300, Leonid Krivoshein wrote:
> В корне есть всё, чтобы начать процесс загрузки. ELF, которому ты передаёшь
> управления по выходу из stage1 (ну хорошо, ядро передаёт) -- это пресловутый
> systemd, а о том, что в конфигурации что-то не так, админ узнает только
> когда отъедет рейд. И не факт, что к этому моменту будет сеть или запущен
> ssh. Я это частенько вижу -- есть только локальный рутовый доступ и страшная
> сага о невозможности запуска некоторой службы.
Не нужно ждать пока отъедет рейд. Для этого есть инструменты.
> Это почему же? Так делают многие. Рейд, в отличие от одиночного диска, нужен
> для избыточности, и чтобы в случае выхода одного диска из строя, всё не
> встало колом.
Не нужно реплицировать страницы памяти по дискам. Я убеждён, что тот кто
так делает явно не понимает что такое swap.
> > Рейд как раз и нужен для того чтобы загрузится если диск вылетел.
>
> Так а по факту сейчас получается наоборот. Бери в расчёт не стадию выхода из
> stage1, а хотя бы ту стадию, когда будет доступен вход снаружи по ssh. Это
> ещё не конец загрузки, но при отъезде рейдов, и до неё можно не дотянуть.
Смотри, есть разделение стадий загрузки. Обычно initrd нужен для того
чтобы использовать расширенные схемы загрузки корня. Все же помнят, что он
опционален. Initrd перестаёт существовать перед передачей управления
системному init.
Чтобы было ясно: я не против выполнения дополнительной функциональности в
момент выполнения initrd, но не нужно на этот _хэлпер_ перекладывать
ответственность за остальную систему. Я готов добавить фичи, которые
приведут к тому поведению, которое ты описываешь, но это не будет
поведением по умолчанию.
Ты мне говоришь, что кто-то делает конфигурации, которые не жизнеспособны
без внешней помощи. Я готов допустить, что есть такие сумрачные гении,
которые вынесли важную часть загрузки из рута с полным набором системных
утилит в initrd, где нет всех инструментов. Это ответственность этих
гениев. Я не хочу им мешать.
> > Ты, видимо, никогда не чинил сервера удалённо через суппорт сервис ...
>
> Слава богу! Но в данном случае лучше попробовать починить сборку рейдов в
> stage1, чем застрять в самом начале stage2. Иначе шансы иметь дело с
> удалённым саппортом будут намного выше.
Я не хочу тебе мешать. Я уже сказал, что есть опция для ожидания
нескольких точек монтирования. Возможно нужны будут ещё какие-нибудь
опции.
> Я имел ввиду, что рабочий корень ещё не панацея, с него нельзя починить все
> мыслимые поломки в дисковой подсистеме.
В initrd их ещё меньше.
> Для удалённых ремонтов сейчас есть IPMI, BMC, iLO и прочие приблуды, в
> конце концов.
Я пользовался ими. Больше не хочу испытывать этот чудесный опыт.
Я не хочу спорить о радостях администрирования. Если тебе нравится такие
схемы, то я не планирую мешать.
Ты можешь указать raid-member-delay=0 при загрузке, чтобы выключить
mdadm -IRs (пока я не изучал вопрос с read-auto и не рассматриваю эту
проблему тут). В этом случае ты будешь ждать rootdelay= время пока
появятся все диски и соберутся все рейды из MOUNTPOINTS.
--
Rgrds, legion
^ permalink raw reply [flat|nested] 21+ messages in thread