Bug 34720 - Не грузится с /dev/sda после инсталляции в режиме EFI
Summary: Не грузится с /dev/sda после инсталляции в режиме EFI
Status: CLOSED FIXED
Alias: None
Product: Sisyphus
Classification: Development
Component: qemu (show other bugs)
Version: unstable
Hardware: x86_64 Linux
: P3 major
Assignee: Alexey Shabalin
QA Contact: qa-sisyphus
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-03-27 18:24 MSK by Leonid Krivoshein
Modified: 2022-01-27 19:36 MSK (History)
11 users (show)

See Also:


Attachments
EFI Disk on PVE (169.80 KB, image/jpeg)
2018-03-27 19:32 MSK, Leonid Krivoshein
no flags Details
grub-efi boot error message (35.39 KB, image/jpeg)
2018-03-28 18:52 MSK, Leonid Krivoshein
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Leonid Krivoshein 2018-03-27 18:24:03 MSK
$ /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.
Comment 1 Anton Farygin 2018-03-27 18:31:45 MSK
при чём тут alterator-vm ?
Это проблема qemu, он видимо или не сохраняет диск, или из EFI BIOS не видит диск.
В общем никаким боком не имеет отношения к alterator-vm.

На PVE установка в efi работает, но до первого выключения виртуалки, т.к. некуда записать порядок загрузки (настройки BIOS'а).
Comment 2 Leonid Krivoshein 2018-03-27 19:32:52 MSK
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'е.
Comment 3 Leonid Krivoshein 2018-03-27 19:46:24 MSK
Стоило ещё добавить, что проблема конкретизировалась при проверке сегодняшних регулярок. Несколько РАЗНЫХ дистрибутивов я таким образом безуспешно пытался установить в режиме EFI. Ещё раньше я наткнулся на эту проблему в выходные. Чтобы закрывать, а не перевешивать ТАКОЙ БАГ, необходимо понимать очевидные последствия для наших дистрибутивов. Очень хорошо, если дело окажется действительно в QEMU или в OVMF-BIOS'е. А если нет?..
Comment 4 Anton Farygin 2018-03-27 20:20:37 MSK
Ну тогда уж grub2-efi.

Сергей, проверьте пожалуйста на virtualbox с EFI.

Нужно поставить ALT Workstation K 8.2 в EFI режиме и обновить до Sisyphus.
Comment 5 Anton Farygin 2018-03-27 20:23:42 MSK
регрессия в OVMF BIOS врятли будет, он же вне гостя работает.
grub2 тоже одинаковый что в Sisyphus что в p8.

Я скорее допускаю ситуацию, что вы как-то не так собираете эти самые регулярки. Как не так - не знаю, на мой взгляд регулярки это не дистрибутивы и особых усилий по приведению их в порядок предпринимать не надо.

Можно попросить Зерга собрать Workstation K на свежем P8 и посмотреть что получится.

И почему бага на Sisyphus, если проблема в p8 ?
Comment 6 Leonid Krivoshein 2018-03-27 20:41:05 MSK
(In reply to comment #5)
> регрессия в OVMF BIOS врятли будет

Вообще-то уже бывали и Валера выправлял... несколько месяцев назад.

> Я скорее допускаю ситуацию, что вы как-то не так собираете эти самые регулярки.

Не мы, а в vb3 или как его там. Но вообще-то все мы, учитывая, что пекутся они из многих ключевых пакетов, попадающих в Сизиф, в т.ч. и с целью такого вот тестирования.

> Как не так - не знаю, на мой взгляд регулярки это не дистрибутивы и особых
> усилий по приведению их в порядок предпринимать не надо.

Мы наоборот, предпринимаем усилия по исправлению подобных вещей, чтобы потом не всплыло на реальных дистрибутивах.

> Можно попросить Зерга собрать Workstation K на свежем P8 и посмотреть что
> получится. И почему бага на Sisyphus, если проблема в p8 ?

В p8 нет проблем, речь о Сизифе и регулярках. Собственно, Миша просил повешать багу в связи с тестированием регулярок. Обновление с p8 до Сизифа исключит alterator-vm, по крайней мере.
Comment 7 Anton Farygin 2018-03-27 20:55:27 MSK
А что говорит efibootmgr -v, если загрузиться при уже установленной системе в rescue cd ?

Регрессии конечно могут быть в OVMF, но если проверять на кластере PVE, развёрнутом на P8, то или на всех дистрибутивах будет одинаково плохо, или на всех одинаково хорошо.

Тут же, судя по всему - проблема скорее в дистрибутиве, а не системе виртуализации.
А что происходит с virtualbox ?
Comment 8 Leonid Krivoshein 2018-03-27 21:41:29 MSK
(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 исключились.
Comment 9 Anton Farygin 2018-03-28 08:06:16 MSK
chrome официально не поддерживает архитектуру i586, очень странно что у нас до сих пор его туда собирают.

Что касается EFI - я правильно понял, что установленная система обновлятся нормально, а с нуля устанавливается криво ?

grub-efi исключать пока нельзя. как и efivars и efibootmgr.
Comment 10 Leonid Krivoshein 2018-03-28 11:42:54 MSK
(В ответ на комментарий №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 машина мне про этот баг напомнила.
Comment 11 Leonid Krivoshein 2018-03-28 18:52:50 MSK
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 и параметрами.
Comment 12 Anton Farygin 2018-03-28 20:35:30 MSK
Перевесим на qemu, на всякий случай
Comment 13 Michael Shigorin 2018-03-29 13:23:14 MSK
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.
Comment 14 Leonid Krivoshein 2018-03-29 21:41:41 MSK
(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].
Comment 15 Alexey Shabalin 2022-01-27 18:59:31 MSK
подозреваю, что все эти проблемы уже не актуальны, и можно закрывать баг.
Comment 16 Leonid Krivoshein 2022-01-27 19:36:19 MSK
Да, переоткроем, если наткнёмся снова.