On Wed, Jan 15, 2020 at 10:51:59PM +0500, Александр Шеметов wrote: > Доброго времени суток. > Увидел Ваши контакты к пакету make-initrd, решил Вас потревожить. > Дело в том, что у меня есть необходимость запускать развёрнутую систему > ALT Linux из *.img образа да ещё и этот образ должен лежать на раздела с NTFS. > Подобное в других дистрибутивах решается, либо добавлением в initramfs некоторого скрипта, > как тут http://www.opopop.net/booting_linux_from_a_loop_file_system/, либо с использованием > dracut https://github.com/rgcjonas/dracut-ntfsloop make-initrd устроен иначе чем dracut и его скрипты не будут работать с make-initrd. > Хочу спросить, на данный момент штатными средствами make-initrd подобное возможно ? На данный момент нет. Поддержку такой схемы загрузки нужно добавлять. > Хотелось бы почитать об этом, но к сожалению никакой документации по make-initrd > найти не удаётся. Не могли бы Вы подсказать её расположение ? Документация находится здесь. https://github.com/legionus/make-initrd/tree/master/docs > Заранее благодарю за ответ. > > -- > С уважением, > Александр Шеметов > -- Rgrds, legion
> На данный момент нет. Поддержку такой схемы загрузки нужно добавлять.
Прошу уточнить, механизм загрузки ОС из развёрнутого образа не реализован
в принципе или проблема только при использовании раздела на NTFS ?
--
С уважением,
Александр Шеметов
On Sat, Jan 18, 2020 at 03:11:55PM +0500, Александр Шеметов wrote:
> > На данный момент нет. Поддержку такой схемы загрузки нужно добавлять.
>
> Прошу уточнить, механизм загрузки ОС из развёрнутого образа не реализован
> в принципе или проблема только при использовании раздела на NTFS ?
Скорее первое.
--
Rgrds, legion
> Скорее первое. Хм, возможно скажу глупость, но ведь на установочных образах работает такой вариант, я проверял его лично https://forum.altlinux.org/index.php?topic=34690.msg256186#msg256186 А из снятого образа уже развёрнутой ОС мне не удаётся запустить систему. Я проваливаюсь в rdshell и дальше ничего сделать не удаётся, подключить root не могу, так как каталог /dev/disk/ вообще отсутствует. К чему интересуюсь, может быть я элементарно что-то упускаю и на самом деле такой вариант работает. У кого-то наверняка был опыт и попытки провернуть такую же схему загрузки ОС, не уж то я первооткрыватель... -- С уважением, Александр Шеметов
On Sat, Jan 18, 2020 at 08:41:46PM +0500, Александр Шеметов wrote: > > Скорее первое. > > Хм, возможно скажу глупость, но ведь на установочных образах работает > такой вариант, я проверял его лично > https://forum.altlinux.org/index.php?topic=34690.msg256186#msg256186 Потому что там работает propagator. Это не совсем initrd. > А из снятого образа уже развёрнутой ОС мне не удаётся запустить систему. > Я проваливаюсь в rdshell и дальше ничего сделать не удаётся, > подключить root не могу, так как каталог /dev/disk/ вообще отсутствует. > > К чему интересуюсь, может быть я элементарно что-то упускаю и на самом > деле такой вариант работает. Мне не известны примеры таких установок. > У кого-то наверняка был опыт и попытки провернуть такую же схему > загрузки ОС, не уж то я первооткрыватель... Вы как минимум первый кто захотел это сделать в альтлинуксе. -- Rgrds, legion
>> А из снятого образа уже развёрнутой ОС мне не удаётся запустить систему. >> Я проваливаюсь в rdshell и дальше ничего сделать не удаётся, >> подключить root не могу, так как каталог /dev/disk/ вообще отсутствует. Проблема решилась добавлением модуля ata_generic и ряда прочих. Полный список можно глянуть, загрузив обычную систему в rdshell. Соответственно добавляем модули в MODULES_PRELOAD += ... и пересобираем initrd. > Вы как минимум первый кто захотел это сделать в альтлинуксе. Значит будем копать дальше... :) Снова вернусь к ссылке http://www.opopop.net/booting_linux_from_a_loop_file_system/ Там предлагается использовать такой скрипт: #!/bin/sh PREREQ="" prereqs() { echo "$PREREQ" } case $1 in # get pre-requisites prereqs) prereqs exit 0 ;; esac modprobe -k ntfs mount -n -t ntfs -o nodiratime,noatime ${ROOT} ${rootmnt}2 modprobe -k loop mount -n -t ext2 -o loop ${rootmnt}2${loop} ${rootmnt} Насколько я могу понять, здесь прерывается штатный premount корня и вместо него монтируется как раз система из образа. На системах Base ALT в таком виде скрипт конечно же не работает. В связи с этим задам вопрос, так как пока дальше самостоятельно продвинуться не выходит, -- как можно прервать штатный premount и передать управление моему скрипту ? Сейчас в корень принудительно монтируется раздел NTFS, на котором лежит сам образ с системой. PS. Да, и вот это немного мешает тестам на p9 https://bugzilla.altlinux.org/show_bug.cgi?id=37254 Спасибо, что исправили. -- С уважением, Александр Шеметов
Удалось продвинуться в моём вопросе. Потребовалось привести файл /etc/initrd.mk к содержимому: # trying to detect modules and features to access to root volume AUTODETECT = all MODULES_PRELOAD += autofs4 fuse ntfs ata_generic scsi_mod ahci ata_piix pata_acpi sd_mod jbd2 mbcache crc16 ext4 MODULES_ADD += fuse ntfs ata_generic scsi_mod ahci ata_piix pata_acpi sd_mod jbd2 mbcache crc16 ext4 FEATURES += plymouth Затем создать файл /usr/share/make-initrd/data/etc/rc.d/init.d/looproot со следующим содержимым: #!/bin/sh ### BEGIN INIT INFO # Provides: mount loop root # Required-Start: modules # Should-Start: # Required-Stop: # Should-Stop: # Default-Start: 3 4 5 # Default-Stop: # Short-Description: Mount loop file system # Description: Mount loop file system ### END INIT INFO . /.initrd/initenv export looproot=/looproot mkdir -p /looproot mount -n -t ntfs -o nodiratime,noatime ${ROOT} ${looproot} mount -n -t ext4 -o loop ${looproot}/basealt.img ${rootmnt} После этого система начинает стартовать из образа, но не запускается. При запуске сервисов вижу первую ошибку: [FAILED] Failed to start Remount Root and Kernel File Systems. See 'systemctl status systemd-remount-fs.service' for details. Далее присутствует ряд других. Создаётся впечатление, что /root смонтировался в ro. Всё это происходит, вероятно, в момент перемонтирования /root. Могу только видеть сообщения на 12 консоли, на остальных отсутствует приглашение ввода. Может подскажите, куда посмотреть, чтобы решить ? Заранее спасибо. -- С уважением, Александр Шеметов
Удалось всё-таки запустить систему, но только когда образ лежит на разделе с ext4. С разделами на ntfs странная история, похоже полноценной поддержки fuse в initrd попросту нет, а имеющийся ntfs.ko монтирует раздел в режиме readonly. Так, при подключении раздела ntfs с помощью fuse и последующим монтированием с него образа развёрнутой системы в /root, ядро падает в kernel panic при попытке выполнить init. Возможно ли это исправить ? Потому что в других дистрибутивах, отличный от BaseALT, такой проблемы нет. Готов предоставить больше сведений. Заранее спасибо. -- С уважением, Александр Шеметов
Здравствуйте. Понадобилось мне добавить новый сервис в makr-initrd, который должен запускаться после запуска сети. Соответственно, создал для него feature, прописал в нее нужные файлы и создал файл для запуска сервиса в etc/rc.d/init.d следующего вида: #!/bin/sh ### BEGIN INIT INFO # Provides: myservice # Required-Start: network-up # Required-Stop: # Default-Start: 3 4 5 # Default-Stop: 0 1 2 6 # Short-Description: My service # Description: Starts and stops my service ### END INIT INFO .... При генерации образа в /etc/rc[345].d симлинк на этот сервис создается с именем S100myservice. И кажется мне, что он будет запущен явно раньше, чем будет запущена сеть, так как S100 при сортировке будет выше, чем S90network. Может, есть смысл не нумеровать сервисы десятками, или перейти на трехзначную нумерацию (вида S090network, S100myservice)? Или же я зря беспокоюсь и можно пробовать загрузиться и в таком варианте?
On Fri, Sep 04, 2020 at 12:16:04PM +0300, Alex Moskalenko wrote: > Здравствуйте. > > Понадобилось мне добавить новый сервис в makr-initrd, который должен > запускаться после запуска сети. Соответственно, создал для него > feature, прописал в нее нужные файлы и создал файл для запуска сервиса > в etc/rc.d/init.d следующего вида: > > #!/bin/sh > ### BEGIN INIT INFO > # Provides: myservice > # Required-Start: network-up > # Required-Stop: > # Default-Start: 3 4 5 > # Default-Stop: 0 1 2 6 > # Short-Description: My service > # Description: Starts and stops my service > ### END INIT INFO > > .... > > При генерации образа в /etc/rc[345].d симлинк на этот сервис создается > с именем S100myservice. И кажется мне, что он будет запущен явно > раньше, чем будет запущена сеть, так как S100 при сортировке будет > выше, чем S90network. > > Может, есть смысл не нумеровать сервисы десятками, или перейти на > трехзначную нумерацию (вида S090network, S100myservice)? Похоже вы правы. > Или же я зря беспокоюсь и можно пробовать загрузиться и в таком > варианте? Лучше не надо. Подождите следующей версии make-initrd. -- Rgrds, legion
Всем привет! Сейчас в bootchain есть такой код: ... if has_module interactive; then . interactive-sh-functions ... fi Функция has_module() в bootchain: has_module() { [ -f "/etc/initrd/cmdline.d/bootchain-$1" ] || [ -f "/etc/bootchain.d/$1" ] || return 1 } Можно было бы перенести в initrd-sh-functions, но не в таком конечно виде. Другими словами, есть запрос на функцию проверки наличия фичи в собранном образе initramfs. Это может быть полезно для опциональной интеграции фич. Например, хотим конфигурировать сеть диалогами. Собрана ли сюда фича network? -- Best regards, Leonid Krivoshein.
Всем привет! Сейчас в bootchain есть такой код: initrd_version() { [ ! -s /etc/initrd-release ] || . /etc/initrd-release local __version="${VERSION_ID-}" printf '%s' "INITRAMFS${__version:+ $__version}" } Он используется следующим образом в том же демоне: ... exec >"$BC_LOGFILE" 2>&1 message "Starting server [$(initrd_version)]..." ... В логах это обычно выглядит так: ----- Starting server [INITRAMFS 2.16.0]... ... ----- На регулярках MATE сейчас почему-то вылазит совсем иное: ----- Starting server [INITRAMFS 9.1]... ... ----- Понятно, что вопрос к m-p, а не make-initrd, видимо в initramfs попадает какой-то другой /etc/initrd-release. Кроме логов проверка версии может быть полезна для реализации фрагментов кода по-разному, в зависимости от версии make-initrd. -- Best regards, Leonid Krivoshein.
01.07.2021 18:11, Leonid Krivoshein пишет: > Всем привет! > > > Сейчас в bootchain есть такой код: > > initrd_version() > { > [ ! -s /etc/initrd-release ] || > . /etc/initrd-release > local __version="${VERSION_ID-}" > printf '%s' "INITRAMFS${__version:+ $__version}" > } > > Он используется следующим образом в том же демоне: > > ... > exec >"$BC_LOGFILE" 2>&1 > message "Starting server [$(initrd_version)]..." > ... > > В логах это обычно выглядит так: > > ----- > Starting server [INITRAMFS 2.16.0]... > ... > ----- > > На регулярках MATE сейчас почему-то вылазит совсем иное: > > ----- > Starting server [INITRAMFS 9.1]... > ... > ----- > > Понятно, что вопрос к m-p, а не make-initrd, видимо в initramfs попадает какой-то другой /etc/initrd-release. От kWorkStation. > > Кроме логов проверка версии может быть полезна для реализации фрагментов кода по-разному, в зависимости от версии make-initrd. > > -- С уважением, Антон Мидюков <antohami@basealt.ru>
Всем привет! Из-за скудности сабжа пришлось городить свой набор функций и в процессе отладки они сильно выручили. С включенным bc_debug получаются вменяемые отладочные журналы, не сравнить с использованием set -x. Примеры сейчас можно увидеть здесь: http://git.altlinux.org/people/klark/packages/make-initrd-bootchain.git в подкаталоге boot-logs. В самом make-initrd на эту тему есть немного, например, параметр debug, от которого мало что меняется в run-time, а раньше он ещё и был включен по дефолту (я не знал, как отключить, поэтому ввёл свой bc_debug). Было бы здорово иметь такую инфраструктуру на верхнем уровне make-initrd, доступную для любых фич. Речь о примерно следующем наборе функций: debug() -- Вывод текстового сообщения при расширенной отладке. enter() -- Трассировка при расширенной отладке: вход в указанную функцию. leave() -- Трассировка при расширенной отладке: выход из указанной функции. run() -- Запуск внешней команды. При расширенной отладке команда попадёт в журнал. fdump() -- Вывод в журнал содержимого указанного файла при расширенной отладке. assign() -- Присвоение переменной указанного значения, попадающее в журнал. message() -- уже есть, он отправляет в журнал сообщение независимо от debug. Я понимаю, что после отладки enter()/leave() и возможно что-то ещё из кода может даже лучше убирать. Но в таком виде как сейчас их наличие помогает не только программисту отлаживать программу, но и пользователю разобраться, почему не грузится система. Возможно имеет смысл перетащить в initrd-sh-functions? -- Best regards, Leonid Krivoshein.
On Thu, Jul 01, 2021 at 02:01:16PM +0300, Leonid Krivoshein wrote:
> Всем привет!
>
>
> Сейчас в bootchain есть такой код:
>
> ...
> if has_module interactive; then
> . interactive-sh-functions
> ...
> fi
>
> Функция has_module() в bootchain:
>
> has_module()
> {
> [ -f "/etc/initrd/cmdline.d/bootchain-$1" ] ||
> [ -f "/etc/bootchain.d/$1" ] ||
> return 1
> }
>
> Можно было бы перенести в initrd-sh-functions, но не в таком конечно виде.
> Другими словами, есть запрос на функцию проверки наличия фичи в собранном
> образе initramfs. Это может быть полезно для опциональной интеграции фич.
> Например, хотим конфигурировать сеть диалогами. Собрана ли сюда фича
> network?
У меня совсем недавно просили такой функционал.
В большинстве случаев лучше проверять некоторый конкретный функционал
вместо фичи. Так например в luks проверяется запущен ли plymouthd. С
другой стороны наличие network так не определишь.
Реализовать такой функционал не сложно. В момент создания образа нужно
просто сохранить ALL_ACTIVE_FEATURES. Я не думаю, что это кому-то помешает.
--
Rgrds, legion
On Thu, Jul 01, 2021 at 02:11:58PM +0300, Leonid Krivoshein wrote:
> Всем привет!
>
>
> Сейчас в bootchain есть такой код:
>
> initrd_version()
> {
> [ ! -s /etc/initrd-release ] ||
> . /etc/initrd-release
> local __version="${VERSION_ID-}"
> printf '%s' "INITRAMFS${__version:+ $__version}"
> }
>
> Он используется следующим образом в том же демоне:
>
> ...
> exec >"$BC_LOGFILE" 2>&1
> message "Starting server [$(initrd_version)]..."
> ...
>
> В логах это обычно выглядит так:
>
> -----
> Starting server [INITRAMFS 2.16.0]...
> ...
> -----
>
> На регулярках MATE сейчас почему-то вылазит совсем иное:
>
> -----
> Starting server [INITRAMFS 9.1]...
> ...
> -----
>
> Понятно, что вопрос к m-p, а не make-initrd, видимо в initramfs попадает
> какой-то другой /etc/initrd-release.
>
> Кроме логов проверка версии может быть полезна для реализации фрагментов
> кода по-разному, в зависимости от версии make-initrd.
Похоже кто-то в момент выполнения переопределяет $(VERSION). Ты можешь
показать "битый" /etc/initrd-release ?
--
Rgrds, legion
On Thu, Jul 01, 2021 at 03:31:07PM +0300, Leonid Krivoshein wrote:
> Всем привет!
>
>
> Из-за скудности сабжа пришлось городить свой набор функций и в процессе
> отладки они сильно выручили. С включенным bc_debug получаются вменяемые
> отладочные журналы, не сравнить с использованием set -x. Примеры сейчас
> можно увидеть здесь:
> http://git.altlinux.org/people/klark/packages/make-initrd-bootchain.git в
> подкаталоге boot-logs.
>
> В самом make-initrd на эту тему есть немного, например, параметр debug, от
> которого мало что меняется в run-time, а раньше он ещё и был включен по
> дефолту (я не знал, как отключить, поэтому ввёл свой bc_debug). Было бы
> здорово иметь такую инфраструктуру на верхнем уровне make-initrd, доступную
> для любых фич. Речь о примерно следующем наборе функций:
>
> debug() -- Вывод текстового сообщения при расширенной отладке.
> enter() -- Трассировка при расширенной отладке: вход в указанную функцию.
> leave() -- Трассировка при расширенной отладке: выход из указанной функции.
> run() -- Запуск внешней команды. При расширенной отладке команда попадёт в
> журнал.
> fdump() -- Вывод в журнал содержимого указанного файла при расширенной
> отладке.
> assign() -- Присвоение переменной указанного значения, попадающее в журнал.
>
> message() -- уже есть, он отправляет в журнал сообщение независимо от debug.
>
> Я понимаю, что после отладки enter()/leave() и возможно что-то ещё из кода
> может даже лучше убирать. Но в таком виде как сейчас их наличие помогает не
> только программисту отлаживать программу, но и пользователю разобраться,
> почему не грузится система. Возможно имеет смысл перетащить в
> initrd-sh-functions?
В качестве отдельной фичи ? Если да, то в ней можно принудительно включать
rdlog=console. Если нет, то нужно её держать в памяти.
--
Rgrds, legion
01.07.2021 20:32, Alexey Gladkov пишет:
> On Thu, Jul 01, 2021 at 02:11:58PM +0300, Leonid Krivoshein wrote:
>> Всем привет!
>>
>>
>> Сейчас в bootchain есть такой код:
>>
>> initrd_version()
>> {
>> [ ! -s /etc/initrd-release ] ||
>> . /etc/initrd-release
>> local __version="${VERSION_ID-}"
>> printf '%s' "INITRAMFS${__version:+ $__version}"
>> }
>>
>> Он используется следующим образом в том же демоне:
>>
>> ...
>> exec >"$BC_LOGFILE" 2>&1
>> message "Starting server [$(initrd_version)]..."
>> ...
>>
>> В логах это обычно выглядит так:
>>
>> -----
>> Starting server [INITRAMFS 2.16.0]...
>> ...
>> -----
>>
>> На регулярках MATE сейчас почему-то вылазит совсем иное:
>>
>> -----
>> Starting server [INITRAMFS 9.1]...
>> ...
>> -----
>>
>> Понятно, что вопрос к m-p, а не make-initrd, видимо в initramfs попадает
>> какой-то другой /etc/initrd-release.
>>
>> Кроме логов проверка версии может быть полезна для реализации фрагментов
>> кода по-разному, в зависимости от версии make-initrd.
>
> Похоже кто-то в момент выполнения переопределяет $(VERSION). Ты можешь
> показать "битый" /etc/initrd-release ?
>
Я могу:
ID=make-initrd
VERSION_ID=2.19.1
NAME="make-initrd"
VERSION="9.1 make-initrd-2.19.1"
PRETTY_NAME="ALT Workstation K 9.1 (Centaurea Pineticola) make-initrd-2.19.1 (Initramfs)"
ANSI_COLOR="0;34"
--
С уважением, Антон Мидюков <antohami@basealt.ru>
01.07.2021 16:39, Alexey Gladkov пишет:
> On Thu, Jul 01, 2021 at 03:31:07PM +0300, Leonid Krivoshein wrote:
>> Всем привет!
>>
>>
>> Из-за скудности сабжа пришлось городить свой набор функций и в процессе
>> отладки они сильно выручили. С включенным bc_debug получаются вменяемые
>> отладочные журналы, не сравнить с использованием set -x. Примеры сейчас
>> можно увидеть здесь:
>> http://git.altlinux.org/people/klark/packages/make-initrd-bootchain.git в
>> подкаталоге boot-logs.
>>
>> В самом make-initrd на эту тему есть немного, например, параметр debug, от
>> которого мало что меняется в run-time, а раньше он ещё и был включен по
>> дефолту (я не знал, как отключить, поэтому ввёл свой bc_debug). Было бы
>> здорово иметь такую инфраструктуру на верхнем уровне make-initrd, доступную
>> для любых фич. Речь о примерно следующем наборе функций:
>>
>> debug() -- Вывод текстового сообщения при расширенной отладке.
>> enter() -- Трассировка при расширенной отладке: вход в указанную функцию.
>> leave() -- Трассировка при расширенной отладке: выход из указанной функции.
>> run() -- Запуск внешней команды. При расширенной отладке команда попадёт в
>> журнал.
>> fdump() -- Вывод в журнал содержимого указанного файла при расширенной
>> отладке.
>> assign() -- Присвоение переменной указанного значения, попадающее в журнал.
>>
>> message() -- уже есть, он отправляет в журнал сообщение независимо от debug.
>>
>> Я понимаю, что после отладки enter()/leave() и возможно что-то ещё из кода
>> может даже лучше убирать. Но в таком виде как сейчас их наличие помогает не
>> только программисту отлаживать программу, но и пользователю разобраться,
>> почему не грузится система. Возможно имеет смысл перетащить в
>> initrd-sh-functions?
> В качестве отдельной фичи ? Если да, то в ней можно принудительно включать
> rdlog=console. Если нет, то нужно её держать в памяти.
А почему в памяти? debug() выводит в >&2 если включен debug, остальные
функции, на нём основаны. А куда уж скрипт направит свой stderr, туда и
будет выводиться. Зачем делать это фичей, если тут просто расширение API?
--
Best regards,
Leonid Krivoshein.
01.07.2021 16:44, Антон Мидюков пишет:
> 01.07.2021 20:32, Alexey Gladkov пишет:
>> On Thu, Jul 01, 2021 at 02:11:58PM +0300, Leonid Krivoshein wrote:
>>> Всем привет!
>>>
>>>
>>> Сейчас в bootchain есть такой код:
>>>
>>> initrd_version()
>>> {
>>> [ ! -s /etc/initrd-release ] ||
>>> . /etc/initrd-release
>>> local __version="${VERSION_ID-}"
>>> printf '%s' "INITRAMFS${__version:+ $__version}"
>>> }
>>>
>>> Он используется следующим образом в том же демоне:
>>>
>>> ...
>>> exec >"$BC_LOGFILE" 2>&1
>>> message "Starting server [$(initrd_version)]..."
>>> ...
>>>
>>> В логах это обычно выглядит так:
>>>
>>> -----
>>> Starting server [INITRAMFS 2.16.0]...
>>> ...
>>> -----
>>>
>>> На регулярках MATE сейчас почему-то вылазит совсем иное:
>>>
>>> -----
>>> Starting server [INITRAMFS 9.1]...
>>> ...
>>> -----
>>>
>>> Понятно, что вопрос к m-p, а не make-initrd, видимо в initramfs попадает
>>> какой-то другой /etc/initrd-release.
>>>
>>> Кроме логов проверка версии может быть полезна для реализации фрагментов
>>> кода по-разному, в зависимости от версии make-initrd.
>> Похоже кто-то в момент выполнения переопределяет $(VERSION). Ты можешь
>> показать "битый" /etc/initrd-release ?
>>
> Я могу:
> ID=make-initrd
> VERSION_ID=2.19.1
> NAME="make-initrd"
> VERSION="9.1 make-initrd-2.19.1"
> PRETTY_NAME="ALT Workstation K 9.1 (Centaurea Pineticola) make-initrd-2.19.1 (Initramfs)"
> ANSI_COLOR="0;34"
У меня пакетная база в зеркале чуть старее и вывод сейчас такой:
NAME="ALT"
VERSION="9.1"
ID=altlinux
VERSION_ID=9.1
PRETTY_NAME="ALT Workstation K 9.1 (Centaurea Pineticola)"
ANSI_COLOR="0;33"
...
При этом я проверил, что /etc/initrd-release перед запуском make-initrd
в образ не попадает при сборке. Какая-то хитрая фича make-initrd от K-9.1?
--
Best regards,
Leonid Krivoshein.
On Thu, Jul 01, 2021 at 04:50:21PM +0300, Leonid Krivoshein wrote:
>
>
> 01.07.2021 16:39, Alexey Gladkov пишет:
> > On Thu, Jul 01, 2021 at 03:31:07PM +0300, Leonid Krivoshein wrote:
> > > Всем привет!
> > >
> > >
> > > Из-за скудности сабжа пришлось городить свой набор функций и в процессе
> > > отладки они сильно выручили. С включенным bc_debug получаются вменяемые
> > > отладочные журналы, не сравнить с использованием set -x. Примеры сейчас
> > > можно увидеть здесь:
> > > http://git.altlinux.org/people/klark/packages/make-initrd-bootchain.git в
> > > подкаталоге boot-logs.
> > >
> > > В самом make-initrd на эту тему есть немного, например, параметр debug, от
> > > которого мало что меняется в run-time, а раньше он ещё и был включен по
> > > дефолту (я не знал, как отключить, поэтому ввёл свой bc_debug). Было бы
> > > здорово иметь такую инфраструктуру на верхнем уровне make-initrd, доступную
> > > для любых фич. Речь о примерно следующем наборе функций:
> > >
> > > debug() -- Вывод текстового сообщения при расширенной отладке.
> > > enter() -- Трассировка при расширенной отладке: вход в указанную функцию.
> > > leave() -- Трассировка при расширенной отладке: выход из указанной функции.
> > > run() -- Запуск внешней команды. При расширенной отладке команда попадёт в
> > > журнал.
> > > fdump() -- Вывод в журнал содержимого указанного файла при расширенной
> > > отладке.
> > > assign() -- Присвоение переменной указанного значения, попадающее в журнал.
> > >
> > > message() -- уже есть, он отправляет в журнал сообщение независимо от debug.
> > >
> > > Я понимаю, что после отладки enter()/leave() и возможно что-то ещё из кода
> > > может даже лучше убирать. Но в таком виде как сейчас их наличие помогает не
> > > только программисту отлаживать программу, но и пользователю разобраться,
> > > почему не грузится система. Возможно имеет смысл перетащить в
> > > initrd-sh-functions?
> > В качестве отдельной фичи ? Если да, то в ней можно принудительно включать
> > rdlog=console. Если нет, то нужно её держать в памяти.
>
> А почему в памяти? debug() выводит в >&2 если включен debug, остальные
> функции, на нём основаны. А куда уж скрипт направит свой stderr, туда и
> будет выводиться. Зачем делать это фичей, если тут просто расширение API?
Держать в памяти в смысле в уме, что для отладки этот параметр стоит
указывать в cmdline.
--
Rgrds, legion
On Thu, Jul 01, 2021 at 04:59:52PM +0300, Leonid Krivoshein wrote:
> > Я могу:
> > ID=make-initrd
> > VERSION_ID=2.19.1
> > NAME="make-initrd"
> > VERSION="9.1 make-initrd-2.19.1"
> > PRETTY_NAME="ALT Workstation K 9.1 (Centaurea Pineticola) make-initrd-2.19.1 (Initramfs)"
> > ANSI_COLOR="0;34"
>
> У меня пакетная база в зеркале чуть старее и вывод сейчас такой:
>
> NAME="ALT"
> VERSION="9.1"
> ID=altlinux
> VERSION_ID=9.1
> PRETTY_NAME="ALT Workstation K 9.1 (Centaurea Pineticola)"
> ANSI_COLOR="0;33"
> ...
>
>
> При этом я проверил, что /etc/initrd-release перед запуском make-initrd в
> образ не попадает при сборке. Какая-то хитрая фича make-initrd от K-9.1?
Теперь видно, что в initrd попадает системный os-release. make-initrd
должен генерировать initrd-release, но видно я проглядел что-то.
Спасибо, буду смотреть и закручивать гайки.
--
Rgrds, legion
01.07.2021 16:32, Alexey Gladkov пишет:
> On Thu, Jul 01, 2021 at 02:11:58PM +0300, Leonid Krivoshein wrote:
>> Всем привет!
>>
>>
>> Сейчас в bootchain есть такой код:
>>
>> initrd_version()
>> {
>> [ ! -s /etc/initrd-release ] ||
>> . /etc/initrd-release
>> local __version="${VERSION_ID-}"
>> printf '%s' "INITRAMFS${__version:+ $__version}"
>> }
>>
>> Он используется следующим образом в том же демоне:
>>
>> ...
>> exec >"$BC_LOGFILE" 2>&1
>> message "Starting server [$(initrd_version)]..."
>> ...
>>
>> В логах это обычно выглядит так:
>>
>> -----
>> Starting server [INITRAMFS 2.16.0]...
>> ...
>> -----
>>
>> На регулярках MATE сейчас почему-то вылазит совсем иное:
>>
>> -----
>> Starting server [INITRAMFS 9.1]...
>> ...
>> -----
>>
>> Понятно, что вопрос к m-p, а не make-initrd, видимо в initramfs попадает
>> какой-то другой /etc/initrd-release.
>>
>> Кроме логов проверка версии может быть полезна для реализации фрагментов
>> кода по-разному, в зависимости от версии make-initrd.
> Похоже кто-то в момент выполнения переопределяет $(VERSION). Ты можешь
> показать "битый" /etc/initrd-release ?
Кстати, похожий вызов используется где-то в самом make-initrd. Заметил,
что /dev/console на этом диске сейчас выглядит так:
...
Run /init as init process
INITRAMFS: 9.1
INIT: Entering runlevel: 3
...
Это я к тому, что если есть хотя бы два "клиента", то в качестве общего
кода не помешает. Причём, не менее полезно было бы иметь функцию для
сравнения с текущей версией make-initrd, а-ля initrd_version_compare()
$1:major [, $2:minor].
--
Best regards,
Leonid Krivoshein.
On Thu, Jul 01, 2021 at 04:59:52PM +0300, Leonid Krivoshein wrote:
>
>
> 01.07.2021 16:44, Антон Мидюков пишет:
> > 01.07.2021 20:32, Alexey Gladkov пишет:
> > > On Thu, Jul 01, 2021 at 02:11:58PM +0300, Leonid Krivoshein wrote:
> > > > Всем привет!
> > > >
> > > >
> > > > Сейчас в bootchain есть такой код:
> > > >
> > > > initrd_version()
> > > > {
> > > > [ ! -s /etc/initrd-release ] ||
> > > > . /etc/initrd-release
> > > > local __version="${VERSION_ID-}"
> > > > printf '%s' "INITRAMFS${__version:+ $__version}"
> > > > }
> > > >
> > > > Он используется следующим образом в том же демоне:
> > > >
> > > > ...
> > > > exec >"$BC_LOGFILE" 2>&1
> > > > message "Starting server [$(initrd_version)]..."
> > > > ...
> > > >
> > > > В логах это обычно выглядит так:
> > > >
> > > > -----
> > > > Starting server [INITRAMFS 2.16.0]...
> > > > ...
> > > > -----
> > > >
> > > > На регулярках MATE сейчас почему-то вылазит совсем иное:
> > > >
> > > > -----
> > > > Starting server [INITRAMFS 9.1]...
> > > > ...
> > > > -----
> > > >
> > > > Понятно, что вопрос к m-p, а не make-initrd, видимо в initramfs попадает
> > > > какой-то другой /etc/initrd-release.
> > > >
> > > > Кроме логов проверка версии может быть полезна для реализации фрагментов
> > > > кода по-разному, в зависимости от версии make-initrd.
> > > Похоже кто-то в момент выполнения переопределяет $(VERSION). Ты можешь
> > > показать "битый" /etc/initrd-release ?
> > >
> > Я могу:
> > ID=make-initrd
> > VERSION_ID=2.19.1
> > NAME="make-initrd"
> > VERSION="9.1 make-initrd-2.19.1"
> > PRETTY_NAME="ALT Workstation K 9.1 (Centaurea Pineticola) make-initrd-2.19.1 (Initramfs)"
> > ANSI_COLOR="0;34"
>
> У меня пакетная база в зеркале чуть старее и вывод сейчас такой:
>
> NAME="ALT"
> VERSION="9.1"
> ID=altlinux
> VERSION_ID=9.1
> PRETTY_NAME="ALT Workstation K 9.1 (Centaurea Pineticola)"
> ANSI_COLOR="0;33"
> ...
>
>
> При этом я проверил, что /etc/initrd-release перед запуском make-initrd в
> образ не попадает при сборке. Какая-то хитрая фича make-initrd от K-9.1?
А ты можешь приаттачить make-initrd -v ... ? Никак не могу воспроизвести.
--
Rgrds, legion
[-- Attachment #1: Type: text/plain, Size: 2781 bytes --] 01.07.2021 17:48, Alexey Gladkov пишет: > On Thu, Jul 01, 2021 at 04:59:52PM +0300, Leonid Krivoshein wrote: >> 01.07.2021 16:44, Антон Мидюков пишет: >>> 01.07.2021 20:32, Alexey Gladkov пишет: >>>> On Thu, Jul 01, 2021 at 02:11:58PM +0300, Leonid Krivoshein wrote: >>>>> Всем привет! >>>>> >>>>> >>>>> Сейчас в bootchain есть такой код: >>>>> >>>>> initrd_version() >>>>> { >>>>> [ ! -s /etc/initrd-release ] || >>>>> . /etc/initrd-release >>>>> local __version="${VERSION_ID-}" >>>>> printf '%s' "INITRAMFS${__version:+ $__version}" >>>>> } >>>>> >>>>> Он используется следующим образом в том же демоне: >>>>> >>>>> ... >>>>> exec >"$BC_LOGFILE" 2>&1 >>>>> message "Starting server [$(initrd_version)]..." >>>>> ... >>>>> >>>>> В логах это обычно выглядит так: >>>>> >>>>> ----- >>>>> Starting server [INITRAMFS 2.16.0]... >>>>> ... >>>>> ----- >>>>> >>>>> На регулярках MATE сейчас почему-то вылазит совсем иное: >>>>> >>>>> ----- >>>>> Starting server [INITRAMFS 9.1]... >>>>> ... >>>>> ----- >>>>> >>>>> Понятно, что вопрос к m-p, а не make-initrd, видимо в initramfs попадает >>>>> какой-то другой /etc/initrd-release. >>>>> >>>>> Кроме логов проверка версии может быть полезна для реализации фрагментов >>>>> кода по-разному, в зависимости от версии make-initrd. >>>> Похоже кто-то в момент выполнения переопределяет $(VERSION). Ты можешь >>>> показать "битый" /etc/initrd-release ? >>>> >>> Я могу: >>> ID=make-initrd >>> VERSION_ID=2.19.1 >>> NAME="make-initrd" >>> VERSION="9.1 make-initrd-2.19.1" >>> PRETTY_NAME="ALT Workstation K 9.1 (Centaurea Pineticola) make-initrd-2.19.1 (Initramfs)" >>> ANSI_COLOR="0;34" >> У меня пакетная база в зеркале чуть старее и вывод сейчас такой: >> >> NAME="ALT" >> VERSION="9.1" >> ID=altlinux >> VERSION_ID=9.1 >> PRETTY_NAME="ALT Workstation K 9.1 (Centaurea Pineticola)" >> ANSI_COLOR="0;33" >> ... >> >> >> При этом я проверил, что /etc/initrd-release перед запуском make-initrd в >> образ не попадает при сборке. Какая-то хитрая фича make-initrd от K-9.1? > А ты можешь приаттачить make-initrd -v ... ? Никак не могу воспроизвести. Готово! -- Best regards, Leonid Krivoshein. [-- Attachment #2: initrd.log.gz --] [-- Type: application/gzip, Size: 7224 bytes --]
01.07.2021 17:48, Alexey Gladkov пишет:
> On Thu, Jul 01, 2021 at 04:59:52PM +0300, Leonid Krivoshein wrote:
>> [...]
>> У меня пакетная база в зеркале чуть старее и вывод сейчас такой:
>>
>> NAME="ALT"
>> VERSION="9.1"
>> ID=altlinux
>> VERSION_ID=9.1
>> PRETTY_NAME="ALT Workstation K 9.1 (Centaurea Pineticola)"
>> ANSI_COLOR="0;33"
>> ...
>>
>>
>> При этом я проверил, что /etc/initrd-release перед запуском make-initrd в
>> образ не попадает при сборке. Какая-то хитрая фича make-initrd от K-9.1?
> А ты можешь приаттачить make-initrd -v ... ? Никак не могу воспроизвести.
Так и у нас это почти ни на чём не воспроизводится, только на сборке
регулярок MATE. Это точно приезжает из конкретного профиля m-p.
Наверное, стоит данный файл создавать одним из первых, тогда его никто
не сможет перезаписать через PUT_FILES.
--
Best regards,
Leonid Krivoshein.
01.07.2021 22:41, Leonid Krivoshein пишет:
>
> 01.07.2021 17:48, Alexey Gladkov пишет:
>> On Thu, Jul 01, 2021 at 04:59:52PM +0300, Leonid Krivoshein wrote:
>>> [...]
>>> У меня пакетная база в зеркале чуть старее и вывод сейчас такой:
>>>
>>> NAME="ALT"
>>> VERSION="9.1"
>>> ID=altlinux
>>> VERSION_ID=9.1
>>> PRETTY_NAME="ALT Workstation K 9.1 (Centaurea Pineticola)"
>>> ANSI_COLOR="0;33"
>>> ...
>>>
>>>
>>> При этом я проверил, что /etc/initrd-release перед запуском make-initrd в
>>> образ не попадает при сборке. Какая-то хитрая фича make-initrd от K-9.1?
>> А ты можешь приаттачить make-initrd -v ... ? Никак не могу воспроизвести.
>
> Так и у нас это почти ни на чём не воспроизводится, только на сборке регулярок MATE. Это точно приезжает из конкретного профиля m-p. Наверное, стоит данный файл создавать одним из первых, тогда его никто не сможет перезаписать через PUT_FILES.
>
>
С чего это? Во всех регулярках и стартеркитах воспроизводится. А дистрибутивы стоит проверить на сей счёт. Думаю, что тоже.
--
С уважением, Антон Мидюков <antohami@basealt.ru>
On Thu, Jul 01, 2021 at 06:41:37PM +0300, Leonid Krivoshein wrote: > > 01.07.2021 17:48, Alexey Gladkov пишет: > > On Thu, Jul 01, 2021 at 04:59:52PM +0300, Leonid Krivoshein wrote: > > > [...] > > > У меня пакетная база в зеркале чуть старее и вывод сейчас такой: > > > > > > NAME="ALT" > > > VERSION="9.1" > > > ID=altlinux > > > VERSION_ID=9.1 > > > PRETTY_NAME="ALT Workstation K 9.1 (Centaurea Pineticola)" > > > ANSI_COLOR="0;33" > > > ... > > > > > > > > > При этом я проверил, что /etc/initrd-release перед запуском make-initrd в > > > образ не попадает при сборке. Какая-то хитрая фича make-initrd от K-9.1? > > А ты можешь приаттачить make-initrd -v ... ? Никак не могу воспроизвести. > > Так и у нас это почти ни на чём не воспроизводится, только на сборке > регулярок MATE. Это точно приезжает из конкретного профиля m-p. Наверное, > стоит данный файл создавать одним из первых, тогда его никто не сможет > перезаписать через PUT_FILES. Так в том-то и дело, что я создаю его почти первым. Есть подозрение, что кто-то в фиче (не из make-initrd) заменяет этот файл в rules.mk. https://github.com/osboot/make-initrd/blob/master/tools/create-initrd#L162 https://github.com/osboot/make-initrd/blob/master/tools/initrd-release -- Rgrds, legion
01.07.2021 18:51, Антон Мидюков пишет:
> 01.07.2021 22:41, Leonid Krivoshein пишет:
>> 01.07.2021 17:48, Alexey Gladkov пишет:
>>> On Thu, Jul 01, 2021 at 04:59:52PM +0300, Leonid Krivoshein wrote:
>>>> [...]
>>>> У меня пакетная база в зеркале чуть старее и вывод сейчас такой:
>>>>
>>>> NAME="ALT"
>>>> VERSION="9.1"
>>>> ID=altlinux
>>>> VERSION_ID=9.1
>>>> PRETTY_NAME="ALT Workstation K 9.1 (Centaurea Pineticola)"
>>>> ANSI_COLOR="0;33"
>>>> ...
>>>>
>>>>
>>>> При этом я проверил, что /etc/initrd-release перед запуском make-initrd в
>>>> образ не попадает при сборке. Какая-то хитрая фича make-initrd от K-9.1?
>>> А ты можешь приаттачить make-initrd -v ... ? Никак не могу воспроизвести.
>> Так и у нас это почти ни на чём не воспроизводится, только на сборке регулярок MATE. Это точно приезжает из конкретного профиля m-p. Наверное, стоит данный файл создавать одним из первых, тогда его никто не сможет перезаписать через PUT_FILES.
> С чего это? Во всех регулярках и стартеркитах воспроизводится. А дистрибутивы стоит проверить на сей счёт. Думаю, что тоже.
На JeOS и Rescue я такого не вижу, а с другими не собирал. Возможно, всё
дело в live...
Но вопрос же не в этом мелком артефакте, а в том, что если начать
полагаться на данный файл как источник информации о версии, тогда ой.
Нужен надёжный механизм в самом make-initrd, которому можно доверять,
лучше в виде готового API.
--
Best regards,
Leonid Krivoshein.
01.07.2021 18:57, Alexey Gladkov пишет:
> On Thu, Jul 01, 2021 at 06:41:37PM +0300, Leonid Krivoshein wrote:
>> 01.07.2021 17:48, Alexey Gladkov пишет:
>>> On Thu, Jul 01, 2021 at 04:59:52PM +0300, Leonid Krivoshein wrote:
>>>> [...]
>>>> У меня пакетная база в зеркале чуть старее и вывод сейчас такой:
>>>>
>>>> NAME="ALT"
>>>> VERSION="9.1"
>>>> ID=altlinux
>>>> VERSION_ID=9.1
>>>> PRETTY_NAME="ALT Workstation K 9.1 (Centaurea Pineticola)"
>>>> ANSI_COLOR="0;33"
>>>> ...
>>>>
>>>>
>>>> При этом я проверил, что /etc/initrd-release перед запуском make-initrd в
>>>> образ не попадает при сборке. Какая-то хитрая фича make-initrd от K-9.1?
>>> А ты можешь приаттачить make-initrd -v ... ? Никак не могу воспроизвести.
>> Так и у нас это почти ни на чём не воспроизводится, только на сборке
>> регулярок MATE. Это точно приезжает из конкретного профиля m-p. Наверное,
>> стоит данный файл создавать одним из первых, тогда его никто не сможет
>> перезаписать через PUT_FILES.
> Так в том-то и дело, что я создаю его почти первым. Есть подозрение, что
> кто-то в фиче (не из make-initrd) заменяет этот файл в rules.mk.
>
> https://github.com/osboot/make-initrd/blob/master/tools/create-initrd#L162
> https://github.com/osboot/make-initrd/blob/master/tools/initrd-release
У-пс! ))
# FIXME: large storage systems can get that tmpfs filled up
# with debug data as of make-initrd 2.2.12
rm -vf /usr/share/make-initrd/data/etc/udev/rules.d/00-debug.rules \
/usr/share/make-initrd/data/lib/uevent/filters/debug
Может это влиять?
--
Best regards,
Leonid Krivoshein.
01.07.2021 18:51, Антон Мидюков пишет:
> 01.07.2021 22:41, Leonid Krivoshein пишет:
>> 01.07.2021 17:48, Alexey Gladkov пишет:
>>> On Thu, Jul 01, 2021 at 04:59:52PM +0300, Leonid Krivoshein wrote:
>>>> [...]
>>>> У меня пакетная база в зеркале чуть старее и вывод сейчас такой:
>>>>
>>>> NAME="ALT"
>>>> VERSION="9.1"
>>>> ID=altlinux
>>>> VERSION_ID=9.1
>>>> PRETTY_NAME="ALT Workstation K 9.1 (Centaurea Pineticola)"
>>>> ANSI_COLOR="0;33"
>>>> ...
>>>>
>>>>
>>>> При этом я проверил, что /etc/initrd-release перед запуском make-initrd в
>>>> образ не попадает при сборке. Какая-то хитрая фича make-initrd от K-9.1?
>>> А ты можешь приаттачить make-initrd -v ... ? Никак не могу воспроизвести.
>> Так и у нас это почти ни на чём не воспроизводится, только на сборке регулярок MATE. Это точно приезжает из конкретного профиля m-p. Наверное, стоит данный файл создавать одним из первых, тогда его никто не сможет перезаписать через PUT_FILES.
>>
>>
> С чего это? Во всех регулярках и стартеркитах воспроизводится. А дистрибутивы стоит проверить на сей счёт. Думаю, что тоже.
>
В логах сборки не вижу ни VERSION, ни этого файла. Могу только сказать,
что оно так довольно давно, ещё на 2.15.0 воспроизводилось.
--
Best regards,
Leonid Krivoshein.
On Thu, Jul 01, 2021 at 07:03:36PM +0300, Leonid Krivoshein wrote:
> > Так в том-то и дело, что я создаю его почти первым. Есть подозрение, что
> > кто-то в фиче (не из make-initrd) заменяет этот файл в rules.mk.
> >
> > https://github.com/osboot/make-initrd/blob/master/tools/create-initrd#L162
> > https://github.com/osboot/make-initrd/blob/master/tools/initrd-release
>
> У-пс! ))
>
> # FIXME: large storage systems can get that tmpfs filled up
> # with debug data as of make-initrd 2.2.12
> rm -vf /usr/share/make-initrd/data/etc/udev/rules.d/00-debug.rules \
> /usr/share/make-initrd/data/lib/uevent/filters/debug
>
> Может это влиять?
Я не вижу связи. Конечно нет.
Кстати, с Jan 20 2020 этих файлов нет в make-initrd.
--
Rgrds, legion
01.07.2021 23:13, Leonid Krivoshein пишет:
>
> 01.07.2021 18:51, Антон Мидюков пишет:
>> 01.07.2021 22:41, Leonid Krivoshein пишет:
>>> 01.07.2021 17:48, Alexey Gladkov пишет:
>>>> On Thu, Jul 01, 2021 at 04:59:52PM +0300, Leonid Krivoshein wrote:
>>>>> [...]
>>>>> У меня пакетная база в зеркале чуть старее и вывод сейчас такой:
>>>>>
>>>>> NAME="ALT"
>>>>> VERSION="9.1"
>>>>> ID=altlinux
>>>>> VERSION_ID=9.1
>>>>> PRETTY_NAME="ALT Workstation K 9.1 (Centaurea Pineticola)"
>>>>> ANSI_COLOR="0;33"
>>>>> ...
>>>>>
>>>>>
>>>>> При этом я проверил, что /etc/initrd-release перед запуском make-initrd в
>>>>> образ не попадает при сборке. Какая-то хитрая фича make-initrd от K-9.1?
>>>> А ты можешь приаттачить make-initrd -v ... ? Никак не могу воспроизвести.
>>> Так и у нас это почти ни на чём не воспроизводится, только на сборке регулярок MATE. Это точно приезжает из конкретного профиля m-p. Наверное, стоит данный файл создавать одним из первых, тогда его никто не сможет перезаписать через PUT_FILES.
>>>
>>>
>> С чего это? Во всех регулярках и стартеркитах воспроизводится. А дистрибутивы стоит проверить на сей счёт. Думаю, что тоже.
>>
>
> В логах сборки не вижу ни VERSION, ни этого файла. Могу только сказать, что оно так довольно давно, ещё на 2.15.0 воспроизводилось.
>
Да, ты прав. Сейчас определюсь, у кого проблема есть, а у кого нет.
--
С уважением, Антон Мидюков <antohami@basealt.ru>
01.07.2021 21:16, Alexey Gladkov пишет: > On Thu, Jul 01, 2021 at 04:59:52PM +0300, Leonid Krivoshein wrote: >>> Я могу: >>> ID=make-initrd >>> VERSION_ID=2.19.1 >>> NAME="make-initrd" >>> VERSION="9.1 make-initrd-2.19.1" >>> PRETTY_NAME="ALT Workstation K 9.1 (Centaurea Pineticola) make-initrd-2.19.1 (Initramfs)" >>> ANSI_COLOR="0;34" Это же нормальный конфиг? >> >> У меня пакетная база в зеркале чуть старее и вывод сейчас такой: >> >> NAME="ALT" >> VERSION="9.1" >> ID=altlinux >> VERSION_ID=9.1 >> PRETTY_NAME="ALT Workstation K 9.1 (Centaurea Pineticola)" >> ANSI_COLOR="0;33" >> ... >> >> >> При этом я проверил, что /etc/initrd-release перед запуском make-initrd в >> образ не попадает при сборке. Какая-то хитрая фича make-initrd от K-9.1? > > Теперь видно, что в initrd попадает системный os-release. make-initrd > должен генерировать initrd-release, но видно я проглядел что-то. > Спасибо, буду смотреть и закручивать гайки. > У меня появилось предположение, что проблемы в новом make-initrd уже нет. Я конечно не все образы посмотрел. Но везде конфиг, как я привёл в начале письма. Посмотрел последние стартеркиты (с make-initrd 2.16). Проблемный конфиг у live с systemd. У всех этих сборок включен plymouth. -- С уважением, Антон Мидюков <antohami@basealt.ru>
01.07.2021 19:54, Антон Мидюков пишет:
> 01.07.2021 21:16, Alexey Gladkov пишет:
>> On Thu, Jul 01, 2021 at 04:59:52PM +0300, Leonid Krivoshein wrote:
>>>> Я могу:
>>>> ID=make-initrd
>>>> VERSION_ID=2.19.1
>>>> NAME="make-initrd"
>>>> VERSION="9.1 make-initrd-2.19.1"
>>>> PRETTY_NAME="ALT Workstation K 9.1 (Centaurea Pineticola) make-initrd-2.19.1 (Initramfs)"
>>>> ANSI_COLOR="0;34"
> Это же нормальный конфиг?
>
> [...]
> У меня появилось предположение, что проблемы в новом make-initrd уже нет. Я конечно не все образы посмотрел. Но везде конфиг, как я привёл в начале письма.
> Посмотрел последние стартеркиты (с make-initrd 2.16). Проблемный конфиг у live с systemd. У всех этих сборок включен plymouth.
Правильно ориентироваться на информацию от тебя, т.к. у тебя актуальный
Сизиф и сборка всех образов. У меня зеркало устарело. Сейчас соберу
make-initrd 2.19.1, bootchain посвежее, и образы с ним, тоже буду
проверять, заодно поразбираюсь с плимутом и консолью. Я-то надеялся, что
исправления окажут влияние и на мои проблемы, ан нет, у меня всё хорошо
было, вплоть до 2.16.0, теперь надо разбираться.
--
Best regards,
Leonid Krivoshein.
On Thu, Jul 01, 2021 at 11:54:18PM +0700, Антон Мидюков wrote: > 01.07.2021 21:16, Alexey Gladkov пишет: > > On Thu, Jul 01, 2021 at 04:59:52PM +0300, Leonid Krivoshein wrote: > >>> Я могу: > >>> ID=make-initrd > >>> VERSION_ID=2.19.1 > >>> NAME="make-initrd" > >>> VERSION="9.1 make-initrd-2.19.1" > >>> PRETTY_NAME="ALT Workstation K 9.1 (Centaurea Pineticola) make-initrd-2.19.1 (Initramfs)" > >>> ANSI_COLOR="0;34" > > Это же нормальный конфиг? Да. Этот конфиг сгенерирован make-initrd. > >> > >> У меня пакетная база в зеркале чуть старее и вывод сейчас такой: > >> > >> NAME="ALT" > >> VERSION="9.1" > >> ID=altlinux > >> VERSION_ID=9.1 > >> PRETTY_NAME="ALT Workstation K 9.1 (Centaurea Pineticola)" > >> ANSI_COLOR="0;33" > >> ... Этот явно из системы и к слову не выглядит правильным согласно документации на os-release [1]. Кажется содержимое должно быть: PRETTY_NAME="ALT Workstation K 9.1 (Centaurea Pineticola)" NAME="ALT" VERSION="9.1 (Centaurea Pineticola)" VERSION_ID="9.1" VERSION_CODENAME="Centaurea Pineticola" VARIANT="Workstation" VARIANT_ID=workstation Но вам виднее. [1] https://www.freedesktop.org/software/systemd/man/os-release.html > >> > >> При этом я проверил, что /etc/initrd-release перед запуском make-initrd в > >> образ не попадает при сборке. Какая-то хитрая фича make-initrd от K-9.1? > > > > Теперь видно, что в initrd попадает системный os-release. make-initrd > > должен генерировать initrd-release, но видно я проглядел что-то. > > Спасибо, буду смотреть и закручивать гайки. > > > > У меня появилось предположение, что проблемы в новом make-initrd уже > нет. Я конечно не все образы посмотрел. Но везде конфиг, как я привёл в > начале письма. Посмотрел последние стартеркиты (с make-initrd 2.16). > Проблемный конфиг у live с systemd. У всех этих сборок включен plymouth. Проблемного конфига нет с последним make-initrd и с systemd ? -- Rgrds, legion
02.07.2021 00:18, Alexey Gladkov пишет: > On Thu, Jul 01, 2021 at 11:54:18PM +0700, Антон Мидюков wrote: >> 01.07.2021 21:16, Alexey Gladkov пишет: ... >>>> >>>> При этом я проверил, что /etc/initrd-release перед запуском make-initrd в >>>> образ не попадает при сборке. Какая-то хитрая фича make-initrd от K-9.1? >>> >>> Теперь видно, что в initrd попадает системный os-release. make-initrd >>> должен генерировать initrd-release, но видно я проглядел что-то. >>> Спасибо, буду смотреть и закручивать гайки. >>> >> >> У меня появилось предположение, что проблемы в новом make-initrd уже >> нет. Я конечно не все образы посмотрел. Но везде конфиг, как я привёл в >> начале письма. Посмотрел последние стартеркиты (с make-initrd 2.16). >> Проблемный конфиг у live с systemd. У всех этих сборок включен plymouth. > > Проблемного конфига нет с последним make-initrd и с systemd ? > Да. Не наблюдаю пока. В регулярках с make-initrd 2.18 тоже не нашёл. -- С уважением, Антон Мидюков <antohami@basealt.ru>
01.07.2021 20:21, Антон Мидюков пишет:
> 02.07.2021 00:18, Alexey Gladkov пишет:
>> On Thu, Jul 01, 2021 at 11:54:18PM +0700, Антон Мидюков wrote:
>>> 01.07.2021 21:16, Alexey Gladkov пишет:
> ...
>>>>> При этом я проверил, что /etc/initrd-release перед запуском make-initrd в
>>>>> образ не попадает при сборке. Какая-то хитрая фича make-initrd от K-9.1?
>>>> Теперь видно, что в initrd попадает системный os-release. make-initrd
>>>> должен генерировать initrd-release, но видно я проглядел что-то.
>>>> Спасибо, буду смотреть и закручивать гайки.
>>>>
>>> У меня появилось предположение, что проблемы в новом make-initrd уже
>>> нет. Я конечно не все образы посмотрел. Но везде конфиг, как я привёл в
>>> начале письма. Посмотрел последние стартеркиты (с make-initrd 2.16).
>>> Проблемный конфиг у live с systemd. У всех этих сборок включен plymouth.
>> Проблемного конфига нет с последним make-initrd и с systemd ?
>>
> Да. Не наблюдаю пока. В регулярках с make-initrd 2.18 тоже не нашёл.
Да, с версией ситуация в 2.19.1 нормализовалась. У меня всё хорошо с
новым bootchain и плимутом. Проблема у плимута + rdshell. Иногда
зависаем, а если попадаем в rdshell, то не работает или почти не
работает клавиатурный ввод. Стоит запустить с rdshell nosplash и всё
чудесно. Антон похожие проблемы сегодня описывал с консолью initeractive
на старом задании. Пробовал собирать с kbd и без...
--
Best regards,
Leonid Krivoshein.
01.07.2021 20:45, Leonid Krivoshein пишет:
>
> 01.07.2021 20:21, Антон Мидюков пишет:
>> 02.07.2021 00:18, Alexey Gladkov пишет:
>>> Проблемного конфига нет с последним make-initrd и с systemd ?
>>>
>> Да. Не наблюдаю пока. В регулярках с make-initrd 2.18 тоже не нашёл.
>
> Да, с версией ситуация в 2.19.1 нормализовалась. У меня всё хорошо с
> новым bootchain и плимутом. Проблема у плимута + rdshell. Иногда
> зависаем, а если попадаем в rdshell, то не работает или почти не
> работает клавиатурный ввод. Стоит запустить с rdshell nosplash и всё
> чудесно. Антон похожие проблемы сегодня описывал с консолью
> initeractive на старом задании. Пробовал собирать с kbd и без...
>
У меня воспроизвелось и на свежеустановленной rootfs с grub. И у Антона
на ещё более свежем Сизифе: если подобное повторится ещё у кого-то, то
догадка в том, что plymouthd --tty=tty1 дерутся за одну консоль с
rdshell, который вроде как на /dev/console, но попытка перекинуть его на
другой TTY ни к чему не приводит, а тут какие-то рейсы, из-за которых
либо почти не работает клавиатурный ввод, либо происходит зависание
из-за блокировок консоли. Конечно, вариант отключать plymouth, если
нужен rdshell. Но тогда что делать с интерактивной консолью? Похоже,
плимут недовылечили... ((
--
Best regards,
Leonid Krivoshein.
02.07.2021 01:31, Leonid Krivoshein пишет:
>
> 01.07.2021 20:45, Leonid Krivoshein пишет:
>>
>> 01.07.2021 20:21, Антон Мидюков пишет:
>>> 02.07.2021 00:18, Alexey Gladkov пишет:
>>>> Проблемного конфига нет с последним make-initrd и с systemd ?
>>>>
>>> Да. Не наблюдаю пока. В регулярках с make-initrd 2.18 тоже не нашёл.
>>
>> Да, с версией ситуация в 2.19.1 нормализовалась. У меня всё хорошо с новым bootchain и плимутом. Проблема у плимута + rdshell. Иногда зависаем, а если попадаем в rdshell, то не работает или почти не работает клавиатурный ввод. Стоит запустить с rdshell nosplash и всё чудесно. Антон похожие проблемы сегодня описывал с консолью initeractive на старом задании. Пробовал собирать с kbd и без...
>>
>
> У меня воспроизвелось и на свежеустановленной rootfs с grub. И у Антона на ещё более свежем Сизифе: если подобное повторится ещё у кого-то, то догадка в том, что plymouthd --tty=tty1 дерутся за одну консоль с rdshell, который вроде как на /dev/console, но попытка перекинуть его на другой TTY ни к чему не приводит, а тут какие-то рейсы, из-за которых либо почти не работает клавиатурный ввод, либо происходит зависание из-за блокировок консоли. Конечно, вариант отключать plymouth, если нужен rdshell. Но тогда что делать с интерактивной консолью? Похоже, плимут недовылечили... ((
>
>
Я думаю, что это инициализация фреймбуфера ломает rdshell. Не нужно запускать plymouth, если загружаемся в rdshell.
--
С уважением, Антон Мидюков <antohami@basealt.ru>