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?


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

  • OK, that edit is a step in the right direction. Are we to assume that you already have a Linux system installed? Does it boot from sda6? Does my answer here help?
    – terdon
    Oct 21, 2013 at 14:34
  • FWIW, /cow seems to refer to the Copy-on-write filesystem which is mounted at / when booting from a CD or USB
    – krubo
    Apr 19, 2020 at 13:08
  • Oddly enough, grub code has no matches for cow word at all.
    – Hi-Angel
    Jan 21, 2022 at 12:12

6 Answers 6


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.

  • I'm trying to install from the usb device. any way, I tried also without mounting - same error. can you explain the error?
    – elyashiv
    Oct 21, 2013 at 14:11
  • 1
    @elyashiv please edit your question and explain what it is you are attempting. Are you attempting to rescue a broken system? Are you booting a live system from the USB? If so, tell us. What OS are you using? What makes you think GRUB has a root-device option and what do you expect that option to do? Have you set up a chroot environment? Whenever you ask a question, you need to explain exactly what t is you are trying to do, we can't guess.
    – terdon
    Oct 21, 2013 at 14:19
  • oops, I meant -root-directory
    – elyashiv
    Oct 21, 2013 at 14:30
  • @elyashiv there's not --root-directory either. Go read my answer here that explains how to reinstall grub.
    – terdon
    Oct 21, 2013 at 14:34
  • look at the first answer here
    – elyashiv
    Oct 21, 2013 at 15:13

For me

sudo touch /cow

solved the problem.

  • So did for me, smart guy! :-) I transfer Acer One 10 from Windows to Linux. Very difficult problems with EFI, but it seems to be possible...
    – xerostomus
    Jan 5, 2022 at 2:54
  • grub-install: error: unknown filesystem. However this worked: ln /dev/sdb1 /cow -fis did the trick. Well I planned to install grub on a USB-Stick. VBoxManage internalcommands createrawvmdk to get the stick 'into' Virtualbox. Add the vmdk and the Linux mint ISO and boot the box. USB-Stick uses GPT and is on /dev/sdb. (sdb1 is some FAT ) sdb2 is some 1MB BIOS-Boot (2168...4649) GPT and sdb3 the FAT for grub.cfg and other files. grub-install /dev/sdb3 -v --force --boot-directory=/media/mint/boot
    – Nadu
    Apr 15, 2022 at 15:37

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


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:

DeviceAllow=char-usb_device rwm

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.


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 
Installation finished. No error reported.

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

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

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.


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.


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.


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.

  • I have the first command working, but not the 2nd one.
    – Quidam
    Apr 27, 2020 at 15:17
  • ME: root@ubuntu:/# realpath /cow TERMINAL: /cow ME:# ls -la /cow TERMINAL: ls: impossible to access '/cow': No file or folder of this kind (roughly translated).
    – Quidam
    Apr 27, 2020 at 15:19

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

  • Why are you talking about chroot when the question isn't about`` chroot``? Dec 19, 2018 at 4:05
  • The OP says "running from a USB containing linux mint". That will be a chroot. Feb 20, 2019 at 10:35

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

  • I already typed the grub-install command (on dev.sda1), but I had an error talking about blocks. And I got the "cow" error with the "grub-install --recheck --root-directory=/mnt /dev/sda1" command.
    – Quidam
    Apr 27, 2020 at 15:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .