Ubuntu ошибка установки grub

Страницы: [1] 2  Все   Вниз

0 Пользователей и 1 Гость просматривают эту тему.

Страницы: [1] 2  Все   Вверх

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

В какой-то момент установки вылетает окно со словами: «Не удалось выполнить команду ‘grub-install/dev/sda2. Это неисправимая ошибка.'»:

Потом 2 окна, что установка завершена, и что программа установки аварийно завершена. Потом ещё одно окно с заголовком: «Installation failed», и текстом: «The installer encountered an unrecoverable error. A desktop session will now be run so that you may investigate the problem or try installing again».

При повторной установке всё то же.

Если кому-то внесёт ясность какая структура дисков моего ноутбука, то вот:

• Красным выделен тот раздел, куда я намерен установить убунту;
• Если я ничего не попутал, то: sda4 — диск C, sda7 — диск D, sda8 — то место, куда я хочу поставить убунту.

Да, я искал решения. Например, есть такой ответ: https://askubuntu.com/a/571582. Возможно, это решение, но я его даже с переводчиком не понял .

Если нужны ещё какие-то данные, то уточняйте, я сделаю апдейт вопроса.

UPD1. Попробовал установить grub не в sda2, а в sda — всё то же, прерывается на том же месте.

I’m installing Ubuntu 18.04 LTS on a Dell Inspiron 5559 with 1 TB HDD where WIndows 10 is already installed, hence it’s a dual boot. I have set up a Ubuntu bootable USB drive and booted Ubuntu in UEFI mode from it. I have disabled secure boot, fast boot and created suitable partitions on Windows already.

The installation starts smoothly but fails again and again with the message «unable to install GRUB on dev/sda1» and says that it is a «fatal error». /dev/sda1 is the EFI boot partition (ESP partition) on my HDD to which Windows Boot Manager is installed. I had read that GRUB bootloader must be installed to that partition.

I am somewhat certain (but not completely) that the Ubuntu OS installed perfectly and the problem cropped up only in the GRUB installation, since whenever I try to re-install, the setup wizard says that «this computer has Windows 10 and Ubuntu 18.04 LTS on it» and gives the option to «Erase Ubuntu 18.04 LTS and re-install», which would only be possible if Ubuntu was already installed.

I have tried boot-repair, which says that that there was an error during repair due to which it could not be completed. Pastebin : http://paste.ubuntu.com/p/J3dk2YGBqG/

I’m a complete newbie at Linux/Ubuntu and would be grateful if anyone can provide a solution to this problem.

NVram Locked sounds like there might be some problems writing into the UEFI NVRAM variables, which are accessible in Linux via /sys/firmware/efivars or using the efibootmgr tool.

If you are accessing the failed installation by mounting it under /mnt/chrootdir and chrooting into it as suggested in answers to the AskUbuntu question you linked, I would suggest using mount --rbind instead of mount --bind for both /dev and /sys, as both include separate sub-filesystems that can be important for grub-install functionality:

• if /dev/pts is not available in the chrooted environment, it would cause the unable to allocate pty: No such device error
• if /sys/firmware/efi/efivars is not available in the chrooted environment, it would cause the attempts to write into UEFI NVRAM variables to fail… which is exactly your primary issue.

But if this does not help, you might want to read this excellent webpage by Roderick W. Smith, which explains certain problems other OSs or buggy UEFI firmware implementations can cause, and gives methods for working around them.

On your sda1 disk, there is apparently a efi/ubuntu/grub.cfg file, with the following contents:

search.fs_uuid 2D07-0F0A root hd0,gpt1 
set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfg

This seems incorrect: it is looking for the ESP partition (sda1) by filesystem UUID, and then assuming it should be a Linux root filesystem that contains /boot/grub… which is not true, as sda1 is the UEFI ESP, not the Linux root filesystem.

That file should instead have the following contents:

search.fs_uuid 25f0e88-f20a-4350-9df0-ee8c57ecc455 root hd0,gpt2
set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfg

You might want to copy this efi/ubuntu/grub.cfg to efi/BOOT/grub.cfg (also on sda1) too, to allow GRUB to find a valid configuration even if started as efi/BOOT/BOOTx64.efi.

This configuration file would cause the grubx64.efi on the ESP to seek the real Ubuntu root partition (sda2) by filesystem UUID, and then load any necessary GRUB modules from there, and also load the true GRUB configuration from /boot/grub/grub.cfg on sda2.

You might also want to copy efi/ubuntu/grubx64.efi into efi/BOOT/grubx64.efi on sda1, to ensure the full set of boot files are also available on the UEFI fallback/removable media boot path.

This part of the boot-repair output is actually produced by efibootmgr -v:

BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0004
Boot0003* UEFI: TOSHIBA TransMemory 1.00    PciRoot(0x0)/Pci(0x14,0x0)/USB(1,0)/HD(2,GPT,9240a165-d190-4ab6-8a12-46dc207b42ee,0x71e8a0,0x2130)..BO
Boot0004* UEFI: ST2000DM001-1ER164  HD(1,GPT,22c1dbaf-a26e-4408-a6f9-d1fc06b0d615,0x800,0x100000)/File(EFIbootbootx64.efi)..BO

It indicates that although you’ve currently booted from USB, your system firmware is prepared to boot from sda1 (identified by PARTUUID 2c1dbaf-a26e-4408-a6f9-d1fc06b0d615 using the file fallback/removable media boot path EFI/boot/bootx64.efi (the filesystem on ESP is vfat, so it should be case-insensitive… but some UEFI firmware implementations aren’t). So if you can perform the above-mentioned changes to the ESP, the system might be able to boot from sda1.

If you can get a regular Ubuntu system running in UEFI mode, you could retry sudo grub-install /dev/sda to rewrite the bootloader and automatically re-write the NVRAM boot variable for Ubuntu. Or alternatively, you could use the efibootmgr command to try and precision-fix just the boot variable issue yourself:

sudo efibootmgr -c -d /dev/sda -p 1 -l \EFI\ubuntu\grubx64.efi -L Ubuntu 

(This command requires that /dev/sda1 is mounted as /boot/efi and the efivarfs filesystem is mounted at /sys/firmware/efi/efivars. Both of these conditions should be handled automatically by a normal Ubuntu boot process.)

If this still fails with «NVram Locked» or similar, you might have a buggy UEFI implementation, but at least it allows you to boot into Ubuntu by using the fallback/removable media path.