grub-probe：错误：无法获得/ cow的规范路径

我正在尝试从USB驱动器重新安装grub。我运行以下命令：

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

我收到以下错误：

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

有人可以解释该错误，以及如何解决？

编辑

我正在尝试修复一个损坏的双引导系统，该系统从包含Linux Mint的USB运行。

按着这些次序：

1. 启动进入Live Linux会话。

2. /将已安装的操作系统的分区挂载到/mnt

   sudo mount /dev/sda6 /mnt
   

3. 设置chroot环境：

   sudo chroot /mnt
   

4. 您现在是在一个“假”的Linux安装对待/mnt的/。这意味着GRUB所需的所有文件都在/boot系统期望的位置，并且您可以像实际运行已安装的系统一样安装GRUB：

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

现在重新启动，您应该看到GRUB菜单正常显示。

如果grub说它无法解析某些事物的规范路径，则意味着它不存在或realpath()失败。

在这种情况下，请尝试：

$ realpath /cow
$ ls -la /cow

如果两个命令都说“找不到文件或目录”，则必须创建一个。

如果第二个命令有效，但第一个命令无效，请检查为什么realpath()不起作用。原因之一可能/proc是未安装。在libc的某些实现中，/proc/self/fd用于获取文件的规范路径。

根据所写内容，您似乎正在尝试将GRUB安装到/ dev / sda。您不想挂载磁盘。

您可能正在寻找： grub-install /dev/sda

GRUB手册页供参考，也可以man grub-install从您的系统中获取：http : //linux.die.net/man/8/grub-install

我也收到此错误，并且我认为它不会在chroot中发生。

背景

我认为这是当systemd因为安装在目录中而找不到路径时。因此，不同之处在于，当您设置chroot时，您已经配置了对硬件（包括驱动器）的访问。

尽管您可以在Systemd中配置此访问权限，但这并不意味着您可以以相同的方式配置这些驱动器的权限。

例如，我创建了这个文件：

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

它包含以下设置：

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

在通过Debian Stretch解除引导的Pi上使用USB grub-install /dev/sda或将其update-grub用于USB 时，这仍然不起作用。即使使用grub-uboot和grub-efi-arm仍然存在错误，grub-probe无法找到规范路径。

不仅如此，尽管update-grub可以看到并知道操作系统是什么，但有趣的grub-install是无法识别Debian操作系统在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 
performed.
Installation finished. No error reported.
root@raspixmc:/home/pi#

有趣的是，当我创建chroot并可以运行时update-grub，即使我使用的是自己重新引导到USB本身的操作系统，也看不到它自己的操作系统！

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:/#

它只看到Raspbian。仅当尝试在容器内安装和更新GRUB时才会发生这种情况，但是当我退出chroot时会发生这种情况。

观察它现在如何工作，因为我没有卸载chroot目录：

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

从容器外部，您正在运行此命令，该命令grub-uboot已安装在Raspbian上，而包含已解引导的Debian的USB上没有安装Grub。

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#

使用以下方法之一不会发生这种情况 对于Debian ARM，非官方可用的映像，但是显然，这仍然是自定义，尚无法用于解除引导。

故障排除

确实有时候创建一条路径会更好。唯一的下一种可能性（也是可能的可能性）就是简单地编写GRUB。为此，我将在本页上阅读。

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

关于此问题，我想分享的另一件事是可能有效的解决方案，但要意识到microSD卡非常敏感。我一直在构建自己的Linux映像，并且学得很快。最好的办法是尽可能使用Qemu，但是要清除旧的分区表，您可以尝试sgdisk --zap-all在驱动器上运行。

sgdisk --zap-all /dev/sdd

实际上，有时如果是第一次出现错误， 不是只读错误，则可以再次运行它，最终它将所有新的或旧的分区表。

而且，您可以使用Qemu在基于AMD / Intel的标准PC上模拟Raspberry Pi。我会推荐。我知道这是比原始帖子更多的信息，但是我认为这很可能是该错误的来源。这是集装箱的年龄。

对于任何尝试使用实时USB或其他chroot方式重新安装或安装grub的人，尽管我打算这样做，但我已经处理了几次，却忘记了对其进行记录。

您面临的问题是grub无法访问您称为源（/ boot）或目标（您的系统和chroot可以看到/dev/sda例如？）或两者的路径。当您准备使用chroot时，您将创建在chroot环境中可访问的绑定安装，或者您可以在chroot中使用mount -t进行绑定安装。网上有很多指南都可以做到这一点。

您需要确保绑定/ dev或仅绑定包含/ boot中引导文件的特定分区（例如/ dev / sda1）。/ boot是/中的单独分区或目录。chroot需要访问您将要（重新）安装grub的驱动器的访问权限，因此chroot中的fdisk -l也是这样，以确保您可以看到输出中列出的设备。另请注意，如果您没有单独的引导分区，但是/ root中确实有包含引导文件的引导目录（不仅是安装点），则只需安装包含root的分区。然后，您不必将任何文件挂载到/ root / boot。

您还需要确保绑定proc fileystem和sys文件系统，但是我所见过的每本指南都包含这两个。我刚刚看到/ dev有时会错过。在某些情况下，您可能不需要它，但我不知道它们。

tl; dr：确保绑定了mount / dev