Ошибка grub

По твоей проблеме не подскажу, но у меня тоже было несколько раз проблемы с виртуалками кему квм и грабом при обновлении версии кему. Я использую efi режим для всех виртуалок. После обновления виртуалка могла на загружаться из-за того, что граб не находил разделы вообще. Решалось хаком - включить поддержку ефи, запустить машину, увидеть ошибку, выключить машину, включить ефи, загрузиться.

Тут efi даже не пахнет.

Виртуалки кручу уже много лет, никогда ни на legacy, ни на efi проблем не возникало.

Пардон, конечно, что влезаю в калашный ряд. А

grub-probe -t hints_string -d /dev/vda

Так-то судя по коду это errno, который возвращается из-за !canonicalize_file_name(). То есть как-то должно быть связано с тем, что некое устройство... «потерялось» )

...упс, с поправкой, что в 18.04 старый grub в котором нет hints_string, тогда bios_hints посмотреть.

Запустил, показал новую ошибку, но куда копать - всё равно не совсем понятно :)

grub-probe -t bios_hints /dev/vda
grub-probe: error: failed to get canonical path of `udev'.

В Гугле люди говорят, что это может быть связано с тем, что zpool недоступен. Знаю, что вы поклонник ZFS. Если еще и внутри виртуалок у вас ZFS, то может быть ваш случай?

i have a similar problem
grub2-probe fails when 'zpool' is not in the path

sh-4.2# /usr/sbin/grub2-probe --target=device /
/usr/sbin/grub2-probe: error: failed to get canonical path of ‘ZoL-2316/ROOT/rhel7’.
sh-4.2# export PATH=$PATH:/usr/sbin
sh-4.2# /usr/sbin/grub2-probe --target=device /
/dev/nbd0p2

Если еще и внутри виртуалок у вас ZFS

Нет-нет. ZFS снаружи, qcow2-образы лежат на ZFS, но внутри просто 2 раздела (vda1 swap и vda2 корень)

e2fsck -f /dev/vda2 делали?

Нет, виртуалка работает и корень примонтирован же.

Только сегодня дошло, что вы без "-d" запускали. Без device оно так и должно отвечать (или с вариантом failed to get canonical path of 'devtmpfs').

Впрочем, внимательнее прочитав стартовое сообщение, дошло ещё что это никак не поможет. Раз оно вам на fs_uuid отвечает правильно, а потом отваливается, то и на bios_hints ответит правильным hd0 и также отвалится.

Тогда сдаюсь. Разве только попробовать повторить вашу конфигурацию и воспроизвести ошибку у себя, когда делать будет нечего.

Мимо крокодил: а какой раздел у тебя активный? Может сделать /boot отдельным разделом в начале диска?

Но если до обновления всё работало - время писать багрепорт.

Может нужно сделать /dev/vda2 активнымии попробовать туда grub?

/dev/vda1 - swap, /dev/vda2 - /

Корень активный.

В общем, подготовился бэкапами, положил утащенный с другой виртуалки /boot/grub/grub.cfg и перегрузил хост со всеми виртуалками (пора уже, куча ядер новых прилетело с момента последней перезагрузки)

Все виртуалки (в т.ч. и проблемная) успешно загрузились, теперь update-grub проходит нормально. Такое решение проблемы мне, конечно же, не нравится. Но проблема решена.

Из разницы - когда возникала проблема, не генерились файлы boot.img и core.img в /boot/grub/ при «grub-install --target=i386-pc --boot-directory=/boot --verbose /dev/vda». После перезагрузки - генерятся.