[devel] [RFC] make-initrd

[devel] [RFC] make-initrd

[Alexey Gladkov]

Привет!

Недавно мне пришла мысль о переделке runtime части make-initrd с целью
повышения гибкости и увеличения сфер применения.

Первая идея состоит в том, чтобы использовать в initramfs не скрипт
притворяющий init'ом, а использовать там вполне себе настоящий init.
Проведя некоторые исследования я пришёл к выводу, что обычный
немодифицированный sysv-init может уже рассматриваться как вполне себе
встраиваемое решение: sysv-init ~40K, upstart ~160K, systemd ~1,1M.

Ещё одна особенность sysv-init, которую я обнаружил у него это
возможность запустить вместо себя совершенно любой процесс.
Особенность очень полезная применительно к задачам в initramfs.

В случае использования sysv-init все стадии работы initramfs
превращаются в сервисы с зависимостями между собой (я использовал LSB
заголовки). Это поможет решить ряд вопросов с очисткой системы перед
переходом в реальную систему (например lo). А также наоборот с
пробросом в реальную систему сервисов (например plymouth) или ресурсов.

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

Также этот подход позволит упростить некоторые существующие решения на
основе initramfs позволяя добавлять и отключать любые или почти любые
стадии/сервисы.

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

http://git.altlinux.org/people/legion/packages/make-initrd.git?a=shortlog;h=refs/heads/sysinit

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

-- 
Rgrds, legion

[devel] Dracut (was: make-initrd)

[Sergey V Turchin]

[-- Attachment #1: Type: text/plain, Size: 316 bytes --]

On Tuesday 14 January 2014 17:58:43 Alexey Gladkov wrote:
> Привет!
> 
> Недавно мне пришла мысль о переделке
Сейчас в OpenSUSE и Fedora https://dracut.wiki.kernel.org/ .
Может и нам пора?

[...]

-- 
Regards, Sergey.       ALT Linux, http://www.altlinux.ru/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Dracut

[Alexey Gladkov]

14.01.2014 18:12, Sergey V Turchin wrote:
> On Tuesday 14 January 2014 17:58:43 Alexey Gladkov wrote:
>> Привет!
>>
>> Недавно мне пришла мысль о переделке
> Сейчас в OpenSUSE и Fedora https://dracut.wiki.kernel.org/ .
> Может и нам пора?

dracut это другой проект. Очень прошу писать по теме или открывать
другой тред.

-- 
Rgrds, legion

[devel] make-initrd (was: Dracut)

[Michael Shigorin]

On Tue, Jan 14, 2014 at 06:12:44PM +0400, Sergey V Turchin wrote:
> Сейчас в OpenSUSE и Fedora https://dracut.wiki.kernel.org/ .
> Может и нам пора?

Зачем?

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] [RFC] make-initrd

[Alexey Gladkov]

14.01.2014 19:42, Alexey Shabalin wrote:
> 14 января 2014 г., 17:58 пользователь Alexey Gladkov написал:
> 
>> Привет!
>>
>> Недавно мне пришла мысль о переделке runtime части make-initrd с целью
>> повышения гибкости и увеличения сфер применения.
>>
>> Первая идея состоит в том, чтобы использовать в initramfs не скрипт
>> притворяющий init'ом, а использовать там вполне себе настоящий init.
>> Проведя некоторые исследования я пришёл к выводу, что обычный
>> немодифицированный sysv-init может уже рассматриваться как вполне себе
>> встраиваемое решение: sysv-init ~40K, upstart ~160K, systemd ~1,1M.
>>
> А можно ли сразу заложить возможность использования разных init в
> initramfs. Интересует использование systemd тоже.

Дело в том, что я отталкивался от того, что init в initramfs не
мигрирует в систему, а запускает родной init. При такой архитектуре
использовать systemd не возможно т.к. он не может запустить что-либо
вместо себя.

Более того, скорее всего использовать совсем не модифицированный init
в initramfs не получится т.к. существует ряд проблем. Например, разбор
cmdline и выбор на его основе runlevel'а. Внести коррективы в
sysv-init намного проще чем в другие реализации инита.

Зачем вам такой функционал ?
Могли бы вы рассказать подробнее ?

-- 
Rgrds, legion

Re: [devel] [RFC] make-initrd

[Alexey Gladkov]

14.01.2014 20:25, Alexey Shabalin wrote:
>> В systemd есть все необходимое, что бы работать в initramfs, подготовлены
> все необходимые для этого unit-файлы(возможно что -то не хватает, то можно
> взять из dracut).

В dracut есть поддержка запуска systemd в initramfs и переездом его в
реальную систему. Умение работать в initramfs не является чем-то
исключительным т.к. это своего рода liveusb. Вопрос в том, зачем это
нужно и перевешивают ли плюсы от такого решения минусы.

> Какой-то необходимости засунуть systemd в initramfs у меня нет, но если у
> меня в системе и так systemd, то запустить его еще на ранней стадии в
> initramfs и остаться с ним выглядит довольно элегантно.

Вот только как и с udev встаёт вопрос обновления столь важных
компонентов. Пока существует барьер между initramfs и реальной
системой эта проблема тоже стоит, но не настолько сильно.

-- 
Rgrds, legion

Re: [devel] [RFC] make-initrd

[Viacheslav Dubrovskyi]

[-- Attachment #1: Type: text/plain, Size: 526 bytes --]

14.01.2014 20:23, Alexey Gladkov пишет:
> Вот только как и с udev встаёт вопрос обновления столь важных 
> компонентов. Пока существует барьер между initramfs и реальной 
> системой эта проблема тоже стоит, но не настолько сильно. 
Можно засунуть туда rpm. Или даже apt.
Не, ну в хешере же работает rpm.

-- 
WBR,
Viacheslav Dubrovskyi


[-- Attachment #2: Криптографическая подпись S/MIME --]
[-- Type: application/pkcs7-signature, Size: 3738 bytes --]

Re: [devel] [RFC] make-initrd

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 296 bytes --]

On Tue, Jan 14, 2014 at 10:23:59PM +0400, Alexey Gladkov wrote:
> Вот только как и с udev встаёт вопрос обновления столь важных
> компонентов. Пока существует барьер между initramfs и реальной
> системой эта проблема тоже стоит, но не настолько сильно.

А в чем тут проблема?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] [RFC] make-initrd

[Michael Shigorin]

On Tue, Jan 14, 2014 at 09:24:30PM +0200, Viacheslav Dubrovskyi wrote:
> Можно засунуть туда rpm. Или даже apt.
> Не, ну в хешере же работает rpm.

Это уже напоминает бутстрап Мюнхгаузена методом порождения
ещё одного, но в другом месте...

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] [RFC] make-initrd

[Alexey Gladkov]

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 работало в реальной системе,
то нам нужно придумать, как синхронизировать их.

-- 
Rgrds, legion

Re: [devel] [RFC] make-initrd

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1402 bytes --]

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
поддерживается синхронизированным с реальной системой.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] [RFC] make-initrd

[Led]

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

Re: [devel] [RFC] make-initrd

[Dmitry V. Levin]

[-- 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 --]

Re: [devel] [RFC] make-initrd

[Денис Смирнов]

[-- 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 --]

Re: [devel] [RFC] make-initrd

[Led]

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

Re: [devel] [RFC] make-initrd

[Dmitry V. Levin]

[-- 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 --]

Re: [devel] [RFC] make-initrd

[Dmitry V. Levin]

[-- 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 --]

Re: [devel] [RFC] make-initrd

[Led]

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

Re: [devel] [RFC] make-initrd

[Денис Смирнов]

[-- 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 --]

Re: [devel] [RFC] make-initrd

[Денис Смирнов]

[-- 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 --]

Re: [devel] [RFC] make-initrd

[Sergey Y. Afonin]

On Tuesday 14 January 2014, Alexey Shabalin wrote:

> Какой-то необходимости засунуть systemd в initramfs у меня нет,
> но если у меня в системе и так systemd, то запустить его еще на
> ранней стадии в initramfs и остаться с ним выглядит довольно 
> элегантно.    
 
А что делать тем, у кого нет systemd ? Или делать разные initramfs ?

-- 
С уважением, Сергей Афонин
asy@altlinux.ru

Re: [devel] [RFC] make-initrd

[Sergey Y. Afonin]

On Wednesday 15 January 2014, Dmitry V. Levin wrote:

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

А как выполнить откат на старое ядро ? А на совсем старое ?
Мне кажется, это сильно уменьшит совместимость со старыми
ядрами, а они бывают нужны... Плюс, когда обновляется ядро 
и генерируется initrd для него, я, например, готов к тому, 
что будут косяки и сохраняю возможность отката по reset. 

А что делать в случае, если рабочий initrd поменяется внезапно
и, случайно, получит проблему, которая начнёт мешать загрузке ?

-- 
С уважением, Сергей Афонин
asy@altlinux.ru

Re: [devel] [RFC] make-initrd

[Sergey Y. Afonin]

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

Re: [devel] [RFC] make-initrd

[Sergey Y. Afonin]

On Wednesday 15 January 2014, Led wrote:

>  Да и он мне в живой природе редко попадается.

Могу показать / на raid/lvm :-) Два раза.

-- 
С уважением, Сергей Афонин
asy@altlinux.ru

Re: [devel] [RFC] make-initrd

[Alexey Gladkov]

15.01.2014 03:34, Dmitry V. Levin wrote:
> Автоматическое обновление образа при обновлении входящих в него компонент
> не выглядит принципиальной проблемой.  Например, можно попробовать
> написать файлтриггер, который будет это делать.

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

Для правильной работы триггера make-initrd должен запоминать имена
пакетов или оригинальные имена файлов, которые он использовал для
создания initramfs.

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

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

Мне такая идея не нравится т.к. происходит смешивание сущностей.
initramfs становится частью конкретной системы.

-- 
Rgrds, legion

Re: [devel] [RFC] make-initrd

[Alexey Gladkov]

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

Re: [devel] [RFC] make-initrd

[Dmitry V. Levin]

[-- 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 --]

Re: [devel] [RFC] make-initrd

[Sergey V Turchin]

[-- 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 --]

Re: [devel] [RFC] make-initrd

[Alexey Gladkov]

15.01.2014 16:27, Dmitry V. Levin wrote:
> Мне кажется, что достаточно держать в запасе последний успешно загруженный
> initramfs (для каждого ядра), все остальное - это уже экзотика для QA.

Под успешной загрузкой ты предлагаешь понимать успешное
перемонтирование рута в rw ?

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

Ты же знаешь, что у меня есть далеко идущие планы :)))

> systemd без dbus и прочих плюшек тоже подошел бы, но такого systemd
> в природе не наблюдается.

Я приводил пример его размера. Возможно без "плюшек" он был бы сильно
меньше, но, как ты правильно сказал, такого в природе нет.

-- 
Rgrds, legion

Re: [devel] [RFC] make-initrd

[Dmitry V. Levin]

[-- 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 --]

Re: [devel] [RFC] make-initrd

[Sergey V Turchin]

[-- 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 --]

Re: [devel] [RFC] make-initrd

[Alexey Gladkov]

14.01.2014 17:58, Alexey Gladkov wrote:
> В нём есть поддержка загрузки только с обычного раздела и
> тестировалось это лишь в qemu, но если кому интересно, то получить
> представление о загрузке можно. Этот код сделан в основном для того
> чтобы можно было посмотреть на новую компоновку initramfs.

Я думаю, что никто сам не будет генерировать образ, чтобы посмотреть.
Я сделал образ, чтобы все заинтересованные могли посмотреть на масштаб
разрушений:

ftp://devel.altlinux.org/legion/files/initrd-sysvinit.img

-- 
Rgrds, legion