при чём тут 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].

подозреваю, что все эти проблемы уже не актуальны, и можно закрывать баг.

Да, переоткроем, если наткнёмся снова.