ALT Linux Bugzilla – Full Text Bug Listing
| Summary: | Запускать install-kernel с опцией --u-boot при наличии /sys/firmware/devicetree | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Sisyphus | Reporter: | Антон Мидюков <antohami> | ||||
| Component: | bootloader-utils | Assignee: | placeholder <placeholder> | ||||
| Status: | CLOSED NOTABUG | QA Contact: | qa-sisyphus | ||||
| Severity: | normal | ||||||
| Priority: | P5 | CC: | asheplyakov, asheplyakov, at, boyarsh, glebfm, iv, jqt4, ldv, placeholder, sem, slazav, vitty, vt | ||||
| Version: | unstable | ||||||
| Hardware: | all | ||||||
| OS: | Linux | ||||||
| Attachments: |
|
||||||
Ниоткуда не следует, что при наличии device tree 1) система *может* загрузиться при помощи u-boot, примеры: платы на Байкал-М, TaiShan, и прочие SBBR [1] ARM системы. 2) пользователь/администратор *хочет*, чтобы система грузилась при помощи u-boot (а не UEFI или иного загрузчика, встроенного в плату) (Ответ для Alexey Sheplyakov на комментарий #1) > Ниоткуда не следует, что при наличии device tree > > 1) система *может* загрузиться при помощи u-boot, примеры: платы на > Байкал-М, TaiShan, и прочие SBBR [1] ARM системы. > 2) пользователь/администратор *хочет*, чтобы система грузилась при > помощи u-boot (а не UEFI или иного загрузчика, встроенного в плату) Опция --u-boot дополняет, но не ограничивает другие типы загрузки. Сейчас она будет создавать только симлинк /boot/dtb. Если существует /boot/extlinux/extlinux.conf, то обновит его. Если его нет, его не создаст. Но можно ещё подумать, как сделать иначе... (In reply to Антон Мидюков from comment #0) > Предлагаю запускать install-kernel с опцией --u-boot при наличии > /sys/firmware/devicetree. > u-boot также имеет возможность загружаться в режиме EFI, так что наличие EFI > не является достаточным признаком, что это не u-boot. Наличие device tree не является достаточным признаком того, что это u-boot, это вполне может быть UEFI без ACPI (что весьма распространено на arm) > Система может быть переносной и втыкаться из одного одноплатника в другой. К сожалению, не может, потому что у каждого одноплатника свои представления о том, где (и какой) должен быть загрузчик. Например, rock pi 4 тупо считывает с 32 КБ, начиная со второго (512-байтного) блока SD карты, и запускает это. А поэтому: пожалуйста, не надо. (Ответ для Alexey Sheplyakov на комментарий #3) > (In reply to Антон Мидюков from comment #0) > > К сожалению, не может, потому что у каждого одноплатника свои представления > о том, > где (и какой) должен быть загрузчик. Например, rock pi 4 тупо считывает с 32 > КБ, > начиная со второго (512-байтного) блока SD карты, и запускает это. > > А поэтому: пожалуйста, не надо. installkernel не устанавливает u-boot. (In reply to Антон Мидюков from comment #4) > (Ответ для Alexey Sheplyakov на комментарий #3) > > (In reply to Антон Мидюков from comment #0) > > > > К сожалению, не может, потому что у каждого одноплатника свои представления > > о том, > > где (и какой) должен быть загрузчик. Например, rock pi 4 тупо считывает с 32 > > КБ, > > начиная со второго (512-байтного) блока SD карты, и запускает это. > > > > А поэтому: пожалуйста, не надо. > > installkernel не устанавливает u-boot. а) Из названия опции это никак не следует, из-за чего возникают неожиданности двух типов 1) Караул, мне тут насильно u-boot ставят! (мой случай) 2) А я запустил installkernel --u-boot, а загрузчик не установился! б) *Пока* не устанавливает. (Ответ для Alexey Sheplyakov на комментарий #5) > (In reply to Антон Мидюков from comment #4) > > (Ответ для Alexey Sheplyakov на комментарий #3) > > > (In reply to Антон Мидюков from comment #0) > > > > > > К сожалению, не может, потому что у каждого одноплатника свои представления > > > о том, > > > где (и какой) должен быть загрузчик. Например, rock pi 4 тупо считывает с 32 > > > КБ, > > > начиная со второго (512-байтного) блока SD карты, и запускает это. > > > > > > А поэтому: пожалуйста, не надо. > > > > installkernel не устанавливает u-boot. > > а) Из названия опции это никак не следует, из-за чего возникают > неожиданности двух типов > 1) Караул, мне тут насильно u-boot ставят! (мой случай) > 2) А я запустил installkernel --u-boot, а загрузчик не установился! > б) *Пока* не устанавливает. Резонно. Хорошо, буду иначе решать проблему. (In reply to Антон Мидюков from comment #2) > (Ответ для Alexey Sheplyakov на комментарий #1) > > Ниоткуда не следует, что при наличии device tree > > > > 1) система *может* загрузиться при помощи u-boot, примеры: платы на > > Байкал-М, TaiShan, и прочие SBBR [1] ARM системы. > > 2) пользователь/администратор *хочет*, чтобы система грузилась при > > помощи u-boot (а не UEFI или иного загрузчика, встроенного в плату) > > Опция --u-boot дополняет, но не ограничивает другие типы загрузки. > Сейчас она будет создавать только симлинк /boot/dtb. Если существует > /boot/extlinux/extlinux.conf, то обновит его. Если его нет, его не создаст. > Но можно ещё подумать, как сделать иначе... 1) Добавить опции (и в командную строку, и в /etc/sysconfig/installkernel) для явного включения/отключения обновления /boot/dtb (по аналогии с --noflavour --nodefault) 2) Аналогично для обновления/создания /boot/extlinux.conf 3) Использовать более явные и понятные названия опций, например --update-dtb-symlink/--no-update-dtb-symlink (Ответ для Alexey Sheplyakov на комментарий #7) > (In reply to Антон Мидюков from comment #2) > > (Ответ для Alexey Sheplyakov на комментарий #1) > > > Ниоткуда не следует, что при наличии device tree > > > > > > 1) система *может* загрузиться при помощи u-boot, примеры: платы на > > > Байкал-М, TaiShan, и прочие SBBR [1] ARM системы. > > > 2) пользователь/администратор *хочет*, чтобы система грузилась при > > > помощи u-boot (а не UEFI или иного загрузчика, встроенного в плату) > > > > Опция --u-boot дополняет, но не ограничивает другие типы загрузки. > > Сейчас она будет создавать только симлинк /boot/dtb. Если существует > > /boot/extlinux/extlinux.conf, то обновит его. Если его нет, его не создаст. > > Но можно ещё подумать, как сделать иначе... > > > 1) Добавить опции (и в командную строку, и в /etc/sysconfig/installkernel) > для явного включения/отключения обновления /boot/dtb (по аналогии с > --noflavour --nodefault) > 2) Аналогично для обновления/создания /boot/extlinux.conf > 3) Использовать более явные и понятные названия опций, например > --update-dtb-symlink/--no-update-dtb-symlink 1) Я думаю, что ничего плохого в обновлении симлинка нет при наличии devicetree у ядра. 2) Если есть /boot/extlinux/extlinux.conf то почему бы его не обновлять, невзирая на опцию --u-boot? exlinux.conf может использоваться загрузчиком extlinux. |
Created attachment 10342 [details] Патч для kernel.filetrigger Предлагаю запускать install-kernel с опцией --u-boot при наличии /sys/firmware/devicetree. u-boot также имеет возможность загружаться в режиме EFI, так что наличие EFI не является достаточным признаком, что это не u-boot. u-boot в режиме EFI может загружать dtb из /boot/dtb на ext4 разделе, если его пропатчить. Поэтому есть необходимость, чтобы симлинк /boot/dtb создавался. u-boot'ы для riscv64 были пропатчены так. Но на riscv64 возникла проблема после установки с iso. Симлинка /boot/dtb после установки нет, ядро не грузится без dtb. Ещё один резон этой опции состоит в том, чтобы обновлялся при наличии extlinux.conf у системы, находящейся в режиме EFI. Система может быть переносной и втыкаться из одного одноплатника в другой. Один будет грузиться через EFI, другой через extlinux.conf. Будем считать, что раз в системе есть extlinux.conf, то его стоит актуализировать. Разумеется, если система EFI с ACPI, то опцию u-boot включать не нужно. Но есть ещё Байкал М, у которого не u-boot, а полноценный EFI, но с devicetree. Думаю, что ничего страшного не случится, если на Байкал М появится симлинк /boot/dtb.