Как сменить дефолтный загрузчик в новых версиях openSUSE 15.5 с grub2 на isolinux с поддержкой gfx?1

Pусский (Russian) Общий
,
#1

В старых версиях openSuSE 13-43-15.0 по умолчанию на сколько я понял использовался загрузчик isolinux,
а начиная с openSuSE 15.1-15.5 используется grub2, при этом значение опции в конфигурационном файле config.kiwi

<preferences><type firmware="uefi"><bootloader name=isolinux console=”gfxterm">

не работает и логах четко видно

EXEC: [/usr/bin/xorriso -application_id 0x6c234f61 -publisher SUSE LINUX GmbH -preparer_id KIWI - https://github.com/OSInside/kiwi -volid MyLiveOS -joliet on -padding 0 -outdev /usr/src/packages/KIWI-iso/MyLiveOS.iso -map /usr/src/packages/KIWI-iso/live-media.y0768wkl / -chmod 0755 / --                    -boot_image grub     bin_path=boot/x86_64/loader/eltorito.img -boot_image grub       grub2_mbr=/usr/src/packages/KIWI-iso/live-media.y0768wkl/boot/x86_64//loader/boot_hybrid.img -boot_image grub     grub2_boot_info=on -boot_image any partition_offset=16               -boot_image any cat_path=boot/x86_64/boot.catalog -boot_image any cat_hidden=on -boot_image any boot_info_table=on -boot_image any platform_id=0x00 -boot_image any emul_type=no_emulation -boot_image any load_size=2048 -append_partition 2 0xef /usr/src/packages/KIWI-iso/efi-loader.kq5k0va1                 -boot_image any next -boot_image any efi_path=--interval:appended_partition_2:all:: -boot_image any platform_id=0xef -boot_image any emul_type=no_emulation]

Некоторые сразу стрегиряться, что установлено то

firmware="uefi"

и значит правильно что используется grub2, но в старых версиях openSuSE 13-43-15.0 все работало именно так и с таким вот настройками без проблем !!!

ВОПРОС: Как в openSuSE 15.5 при сборке Live образа в OBS с помощью config.kiwi прописать/указать использование именнно загрузчика isolinux с поддержкой gfxboot меню ?

PS: В официальных сборках isolinux оставили лишь в сборках NET и DVD, но они формируются на основе особых файлов config.kiwi с недокументированным функционалом и отстствием вызова своего скрипта для модификации сборки.

000
0003000×1352 272 KB

#2

Интересно, сколько раз вы собираетесь задавать один и тот же вопрос?

Ваш вопрос в заголовке темы похож на вопрос Карлсона - “когда ты перестала пить коньяк по утрам”. В Leap 15.5 ничего менять не надо, потому что образ Leap 15.5 использует isolinux в режиме Legacy BIOS.

Вы смешиваете теплое с мягким.

Как я вам уже отвечал два раза в ваших двух предыдущих темах, при сборке с помощью kiwi будет использоваться grub2 если образ генерируется под EFI и isolinux если образ генерируется под legacy BIOS. Никакого отношения к несуществующему дистрибутиву “openSuSE 15.5” это не имеет, а имеет отношение только к версии kiwi. Если нужен isolinux при сборке для EFI, используйте старую версию kiwi.

Выбор загрузчика работает только при генерации образа HDD. При генерации ISO выбор загрузчика полностью определяется встроенной логикой kiwi и указанные опции на него не влияют. Увы. недостаток документации.

#3

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

Вот это дельное замечание, за это спасибо, учту (просто еще не пробовал на данных момент в этот раз собирать установщик и сборки под виртуалки, т.к. как всегда сосредоточил свое внимание в первую очередь именно на Live сборках)

А вот тут вы не правы и в очередной раз мне отвечаете одинаково по сути, а я ведь вам уже приводил примеры и конкретно сейчас в этотой теме тоже написал и прикрепил скрины

Вот же не скринах привел пример внешнего вида итогового ISO, который генерится на основе одного и того же config.kiwi файла одной и той же версии, единственное что меняется так это раздел где указывается из какой версии дистрибутива брать пакеты 13.2, 43.3, 15.0, 15.5

Еще раз повторю, что в старых версиях при использовании даже firmware=“uefi” у меня по факту загрузчик был isolinux и при этом gfx работал !!! Если, как вы говорите в новой версии openSuSE 15.5 для того чтобы у меня был загрузчки isolinux мне нужно изменить значение этой опции на firmware=“bios” ну хорошо, пусть так, но в этом случае gfx - НЕ РАБОТАЕТ, внутри содержимого ISO даже не генерятся папки с grub2 и темами откуда там посасывается все барахло для gfx.

И я очень надеюсь что при этом выставляя данную опцию в это значение как вы рекомендуете firmware=“bios” я смогу потом загрузиться в Live режиме с ISO на ПК в которых присутствует исключительно только один единственный режим UEFI.

#4

Какая то каша. Я не знаю, что именно вы называете “gfx”. С параметром firmware="bios" kiwi использует isolinux с модулем gfxboot. Поскольку grub2 в этом случае не используется, естественно для него ничего и не генерируется. Почему вы решили, что “папки grub2” имеют какое-то отношение к gfxboot, я не знаю.

Если у вас вопрос - как добавить (тему) gfxboot к образу с isolinux - так и говорите.

Нет, не сможете, и я вам про это уже говорил. И на таких ПК вы в любом случае не увидите того загрузчика, который вам требуется, потому что он там не работает.

  • Приборы!
  • 100!
  • Что 100?
  • А что приборы?

Если это образы, которые собрали вы - дайте ссылку на ваши проекты. Или объясните, что это за образы, с которых сделаны картинки.

#5

На данный момент изучив различные логи сборок как свои так и чужие и оригинальный официальные
различных версий SuSE 13.2 43.3 15.0 15.1-15.5 основное отличие в логах которое явно влияет на загрузчик
это параметры при вызове /usr/bin/xorriso при этом совершенно не важно что именно прописано в
опиции firmware в конфигурационном файле, поскольку начиная с версии SuSE 15.1 разработчики
явно что-то изменили в правилах-скриптах сборки.

Если раньше в одном файле ISO использовалось два загрузчика isolinux + grub,
при чем isolinux использовался для Legacy, а grub - для UEFI, то теперь и для того
и для другого режима используется исключительно только grub.

В старых версиях SuSE 13.2 43.3 15.0 сами файлы згарзчика от версии к версии изменялись,
как минимум просто указывалась циферка текущего релиза, таким образом для релиза
SuSE 15.0 в загрузочных файлах встречается упоминание именно 15.0 (данное утверждение относится к Legacy режиму).

При этом, хоть в версих 15.1-15.5 используется для режимом Legacy и UEFI единый загрузчик

  • grub, официальные сборки NET и DVD по прежнему продолжают собираться по старой схеме,
    т.е. isolinux + grub для соответствующих режимов. Хоть непосредственно логи для этих сборок недоступны,
    т.к. собираются из особого недокоментированного конфигурационного файла KIWI,
    но если изучить содержимое сгенерированного ISO файла, то данный факт легко прослеживается.
    Непонятным моментом остается лишь вопрос, почему в подобного рода сборках разработчики
    продолжают использовать видоизменные файлы для загрузчика работающего в режиме Legacy,
    но при этом не изменили его версию на текущую релизную 15.5 и даже не 15.0, а почему-то
    используют 13.2

Поскольку самый казалось бы простой вариант изменения файлов конфигурационных и картинок
в любой официальной сборке ISO файле поддерживающей оба загрузчика isolinux + grub для режимов Legacy и UEFI
т.е. допустим 15.0 - не работает, точнее ISO образ после такого рефакторинга с помощью UltraISO
хоть и загружается, и даже отображает нужный вид меню, но вот дальнейшая работа становится невозможной,
т.к. сам файл LiveOS\squashfs.img перестает загружаться, хотя его изменение является следующим шагом,
а на текущем шаге я лишь пытаюсь получить нужный вид загрузчика для различных режимов работы.

Таким образом, после многочисленных различных попыток решить мою задачу я пришел к выводу,
что проще видимо будет это делать в обход стандартной процедуры генерации ISO на строне OBS,
т.е. создавать свой ISO файл внутри генерируемого стандартным сопособом ISO файла средствами OBS.
Для решения данной подзадачи я набросал скрипт который по сути повторяет все шаги из логов
сборки SuSE 15.0, при этом ключевым моментом тут является именно вызов /usr/bin/xorriso
с нужными параметрами
/usr/bin/xorriso -application_id 0x796b655a -publisher SUSE LINUX GmbH -preparer_id KIWI - https://github.com/OSInside/kiwi -volid NikotinRed7_S.u.S.E._linux_image -joliet on -padding 0 -outdev /usr/src/packages/KIWI-iso/NikotinRed7_S.u.S.E._linux_image.x86_64-1.1.0.iso -map /usr/src/packages/KIWI-iso/live-media.clyk9npp / -boot_image isolinux bin_path=boot/x86_64/loader/isolinux.bin -boot_image isolinux system_area=/usr/share/syslinux/isohdpfx.bin -boot_image isolinux partition_table=on -boot_image any partition_offset=16 -boot_image any cat_path=boot/x86_64/boot.catalog -boot_image any cat_hidden=on -boot_image any boot_info_table=on -boot_image any platform_id=0x00 -boot_image any emul_type=no_emulation -boot_image any load_size=2048 -append_partition 2 0xef /usr/src/packages/KIWI-iso/live-media.clyk9npp/boot/x86_64/efi -boot_image any next -boot_image any efi_path=--interval:appended_partition_2:all:: -boot_image any platform_id=0xef -boot_image any emul_type=no_emulation

По завершению сборки OBS я получаю ISO файл фейковый, в котором лежит уже нужный мне мой правильный ISO,
грузясь с которого я получаю нужный мне вид загрузочного меню для соответсвующих режим Legacy и UEFI.
Таким образом первая часть моей изначальной проблемы можно сказать что решена, и мы переходим к следующей проблеме - правильной генерации контента
загружаемого Live образа системы.

Данную задачу я бы разделили на несколько подзадач:

  1. Нужно уточнить теорию логики формирования файлов boot/x86_64/loader/initrd, boot/x86_64/loader/linux и их связи с LiveOS/squashfs.img
    В конфигурационных файлах boot/x86_64/loader/isolinux.cfg и boot/grub2/grub.cfg я вижу лишь упоминание о boot/x86_64/loader/initrd и boot/x86_64/loader/linux,
    но не понимаю как именно и в какой момент вызывается LiveOS/squashfs.img
  2. Нужно уточнить теорию логики формирования самого файла LiveOS/squashfs.img
    Полагаю, что было бы гораздо эффективнее не собирать контент каждый раз с нуля, а допустим
    закидывать в OBS подобный файл и обновлять в нем лишь некоторые пакеты.
  3. OBS - конечно вещь хорощая и полезная, но коли мне приходится теперь уже по сути самому все ручками прописывать и указывать для сборки,
    то наверное проще было бы это делать локально на своей машине с установленной SuSE.
    Поэтому возникает вопрос: Как именно настроить свою локальную тачку для сборки ISO файлов по аналогии с OBS
    (нужна пошаговая инструкция, список пакетов для установки, скрипты для конфигурации и пример сборки простого ISO локально)
    Для начала я бы также наверное использовал временно для отладки сетевые пути на официальные репозитории, а в последствии
    как-то бы скачал и использовал локальные или вообще бы как-то настроить сборку чтобы использовались только те пакеты,
    которые уже установлены в текущей системе на которой и производится генерация нового ISO

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

#6

kiwi использует модуль dracut kiwi-live. LiveOS/suqashfs.img - путь по умолчанию. Можно изменить параметрами rd.live.dir и rd.live.squashimg. Подробности смотрите в коде kiwi.

kiwi инсталлирует пакеты, которые указаны в конфигурации, и потом сворачивает в контейнер в зависимости от требуемого формата.

Читайте документацию kiwi, раздел “User Defined Scripts”. Там достаточно подробно описаны скрипты, которые вы можете использовать - например, чтобы скопировать в создаваемый образ ваши собственные файлы. Может быть, можно даже не указывать пакеты для инсталляции, но это надо пробовать.

1 Like
#7

Хорошо, допустим это так и есть.

Указанных параметров я не наблюдал ни в одном из файлов логов моих многочисленных сборок.

В конфигурационном файле grub.cfg имеются лишь подобные строки

menuentry 'Live' --class os --class gnu --class gnu-linux --class opensuse --unrestricted {
    set gfxpayload=keep
    echo 'Loading kernel ...'
    $linux ($root)/boot/x86_64/loader/linux splash=silent quiet plymouth.enable=0 systemd.show_status=yes lang=ru_RU ${extra_cmdline} ${isoboot} rd.live.image rd.live.overlay.persistent rd.live.overlay.cowfs=ext4 root=live:CDLABEL=NikotinRed7_S.u.S.E._linux_image
    echo 'Loading initial ramdisk ...'
    $initrd ($root)/boot/x86_64/loader/initrd
}

Вы имели ввиду что мне в дополнение к этим параметрам тут в этом файле grub.cfg нужно прописывать rd.live.dir и rd.live.squashimg или где ?

Полагаю что rd.live.dir - это исключительно только путь к файлу, а rd.live.squashimg - это исключительно только имя файла, т.е. если допустим это где-то и задается по умолчанию то выглядело бы вот так:
rd.live.dir=LiveOS/
rd.live.squashimg=suqashfs.img

верно ?

Как формируются сами файлы boot/x86_64/loader/initrd и boot/x86_64/loader/linux ?

#8

Нужно или нет - это решать вам, но да, их можно указать в командной строке linux, можно сохранить в сгенерированном initrd используя средства dracut.

linux - это ядро linux. Берется из установленного пакета. initrd генерируется используя утилиту dracut, как и в “нормальной” инсталляции openSUSE.

1 Like
#9

Это я вижу и так в логе и повторяю в соих скриптах аналогичное действие, но я думал что этот файл как-то тоже генерится-собирается, но ответ тоже получил из вашего коментария:

Хорошо, понял.

Не понимаю какой командой, по логам сборки лишь вижу что создается файл архив

Creating generic dracut initrd archive
EXEC: [chroot /usr/src/packages/KIWI-iso/build/image-root dracut --force --no-hostonly --no-hostonly-cmdline --xz --install /.profile NikotinRed7_S.u.S.E._linux_image.x86_64-1.1.0.initrd.xz 4.12.14-lp150.12.82-default]
EXEC: [mv /usr/src/packages/KIWI-iso/build/image-root/NikotinRed7_S.u.S.E._linux_image.x86_64-1.1.0.initrd.xz /usr/src/packages/KIWI-iso]

А что дальше с этим архивом получается, каким образом у меня в папке итогового ISO файла появляется файл boot/x86_64/loader/initrd (если бы это было бы также как и в случае с файлом boot/x86_64/loader/linux то проблем бы не было, но увы это не так и этот момент я не понимаю)

Полагаю initrd - это просто архив всего содержимого / но возникает вопрос как именно изменять тогда содержимое, чтобы в нем были необходимые пакеты или типа того, поскольку в разных даже взять если чисто официальные сборки данный файл boot/x86_64/loader/initrd имеет разный размер и это очень хорошо видно на примере сборки NET в сравнении с тем же Live. Если распаковать содержимое initrd то видно отличие, но как те или инцые команды/пакеты/программы туда попадают - не понятно, ведь сами пакеты которые указываются в основном кофигурационном файле, опять же, на сколько я понимаю - попадают в LiveOS/suqashfs.img

Правда еще не проверял, но возможно, поправьте меня если я не прав, что то что должно попасть в initrd формируется на основе и/или раздела основного конфигурационного файла config.kiwi, а именно его секции <packages type="bootstrap"> либо на основе данных указанных глобальное в проекте во вкладке
Project Config , а именно то что указывается в секциях Preinstall
?

И все равно не понимаю как именно, какие командами формируется LiveOS/suqashfs.img т.к. в коде вижу лишь вот эти места где идет хоть какое-то упоминание на эту тему

EXEC: [mkdir -p /usr/src/packages/KIWI-iso/live-container.cocidru1/LiveOS]
EXEC: [mksquashfs /usr/src/packages/KIWI-iso/live-container.cocidru1 /tmp/tmp0gzjspsv -noappend -b 1M -comp xz -Xbcj x86]

Просто судя по логу указанные в этих двух командах каталоги просто создаются, а затем просто удаляются и в них ничего не пишится и не сохраняется.

На момент вызова моего скрипта указанного к конфигурационном файле в секции <type editbootconfig="isopatch.sh" /> по логам уже все пакеты уже установлены и видимо распакованы и настроены, но где они и как попадают в LiveOS/suqashfs.img ?

#10

А дальше он копируется в .../loader/initrd. Мне что, мамой поклясться? Скачайте исходный текст kiwi, убедитесь сами.

Это squashfs.img.

#11

Я же ранее написал, что оба эти архива и boot/x86_64/loader/initrd и LiveOS/suqashfs.img содержат структуру каталогов как в / но отличаются количеством установленных пакетов. В LiveOS/suqashfs.img действительно полноценный / именнно тот который я и формирую указывая в конфигурационном файле необходимые мне пакеты для установки, а вот как формируется boot/x86_64/loader/initrd - я не понимаю (каким образом в него попадают те или иные пакеты, могу ли я на это как-то повлиять ?!)

Самый жирый boot/x86_64/loader/initrd у официальной сборки NET (порядка 120 MB), а самый маленький у Live (порядка 25 MB), вот мне и интересно почему так происходит и как именно, на что это в последствии влияет и т.п.

#12

Пересказывать (да ещё и с переводом) всю документацию по dracut я здесь не буду, извините. Начните хотя бы с чтения man dracut.

Вы можете повлиять на модули dracut, на драйверы ядра, на файлы, которые добавляются в initrd. Как это сделать - есть в документации dracut.

Я вам уже говорил неоднократно и по русски, и по английски, что установочный образ openSUSE собирается не с помощью kiwi, поэтому сравнивать их бессмысленно.

#13

Если Вас не затруднит и во избежания дальнешего недопонимания, прошу предоставить онлайн ссылки на документацию которую Вы считаете правильной и самодостаточной, информация в которой позволила бы мне решить все озвученные ранее мной вопросы (ссылку на dracut и kiwi, и еще Вы говорили про исходный код kiwi)

PS: А опять получится, что я что-то найду, начну изучать это и потом снова задам вопросы и выяснится что то что я нашел - устаревшее и вообще не то что Вы имели ввиду.

#14

Why is this long thread in the “English Category”?

2 Likes
#15

I know, I’m really sorry. The language English was specified by default and I forgot to change it, and then it was too late.
Unfortunately, I do not know how to change the language for this post now.

#16

Should I move it to the Russian subforum?

#17

Yes, please, if it’s not difficult for you to do it.

#18

Temporarily closed for now

#19

Here it is once more.

#20

Thank you so much for your help. I’ll try to be more attentive next time.