$ /usr/bin/qemu-system-x86_64 --version QEMU emulator version 2.11.0(qemu-2.11.0-alt0.M80P.1) Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers # Запускаю установку с образа DVD на жёсткий диск /dev/sda любой # относительно свежей регулярки в гиппервизоре QEMU в режиме EFI # /usr/bin/qemu-system-x86_64 -name lxde/x86_64/EFI \ -machine pc-i440fx-2.9,accel=kvm -enable-kvm \ -smbios type=0,uefi=on -global PIIX4_PM.disable_s3=0 \ -drive if=pflash,format=raw,readonly,file=$TMPDIR/run-ovmf/bios.bin \ -drive if=pflash,format=raw,file=$TMPDIR/run-ovmf/efivars.bin \ -smp sockets=1,cores=4 -m 4096 -balloon virtio -soundhw hda,pcspk \ -drive if=scsi,id=drive0,format=qcow2,file=$TMPDIR/qemu-PUifHs2er.img \ -device scsi-hd,drive=drive0 -cdrom regular-lxde-20180327-x86_64.iso \ -netdev user,id=net0,restrict=no -device virtio-net,netdev=net0,id=eth0 \ -fsdev local,security_model=none,id=fsdev0,path=$TMPDIR \ -device virtio-9p-pci,id=fs0,fsdev=fsdev0,mount_tag=host-in \ -rtc base=localtime,clock=host,driftfix=slew -no-fd-bootchk \ -sdl -ctrl-grab -vga virtio При установке используется автоматическая разметка диска (25 Гб), установка проходит гладко, загрузчик устанавливается в EFI раздел. Но после перезагрузки снова стартует установочный DVD-диск, не помогает "как бы удаление" диска из привода: # убираем только вот это -cdrom regular-lxde-20180327-x86_64.iso Не помогает принудительная загрузка с "altlinux", указанная в OVMF-BIOS'е. /dev/sda не воспринимается загрузочным. Однако помогает смена типа диска: # HDD виден как /dev/sda в гостевой системе -drive if=scsi,id=drive0,... -device scsi-hd,... на: # HDD виден как /dev/vda в гостевой системе -drive if=none,id=drive0,discard=ignore,aio=threads,... \ -device virtio-blk-pci,scsi=off,write-cache=off,... На голом железе и в других гиппервизорах не проверял. Проблема затрагивает не только сегодняшние регулярки, но и более ранние выпуски. И только EFI-режим, только x86_64.
при чём тут 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].
подозреваю, что все эти проблемы уже не актуальны, и можно закрывать баг.
Да, переоткроем, если наткнёмся снова.
