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ミントを含むUSBから実行されている、壊れたデュアルブートシステムを修復しようとしています。

次の手順を実行します：

1. ライブLinuxセッションを起動します。

2. /インストールしたOSのパーティションをマウントします/mnt

   sudo mount /dev/sda6 /mnt
   

3. chroot環境を設定します。

   sudo chroot /mnt
   

4. これで、/mntとして扱われる「偽の」Linuxインストールが開始されました/。つまり、GRUBに必要なすべてのファイル/bootは、システムが想定する場所にあり、実際にインストールしたシステムを実行しているかのようにGRUBをインストールできます。

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

ここで再起動すると、GRUBメニューが正常に表示されるはずです。

何かの正規パスを解決できなかったとgrubが言った場合、それは存在しないかrealpath()失敗したことを意味します。

この場合、次のことを試してください。

$ realpath /cow
$ ls -la /cow

両方のコマンドで「ファイルまたはディレクトリが見つかりません」と表示された場合は、作成する必要があります。

2番目のコマンドは機能するが、最初のコマンドは機能しない場合は、なぜrealpath()機能しないかを確認してください。理由の1つは、/procマウントされていないことです。libcの一部の実装で/proc/self/fdは、ファイルの正規パスを取得するために使用されます。

書かれた内容によると、GRUBを/ dev / sdaにインストールしようとしているようです。ディスクをマウントしたくない。

あなたはおそらく探しています： grub-install /dev/sda

参照用のGRUB manページ、または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。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-ubootRaspbianにインストールして実行し、USBにはブートストラップが解除されたDebianを含む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のイメージの 1つを使用しても発生しませんが、明らかに、これはまだブートストラップ解除に利用できないカスタマイズです。

トラブルシューティング

実際には、パスを作成するだけの方が良い場合があります。次の唯一の可能性（およびおそらく）は、GRUBを記述することです。そのために、このページで読みます。

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

この問題について私が共有したいもう1つのことは、機能する可能性があるソリューションですが、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環境でアクセス可能なバインドマウントを作成するか、mount -tを使用してchroot内で作成します。オンラインで非常に多くのガイドがあり、どちらの方法でも実行できます。

/ devをバインドするか、/ bootにブートファイルを含む特定のパーティション（例：/ dev / sda1）のみをバインドする必要があります。/ bootは別のパーティションまたは/のディレクトリです。chrootは、grubを（再）インストールするドライブにアクセスする必要があるため、chrootでfdisk -lを実行して、出力にデバイスが表示されることを確認します。また、個別のブートパーティションはなく、/ rootにブートファイル（マウントポイントだけでなく）を含むブートディレクトリがある場合は、ルートを含むパーティションをマウントするだけで済みます。その後、/ root / bootに何もマウントする必要はありません。

また、procファイルシステムとsysファイルシステムを確実にバインドする必要がありますが、私が見たすべてのガイドにはこれら2つがあります。/ devが見逃されているのを見たことがあります。必要ない場合もあるかもしれませんが、わかりません。

tl; dr：必ずマウント/ devをバインドしてください