grub-probe: error: failed to get canonical path of /cow

Question

I'm trying to re-install grub from a USB drive. I run the following:

sudo mount /dev/sda6 /mnt
sudo grub-install --root-directory=/mnt /dev/sda

I get the following error:

grub-probe: error: failed to get canonical path of /cow.

can someone explain the error, and how to solve it?

Edit

I'm trying to repair a broken dual-boot system, running from a USB containing linux mint.

Answer 1

Follow these steps:

1. Boot into a Live Linux session.

2. Mount the / partition of your installed OS to /mnt

   sudo mount /dev/sda6 /mnt
   

3. Set up a chroot environment:

   sudo chroot /mnt
   

4. You are now in a "fake" Linux install that treats /mnt as /. This means that all the files necessary for GRUB are in /boot where the system expects them to be and you can install GRUB just as if you were actually running your installed system:

   sudo update-grub
   sudo grub-install /dev/sda
   

Now reboot and you should see the GRUB menu appear normally.

Answer 2

For me

sudo touch /cow

solved the problem.

Answer 3

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/[email protected]/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.

Answer 4

If grub says that it could not resolve canonical path of something, it means that it does not exist or realpath() failed.

In this case, try:

$ realpath /cow
$ ls -la /cow

If both commands say "cannot find file or directory", then you have to create one.

If the second command works, but the first does not, check why realpath() does not work. One of the reasons can be that /proc is not mounted. In some implementations of libc, /proc/self/fd is used to get canonical path of a file.

Answer 5

For anyone struggling with this who is attempting to use a live USB or other means of chroot to reinstall or install grub - I've dealt with this a few times and forgot to document it before although I intended to.

The problem you face is grub doesn't have access to the path you are referring to either as the source (/boot) or the destination (can your system and chroot see /dev/sda for example?) or both. When you prepare to chroot you create bind mounts that are accessible in the chroot environment, or you do so within the chroot using mount -t. There are so many guides online that do it either way.

You need to make sure you bind /dev or just the specific partition(s) containing the boot files in /boot (e.g. /dev/sda1). /boot is either a separate partition or a directory in / The chroot needs access to the drive that you will be (re)installing grub to so do fdisk -l in the chroot to make sure you can see the device listed in the output. Also note, if you don't have a separate boot partition, but you do have a boot directory in /root with the boot files (not just a mount point) then you only have to mount the partition containing root. You then don't have to mount anything to /root/boot.

You also need to make sure you bind the proc fileystem and the sys filesystem, but every guide I've seen has those two. I've just seen /dev missed out sometimes. There might be some cases when you don't need it, but I don't know of them.

tl;dr: make sure you bind mount /dev

Answer 6

Based on what was written, it looks like you're trying to install GRUB to /dev/sda. You do not want to mount the disk.

You're probably looking for: grub-install /dev/sda

GRUB man page for reference, or you can man grub-install from your system: http://linux.die.net/man/8/grub-install