ALT Linux Bugzilla – Full Text Bug Listing
| Summary: | Не грузится с /dev/sda после инсталляции в режиме EFI | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Sisyphus | Reporter: | Leonid Krivoshein <klark.devel> | ||||||
| Component: | qemu | Assignee: | Alexey Shabalin <shaba> | ||||||
| Status: | CLOSED FIXED | QA Contact: | qa-sisyphus | ||||||
| Severity: | major | ||||||||
| Priority: | P3 | CC: | boyarsh, glebfm, iv, klark, mike, rider, sbolshakov, shaba, sotor, vitty, vt | ||||||
| Version: | unstable | ||||||||
| Hardware: | x86_64 | ||||||||
| OS: | Linux | ||||||||
| Attachments: |
|
||||||||
|
Description
Leonid Krivoshein
2018-03-27 18:24:03 MSK
при чём тут alterator-vm ? Это проблема qemu, он видимо или не сохраняет диск, или из EFI BIOS не видит диск. В общем никаким боком не имеет отношения к alterator-vm. На PVE установка в efi работает, но до первого выключения виртуалки, т.к. некуда записать порядок загрузки (настройки BIOS'а). Created attachment 7456 [details] EFI Disk on PVE (In reply to comment #1) > при чём тут alterator-vm ? Он один из "подозреваемых". Поскольку более точно компонент выявить пока не удалось, выбрал этот. Давайте перевесим, если найдём более подходящий. > Это проблема qemu Возможно, не утверждаю на 100%. > На PVE установка в efi работает, но до первого выключения виртуалки Написал багреппорт по просьбе mike@ именно об этой проблеме! У меня установка тоже проходит без единой ошибки до первой перезагрузки. И дальше снова грузится с DVD-образа вместо харда. Но! PVE-кластер использует гиппервизор KVM и тот же самый OVMF-bios, что и я командой выше. > т.к. некуда записать порядок загрузки (настройки BIOS'а). В QEMU есть куда. В примере выше это делается параметром: -drive if=pflash,format=raw,file=$TMPDIR/run-ovmf/efivars.bin И при установке на /dev/vda ЭТО работает, в отличии от установки на /dev/sda. А в PVE это делается так: Оборудование -> Добавить -> Диск EFI. В результате у нас получается диск на 128Кб для EFI VARS. См. скриншот. Теперь по-существу. См. bve01:142, поднятую только что ради этого бага. Нет проблем у сервера 8.2 при установке на SCSI-диск /dev/sda в режиме EFI. А в относительно свежих регулярках проблема проявилась. Значит, где-то у нас регрессия, давайте разбираться. Может и в QEMU, может и в OVMF-BIOS'е. Стоило ещё добавить, что проблема конкретизировалась при проверке сегодняшних регулярок. Несколько РАЗНЫХ дистрибутивов я таким образом безуспешно пытался установить в режиме EFI. Ещё раньше я наткнулся на эту проблему в выходные. Чтобы закрывать, а не перевешивать ТАКОЙ БАГ, необходимо понимать очевидные последствия для наших дистрибутивов. Очень хорошо, если дело окажется действительно в QEMU или в OVMF-BIOS'е. А если нет?.. Ну тогда уж grub2-efi. Сергей, проверьте пожалуйста на virtualbox с EFI. Нужно поставить ALT Workstation K 8.2 в EFI режиме и обновить до Sisyphus. регрессия в OVMF BIOS врятли будет, он же вне гостя работает. grub2 тоже одинаковый что в Sisyphus что в p8. Я скорее допускаю ситуацию, что вы как-то не так собираете эти самые регулярки. Как не так - не знаю, на мой взгляд регулярки это не дистрибутивы и особых усилий по приведению их в порядок предпринимать не надо. Можно попросить Зерга собрать Workstation K на свежем P8 и посмотреть что получится. И почему бага на Sisyphus, если проблема в p8 ? (In reply to comment #5) > регрессия в OVMF BIOS врятли будет Вообще-то уже бывали и Валера выправлял... несколько месяцев назад. > Я скорее допускаю ситуацию, что вы как-то не так собираете эти самые регулярки. Не мы, а в vb3 или как его там. Но вообще-то все мы, учитывая, что пекутся они из многих ключевых пакетов, попадающих в Сизиф, в т.ч. и с целью такого вот тестирования. > Как не так - не знаю, на мой взгляд регулярки это не дистрибутивы и особых > усилий по приведению их в порядок предпринимать не надо. Мы наоборот, предпринимаем усилия по исправлению подобных вещей, чтобы потом не всплыло на реальных дистрибутивах. > Можно попросить Зерга собрать Workstation K на свежем P8 и посмотреть что > получится. И почему бага на Sisyphus, если проблема в p8 ? В p8 нет проблем, речь о Сизифе и регулярках. Собственно, Миша просил повешать багу в связи с тестированием регулярок. Обновление с p8 до Сизифа исключит alterator-vm, по крайней мере. А что говорит efibootmgr -v, если загрузиться при уже установленной системе в rescue cd ? Регрессии конечно могут быть в OVMF, но если проверять на кластере PVE, развёрнутом на P8, то или на всех дистрибутивах будет одинаково плохо, или на всех одинаково хорошо. Тут же, судя по всему - проблема скорее в дистрибутиве, а не системе виртуализации. А что происходит с virtualbox ? (In reply to comment #7) > А что говорит efibootmgr -v, если загрузиться при уже установленной системе в > rescue cd ? Очень хороший вопрос, надо поизучать завтра. Сегодня большой "улов" на регулярках, ещё и хромиум-i586 сломался, успеть бы добить багреппорт. > Регрессии конечно могут быть в OVMF, но если проверять на кластере PVE, > развёрнутом на P8, то или на всех дистрибутивах будет одинаково плохо, или на > всех одинаково хорошо. Вот и я ратую за максимально широкое тестирование, в том числе, на голом железе. У нас, к сожалению, нет ничего с EFI. > А что происходит с virtualbox ? Кстати, проверил Вашу идею на PVE. Обновил до Sisyphus #142 машину. Nothing! Так что: либо mkimage-profiles/regular, либо alterator-vm. А grub-efi и qemu/bios исключились. chrome официально не поддерживает архитектуру i586, очень странно что у нас до сих пор его туда собирают. Что касается EFI - я правильно понял, что установленная система обновлятся нормально, а с нуля устанавливается криво ? grub-efi исключать пока нельзя. как и efivars и efibootmgr. (В ответ на комментарий №9) > chrome официально не поддерживает архитектуру i586, очень странно что у нас до > сих пор его туда собирают. Так ведь у нас Chromium собирают, а Chrome собирает Google. Chromium под 32-бит пока поддерживается, и не только под Linux. > Что касается EFI - я правильно понял, что установленная система обновлятся > нормально, а с нуля устанавливается криво ? Именно так. Не совсем идеально обновлялась, были анметы на udev, но всё решилось. С загрузкой в режиме EFI при таком подходе проблем не возникло. > grub-efi исключать пока нельзя. как и efivars и efibootmgr. У grub-efi нашёлся другой мелкий изъян. Появился уже после выпуска ALT Server 8.2 -- в генерируемый /boot/grub/grub.cfg стала попадать строка (точно не помню, вроде как) "lang=POSIX". В результате до первого графического меню стало очень быстро проскакивать ошибка на чёрном фоне. Её оказалось возможным выловить только камерой с ускоренной съёмкой. Пишет что нет файла с таким именем в языковой директории. Удаление этой строки проблему решает. Обнаружил неделю назад и вот как раз #142 машина мне про этот баг напомнила. Created attachment 7459 [details] grub-efi boot error message 1. Удалось снять скриншот момента мелькания сообщения об ошибке grub-efi до появления загрузочного меню GRUB. Решается заменой строки " set lang=POSIX" на " set lang=ru" в файле /boot/grub/grub.cfg, но после запуска update-grub в конфиг снова попадёт POSIX! 2. Частично разобрался с EFI VARS и QEMU. И у меня на машине, и на PVE стоят p8 и одинаковые версии OVMF: edk2-ovmf-20170720-alt3.M80P.1, но qemu собраны по-разному. Кроме того, есть разница в параметрах запуска qemu. Оказалось, что на PVE машина получает "Диск EFI" отличающийся по наполнению от моего. На PVE элементы 0, 3, 4 и 9 активированы, QEMU DVD это #3, элементы 1, 2, 5-8 удалены. Это точно не оригинальный EFI VARS из пакета OVMF. Соответственно, при инсталляции элемент altlinux становится элементом #1 и меняется BootOrder. Я же скриптом на машине оригинальный EFI VARS из пакета OVMF не меняю, а там задействованы все элементы 0-8. При инсталляции наш altlinux занимает #9 позицию. Но это ещё не всё. Даже, если удалить руками все "лишние" элементы, они добавляются автоматом у меня на машине (имеющиеся сохраняются, их никто не дёргает). А ранее удалённые элементы занимают первые "свободные" места. Очевидно, этим занимается установленная у меня версия qemu/2.11, а та, что входит в состав PVE, так себя не ведёт. Но и это ещё не всё. В обеих случаях меняется BootOrder, элемент altlinux, несмотря ни на что, активен, правильно заполнен и должен грузиться первым. Это происходит на PVE в случае /dev/sda, это происходит у меня в случае /dev/vda, но почему-то не происходит у меня, если диск /dev/sda. Ручное вмешательство не помогает и есть подозрение на опции запуска QEMU на моей машине. С этим продолжу разбираться... 3. Почему сделал пока такие выводы. Сегодня поставил на PVE вчерашнюю регулярку с lxde/x86_64 и там указанных проблем не возникло. А когда поставил на свою машину "старый" ALT Server 8.2 тоже в EFI-режиме, проблема проявилась. Выходит, разбираться надо действительно с QEMU и параметрами. Перевесим на qemu, на всякий случай 1. Я пока не знаю виртуалок, сохраняющих постоянно содержимое EFI NVRAM. Как минимум qemu/kvm и vbox этим не заморачиваются, wmvare/hyperv не видел. Если vbox только ребутать/ресетить, но не выключать -- "в себе" помнит. 2. Если такого плана проблемы вылезают на стартеркитах, они будут одинаковыми и для дистрибутивов; если не решить на регулярках -- придётся более срочно решать ближе к бранчу/выпуску. 3. Можно взять http://freesource.info/wiki/MichaelShigorin/ZenbookUX31A (около моего места, сзади справа) и с внешней клавиатурой задействовать для проверки загрузки с флэшки или внешнего USB DVD, блок питания воткнут около монитора. Содержимое забэкаплено, но я бы попросил его без меня всё-таки пока не сносить. 4. Собираются регулярки/стартеркиты на basalt, мысль перетащить их сборку тоже на vb3 пока только витает (и нуждается в утряске с nbr@, чтоб ему не помешать чем). 5. Chromium, видимо, сейчас реально i686 (и то не всякий), а не i586. (In reply to comment #13) > 1. Я пока не знаю виртуалок, сохраняющих постоянно содержимое EFI NVRAM. > Как минимум qemu/kvm и vbox этим не заморачиваются С этим разобрался и выложил сюда инструкцию. Как минимум, наш PVE (со своим собственным qemu) и собственно QEMU из репозитория с этой задачей справляются. И даже догадываюсь теперь, кто и почему выкинул часть содержимого "Диска EFI" на PVE-кластере -- по сравнению с дистрибутивным файликом там уже нет вариантов загрузки UEFI Floopy [1,2], UEFI PXE ipv[4,6], UEFI http ipv[4,6]. подозреваю, что все эти проблемы уже не актуальны, и можно закрывать баг. Да, переоткроем, если наткнёмся снова. |
