* Re: [devel] [RFC] make-initrd
2014-01-14 23:34 ` Dmitry V. Levin
@ 2014-01-15 0:07 ` Led
2014-01-15 0:36 ` Dmitry V. Levin
2014-01-15 8:08 ` Sergey Y. Afonin
2014-01-15 8:33 ` Alexey Gladkov
2 siblings, 1 reply; 32+ messages in thread
From: Led @ 2014-01-15 0:07 UTC (permalink / raw)
To: ALT Devel discussion list
On Wednesday 15 January 2014 01:34:13 Dmitry V. Levin wrote:
> On Wed, Jan 15, 2014 at 02:30:51AM +0400, Alexey Gladkov wrote:
> > 14.01.2014 23:34, Dmitry V. Levin wrote:
> > > On Tue, Jan 14, 2014 at 10:23:59PM +0400, Alexey Gladkov wrote:
> > >> Вот только как и с udev встаёт вопрос обновления столь важных
> > >> компонентов. Пока существует барьер между initramfs и реальной
> > >> системой эта проблема тоже стоит, но не настолько сильно.
> > >
> > > А в чем тут проблема?
> >
> > Некоторое время назад поднимался вопрос о том, чтобы не выгружать udev
> > в initramfs а оставлять его. Но при обновлении udev он не обновится в
> > образе. Плюс база будет создаваться первой копией. С временем разница
> > будет расти, но всё будет хорошо пока не появится проблема и тогда
> > станет очень плохо.
>
> Автоматическое обновление образа при обновлении входящих в него компонент
> не выглядит принципиальной проблемой. Например, можно попробовать
> написать файлтриггер, который будет это делать.
Так и делают в других дистрибутивах. Вот только гарантии, что перегенерированный образ будет настолько же рабочим,
насколько существующий (с помощью которого мы и загружены), боюсь, никто не даст :(
>
> > Сейчас проблема расхождения миров initramfs и реальной системы тоже
> > есть, но она не критична т.к. эти миры не пересекаются.
> >
> > Если мы хотим, чтобы что-то из initramfs работало в реальной системе,
> > то нам нужно придумать, как синхронизировать их.
>
> Интересно, какие риски несет сохранение процессов, запущенных с initramfs,
> после запуска реальной системы, в предположении, что образ initramfs
> поддерживается синхронизированным с реальной системой.
--
Led
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [devel] [RFC] make-initrd
2014-01-15 0:07 ` Led
@ 2014-01-15 0:36 ` Dmitry V. Levin
2014-01-15 2:39 ` Денис Смирнов
2014-01-15 8:13 ` Sergey Y. Afonin
0 siblings, 2 replies; 32+ messages in thread
From: Dmitry V. Levin @ 2014-01-15 0:36 UTC (permalink / raw)
To: ALT Devel discussion list
[-- Attachment #1: Type: text/plain, Size: 1792 bytes --]
On Wed, Jan 15, 2014 at 02:07:40AM +0200, Led wrote:
> On Wednesday 15 January 2014 01:34:13 Dmitry V. Levin wrote:
> > On Wed, Jan 15, 2014 at 02:30:51AM +0400, Alexey Gladkov wrote:
> > > 14.01.2014 23:34, Dmitry V. Levin wrote:
> > > > On Tue, Jan 14, 2014 at 10:23:59PM +0400, Alexey Gladkov wrote:
> > > >> Вот только как и с udev встаёт вопрос обновления столь важных
> > > >> компонентов. Пока существует барьер между initramfs и реальной
> > > >> системой эта проблема тоже стоит, но не настолько сильно.
> > > >
> > > > А в чем тут проблема?
> > >
> > > Некоторое время назад поднимался вопрос о том, чтобы не выгружать udev
> > > в initramfs а оставлять его. Но при обновлении udev он не обновится в
> > > образе. Плюс база будет создаваться первой копией. С временем разница
> > > будет расти, но всё будет хорошо пока не появится проблема и тогда
> > > станет очень плохо.
> >
> > Автоматическое обновление образа при обновлении входящих в него компонент
> > не выглядит принципиальной проблемой. Например, можно попробовать
> > написать файлтриггер, который будет это делать.
>
> Так и делают в других дистрибутивах. Вот только гарантии, что перегенерированный образ будет настолько же рабочим,
> насколько существующий (с помощью которого мы и загружены), боюсь, никто не даст :(
Кто багов боится - тот dist-upgrade не делает. :)
Не похоже, чтобы риски обновления образа initramfs существенно отличались
от рисков обновления системы.
Можно провести параллель между образом initramfs и executable, статически
слинкованным с несколькими библиотеками. По идее, после обновления любой
из этих библиотек такой executable полагается пересобрать, но при этом
возникает риск, что полученный результат не будет настолько же рабочим.
--
ldv
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [devel] [RFC] make-initrd
2014-01-15 0:36 ` Dmitry V. Levin
@ 2014-01-15 2:39 ` Денис Смирнов
2014-01-15 3:00 ` Led
2014-01-15 3:08 ` Dmitry V. Levin
2014-01-15 8:13 ` Sergey Y. Afonin
1 sibling, 2 replies; 32+ messages in thread
From: Денис Смирнов @ 2014-01-15 2:39 UTC (permalink / raw)
To: devel
[-- Attachment #1: Type: text/plain, Size: 1742 bytes --]
On Wed, Jan 15, 2014 at 04:36:41AM +0400, Dmitry V. Levin wrote:
> Кто багов боится - тот dist-upgrade не делает. :)
> Не похоже, чтобы риски обновления образа initramfs существенно отличались
> от рисков обновления системы.
Если после обновления системы systemd сдохнет и не будет грузиться, то init=/bin/sh спасёт.
И до тех пор, пока в системе живы хотя бы /bin/sh, /usr/bin/ip (кстати, с
чего это он в /usr/bin?) и /bin/rpm, вместе со своими зависимостями --
большинство багов от неудачного dist-upgrade можно исправить без помощи
rescue.
А критичный баг в initramfs для меня уже будет означать однозначную
необходимость в rescue, да с переменным успехом (ибо выяснить что там не
так, и исправить -- нужны отдельные знания).
> Можно провести параллель между образом initramfs и executable, статически
> слинкованным с несколькими библиотеками. По идее, после обновления любой
> из этих библиотек такой executable полагается пересобрать, но при этом
> возникает риск, что полученный результат не будет настолько же рабочим.
Только вот работоспособность этого бинарника критична для загрузки системы
хоть в какое-то ремонтопригодное состояние.
У initramfs ровно две критичных задачи:
1. примонтировать rootfs (с последующей загрузкой)
2. в случае невозможности примонтировать rootfs -- дать администратору
ручки, чтобы это как-либо исправить
systemd тут -- это уже из пушки по вороьбям. А вот использование старого
доброго init выглядит разумным шагом.
И лучше бы initramfs максимально изолировать от остальной системы. Потому
как выигрышь в максимум единицы секунд на повторном старте udev+systemd не
стоит того, чтобы терять на этом надёжность.
--
С уважением, Денис
http://mithraen.ru/
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [devel] [RFC] make-initrd
2014-01-15 2:39 ` Денис Смирнов
@ 2014-01-15 3:00 ` Led
2014-01-15 3:13 ` Dmitry V. Levin
2014-01-15 5:12 ` Денис Смирнов
2014-01-15 3:08 ` Dmitry V. Levin
1 sibling, 2 replies; 32+ messages in thread
From: Led @ 2014-01-15 3:00 UTC (permalink / raw)
To: devel
On Wednesday 15 January 2014 04:39:36 Денис Смирнов wrote:
> On Wed, Jan 15, 2014 at 04:36:41AM +0400, Dmitry V. Levin wrote:
> > Кто багов боится - тот dist-upgrade не делает. :)
> > Не похоже, чтобы риски обновления образа initramfs существенно отличались
> > от рисков обновления системы.
>
> Если после обновления системы systemd сдохнет и не будет грузиться, то
> init=/bin/sh спасёт.
Только если драйвер клавиатуры вкомпилен в ядро, или, каким-то чудом, подгрузился:)
> И до тех пор, пока в системе живы хотя бы /bin/sh,
> /usr/bin/ip (кстати, с чего это он в /usr/bin?) и /bin/rpm, вместе со
> своими зависимостями -- большинство багов от неудачного dist-upgrade можно
> исправить без помощи rescue.
>
> А критичный баг в initramfs для меня уже будет означать однозначную
> необходимость в rescue, да с переменным успехом (ибо выяснить что там не
> так, и исправить -- нужны отдельные знания).
>
> > Можно провести параллель между образом initramfs и executable, статически
> > слинкованным с несколькими библиотеками. По идее, после обновления любой
> > из этих библиотек такой executable полагается пересобрать, но при этом
> > возникает риск, что полученный результат не будет настолько же рабочим.
>
> Только вот работоспособность этого бинарника критична для загрузки системы
> хоть в какое-то ремонтопригодное состояние.
>
> У initramfs ровно две критичных задачи:
> 1. примонтировать rootfs (с последующей загрузкой)
> 2. в случае невозможности примонтировать rootfs -- дать администратору
> ручки, чтобы это как-либо исправить
>
> systemd тут -- это уже из пушки по вороьбям.
> А вот использование старого
> доброго init выглядит разумным шагом.
Я к сожалению так и не понял: в чём же тут профит... :(
>
> И лучше бы initramfs максимально изолировать от остальной системы. Потому
> как выигрышь в максимум единицы секунд на повторном старте udev+systemd не
> стоит того, чтобы терять на этом надёжность.
ИМХО у initramfs ровно одна задача: смонтировать / и запустить с него системный init (чем бы он ни был). В 90% случаев
для этого даже udev не нужен.
--
Led
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [devel] [RFC] make-initrd
2014-01-15 3:00 ` Led
@ 2014-01-15 3:13 ` Dmitry V. Levin
2014-01-15 3:50 ` Led
2014-01-15 5:12 ` Денис Смирнов
1 sibling, 1 reply; 32+ messages in thread
From: Dmitry V. Levin @ 2014-01-15 3:13 UTC (permalink / raw)
To: ALT Devel discussion list
[-- Attachment #1: Type: text/plain, Size: 1237 bytes --]
On Wed, Jan 15, 2014 at 05:00:13AM +0200, Led wrote:
> On Wednesday 15 January 2014 04:39:36 Денис Смирнов wrote:
> > On Wed, Jan 15, 2014 at 04:36:41AM +0400, Dmitry V. Levin wrote:
> > > Кто багов боится - тот dist-upgrade не делает. :)
> > > Не похоже, чтобы риски обновления образа initramfs существенно отличались
> > > от рисков обновления системы.
> >
> > Если после обновления системы systemd сдохнет и не будет грузиться, то
> > init=/bin/sh спасёт.
>
> Только если драйвер клавиатуры вкомпилен в ядро, или, каким-то чудом, подгрузился:)
Подгрузить драйвер клавиатуры на этот случай - тоже задача, достойная
initramfs. :)
> > И лучше бы initramfs максимально изолировать от остальной системы. Потому
> > как выигрышь в максимум единицы секунд на повторном старте udev+systemd не
> > стоит того, чтобы терять на этом надёжность.
>
> ИМХО у initramfs ровно одна задача: смонтировать / и запустить с него системный init (чем бы он ни был). В 90% случаев
> для этого даже udev не нужен.
Не знаю, как получена эта оценка (90%), но на практике сейчас далеко
запрятанный / (когда нужно активировать последовательно несколько уровней)
не такая уж и редкость, чтобы ей можно было пренебречь.
--
ldv
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [devel] [RFC] make-initrd
2014-01-15 3:13 ` Dmitry V. Levin
@ 2014-01-15 3:50 ` Led
2014-01-15 8:16 ` Sergey Y. Afonin
0 siblings, 1 reply; 32+ messages in thread
From: Led @ 2014-01-15 3:50 UTC (permalink / raw)
To: ALT Devel discussion list
On Wednesday 15 January 2014 05:13:55 Dmitry V. Levin wrote:
> On Wed, Jan 15, 2014 at 05:00:13AM +0200, Led wrote:
> > On Wednesday 15 January 2014 04:39:36 Денис Смирнов wrote:
> > > On Wed, Jan 15, 2014 at 04:36:41AM +0400, Dmitry V. Levin wrote:
> > > > Кто багов боится - тот dist-upgrade не делает. :)
> > > > Не похоже, чтобы риски обновления образа initramfs существенно
> > > > отличались от рисков обновления системы.
> > >
> > > Если после обновления системы systemd сдохнет и не будет грузиться, то
> > > init=/bin/sh спасёт.
> >
> > Только если драйвер клавиатуры вкомпилен в ядро, или, каким-то чудом,
> > подгрузился:)
>
> Подгрузить драйвер клавиатуры на этот случай - тоже задача, достойная
> initramfs. :)
>
> > > И лучше бы initramfs максимально изолировать от остальной системы.
> > > Потому как выигрышь в максимум единицы секунд на повторном старте
> > > udev+systemd не стоит того, чтобы терять на этом надёжность.
> >
> > ИМХО у initramfs ровно одна задача: смонтировать / и запустить с него
> > системный init (чем бы он ни был). В 90% случаев для этого даже udev не
> > нужен.
>
> Не знаю, как получена эта оценка (90%), но на практике сейчас далеко
> запрятанный / (когда нужно активировать последовательно несколько уровней)
> не такая уж и редкость, чтобы ей можно было пренебречь.
IMHO "не редкость" разве что device mapping. Да и он мне в живой природе редко попадается. Но это всего лишь личное
субъективное "наблюдение". Да он, в общем-то и без udev "раскручиватся". Может с udev проще...
В любом случае, это лишь моё ламерское время и, скорее всего, я неправ. Прошу прощения, что влез с этим:)
--
Led
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [devel] [RFC] make-initrd
2014-01-15 3:00 ` Led
2014-01-15 3:13 ` Dmitry V. Levin
@ 2014-01-15 5:12 ` Денис Смирнов
1 sibling, 0 replies; 32+ messages in thread
From: Денис Смирнов @ 2014-01-15 5:12 UTC (permalink / raw)
To: devel
[-- Attachment #1: Type: text/plain, Size: 1106 bytes --]
On Wed, Jan 15, 2014 at 05:00:13AM +0200, Led wrote:
>> Если после обновления системы systemd сдохнет и не будет грузиться, то
>> init=/bin/sh спасёт.
> Только если драйвер клавиатуры вкомпилен в ядро, или, каким-то чудом, подгрузился:)
$ grep usbhid /etc/initrd.mk
MODULES_PRELOAD += usbhid
>> А вот использование старого
>> доброго init выглядит разумным шагом.
> Я к сожалению так и не понял: в чём же тут профит... :(
Может быть ценно с учетом того, что в initramfs периодически возникает
желание воткнуть элементы rescue.
>> И лучше бы initramfs максимально изолировать от остальной системы. Потому
>> как выигрышь в максимум единицы секунд на повторном старте udev+systemd не
>> стоит того, чтобы терять на этом надёжность.
> ИМХО у initramfs ровно одна задача: смонтировать / и запустить с него системный init (чем бы он ни был). В 90% случаев
> для этого даже udev не нужен.
Ну, вообще говоря в 100% случаев -- 10 лет назад без всякого удава
справлялись. Но с ним сейчас проще, иначе нужно его куски ручками писать.
--
С уважением, Денис
http://mithraen.ru/
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [devel] [RFC] make-initrd
2014-01-15 2:39 ` Денис Смирнов
2014-01-15 3:00 ` Led
@ 2014-01-15 3:08 ` Dmitry V. Levin
2014-01-15 5:04 ` Денис Смирнов
2014-01-15 8:56 ` Alexey Gladkov
1 sibling, 2 replies; 32+ messages in thread
From: Dmitry V. Levin @ 2014-01-15 3:08 UTC (permalink / raw)
To: ALT Devel discussion list
[-- Attachment #1: Type: text/plain, Size: 1339 bytes --]
On Wed, Jan 15, 2014 at 06:39:36AM +0400, Денис Смирнов wrote:
> On Wed, Jan 15, 2014 at 04:36:41AM +0400, Dmitry V. Levin wrote:
>
> > Кто багов боится - тот dist-upgrade не делает. :)
> > Не похоже, чтобы риски обновления образа initramfs существенно отличались
> > от рисков обновления системы.
>
> Если после обновления системы systemd сдохнет и не будет грузиться, то init=/bin/sh спасёт.
> И до тех пор, пока в системе живы хотя бы /bin/sh, /usr/bin/ip (кстати, с
> чего это он в /usr/bin?)
$ readlink /usr/bin/ip
../../sbin/ip
> и /bin/rpm, вместе со своими зависимостями --
> большинство багов от неудачного dist-upgrade можно исправить без помощи
> rescue.
Это как повезет.
> А критичный баг в initramfs для меня уже будет означать однозначную
> необходимость в rescue, да с переменным успехом (ибо выяснить что там не
> так, и исправить -- нужны отдельные знания).
Если можно держать запасные ядра, то почему бы не применить аналогичный
подход к initramfs?
> systemd тут -- это уже из пушки по вороьбям. А вот использование старого
> доброго init выглядит разумным шагом.
Тоже в общем выглядит как overkill. Впрочем, если есть желание сделать
make-initrd еще более гибким (казалось бы, что там можно сделать более
гибким, но автору, наверное, виднее), то почему бы и нет.
--
ldv
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [devel] [RFC] make-initrd
2014-01-15 3:08 ` Dmitry V. Levin
@ 2014-01-15 5:04 ` Денис Смирнов
2014-01-15 8:56 ` Alexey Gladkov
1 sibling, 0 replies; 32+ messages in thread
From: Денис Смирнов @ 2014-01-15 5:04 UTC (permalink / raw)
To: devel
[-- Attachment #1: Type: text/plain, Size: 1347 bytes --]
On Wed, Jan 15, 2014 at 07:08:48AM +0400, Dmitry V. Levin wrote:
> $ readlink /usr/bin/ip
> ../../sbin/ip
Упс, не заметил.
>> и /bin/rpm, вместе со своими зависимостями --
>> большинство багов от неудачного dist-upgrade можно исправить без помощи
>> rescue.
> Это как повезет.
К счастью мне пока везло.
>> А критичный баг в initramfs для меня уже будет означать однозначную
>> необходимость в rescue, да с переменным успехом (ибо выяснить что там не
>> так, и исправить -- нужны отдельные знания).
> Если можно держать запасные ядра, то почему бы не применить аналогичный
> подход к initramfs?
Потому как если у меня старый initramfs со старым systemd, то не факт что
он будет нормально работать, после обновления systemd в системе.
>> systemd тут -- это уже из пушки по вороьбям. А вот использование старого
>> доброго init выглядит разумным шагом.
> Тоже в общем выглядит как overkill. Впрочем, если есть желание сделать
> make-initrd еще более гибким (казалось бы, что там можно сделать более
> гибким, но автору, наверное, виднее), то почему бы и нет.
В любом случае, initramfs должен быть максимально изолирован от системы.
Идея запускать нечто из initramfs так, чтобы оно продолжало работать после
загрузке системы -- это мина замедленного действия.
--
С уважением, Денис
http://mithraen.ru/
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [devel] [RFC] make-initrd
2014-01-15 3:08 ` Dmitry V. Levin
2014-01-15 5:04 ` Денис Смирнов
@ 2014-01-15 8:56 ` Alexey Gladkov
2014-01-15 12:27 ` Dmitry V. Levin
1 sibling, 1 reply; 32+ messages in thread
From: Alexey Gladkov @ 2014-01-15 8:56 UTC (permalink / raw)
To: devel
15.01.2014 07:08, Dmitry V. Levin wrote:
>> А критичный баг в initramfs для меня уже будет означать однозначную
>> необходимость в rescue, да с переменным успехом (ибо выяснить что там не
>> так, и исправить -- нужны отдельные знания).
>
> Если можно держать запасные ядра, то почему бы не применить аналогичный
> подход к initramfs?
Если initramfs обновлять каждый раз, когда меняется ПО задействованное
внутри него, то таких запасных initrd будет больше. При чём, их будет
тем больше чем чаще пользователь делает dist-upgrade :)
Также подумай о размере этих бэкапов. Эх вот была бы возможность
делать эти бэкапы инкрементально.
Плюс представь как осуществлять навигацию по этим "запасным" initrd в
загрузчике. Сейчас если система существует достаточно долго и
пользователь не проводит чистку, в загрузчике видится здоровый список
ядер. А теперь представим, что к каждому ядру будет несколько initrd
(1,3,5,10... N) на которые можно откатиться.
Это будет издевательство над пользователем т.к. мы по сути создаём
снапшоты системы в initramfs и позволяем откатываться на любой снапшот.
> Тоже в общем выглядит как overkill. Впрочем, если есть желание сделать
> make-initrd еще более гибким (казалось бы, что там можно сделать более
> гибким, но автору, наверное, виднее), то почему бы и нет.
Наконец-то комментарий по первому письму.
Почему ты считаешь использование sysv-init оверкилом ?
--
Rgrds, legion
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [devel] [RFC] make-initrd
2014-01-15 8:56 ` Alexey Gladkov
@ 2014-01-15 12:27 ` Dmitry V. Levin
2014-01-15 12:37 ` Sergey V Turchin
2014-01-15 12:41 ` Alexey Gladkov
0 siblings, 2 replies; 32+ messages in thread
From: Dmitry V. Levin @ 2014-01-15 12:27 UTC (permalink / raw)
To: ALT Devel discussion list
[-- Attachment #1: Type: text/plain, Size: 1419 bytes --]
On Wed, Jan 15, 2014 at 12:56:57PM +0400, Alexey Gladkov wrote:
> 15.01.2014 07:08, Dmitry V. Levin wrote:
> >> А критичный баг в initramfs для меня уже будет означать однозначную
> >> необходимость в rescue, да с переменным успехом (ибо выяснить что там не
> >> так, и исправить -- нужны отдельные знания).
> >
> > Если можно держать запасные ядра, то почему бы не применить аналогичный
> > подход к initramfs?
>
> Если initramfs обновлять каждый раз, когда меняется ПО задействованное
> внутри него, то таких запасных initrd будет больше. При чём, их будет
> тем больше чем чаще пользователь делает dist-upgrade :)
Мне кажется, что достаточно держать в запасе последний успешно загруженный
initramfs (для каждого ядра), все остальное - это уже экзотика для QA.
> > Тоже в общем выглядит как overkill. Впрочем, если есть желание сделать
> > make-initrd еще более гибким (казалось бы, что там можно сделать более
> > гибким, но автору, наверное, виднее), то почему бы и нет.
>
> Наконец-то комментарий по первому письму.
> Почему ты считаешь использование sysv-init оверкилом ?
Потому что мне кажется, что оно и так уже достаточно гибкое, чтобы
выразить любую идею. Но, возможно, если тебе требуется более удобный
механизм организации зависимостей, то sysv scripts подойдут.
systemd без dbus и прочих плюшек тоже подошел бы, но такого systemd
в природе не наблюдается.
--
ldv
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [devel] [RFC] make-initrd
2014-01-15 12:27 ` Dmitry V. Levin
@ 2014-01-15 12:37 ` Sergey V Turchin
2014-01-15 12:43 ` Dmitry V. Levin
2014-01-15 12:41 ` Alexey Gladkov
1 sibling, 1 reply; 32+ messages in thread
From: Sergey V Turchin @ 2014-01-15 12:37 UTC (permalink / raw)
To: ALT Devel discussion list
[-- Attachment #1: Type: text/plain, Size: 726 bytes --]
On Wednesday 15 January 2014 16:27:08 Dmitry V wrote:
[...]
> Мне кажется, что достаточно держать в запасе последний успешно загруженный
> initramfs (для каждого ядра), все остальное - это уже экзотика для QA.
Для каждого не получится, т.к. у меня, например, un-def установлено только для
проблемных случаев(в основном с новым initrd) и попытка стать "успешно
загружаенным" бывает только при проблемах.
[...]
--
Regards, Sergey. ALT Linux, http://www.altlinux.ru/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [devel] [RFC] make-initrd
2014-01-15 12:37 ` Sergey V Turchin
@ 2014-01-15 12:43 ` Dmitry V. Levin
2014-01-15 12:48 ` Sergey V Turchin
0 siblings, 1 reply; 32+ messages in thread
From: Dmitry V. Levin @ 2014-01-15 12:43 UTC (permalink / raw)
To: ALT Devel discussion list
[-- Attachment #1: Type: text/plain, Size: 760 bytes --]
On Wed, Jan 15, 2014 at 04:37:36PM +0400, Sergey V Turchin wrote:
> On Wednesday 15 January 2014 16:27:08 Dmitry V wrote:
>
> [...]
> > Мне кажется, что достаточно держать в запасе последний успешно загруженный
> > initramfs (для каждого ядра), все остальное - это уже экзотика для QA.
> Для каждого не получится, т.к. у меня, например, un-def установлено только для
> проблемных случаев(в основном с новым initrd) и попытка стать "успешно
> загружаенным" бывает только при проблемах.
Идея простая: обычно нет смысла бэкапить образ initramfs,
с которым система еще ни разу не загрузилась.
Если ты установил ядро, но ни разу его не загрузил, то ценность образа
initramfs, созданного в момент установки этого ядра, не очевидна.
--
ldv
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [devel] [RFC] make-initrd
2014-01-15 12:43 ` Dmitry V. Levin
@ 2014-01-15 12:48 ` Sergey V Turchin
0 siblings, 0 replies; 32+ messages in thread
From: Sergey V Turchin @ 2014-01-15 12:48 UTC (permalink / raw)
To: ALT Devel discussion list
[-- Attachment #1: Type: text/plain, Size: 814 bytes --]
On Wednesday 15 January 2014 16:43:59 Dmitry V wrote:
[...]
> Идея простая: обычно нет смысла бэкапить образ initramfs,
> с которым система еще ни разу не загрузилась.
>
> Если ты установил ядро, но ни разу его не загрузил, то ценность образа
> initramfs, созданного в момент установки этого ядра, не очевидна.
Очевидна, т.к. он был сгенерирован в других условиях, когда проблем не
наблюдалось, т.е. его тоже нужно бэкапить вместе с "успешно загруженными".
--
Regards, Sergey. ALT Linux, http://www.altlinux.ru/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [devel] [RFC] make-initrd
2014-01-15 12:27 ` Dmitry V. Levin
2014-01-15 12:37 ` Sergey V Turchin
@ 2014-01-15 12:41 ` Alexey Gladkov
1 sibling, 0 replies; 32+ messages in thread
From: Alexey Gladkov @ 2014-01-15 12:41 UTC (permalink / raw)
To: devel
15.01.2014 16:27, Dmitry V. Levin wrote:
> Мне кажется, что достаточно держать в запасе последний успешно загруженный
> initramfs (для каждого ядра), все остальное - это уже экзотика для QA.
Под успешной загрузкой ты предлагаешь понимать успешное
перемонтирование рута в rw ?
> Потому что мне кажется, что оно и так уже достаточно гибкое, чтобы
> выразить любую идею. Но, возможно, если тебе требуется более удобный
> механизм организации зависимостей, то sysv scripts подойдут.
Ты же знаешь, что у меня есть далеко идущие планы :)))
> systemd без dbus и прочих плюшек тоже подошел бы, но такого systemd
> в природе не наблюдается.
Я приводил пример его размера. Возможно без "плюшек" он был бы сильно
меньше, но, как ты правильно сказал, такого в природе нет.
--
Rgrds, legion
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [devel] [RFC] make-initrd
2014-01-15 0:36 ` Dmitry V. Levin
2014-01-15 2:39 ` Денис Смирнов
@ 2014-01-15 8:13 ` Sergey Y. Afonin
1 sibling, 0 replies; 32+ messages in thread
From: Sergey Y. Afonin @ 2014-01-15 8:13 UTC (permalink / raw)
To: ALT Devel discussion list
On Wednesday 15 January 2014, Dmitry V. Levin wrote:
> Кто багов боится - тот dist-upgrade не делает. :)
Делает. :-) Я.
1. dist-upgrade в текущем бранче.
2. смена репозитария.
3. update-kernel (если ничего страшного дополнительно не тянется)
4. lilo -R <new kernel>
5. reboot
6. "звонок другу", если не загрузилось, если загрузилось - обновляемся дальше.
В случае обновления ядра в рамках одного бранча - аналогично.
Получить нерабочую основную пару ядро/initrd - это весьма плохо
и грозит выездом на место того, кто хоть что-то понимает, а
ресет может сделать кто угодно, включая управляемый блок розеток.
--
С уважением, Сергей Афонин
asy@altlinux.ru
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [devel] [RFC] make-initrd
2014-01-14 23:34 ` Dmitry V. Levin
2014-01-15 0:07 ` Led
@ 2014-01-15 8:08 ` Sergey Y. Afonin
2014-01-15 8:33 ` Alexey Gladkov
2 siblings, 0 replies; 32+ messages in thread
From: Sergey Y. Afonin @ 2014-01-15 8:08 UTC (permalink / raw)
To: ALT Devel discussion list
On Wednesday 15 January 2014, Dmitry V. Levin wrote:
> Автоматическое обновление образа при обновлении входящих в него
> компонент не выглядит принципиальной проблемой. Например, можно
> попробовать написать файлтриггер, который будет это делать.
А как выполнить откат на старое ядро ? А на совсем старое ?
Мне кажется, это сильно уменьшит совместимость со старыми
ядрами, а они бывают нужны... Плюс, когда обновляется ядро
и генерируется initrd для него, я, например, готов к тому,
что будут косяки и сохраняю возможность отката по reset.
А что делать в случае, если рабочий initrd поменяется внезапно
и, случайно, получит проблему, которая начнёт мешать загрузке ?
--
С уважением, Сергей Афонин
asy@altlinux.ru
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [devel] [RFC] make-initrd
2014-01-14 23:34 ` Dmitry V. Levin
2014-01-15 0:07 ` Led
2014-01-15 8:08 ` Sergey Y. Afonin
@ 2014-01-15 8:33 ` Alexey Gladkov
2 siblings, 0 replies; 32+ messages in thread
From: Alexey Gladkov @ 2014-01-15 8:33 UTC (permalink / raw)
To: devel
15.01.2014 03:34, Dmitry V. Levin wrote:
> Автоматическое обновление образа при обновлении входящих в него компонент
> не выглядит принципиальной проблемой. Например, можно попробовать
> написать файлтриггер, который будет это делать.
Триггер сделать можно, но сам он по initrd лазать не коем случае не
должен. В initrd могут быть утилиты, которые имеют тоже название что и
утилиты из системы, но сделаны из специально для initrd. Также
некоторые утилиты могут находиться в других местах в initrd.
Для правильной работы триггера make-initrd должен запоминать имена
пакетов или оригинальные имена файлов, которые он использовал для
создания initramfs.
> Интересно, какие риски несет сохранение процессов, запущенных с initramfs,
> после запуска реальной системы, в предположении, что образ initramfs
> поддерживается синхронизированным с реальной системой.
На первый взгляд никаких, кроме неудобства обновления.
Мне такая идея не нравится т.к. происходит смешивание сущностей.
initramfs становится частью конкретной системы.
--
Rgrds, legion
^ permalink raw reply [flat|nested] 32+ messages in thread