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

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]   Вниз

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

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

Многие пользователи дистрибутивов Linux устанавливают на жёстком диске своего компьютера две и более систем, одну как рабочую, а другую/другие для тестирования или просто ради любопытства. И здесь возникает не существенная, но всё-таки проблема с загрузчиком GRUB, так как установка новой (другой системы) автоматически изменяет меню загрузки систем, т. е. наша вновь установленная система оказывается первой в списке. Для восстановления загрузчика GRUB своей предпочтительной системы пользователь, применяет такие графические инструменты как: Boot-Repair или Grub Customizer, которые прекрасно с этим справляются.

Но оказывается и в терминале можно сделать то же самое всего одной командой. Для этого необходимо так же, как и с вышеупомянутыми инструментами, загрузиться в предпочитаемой системе, GRUB которой хотите восстановить, открыть окно терминала и проверить, какая система примонтирована в настоящий момент. Выполните следующую команду:

lsblk

Как видно на снимке примотированных разделов у меня три. Из них /media, это раздел ntfs, который служит для хранения различных файлов на моём компьютере, [SWAP] в квадратных скобках, указывает на то, что примонтирован, но не задействован в настоящий момент, а вот sda6, отмеченный правым слешем — это тот самый раздел, на котором находится корневая файловая система.
Теперь мы можем приступить к повторной установке загрузчика Grub на ней. Необходимо выполнить следующую команду:

sudo grub-install /dev/sda

Установка завершена. Ошибок нет.

И остаётся только обновить GRUB:

sudo update-grub

Вот и все. Теперь можно перезагрузить компьютер, чтобы убедиться, что выбранная система Linux находится первой в меню загрузчика GRUB.

Удачи.