grub-probe: ошибка: не удалось получить канонический путь к / cow

Я пытаюсь переустановить grub с USB-накопителя. Я запускаю следующее:

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

Я получаю следующую ошибку:

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

может кто-нибудь объяснить ошибку и как ее решить?

редактировать

Я пытаюсь починить сломанную систему с двойной загрузкой, работающую с USB, содержащего Linux Mint.

Следуй этим шагам:

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

Это по-прежнему не работает при использовании grub-install /dev/sdaили update-grubдля USB на Пи, debootstrapped Debian Stretch. Даже при использовании 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:/#

Это видит только Распбиан. Это происходит только при попытке установить и обновить GRUB внутри контейнера, но при выходе из chroot.

Посмотрите, как это теперь работает, потому что я не размонтировал каталоги chroot:

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

grub-ubootОбратите внимание на то, что из-за пределов контейнера я запускаю эту команду с установленным на Raspbian и без Grub на USB-диске, содержащем 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#

Этого не происходит с использованием одного из неофициально доступных образов для Debian ARM , но, очевидно, это все еще настройка, которая еще не доступна для начальной загрузки.

Исправление проблем

Действительно бывают времена, когда лучше просто создать путь. Единственная следующая (и вероятная) возможность - просто написать GRUB. И для этого я просто собираюсь читать на этой странице.

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

Еще одна вещь, которой я хотел бы поделиться по этому вопросу, - это решение, которое может работать, но следует понимать, что карты microSD очень чувствительны. Я создавал свои собственные образы Linux и научился этому быстро. Лучше всего использовать Qemu всякий раз, когда вы можете, но чтобы попытаться очистить старую таблицу разделов, вы можете попробовать запустить ее sgdisk --zap-allна диске.

sgdisk --zap-all /dev/sdd

На самом деле, иногда, если она выдает ошибку в первый раз, и это не ошибка только для чтения, вы можете запустить ее снова, и она, наконец, приведет к тому, что все таблицы разделов будут новыми или старыми.

И вы можете использовать Qemu для эмуляции Raspberry Pi на стандартном ПК на базе AMD / Intel. Я бы порекомендовал это. Я знаю, что это больше информации, чем относится к исходному сообщению, но я думаю, что, вероятно, как эта ошибка происходит. Это контейнерный век.

Для тех, кто борется с этим, кто пытается использовать живой USB или другие средства chroot для переустановки или установки grub - я сталкивался с этим несколько раз и забыл документировать это раньше, хотя и собирался.

Проблема, с которой вы сталкиваетесь, заключается в том, что у grub нет доступа к пути, на который вы указываете ни источник (/ boot), ни место назначения (может ли ваша система и chroot видеть, /dev/sdaнапример?), Либо и то, и другое. Когда вы готовитесь к chroot, вы создаете bind mounts, которые доступны в среде chroot, или вы делаете это в chroot, используя mount -t. В Интернете так много руководств, которые делают это в любом случае.

Вы должны убедиться, что вы связываете / dev или только определенный раздел (ы), содержащий загрузочные файлы в / boot (например, / dev / sda1). / boot - это либо отдельный раздел, либо каталог в /. chroot нужен доступ к диску, на котором вы будете (пере) устанавливать grub, чтобы выполнить команду fdisk -l в chroot, чтобы убедиться, что вы видите устройство, указанное в выходных данных. Также обратите внимание, что если у вас нет отдельного загрузочного раздела, но у вас есть загрузочный каталог в / root с загрузочными файлами (не только с точкой монтирования), то вам нужно только смонтировать раздел, содержащий root. Тогда вам не нужно ничего монтировать в / root / boot.

Вам также необходимо убедиться, что вы связываете файловую систему proc и файловую систему sys, но в каждом руководстве, которое я видел, есть эти два. Я только что видел / dev пропустил иногда. Могут быть случаи, когда вам это не нужно, но я о них не знаю.

tl; dr: убедитесь, что вы связываете mount / dev