Cfrtjryk

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.

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.

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

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 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.

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