+++ This bug was initially created as a clone of Bug #27908 +++ В ядрах std-def, un-def, led-ws есть CONFIG_FB_EFI; led-ws после загрузки ядра и initrd из elilo нормально отображает сообщения во фреймбуфер, un-def проверено как работающее в сборке 3.6.6-alt1 (не работало в 3.6.4-alt1), std-def-3.6.6-alt1 вроде бы содержит все нужные CONFIG_EFI*, но не работает.
try CONFIG_RELOCATABLE
(В ответ на комментарий №1) > try CONFIG_RELOCATABLE можно попробовать, но в un-def оно не выставлено и при этом, насколько я понимаю, работает..
(В ответ на комментарий №2) > (В ответ на комментарий №1) > > try CONFIG_RELOCATABLE > > можно попробовать, но в un-def оно не выставлено и при этом, насколько я > понимаю, работает.. А оно может работать, а может и не: "EFI doesn't provide any guarantees that any given address will be free, so the bootloader must have the freedom to position the kernel appropriately. Make CONFIG_EFI select CONFIG_RELOCATABLE in order to ensure that this constraint is satisfiable." http://us.generation-nt.com/answer/patch-x86-config-efi-should-select-config-relocatable-help-203680552.html
Ещё из замеченного: под vbox 3.6.6-std-def-alt1 отрабатывает нормально, в dmesg такое же "fb0: EFI VGA frame buffer device", как и для 3.6.6-un-def-alt1 или 3.0.51-led-ws-alt6. При этом тот же образ на железе ничего не выводит сразу после загрузчика.
Прошу проверить на текущем ядре std-def
(In reply to comment #5) > Прошу проверить на текущем ядре std-def Под vbox работает, на AMD C60 -- всё так же замирает после "Loading file full.cz...done"; на Alt-SysRq-B не реагирует, похоже, заклинило на старте. (In reply to comment #2) > > try CONFIG_RELOCATABLE > можно попробовать, но в un-def оно не выставлено Насколько понимаю, там тоже следует выставить (и в led-ws -- тоже), иначе на какой-то сборке/железке будет падать.
(In reply to comment #6) > > Прошу проверить на текущем ядре std-def > Под vbox работает, на AMD C60 -- всё так же замирает после "Loading file > full.cz...done"; на Alt-SysRq-B не реагирует, похоже, заклинило на старте. 3.6.7-std-def-alt3 ведёт себя аналогично; http://ftp.linux.kiev.ua/pub/Linux/ALT/people/mike/iso/mkimage-profiles/efi/icewm-uefi-20121125-367sd3-x86_64.iso 3.6.7-un-def-alt2 работает и там, и там; http://ftp.linux.kiev.ua/pub/Linux/ALT/people/mike/iso/mkimage-profiles/efi/icewm-uefi-20121125-367ud2-x86_64.iso --- 8< --- 8< --- > > > try CONFIG_RELOCATABLE > > можно попробовать, но в un-def оно не выставлено > Насколько понимаю, там тоже следует выставить (и в led-ws -- тоже), иначе на > какой-то сборке/железке будет падать. Собсно уже не упоминал как некритичное, но на разных ядрах ловил зависания или oops при выключении или рестарте (в т.ч. по sysrq). Возможно, тоже связано. Ещё из неприятного, но некритичного ловил на led-ws (которое оказалось первым из работающих на EFI под рукой) вертикальные равные чёрно-белые полосы пиксела по четыре при попытке запуска xorg; "объезд" -- reset, при следующей загрузке точно того же комплекта всё нормально. Это подземный стук, поэтому отдельно его вешать пока не думаю, но FYI. --- >8 --- >8 ---
(In reply to comment #7) > 3.6.7-std-def-alt3 ведёт себя аналогично Там в .config очепятка: -CONFIG_RELOCATABLE is=y +CONFIG_RELOCATABLE=y
(In reply to comment #8) > (In reply to comment #7) > > 3.6.7-std-def-alt3 ведёт себя аналогично > Там в .config очепятка: > -CONFIG_RELOCATABLE is=y > +CONFIG_RELOCATABLE=y 2mike: спасибо! :-)
(В ответ на комментарий №8) > (In reply to comment #7) > > 3.6.7-std-def-alt3 ведёт себя аналогично > Там в .config очепятка: > -CONFIG_RELOCATABLE is=y > +CONFIG_RELOCATABLE=y На x86_64 этой опечатки нет, оно работает?
На железе только x86_64 и смотрел (а .config смотрел в патче в srpm). Значит, не в том дело...
Created attachment 5653 [details] diff -u config-3.6.7-std-def-alt3 config-3.6.7-un-def-alt2 diff между конфигами (x86_64) для удобства; из сколь-нибудь цепляющегося за мой непрофессиональный глаз -- не факт, что стоит даже дёргать, особенно если у вас на тех двух образах всё работает: -# CONFIG_DRM_LOAD_EDID_FIRMWARE is not set +CONFIG_DRM_LOAD_EDID_FIRMWARE=y -CONFIG_FONTS=y +# CONFIG_FONTS is not set
(В ответ на комментарий №12) > Created an attachment (id=5653) [details] > diff -u config-3.6.7-std-def-alt3 config-3.6.7-un-def-alt2 > > diff между конфигами (x86_64) для удобства; из сколь-нибудь цепляющегося за мой > непрофессиональный глаз -- не факт, что стоит даже дёргать, особенно если у вас > на тех двух образах всё работает: > > -# CONFIG_DRM_LOAD_EDID_FIRMWARE is not set > +CONFIG_DRM_LOAD_EDID_FIRMWARE=y > > -CONFIG_FONTS=y > +# CONFIG_FONTS is not set Прошу проверить на 3.6.8-std-def-alt1
(In reply to comment #13) > Прошу проверить на 3.6.8-std-def-alt1 То же: под virtualbox-4.2.4-alt1 работает, на C60 виснет. Может, перекрасить уже un-def в std-def, или есть поводы держать отдельно?
(В ответ на комментарий №14) > Может, перекрасить уже un-def в std-def /boot/config-* слишком разные
(In reply to comment #15) > > Может, перекрасить уже un-def в std-def > /boot/config-* слишком разные Знаю, но помню и повод к появлению un-def, который вроде как неактуален.
(В ответ на комментарий №14) > (In reply to comment #13) > > Прошу проверить на 3.6.8-std-def-alt1 > То же: под virtualbox-4.2.4-alt1 работает, на C60 виснет. > > Может, перекрасить уже un-def в std-def, или есть поводы держать отдельно? Это можно обсуждать после выявления причин этой баги, а не до. Попробуйте поиграть настройками C60 и параметрами ядра. И погуглите. Еще: пингвины при загрузке ядра появляются? Не связано это с plymouth?
(In reply to comment #17) > > Может, перекрасить уже un-def в std-def, или есть поводы держать отдельно? > Это можно обсуждать после выявления причин этой баги, а не до. Тут другое направление причинно-следственной связи: _если_ с std-def есть и другие проблемы, которых нет с un-def, а с un-def особых регрессов относительно std-def нет -- то есть ли смысл уже одному человеку тащить два близких ядра? (возможно, есть по другим причинам, ни разу не настаиваю) > Попробуйте поиграть настройками C60 и параметрами ядра. И погуглите. Настроек по части вывода там нет, параметры ядра пока не гуглил -- всё-таки есть работающие варианты ядер и более срочные дела. > Еще: пингвины при загрузке ядра появляются? Не связано это с plymouth? Нет, там сразу текст (когда работает); plymouth в эти образы не клал ещё. Собсно флэшка сразу перестаёт мигать, в отличие от случая с продолжающейся загрузкой. И на Alt-SysRq-b ядро не реагирует (USB или PS/2 kbd -- сейчас точно не вспомню). Поскольку такое крайне неудобно фиксить вслепую (понимаю, что мне бы самому поиграться тут в конфиг std-def, но см. выше) -- и выложил образы да попросил посмотреть, не воспроизводится ли подобное на имеющихся под рукой платформах (comment 7).
Ещё одно потенциально похожее место (изменение из alt8 можно откатывать, наверное; а здесь спасибо за подсказку led@): -CONFIG_RTC=y -# CONFIG_RTC_CLASS is not set +CONFIG_RTC_LIB=y +CONFIG_RTC_CLASS=y +CONFIG_RTC_HCTOSYS=y +CONFIG_RTC_HCTOSYS_DEVICE="rtc0" +# CONFIG_RTC_DEBUG is not set ...и далее по тексту.
> std-def нет -- то есть ли смысл уже одному человеку тащить два близких ядра? > (возможно, есть по другим причинам, ни разу не настаиваю) Причина есть -- вот вот выйдет 3.7 и un-def уйдёт на него, а std-def -- останется. Другое дело, что конфиги действительно надо унифицировать, но до этого пока не доходят руки :(
(В ответ на комментарий №20) > Другое дело, что конфиги действительно надо унифицировать А может, наоборот, не надо? Разве не для этого существует un-def?
(В ответ на комментарий №21) > (В ответ на комментарий №20) > > Другое дело, что конфиги действительно надо унифицировать > А может, наоборот, не надо? Разве не для этого существует un-def? Просто кроме объяснимой разницы в конфигах, которая сделана специально, есть гораздо больше разницы, происхождение которой не известно и как один из результатов имеем не работающий efifb в std-def.
На 3.6.9-std-def-alt1 всё хорошо :-)
Только не смейтесь, но 3.6.10-std-def-alt1 опять виснет.
Перепроверил ещё раз. В установленной системе (GRUB) работают все из списка: 3.0.56-led-ws-alt2 3.6.9-std-def-alt1 3.6.10-std-def-alt1 3.7.0-un-def-alt1 В инсталяторе (ELILO) работают: 3.0.56-led-ws-alt2 3.7.0-un-def-alt1 и виснут: 3.6.9-std-def-alt1 3.6.10-std-def-alt1 Пока думаю в инсталяторе использовать led-ws или un-def, а в систему ставить std-def; тем временем продолжить эксперименты по загрузке с исошки при помощи grub2-efi.
(В ответ на комментарий №25) > Перепроверил ещё раз. > > В установленной системе (GRUB) работают все из списка: > 3.0.56-led-ws-alt2 > 3.6.9-std-def-alt1 > 3.6.10-std-def-alt1 > 3.7.0-un-def-alt1 > > В инсталяторе (ELILO) работают: > 3.0.56-led-ws-alt2 > 3.7.0-un-def-alt1 > > и виснут: > 3.6.9-std-def-alt1 > 3.6.10-std-def-alt1 > > Пока думаю в инсталяторе использовать led-ws или un-def, а в систему ставить > std-def; Эту багу закрываю. Прошу повесить FR : > тем временем продолжить эксперименты по загрузке с исошки при помощи > grub2-efi.
FWIW, на всё той же машинке 3.6.11-std-def-alt1 грузится с refind-0.6.4-alt1 и замерзает с elilo-3.14-alt1.592. Перейти на refind вместо elilo пока не получается, см. bug #28350; но в перспективе это видится для загрузочного образа заметно более выгодным вариантом, нежели grub-efi.
Все же стоит переоткрыть.
(В ответ на комментарий №28) > Все же стоит переоткрыть. Надо проверить с сегодняшними ядрами, собранными при помощи specsubst из унифицированного конфигурационного файла.
(В ответ на комментарий №29) > (В ответ на комментарий №28) > > Все же стоит переоткрыть. > Надо проверить с сегодняшними ядрами, собранными при помощи specsubst из > унифицированного конфигурационного файла. 2mike@: проверили? закрывайте!
Проверил 3.7.2-std-def-alt1.1, на ASUS C60M1-I и ASUS UX31A с ELILO грузится; http://ftp.linux.kiev.ua/pub/Linux/ALT/people/mike/iso/mkimage-profiles/half-/20130115/ 2 cas, amike: если получится на всякий перепроверить хотя бы один из этих x86_64.iso на доступном UEFI-железе, вообще хорошо.
