Ubuntu не запускается по умолчанию после обновления с 18.04 до 20.04

Даже при выполнении незначительных обновлений, а не только обновления основных версий, важно убедиться в отсутствии значительных ошибок при обновлении grub. Если ошибки все же возникают, иногда их можно исправить до перезагрузки.

Если вы знаете, что есть проблема, вместо перезагрузки в конце обновления используйте командную строку для повторного запуска программы установки grub. Даже если ошибок нет, это, как правило, безопасно. Команды в ubuntu следующие:

update-grub
grub-install

Первая команда обновляет меню grub, находит новые ядра и удаляет те, которые больше не доступны. Вторая команда переустановит загрузчик EFI. Если вы все еще используете устаревший загрузчик, вам нужно указать диск для установки загрузчика с помощью этой команды. (Для устаревшего загрузчика можно выполнить эту команду несколько раз, по одному для каждого диска, если вы загружаетесь с нескольких дисков для избыточности, и ваш биос поддерживает это.)

При повторном выполнении этих команд вы можете получить ошибки, и эти ошибки могут подсказать вам, что нужно сделать, чтобы разрешить ситуацию. Например, недавно мне пришлось изменить размер раздела EFI, потому что загрузчик grub разросся. (К счастью, он был смежным с разделом подкачки, поэтому это было не слишком сложно.)

Обратите внимание, что приведенные выше команды не исправляют проблемы, если отдельные установки ядра получают ошибки. Например, если у вас есть отдельный раздел /boot, и он заполнен, вам придется переустановить все ядра, которые были обновлены, когда он был заполнен. Это можно исправить, либо изменив размер раздела, либо удалив старые ядра, которые не используются. (Проще всего это сделать с помощью apt autoremove или apt remove, но в экстренных случаях вы можете удалить части вручную с некоторой осторожностью). Когда освободится место, вы можете использовать dpkg-reconfigure для каждого затронутого пакета ядра, чтобы запустить пересборку initrd и копирование частей ядра. Кроме того, иногда apt запоминает, что не получилось, и повторный запуск apt upgrade может дать указания, что делать дальше, чтобы повторно запустить неработающие части.

Если обновление Ubuntu 18 до Ubuntu 20 вызвало обновление grub legacy до grub2, в Интернете есть руководства о том, как устранить проблемы, связанные с этим. Менеджер перехода позволяет оставить оба установленных загрузчика, чтобы вы могли протестировать новый, но вернуться к старому в случае неудачи. После успешной загрузки с новым загрузчиком можно завершить шаги, описанные в руководстве по удалению старого.

Обратите внимание, что если вы уже совершили ошибку при перезагрузке и загрузка не удалась, и ни один из вариантов, оставшихся в меню grub, не загрузился успешно, в худшем случае можно использовать установочный носитель ubuntu 20 для загрузки в режиме спасения и попытки ремонта. В режиме спасения есть автоматический ремонт, который иногда работает, но вам может потребоваться перейти в командную строку, и тогда можно будет освободить место (или переразметить - но это сложно) и попробовать ремонт снова, или выполнить chroot в установленной операционной системе и повторить шаги, описанные выше, чтобы попытаться выполнить ремонт вручную.

Обратите внимание, что переразметка дисков для установленной ОС или ручное удаление частей ядра в /boot - это операции экспертного уровня, требующие особой осторожности и полного понимания всех последствий.

У меня была такая же проблема, и я попал в такую ​​же ситуацию. Моя проблема была более сложной, потому что у меня в начале моего файла образа виртуального сервера qcow2 было только 32 свободных сектора, поэтому grub2 не был установлен.Я исправил проблему с разбиением на разделы с помощью gparted и переместил первый раздел с помощью qemu-nbd, чтобы смонтировать виртуальный образ на хосте, и gparted, чтобы переместить первый раздел вправо, даже если я получил предупреждение о том, что это опасно, если раздел имеет / boot, как и я. Теперь у меня в начале / dev / sda свободно 4096 секторов. У меня всего 32 сектора, и этого было слишком мало для core.img, который устанавливает grub2.

Результат был успешным, так что, когда у меня был старый grub на моем виртуальном сервере, он загрузился нормально, используя настройки menu.lst - теперь я мог запустить

sudo grub-install /dev/sda

, чтобы установить grub2, который используется в Ubuntu 20.04 и который использует grub.cfg который обновляется при обновлении системы. Но после загрузки с grub2 он не работает, и если я принудительно включу и включу, я получаю меню grub2, в котором я могу выбрать ядро ​​серии 5, но оно не запускается с отключенной паникой ядра.

Если я вошел в меню загрузки grub2 и выбрал последнее ядро ​​4-й серии, виртуальный сервер запустится и, похоже, будет работать нормально.

Итак, у нас есть 2 виртуальных машины Ubuntu 20.04, на которых не работают ядра 5-й серии, но могут быть запущены ядра 4-й серии. Я считаю, что на страницах Ubuntu должно быть предупреждение, что виртуальные машины не следует обновлять до 20.04, пока эта проблема не будет решена!

У меня вчера была такая же проблема. Если я приму версию сопровождающего для меню загрузки / grub и приму обновление до grub2, виртуальная машина не загрузится после обновления.

Думаю, проблема в обновлении до grub2. Я попытался обновить сервер виртуальной машины с нормальной последовательностью в терминале с подключением ssh

sudo apt update
sudo apt upgrade
sudo upt autoremove
sudo apt dist-upgade
sudo do-release-upgrade

При второй попытке обновление зависало с «Расчетом изменений». До этого обновления репозиторий был изменен на репозиторий 20.04, и когда я нажал ctrl-c. Я попытался обновить команду вручную, повторяя указанную выше.У меня такой же вопрос, чтобы принять загрузку по цепочке с Grub 2 с настройкой из menu.lst, и я ответил нет. Он посоветовал мне запустить «upgrade-from-grub-legacy», но я этого не сделал.

В результате у меня есть пакеты 20.04 на моем виртуальном сервере, но на нем запущено последнее ядро ​​Ubuntu 18.04 из 4-й серии, с использованием устаревшего grub, который использует menu.lst, но не grub.cfg, но система использует grub.cfg , когда он обновляет ядро, и эти обновленные ядра не будут работать на моем виртуальном сервере.

Вопрос в том, что если я не запустил «upgrade-from-grub-legacy», виртуальная машина снова зависнет при загрузке? Я могу попробовать, но создание резервной копии займет некоторое время. И устраняет ли это проблему? Ядро из 5-й серии 20.0.4 в основном лучше, чем из ядра 18.0.4 из 4-й серии, потому что нечетная серия является стабильной, а четная серия является разработкой, поэтому всегда использовать ядро ​​четной серии - плохая идея во время разработки продукта, и я не Я не понимаю, почему Ubuntu использует ядра четных серий в некоторых своих LTS Ubuntus. Это не имеет смысла.

Продолженное тестирование и создание резервной копии виртуального сервера и выполнение 'upgrade-from-grub-legacy', вывод (некоторые результаты на финском языке, потому что мои локали)

core.img doesn't exist, trying to create it.

Asennetaan i386-pc-alustalle.
Asennus on päättynyt. Virheitä ei löytynyt.
dpkg: varoitus: version 'dummy-version' has bad syntax: version number does not start with digit
dpkg: varoitus: version 'dummy-version' has bad syntax: version number does not start with digit
Sourcing file `/etc/default/grub'
Sourcing file `/etc/default/grub.d/init-select.cfg'
Tuottaa grub-asetustiedoston ...
Linux-levykuva löytyi: /boot/vmlinuz-5.4.0-73-generic
Löytyi initrd-levykuva: /boot/initrd.img-5.4.0-73-generic
Linux-levykuva löytyi: /boot/vmlinuz-4.15.0-143-generic
Löytyi initrd-levykuva: /boot/initrd.img-4.15.0-143-generic
Linux-levykuva löytyi: /boot/vmlinuz-4.15.0-122-generic
Löytyi initrd-levykuva: /boot/initrd.img-4.15.0-122-generic
Linux-levykuva löytyi: /boot/vmlinuz-3.2.0-23-virtual
Löytyi initrd-levykuva: /boot/initrd.img-3.2.0-23-virtual
Linux-levykuva löytyi: /boot/vmlinuz-3.2.0-23-generic
Löytyi initrd-levykuva: /boot/initrd.img-3.2.0-23-generic
Linux-levykuva löytyi: /boot/vmlinuz-2.6.32-33-server
Löytyi initrd-levykuva: /boot/initrd.img-2.6.32-33-server
Linux-levykuva löytyi: /boot/vmlinuz-2.6.31-23-server
Löytyi initrd-levykuva: /boot/initrd.img-2.6.31-23-server
Linux-levykuva löytyi: /boot/vmlinuz-2.6.28-11-server
Löytyi initrd-levykuva: /boot/initrd.img-2.6.28-11-server
Linux-levykuva löytyi: /boot/vmlinuz-2.6.27-9-server
Löytyi initrd-levykuva: /boot/initrd.img-2.6.27-9-server
valmis
dpkg-maintscript-helper: error: environment variable DPKG_MAINTSCRIPT_NAME is required

Если я перезагружаюсь с виртуального сервера, он переходит в grub (Это grb или grub2?), И я могу выбрать свое ядро ​​для загрузки, но /boot/vmlinuz-5.4.0-73-generic нет в списке. Если я просто нажму return, затем uname -a output

Linux MyVirtualServer 4.15.0-122-generic #124-Ubuntu SMP Thu Oct 15 13:03:05 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Это имеет смысл с конфигурационным файлом menu.lst, но не с grub.cfg, поэтому устаревший grub все еще работает. Я не могу сейчас попробовать ядро ​​5-й серии.Для этого мне нужно перейти на grub2, но как это сделать на виртуальной машине?