Created attachment 22281 [details] скрин ошибки Говорит, не найден init. Пробовал на текущем профиле К.
Created attachment 22282 [details] опции загрузки
Не будет работать by design. Только в rescue образе работает. Прибит к sysvinit.
Получается, у нас сейчас по сути пока нет use/mediacheck.
А ещё use/mediacheck у меня образ 10379M превращает в 11170M.
(Ответ для Sergey V Turchin на комментарий #4) > А ещё use/mediacheck у меня образ 10379M превращает в 11170M. Ааа, ну да. На диске появляется отдельный образ 809652K.
(Ответ для Sergey V Turchin на комментарий #5) > (Ответ для Sergey V Turchin на комментарий #4) > > А ещё use/mediacheck у меня образ 10379M превращает в 11170M. > Ааа, ну да. На диске появляется отдельный образ 809652K. Ну, кстати, можно попробовать поправить, чтобы в этот отдельный образ не прилетало systemd попробовать. Но нужно ли? Было бы лучше проверять в initrd. Но в initrd уже сейчас можно проверять хеш сквоша sha256sum. Достаточно ли проверки хеша сквоша? Или надо md5sum iso образа проверять?
(Ответ для Антон Мидюков на комментарий #6) > можно попробовать поправить, чтобы в этот отдельный образ не прилетало systemd попробовать. Не понял. > Было бы лучше проверять в initrd. Но в initrd уже сейчас можно проверять хеш > сквоша sha256sum. Достаточно ли проверки хеша сквоша? Думаю, да. Если за его пределами что-то сломано, оно, скорее всего, уже воспроизвелось или не страшно.
(Ответ для Sergey V Turchin на комментарий #7) > (Ответ для Антон Мидюков на комментарий #6) > > можно попробовать поправить, чтобы в этот отдельный образ не прилетало systemd попробовать. > Не понял. Хорошо бы не делать отдельный образ, а проверять на том же самом live, где всё.
(Ответ для Sergey V Turchin на комментарий #8) > (Ответ для Sergey V Turchin на комментарий #7) > > (Ответ для Антон Мидюков на комментарий #6) > > > можно попробовать поправить, чтобы в этот отдельный образ не прилетало systemd попробовать. > > Не понял. > Хорошо бы не делать отдельный образ, а проверять на том же самом live, где > всё. Тогда варианта два: 1. Запаковать сервис и, возможно, цель для systemd (доработать пакет isomd5sum). 2. Делать это вообще в initrd (доработать make-initrd-bootchain).
(Ответ для Sergey V Turchin на комментарий #7) > (Ответ для Антон Мидюков на комментарий #6) > > Было бы лучше проверять в initrd. Но в initrd уже сейчас можно проверять хеш > > сквоша sha256sum. Достаточно ли проверки хеша сквоша? > Думаю, да. Если за его пределами что-то сломано, оно, скорее всего, уже > воспроизвелось или не страшно. Если этого достаточно, нужно лишь немного доработать mkimage-profiles.
Ааа, файлы пакетов же снаружи скваш-образа. При ним тоже нужно пройтись. Нередко видел, что при сбое установки ругается на checksum какого-нибудь пакета.
(Ответ для Антон Мидюков на комментарий #9) > 2. Делать это вообще в initrd (доработать make-initrd-bootchain). Думаю, что надо делать именно так, потому что: - нужно проверять как можно раньше, до загрузки второй стадии дело может и не дойти - initrd из-за лишних 100 кБ не разжирнеет, в live то пакет целиком будет попадать. А тут только маленькая утилита и маленькая библиотека.
В пропагаторе ничего специального не было для работы фичи mediacheck, только параметр hash=<sha256sum> и stagename=<mediacheck>. В altboot нет поддержки загрузки сквошей с произвольным именем, но необходимый функционал уже реализован на altboot-шаге checksum для stagename=rescue и возможно даже любого другого (поддерживаются только altinst, live и rescue). Причём реализован в более расширенном варианте, например, можно менять тип контрольной суммы -- см. стр. 32 PDF. В режиме "Rescue Forensic" можно в этом легко убедиться. Так что, в итоге, отдельный сквош для mediacheck вообще не нужен, поскольку проверка уже реализована в initrd с вполне приемлемой индикацией. Осталось только это проверить и в случае подтверждения подпилить m-p: поменять stagename и добавить hash=...
Забыл сказать, что проверять можно не только сквош второй стадии загрузки, но и целый ISO-образ, если параметрами определена загрузка с него.
(Ответ для Leonid Krivoshein на комментарий #13) > В пропагаторе ничего специального не было для работы фичи mediacheck, только > параметр hash=<sha256sum> и stagename=<mediacheck>. В altboot нет поддержки > загрузки сквошей с произвольным именем, но необходимый функционал уже > реализован на altboot-шаге checksum для stagename=rescue и возможно даже > любого другого (поддерживаются только altinst, live и rescue). Причём > реализован в более расширенном варианте, например, можно менять тип > контрольной суммы -- см. стр. 32 PDF. В режиме "Rescue Forensic" можно в > этом легко убедиться. Так что, в итоге, отдельный сквош для mediacheck > вообще не нужен, поскольку проверка уже реализована в initrd с вполне > приемлемой индикацией. Осталось только это проверить и в случае > подтверждения подпилить m-p: поменять stagename и добавить hash=... Про хеши я в курсе. Это надо mkimage-profiles немножко поправить. Но тут задача другая. Предлагается реализовать новую функциональность проверки iso целиком при помощи утилиты checkisomd5. Вижу это так: При наличии mediacheck в kernel cmdline запускается дополнительный шаг с проверкой утилитой checkisomd5. Запускается после обнаружения целевого iso и до поиска сквоша. Для методов cdrom и disk только.
(Ответ для Leonid Krivoshein на комментарий #14) > Забыл сказать, что проверять можно не только сквош второй стадии загрузки, > но и целый ISO-образ, если параметрами определена загрузка с него. Это если мы его монтируем. hash iso образа внутри iso-образа прописать невозможно. Единственный известный мне вариант - использовать инструмент isomd5sum.
Если программа выводит информацию по аналогии с md5sum, можно попробовать так: [/etc/initrd.mk] PUT_FILES += /usr/bin/checkisomd5 в параметрах загрузки использовать hash=checkisomd5:-:/путь/к/yстройству-или-образу.iso Только, боюсь, в altboot своя индикация и он читает устройство/файл целиком: https://github.com/klark973/make-initrd-bootchain/blob/sisyphus/bootchain-altboot/data/lib/bootchain/checksum , так что, если не будет идей, как реализовать интерфейсную часть загрузки в этом модуле (или каким-то отдельным модулем), то я пока не очень представляю реализацию в initrd. По документации непонятно, по ldd вижу, что тянет он только libpopt.so.0.
> пока не очень представляю реализацию в initrd Поясню: с какими именно параметрами сейчас запускается checkisomd5 в mediacheck? С какими параметрами запускается implantisomd5 при создании ISO-образа? И что делать после проверки ISO-образа, в зависимости от результата: https://github.com/rhinstaller/isomd5sum/blob/master/checkisomd5.c#L76
(Ответ для Leonid Krivoshein на комментарий #18) > > пока не очень представляю реализацию в initrd > Поясню: с какими именно параметрами сейчас запускается checkisomd5 в > mediacheck? Смотреть пакет startup-mediacheck https://git.altlinux.org/gitoskop/#/gears/s/startup-mediacheck.git/-/blob/c5afd55731c56a48e1949ae077a871acdd0fd0eb/startup-mediacheck/rc.sysinit.mediacheck checkisomd5 --gauge "$dev" 2>&1 | while read i; do case "$i" in [0-9]*) printf '\b\b\b\b%3s%%' $i;; *PASS.) echo_success; say_OK; RETVAL=0;; *FAIL.) echo_failure; say_NO; RETVAL=1;; *NA.) echo_passed; RETVAL=2;; esac done > С какими параметрами запускается implantisomd5 при создании ISO-образа? Только путь до iso указывается: implantisomd5 "$(IMAGEDIR)/$(IMAGE_OUTFILE)" > И что делать после проверки ISO-образа, в зависимости от результата: > https://github.com/rhinstaller/isomd5sum/blob/master/checkisomd5.c#L76 Выдать ошибку, кнопки прервать и продолжить.
(In reply to Антон Мидюков from comment #19) > (Ответ для Leonid Krivoshein на комментарий #18) > > > пока не очень представляю реализацию в initrd > > Поясню: с какими именно параметрами сейчас запускается checkisomd5 в > > mediacheck? > > checkisomd5 --gauge "$dev" 2>&1 | while read i; do > case "$i" in > [0-9]*) printf '\b\b\b\b%3s%%' $i;; > *PASS.) echo_success; say_OK; RETVAL=0;; > *FAIL.) echo_failure; say_NO; RETVAL=1;; > *NA.) echo_passed; RETVAL=2;; > esac > done > Здесь игнорируются пустые строки и не делается разницы между некоторыми ошибками и отменой проверки. Очевидно в этом случае загрузка продолжится при любом раскладе. > > С какими параметрами запускается implantisomd5 при создании ISO-образа? > Только путь до iso указывается: > implantisomd5 "$(IMAGEDIR)/$(IMAGE_OUTFILE)" Да, теперь понятно: --supported-iso как для Анаконды не вживляется. > > И что делать после проверки ISO-образа, в зависимости от результата: > Выдать ошибку, кнопки прервать и продолжить. Попробую реализовать такой вариант: шаг mediacheck в altboot аналогичный checksum с похожим интерфейсом. Активируется только при установке фичи make-initrd-bootchain-mediacheck и наличии отдельного параметра mediacheck. На первом этапе будет выполняться checkisomd5 --md5sumonly с подавлением вывода: при ненулевом коде возврата проверка молча пропускается. Т.е. условие выполнение шага: наличие mediacheck в /proc/cmdline и наличие вживлённой контрольной суммы. При нажатии Esc, проверка молча прерывается и загрузка продолжается со следующего шага. При несовпадении MD5, задействуется стандартный фатальный выход altboot с последующей перезагрузкой. (In reply to Антон Мидюков from comment #15) > Для методов cdrom и disk только. Почему это должно зависеть от метода? Утилита проверяет файлы точно так же, как и устройства, к тому же есть целых три способа проверку отключить: не использовать фичу, не использовать параметр и не вживлять контрольную сумму.
Вообще, должен ли модуль make-initrd-bootchain-mediacheck быть отдельно включаемым в initrd по запросу? По умолчанию, make-initrd-bootchain подтягивает по зависимостям в initrd все существующие модули, кроме документации.
(Ответ для Leonid Krivoshein на комментарий #21) > Вообще, должен ли модуль make-initrd-bootchain-mediacheck быть отдельно > включаемым в initrd по запросу? По умолчанию, make-initrd-bootchain > подтягивает по зависимостям в initrd все существующие модули, кроме > документации. Я думал? они все включаются только если их прописать в FEATURES. Если это не так это отдельная проблема.
(Ответ для Leonid Krivoshein на комментарий #20) > (In reply to Антон Мидюков from comment #15) > > Для методов cdrom и disk только. > Почему это должно зависеть от метода? Утилита проверяет файлы точно так же, > как и устройства, к тому же есть целых три способа проверку отключить: не > использовать фичу, не использовать параметр и не вживлять контрольную сумму. А что будет, если вживлённая чексумма не будет обнаружена? При сетевой загрузке iso нет. И что будет при конвертации в другую файловую систему?
(In reply to Антон Мидюков from comment #22) > Я думал? они все включаются только если их прописать в FEATURES. Если это не > так это отдельная проблема. Так всегда было by design, о чём говорится даже в документации. Чтобы собрать самый универсальный initrd, достаточно поставить один мета-пакет make-initrd-bootchain. А фичи make-initrd -- это другое, их нужно прописывать явно, но с пакетными зависимостями они не связаны. См. SPEC: https://github.com/klark973/make-initrd-bootchain/blob/sisyphus/make-initrd-bootchain.spec#L22 Другое дело, что выделить это в отдельную фичу пока кажется не самым очевидным решением. По сути, речь о том, что для этой фичи изменения будут во всех имеющихся и будущих фичах. Единственное место, где такой шаг можно запланировать заранее, оказался download для методов ftp/http при type=iso, т.е. при загрузке всего ISO-образа в TMPFS. В остальных случаях место этой проверки где-то до вызова lomount в каждом методе (в коде соответсвущих этим методам модулей), причём, самое скверное в localdev, поскольку там монтируется не весь ISO, а как бы первый раздел ISO Hybrid, после чего выполняются другие быстрые и простые проверки на смонтированном (разделе!), типа fuid и наличие файла стадии. Проверять КС нужно после этого, т.е. временно придётся перемонтировать ISO-образ. (In reply to Антон Мидюков from comment #23) > А что будет, если вживлённая чексумма не будет обнаружена? Поскольку во всех случаях checkisomd5 проверяет файл ISO-образа до его монтирования либо ещё не смонтированное устройство, а по другому эта утилита не умеет работать, то весь ISO-образ целиком так или иначе к этому моменту уже загружен. Если он не изменялся, то деться ей оттуда некуда, она зашивается в незанятые стандартом сектора в пределах первых 32Кб. Так что проверка верная: если сумма не зашита, двигаемся дальше без этой проверки. > При сетевой загрузке iso нет. Там очень много вариантов. В следующих случаях проверка целесообразна: 1. Метод cdrom: оригинальный DVD-ROM или образ, записанный на флешку. 2. Метод disk: то же самое, плюс отдельный файл ISO-образа на файловой системе. 3. Методы cifs и nfs: В случаях, когда на смонтированной файловой системе не изменённый и не распакованный ISO-образ, а не каталог. 4. Методы ftp и http: как описал выше: при type=iso образ целиком загружается сначала на tmpfs, здесь тоже ничего не мешает выполнить эту проверку. И как раз тут встал вопрос, нужно ли выполнять проверку КС сквоша после этой проверки? Мне кажется излишним, т.е. либо параметр mediacheck работает, либо параметр hash=... > И что будет при конвертации в другую файловую систему? Утилита сама залазит в начальные сектора ISO-образа. При его конвертировании в другой ISO-образ, нужно имплантировать новую КС в этот новый образ. Если же целевой системой будет не ISO-9660, то с ними утилита не работает, так что ничего страшного не случится, параметр mediacheck будет просто проигнорирован. В том числе, исходя из того, что вкорячивать её придётся только в определённые места, когда мы имеем дело с оригинальным не смонтированным и не распакованным ISO-образом.
(Ответ для Leonid Krivoshein на комментарий #24) > (In reply to Антон Мидюков from comment #22) > > Я думал? они все включаются только если их прописать в FEATURES. Если это не > > так это отдельная проблема. > Так всегда было by design, о чём говорится даже в документации. Чтобы > собрать самый универсальный initrd, достаточно поставить один мета-пакет > make-initrd-bootchain. А фичи make-initrd -- это другое, их нужно > прописывать явно, но с пакетными зависимостями они не связаны. См. SPEC: > https://github.com/klark973/make-initrd-bootchain/blob/sisyphus/make-initrd- > bootchain.spec#L22 Я тебя не правильно понял. К пакетным зависимостям вопросов нет. > > Другое дело, что выделить это в отдельную фичу пока кажется не самым > очевидным решением. По сути, речь о том, что для этой фичи изменения будут > во всех имеющихся и будущих фичах. Ну, тогда не будем выделять, раз это не имеет смысла. > > Единственное место, где такой шаг можно запланировать заранее, оказался > download для методов ftp/http при type=iso, т.е. при загрузке всего > ISO-образа в TMPFS. В остальных случаях место этой проверки где-то до вызова > lomount в каждом методе (в коде соответсвущих этим методам модулей), причём, > самое скверное в localdev, поскольку там монтируется не весь ISO, а как бы > первый раздел ISO Hybrid, после чего выполняются другие быстрые и простые > проверки на смонтированном (разделе!), типа fuid и наличие файла стадии. > Проверять КС нужно после этого, т.е. временно придётся перемонтировать > ISO-образ. > > (In reply to Антон Мидюков from comment #23) > > А что будет, если вживлённая чексумма не будет обнаружена? > Поскольку во всех случаях checkisomd5 проверяет файл ISO-образа до его > монтирования либо ещё не смонтированное устройство, а по другому эта утилита > не умеет работать, то весь ISO-образ целиком так или иначе к этому моменту > уже загружен. Если он не изменялся, то деться ей оттуда некуда, она > зашивается в незанятые стандартом сектора в пределах первых 32Кб. Так что > проверка верная: если сумма не зашита, двигаемся дальше без этой проверки. > > > При сетевой загрузке iso нет. > Там очень много вариантов. В следующих случаях проверка целесообразна: > > 1. Метод cdrom: оригинальный DVD-ROM или образ, записанный на флешку. > 2. Метод disk: то же самое, плюс отдельный файл ISO-образа на файловой > системе. > 3. Методы cifs и nfs: В случаях, когда на смонтированной файловой системе не > изменённый и не распакованный ISO-образ, а не каталог. > 4. Методы ftp и http: как описал выше: при type=iso образ целиком > загружается сначала на tmpfs, здесь тоже ничего не мешает выполнить эту > проверку. И как раз тут встал вопрос, нужно ли выполнять проверку КС сквоша > после этой проверки? Мне кажется излишним, т.е. либо параметр mediacheck > работает, либо параметр hash=... > > > И что будет при конвертации в другую файловую систему? > Утилита сама залазит в начальные сектора ISO-образа. При его конвертировании > в другой ISO-образ, нужно имплантировать новую КС в этот новый образ. Если > же целевой системой будет не ISO-9660, то с ними утилита не работает, так > что ничего страшного не случится, параметр mediacheck будет просто > проигнорирован. В том числе, исходя из того, что вкорячивать её придётся > только в определённые места, когда мы имеем дело с оригинальным не > смонтированным и не распакованным ISO-образом. Тогда всё хорошо.
PoC фичи можно посмотреть тут: https://github.com/klark973/make-initrd-bootchain/commit/edbc232e8475dc48c0a0f5a40b88c862ec6b1e97
И ещё три улучшения к нему: https://github.com/klark973/make-initrd-bootchain/commit/22749d14cfa86ec0749f1c43e70c01e3f66c8e7f (добавил зависимость на пакет isomd5sum, README фичи и кое-что переделал: теперь КС сквоша или всего ISO, передаваемая через параметр hash=..., не будет проверяться только в том случае, если mediacheck был успешно пройден и не отменён пользователем). Два этих коммита планирую слить в один и смержить в sisyphus после проверки, сверху добавится ещё несколько коммитов по связанному багу и актуализации документации до создания новой версии. Подписывать пакеты и собирать их локально у меня возможность пока сохраняется.
Финальный вариант фичи собран в таске #435065. Если возражений не будет, отправлю в таком виде в сизиф. В сравнении с проверенным, изменения косметические, на работу не должны повлиять.
make-initrd-bootchain-0.1.5-alt32 -> sisyphus: Thu Oct 08 2026 Leonid Krivoshein <klark@altlinux> 0.1.5-alt32 - redesign interaction with rootdelay (ALT #60861) - add a new feature 'mediacheck' (ALT #60692)
