Grub install ошибка не удалось получить канонический путь overlay

Find your drive that’s supposed to boot with

mount

Or

parted -l

Or

fdisk /dev/sda

And type p to list the partitions, look for type 83.

(If you’ve got Fedora you might have to use the commands vgs and lvs and if you’ve got mdraid you might have to cat /proc/mdstat or mdadm -A --scan or insmod raid1 or insmod raid5 and then mdadm -A --scan) and you will use /dev/md0 or /dev/mapper/my-vg instead of /dev/sda

then try mount it

mkdir /mnt
mount /dev/sda1 /mnt
cd /mnt
ls -l

Is this your drive? Cool!

grub-install --recheck --root-directory=/mnt /dev/sda 

(Or whichever /dev drive your root is, with it’s mounted path)

grub-install --recheck --root-directory=/mnt /dev/sda --force

(Force it if it doesn’t like your partitions.)

Now it should boot into grub, and you can use the grub commands to boot up, after rebooting and selecting the right boot drive from the BIOS Setup, or by pressing ESC, F8 or F12 depending on your BIOS and whether you are quick enough, then at the Grub prompt — you can use tab completion to find it if it’s not (hd0,1) but (hd1,3) or something else instead, but beware, tab completion sometimes hangs for a few seconds if grub can’t read the filesystem. Once booted into Grub you can try to boot with:

insmod linux
ls
root=(hd0,1)
linux /boot/vmlinuz root=/dev/sda1
initrd /boot/initrd
boot

Or, hopefully you’ve still got an intact grub.cfg file…

ls
ls (hd0,1)/
ls (hd0,1)/boot
configfile (hd0,1)/boot/grub.cfg

Grub 1 allows you to do the installation from Grub:

install (hd0,1)

Once booted from the correct drive, you can retry update-grub and grub-install. If it still fails, you can try:

grub-mkconfig -o /mnt/boot/grub/grub.cfg

Your paths may differ of course, so just play with these commands until you can see what’s where and what’s going on.

It might be a sign of imminent hard drive failure at worst, or at best maybe just a partition flag or boot file that got overwritten accidentally, or a deliberately- or accidentally broken installer from another OS.

Find your drive that’s supposed to boot with

mount

Or

parted -l

Or

fdisk /dev/sda

And type p to list the partitions, look for type 83.

(If you’ve got Fedora you might have to use the commands vgs and lvs and if you’ve got mdraid you might have to cat /proc/mdstat or mdadm -A --scan or insmod raid1 or insmod raid5 and then mdadm -A --scan) and you will use /dev/md0 or /dev/mapper/my-vg instead of /dev/sda

then try mount it

mkdir /mnt
mount /dev/sda1 /mnt
cd /mnt
ls -l

Is this your drive? Cool!

grub-install --recheck --root-directory=/mnt /dev/sda 

(Or whichever /dev drive your root is, with it’s mounted path)

grub-install --recheck --root-directory=/mnt /dev/sda --force

(Force it if it doesn’t like your partitions.)

Now it should boot into grub, and you can use the grub commands to boot up, after rebooting and selecting the right boot drive from the BIOS Setup, or by pressing ESC, F8 or F12 depending on your BIOS and whether you are quick enough, then at the Grub prompt — you can use tab completion to find it if it’s not (hd0,1) but (hd1,3) or something else instead, but beware, tab completion sometimes hangs for a few seconds if grub can’t read the filesystem. Once booted into Grub you can try to boot with:

insmod linux
ls
root=(hd0,1)
linux /boot/vmlinuz root=/dev/sda1
initrd /boot/initrd
boot

Or, hopefully you’ve still got an intact grub.cfg file…

ls
ls (hd0,1)/
ls (hd0,1)/boot
configfile (hd0,1)/boot/grub.cfg

Grub 1 allows you to do the installation from Grub:

install (hd0,1)

Once booted from the correct drive, you can retry update-grub and grub-install. If it still fails, you can try:

grub-mkconfig -o /mnt/boot/grub/grub.cfg

Your paths may differ of course, so just play with these commands until you can see what’s where and what’s going on.

It might be a sign of imminent hard drive failure at worst, or at best maybe just a partition flag or boot file that got overwritten accidentally, or a deliberately- or accidentally broken installer from another OS.

I get this error too, and I don’t think it happens in a chroot.

Background

I think this is when systemd cannot find the path because it is mounted in a directory. So, the difference is when you setup a chroot you already configure access to hardware, including drives.

Though you can configure this access inside Systemd that does not mean you can configure permissions for those drives the same way.

For instance, I created this file:

/etc/systemd/system/systemd-nspawn@.service.d/override.conf

And it contains these settings:

[Service]
DeviceAllow=char-usb_device rwm
DeviceAllow=char-usb
[Files]
Bind=/var/cache/apt/pkgcache.bin
Bind=/var/cache/apt/srcpkgcache.bin

This still does not work when using grub-install /dev/sda or update-grub for a USB on Pi debootstrapped with Debian Stretch. Even using grub-uboot and grub-efi-arm there is still that error the grub-probe cannot find the canonical path.

Not only that but though update-grub will see and know what the operating systems are, but interestingly grub-install does not recognize the Debian operating system is on USB.

Example

root@raspixmc:/home/pi# grub-install /dev/sda
Installing for arm-uboot platform.
grub-install: warning: no hints available for your platform. Expect 
reduced performance.
grub-install: warning: WARNING: no platform-specific install was 
performed.
Installation finished. No error reported.
root@raspixmc:/home/pi#

Interesting, when I create a chroot and can run update-grub, even though I am on the operating system that I debootstrapped to the USB itself it does not see its own operating system!

root@raspixmc:/home/pi# mount /dev/sda1 /mnt
root@raspixmc:/home/pi# cd /mnt
root@raspixmc:/mnt# mount --bind /dev dev/
root@raspixmc:/mnt# mount --bind /sys sys/
root@raspixmc:/mnt# mount --bind /proc proc/
root@raspixmc:/mnt# mount --bind /dev/pts dev/pts
root@raspixmc:/mnt# chroot . bin/bash
root@raspixmc:/# update-grub
Generating grub configuration file ...
Found Raspbian GNU/Linux 9 (stretch) on /dev/mmcblk0p2
done
root@raspixmc:/#

It only sees Raspbian. This happens only when trying to install and update GRUB inside the container, but when I exit the chroot.

Watch how it now works because I did not unmount the chroot directories:

/dev dev/
/sys sys/
/proc proc/
/dev/pts dev/pts

From outside the container mind you, I am running this command with grub-uboot installed on Raspbian and no Grub on the USB containing debootstrapped Debian.

root@raspixmc:/mnt# update-grub
Generating grub configuration file ...
Found Raspbian GNU/Linux 9 (stretch) on /dev/mmcblk0p2
Found Debian GNU/Linux 9 (stretch) on /dev/sda1
done
root@raspixmc:/mnt#

This does not happen using one of the unofficially available images for Debian ARM, but obviously this is still a customization not yet available for debootstrapping.

Troubleshooting

Really there are times when it is better just to create a path. The only next possibility (and a probable one) is to simply write GRUB. And for that I am just going to read on this page.

https://www.dedoimedo.com/computers/grub-2.html

Another thing I want to share about this issue is a solution that might work, but realize microSD cards are very sensitive. I have been building my own Linux images and learned this fast. The best thing to do is use Qemu whenever you can, but to attempt to clear an old partition table you might try running sgdisk --zap-all on the drive.

sgdisk --zap-all /dev/sdd

In fact, sometimes if it gives an error the first time and it is not a read-only error, you can run it again and it will finally all the partition tables new or old.

And you can use Qemu to emulate Raspberry Pi on a standard AMD/Intel-based PC. I would recommend it. I know this is more information than pertains to the original post, but I think that is likely how this error is derived. It is the container age.

To restore GRUB, you will need a boot disk or a USB flash drive with a Linux distribution. So, you have booted up in Live mode. Now you need to open the terminal.

1.You need to determine the disk partition on which GRUB was installedfdisk -l.

2.For example, installed in /dev/sda, mount the root partition, run the command (instead of /dev/sda, you must specify your own partition):sudo mount /dev/sda /mnt. If you have a separate partition allocated for the loader, then you need to mount it as well (instead of /dev / sdX specify your boot partition):sudo mount /dev/sdX /mnt/boot

3.View the contents of the /mnt directory to make sure that we have mounted the correct partition:ls /mnt.

4.You need to create links to several directories that GRUB must have access to in order to detect all operating systems. To do this, run the following commands:sudo mount --bind /dev /mnt/dev sudo mount --bind /dev/pts /mnt/dev/pts sudo mount --bind /proc /mnt/proc sudo mount --bind /sys /mnt/sys.If you use UEFI, then you also need to mount the EFI partition in the /mnt/boot/efi directory: sudo mount /dev/nvme0n1p1 /mnt/boot/efi for example…

5.To generate a GRUB configuration file the update-grub command is used. This command automatically detects the file systems on your computer and generates a new configuration file. Run the command:sudo update-grub.
If suddenly the update-grub utility has not detected your Windows, then you can run update-grub again from your Linux system when you boot into it (this helped me and Windows was determined).

6.It remains to install GRUB on the disk. We identified the partition on which we have GRUB installed in the first step this manual. This is the /dev/sda section.

To install GRUB, use the command grub-install, which needs to pass as a parameter the disk to which the installation will be performed (in my case, this is the disk /dev/sda):grub-install /dev/sda.

7.Exiting the chroot environment: exit.

8.We will unmount all the partitions that we have mounted:sudo umount /mnt/sys sudo umount /mnt/proc sudo umount /mnt/dev/pts sudo umount /mnt/dev. If you mounted a boot partition, then you also need to mount it:sudo umount /mnt/boot.If you mounted an EFI partition, we will mount:sudo umount /mnt/boot/efi.Unmount the root chapter:sudo umount /mnt.

9.Restarting the computer:reboot.

If the GRUB menu did not appear during the computer restart, it does not mean that it has not recovered. It is possible that the delay is simply set to zero and the menu is not displayed. To show the GRUB menu, you need to during boot, after the motherboard logo has appeared:
удерживать клавишу Shift, если у вас классический BIOS; нажать Esc, если у вас UEFI.

If, when running grub-update, Windows was not detected and was not added to the GRUB menu, then having already booted into open your Linux system (not a LiveCD), open a terminal and run:sudo grub-update.

Для восстановления GRUB потребуется загрузочный диск или флешка с дистрибутивом Linux. Итак, вы загрузились в Live-режиме. Теперь нужно открыть терминал.

1.Нужно определить раздел диска, на котором был установлен GRUB fdisk -l.

2.Например установлен в /dev/sda, примонтируем корневой раздел, выполняем команду (вместо /dev/sda вы должны указать свой раздел):sudo mount /dev/sda /mnt. Если для загрузчика у вас выделен отдельный раздел, то нужно примонтировать еще и его (вместо /dev/sdX укажите ваш boot-раздел):sudo mount /dev/sdX /mnt/boot

3.Посмотреть содержимое директории /mnt, чтобы убедиться, что мы примонтировали верный раздел:ls /mnt.

4.Нужно создать ссылки на несколько директорий, к которым GRUB должен иметь доступ для обнаружения всех операционных систем. Для этого выполните команды:sudo mount --bind /dev /mnt/dev sudo mount --bind /dev/pts /mnt/dev/pts sudo mount --bind /proc /mnt/proc sudo mount --bind /sys /mnt/sys.Если у вас используется UEFI, то еще нужно примонтировать EFI-раздел в директорию /mnt/boot/efi :sudo mount /dev/nvme0n1p1 /mnt/boot/efi например…

5.Для генерации файла конфигурации GRUB используется команда update-grub. Данная команда автоматически определяет файловые системы на вашем компьютере и генерирует новый файл конфигурации. Выполняем команду:sudo update-grub.
Если вдруг утилита update-grub не определила ваш Windows ,то можно будет запустить update-grub повторно уже из вашей Linux-системы, когда вы в нее загрузитесь (мне это помогло и Windows определился).

6.Осталось выполнить установку GRUB на диск. Мы определили раздел на котором у нас установлен GRUB на первом шаге данного руководства. Это раздел /dev/sda.

Для установки GRUB используется команда grub-install, которой нужно передать в качестве параметра диск, на который будет выполняться установка (в моем случае это диск /dev/sda):grub-install /dev/sda.

7.Выходим из окружения chroot: exit.

8.Отмонтируем все разделы, которые мы примонтировали:sudo umount /mnt/sys sudo umount /mnt/proc sudo umount /mnt/dev/pts sudo umount /mnt/dev. Если вы монтировали boot-раздел, то его тоже нужно отмонтировать:sudo umount /mnt/boot.Если вы монтировали EFI-раздел, отмонтируем:sudo umount /mnt/boot/efi.Отмонтируем корневой раздел:sudo umount /mnt.

9.Перезагружаем компьютер:reboot.

Если во время перезагрузки компьютера меню GRUB не появилось, то это еще не значит, что он не восстановился. Возможно, просто установлена нулевая задержка и меню не показывается. Чтобы показать меню GRUB нужно во время загрузки, после того, как появился логотип материнской платы:
удерживать клавишу Shift, если у вас классический BIOS; нажать Esc, если у вас UEFI.

Если у вас, при выполнении grub-update, не определился Windows и не был добавлен в меню GRUB, то уже загрузившись в вашу систему Linux (не LiveCD), откройте терминал и выполните:sudo grub-update.

I get this error too, and I don’t think it happens in a chroot.

Background

I think this is when systemd cannot find the path because it is mounted in a directory. So, the difference is when you setup a chroot you already configure access to hardware, including drives.

Though you can configure this access inside Systemd that does not mean you can configure permissions for those drives the same way.

For instance, I created this file:

/etc/systemd/system/systemd-nspawn@.service.d/override.conf

And it contains these settings:

[Service]
DeviceAllow=char-usb_device rwm
DeviceAllow=char-usb
[Files]
Bind=/var/cache/apt/pkgcache.bin
Bind=/var/cache/apt/srcpkgcache.bin

This still does not work when using grub-install /dev/sda or update-grub for a USB on Pi debootstrapped with Debian Stretch. Even using grub-uboot and grub-efi-arm there is still that error the grub-probe cannot find the canonical path.

Not only that but though update-grub will see and know what the operating systems are, but interestingly grub-install does not recognize the Debian operating system is on USB.

Example

root@raspixmc:/home/pi# grub-install /dev/sda
Installing for arm-uboot platform.
grub-install: warning: no hints available for your platform. Expect 
reduced performance.
grub-install: warning: WARNING: no platform-specific install was 
performed.
Installation finished. No error reported.
root@raspixmc:/home/pi#

Interesting, when I create a chroot and can run update-grub, even though I am on the operating system that I debootstrapped to the USB itself it does not see its own operating system!

root@raspixmc:/home/pi# mount /dev/sda1 /mnt
root@raspixmc:/home/pi# cd /mnt
root@raspixmc:/mnt# mount --bind /dev dev/
root@raspixmc:/mnt# mount --bind /sys sys/
root@raspixmc:/mnt# mount --bind /proc proc/
root@raspixmc:/mnt# mount --bind /dev/pts dev/pts
root@raspixmc:/mnt# chroot . bin/bash
root@raspixmc:/# update-grub
Generating grub configuration file ...
Found Raspbian GNU/Linux 9 (stretch) on /dev/mmcblk0p2
done
root@raspixmc:/#

It only sees Raspbian. This happens only when trying to install and update GRUB inside the container, but when I exit the chroot.

Watch how it now works because I did not unmount the chroot directories:

/dev dev/
/sys sys/
/proc proc/
/dev/pts dev/pts

From outside the container mind you, I am running this command with grub-uboot installed on Raspbian and no Grub on the USB containing debootstrapped Debian.

root@raspixmc:/mnt# update-grub
Generating grub configuration file ...
Found Raspbian GNU/Linux 9 (stretch) on /dev/mmcblk0p2
Found Debian GNU/Linux 9 (stretch) on /dev/sda1
done
root@raspixmc:/mnt#

This does not happen using one of the unofficially available images for Debian ARM, but obviously this is still a customization not yet available for debootstrapping.

Troubleshooting

Really there are times when it is better just to create a path. The only next possibility (and a probable one) is to simply write GRUB. And for that I am just going to read on this page.

https://www.dedoimedo.com/computers/grub-2.html

Another thing I want to share about this issue is a solution that might work, but realize microSD cards are very sensitive. I have been building my own Linux images and learned this fast. The best thing to do is use Qemu whenever you can, but to attempt to clear an old partition table you might try running sgdisk --zap-all on the drive.

sgdisk --zap-all /dev/sdd

In fact, sometimes if it gives an error the first time and it is not a read-only error, you can run it again and it will finally all the partition tables new or old.

And you can use Qemu to emulate Raspberry Pi on a standard AMD/Intel-based PC. I would recommend it. I know this is more information than pertains to the original post, but I think that is likely how this error is derived. It is the container age.

I get this error too, and I don’t think it happens in a chroot.

Background

I think this is when systemd cannot find the path because it is mounted in a directory. So, the difference is when you setup a chroot you already configure access to hardware, including drives.

Though you can configure this access inside Systemd that does not mean you can configure permissions for those drives the same way.

For instance, I created this file:

/etc/systemd/system/systemd-nspawn@.service.d/override.conf

And it contains these settings:

[Service]
DeviceAllow=char-usb_device rwm
DeviceAllow=char-usb
[Files]
Bind=/var/cache/apt/pkgcache.bin
Bind=/var/cache/apt/srcpkgcache.bin

This still does not work when using grub-install /dev/sda or update-grub for a USB on Pi debootstrapped with Debian Stretch. Even using grub-uboot and grub-efi-arm there is still that error the grub-probe cannot find the canonical path.

Not only that but though update-grub will see and know what the operating systems are, but interestingly grub-install does not recognize the Debian operating system is on USB.

Example

root@raspixmc:/home/pi# grub-install /dev/sda
Installing for arm-uboot platform.
grub-install: warning: no hints available for your platform. Expect 
reduced performance.
grub-install: warning: WARNING: no platform-specific install was 
performed.
Installation finished. No error reported.
root@raspixmc:/home/pi#

Interesting, when I create a chroot and can run update-grub, even though I am on the operating system that I debootstrapped to the USB itself it does not see its own operating system!

root@raspixmc:/home/pi# mount /dev/sda1 /mnt
root@raspixmc:/home/pi# cd /mnt
root@raspixmc:/mnt# mount --bind /dev dev/
root@raspixmc:/mnt# mount --bind /sys sys/
root@raspixmc:/mnt# mount --bind /proc proc/
root@raspixmc:/mnt# mount --bind /dev/pts dev/pts
root@raspixmc:/mnt# chroot . bin/bash
root@raspixmc:/# update-grub
Generating grub configuration file ...
Found Raspbian GNU/Linux 9 (stretch) on /dev/mmcblk0p2
done
root@raspixmc:/#

It only sees Raspbian. This happens only when trying to install and update GRUB inside the container, but when I exit the chroot.

Watch how it now works because I did not unmount the chroot directories:

/dev dev/
/sys sys/
/proc proc/
/dev/pts dev/pts

From outside the container mind you, I am running this command with grub-uboot installed on Raspbian and no Grub on the USB containing debootstrapped Debian.

root@raspixmc:/mnt# update-grub
Generating grub configuration file ...
Found Raspbian GNU/Linux 9 (stretch) on /dev/mmcblk0p2
Found Debian GNU/Linux 9 (stretch) on /dev/sda1
done
root@raspixmc:/mnt#

This does not happen using one of the unofficially available images for Debian ARM, but obviously this is still a customization not yet available for debootstrapping.

Troubleshooting

Really there are times when it is better just to create a path. The only next possibility (and a probable one) is to simply write GRUB. And for that I am just going to read on this page.

https://www.dedoimedo.com/computers/grub-2.html

Another thing I want to share about this issue is a solution that might work, but realize microSD cards are very sensitive. I have been building my own Linux images and learned this fast. The best thing to do is use Qemu whenever you can, but to attempt to clear an old partition table you might try running sgdisk --zap-all on the drive.

sgdisk --zap-all /dev/sdd

In fact, sometimes if it gives an error the first time and it is not a read-only error, you can run it again and it will finally all the partition tables new or old.

And you can use Qemu to emulate Raspberry Pi on a standard AMD/Intel-based PC. I would recommend it. I know this is more information than pertains to the original post, but I think that is likely how this error is derived. It is the container age.

Find your drive that’s supposed to boot with

mount

Or

parted -l

Or

fdisk /dev/sda

And type p to list the partitions, look for type 83.

(If you’ve got Fedora you might have to use the commands vgs and lvs and if you’ve got mdraid you might have to cat /proc/mdstat or mdadm -A --scan or insmod raid1 or insmod raid5 and then mdadm -A --scan) and you will use /dev/md0 or /dev/mapper/my-vg instead of /dev/sda

then try mount it

mkdir /mnt
mount /dev/sda1 /mnt
cd /mnt
ls -l

Is this your drive? Cool!

grub-install --recheck --root-directory=/mnt /dev/sda 

(Or whichever /dev drive your root is, with it’s mounted path)

grub-install --recheck --root-directory=/mnt /dev/sda --force

(Force it if it doesn’t like your partitions.)

Now it should boot into grub, and you can use the grub commands to boot up, after rebooting and selecting the right boot drive from the BIOS Setup, or by pressing ESC, F8 or F12 depending on your BIOS and whether you are quick enough, then at the Grub prompt — you can use tab completion to find it if it’s not (hd0,1) but (hd1,3) or something else instead, but beware, tab completion sometimes hangs for a few seconds if grub can’t read the filesystem. Once booted into Grub you can try to boot with:

insmod linux
ls
root=(hd0,1)
linux /boot/vmlinuz root=/dev/sda1
initrd /boot/initrd
boot

Or, hopefully you’ve still got an intact grub.cfg file…

ls
ls (hd0,1)/
ls (hd0,1)/boot
configfile (hd0,1)/boot/grub.cfg

Grub 1 allows you to do the installation from Grub:

install (hd0,1)

Once booted from the correct drive, you can retry update-grub and grub-install. If it still fails, you can try:

grub-mkconfig -o /mnt/boot/grub/grub.cfg

Your paths may differ of course, so just play with these commands until you can see what’s where and what’s going on.

It might be a sign of imminent hard drive failure at worst, or at best maybe just a partition flag or boot file that got overwritten accidentally, or a deliberately- or accidentally broken installer from another OS.

Записан

Записан

Вверх
Страницы1 2 3 4 5 6