grub-probe: error: nie udało się uzyskać kanonicznej ścieżki / cow

Próbuję ponownie zainstalować grub z dysku USB. Uruchamiam następujące:

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

Otrzymuję następujący błąd:

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

czy ktoś może wyjaśnić błąd i jak go rozwiązać?

Edytować

Próbuję naprawić zepsuty system podwójnego rozruchu, uruchamiany z USB zawierającego linuksową miętę.

Wykonaj następujące kroki:

1. Uruchom sesję Live Linux.

2. Zamontuj /partycję zainstalowanego systemu operacyjnego na/mnt

   sudo mount /dev/sda6 /mnt
   

3. Skonfiguruj chrootśrodowisko:

   sudo chroot /mnt
   

4. Jesteś teraz w „fałszywej” instalacji Linuksa, która traktuje /mntjak /. Oznacza to, że wszystkie pliki niezbędne dla GRUB-a znajdują się /boottam, gdzie oczekuje ich system, i możesz zainstalować GRUB tak, jakbyś faktycznie uruchomił zainstalowany system:

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

Teraz uruchom ponownie i powinieneś zobaczyć menu GRUB-a wyświetlane normalnie.

Jeśli grub mówi, że nie może rozwiązać kanonicznej ścieżki czegoś, oznacza to, że nie istnieje lub realpath()nie działa .

W takim przypadku spróbuj:

$ realpath /cow
$ ls -la /cow

Jeśli oba polecenia mówią „nie można znaleźć pliku lub katalogu”, musisz go utworzyć.

Jeśli drugie polecenie działa, ale pierwsze nie, sprawdź, dlaczego realpath()nie działa. Jednym z powodów może być /procbrak zamontowania. W niektórych implementacjach libc /proc/self/fdsłuży do uzyskania kanonicznej ścieżki do pliku.

Na podstawie tego, co zostało napisane, wygląda na to, że próbujesz zainstalować GRUB na / dev / sda. Nie chcesz montować dysku.

Prawdopodobnie szukasz: grub-install /dev/sda

Strona podręcznika użytkownika GRUB w celach informacyjnych, lub możesz to zrobić man grub-installze swojego systemu: http://linux.die.net/man/8/grub-install

Dostaję również ten błąd i nie sądzę, że dzieje się to w chroot.

tło

Myślę, że dzieje się tak, gdy systemd nie może znaleźć ścieżki, ponieważ jest zamontowany w katalogu. Różnica polega na tym, że podczas konfigurowania chroot już konfigurujesz dostęp do sprzętu, w tym dysków.

Chociaż możesz skonfigurować ten dostęp w Systemd, nie oznacza to, że możesz skonfigurować uprawnienia dla tych dysków w ten sam sposób.

Na przykład utworzyłem ten plik:

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

I zawiera te ustawienia:

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

To nadal nie działa, gdy używasz grub-install /dev/sdalub update-grubna USB na Pi debootstrapped z Debian Stretch. Nawet przy użyciu grub-uboot i grub-efi-arm nadal występuje błąd, który grub-probenie może znaleźć ścieżki kanonicznej.

Nie tylko to, ale update-grubzobaczy i dowie się, jakie są systemy operacyjne, ale co ciekawe grub-install, nie rozpoznaje systemu operacyjnego Debian na USB.

Przykład

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#

Ciekawe, kiedy utworzę chroot i mogę uruchomić update-grub, mimo że korzystam z systemu operacyjnego, który debootstrapowałem do samego USB, nie widzi on własnego systemu operacyjnego!

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

Widzi tylko Raspbian. Dzieje się tak tylko wtedy, gdy próbuję zainstalować i zaktualizować GRUB wewnątrz kontenera, ale kiedy wychodzę z chroot.

Zobacz, jak to działa, ponieważ nie odmontowałem katalogów chroot:

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

Z zewnątrz kontenera, proszę cię, uruchamiam to polecenie z grub-ubootzainstalowanym na Raspbian i bez Grub na USB zawierającym 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#

Nie dzieje się tak przy użyciu jednego z nieoficjalnie dostępnych obrazów dla Debian ARM , ale oczywiście jest to nadal dostosowanie, które nie jest jeszcze dostępne do debootstrapowania.

Rozwiązywanie problemów

Naprawdę są chwile, kiedy lepiej jest po prostu stworzyć ścieżkę. Jedyną następną (i prawdopodobną) możliwością jest napisanie GRUB-a. I o tym po prostu przeczytam na tej stronie.

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

Kolejną rzeczą, którą chcę podzielić się tym problemem, jest rozwiązanie, które może działać, ale zdaj sobie sprawę, że karty microSD są bardzo wrażliwe. Budowałem własne obrazy Linuksa i nauczyłem się tego szybko. Najlepiej jest używać Qemu, kiedy tylko możesz, ale aby wyczyścić starą tablicę partycji, możesz spróbować uruchomić sgdisk --zap-allna dysku.

sgdisk --zap-all /dev/sdd

W rzeczywistości, czasami jeśli daje błąd po raz pierwszy i to nie błąd tylko do odczytu, można go uruchomić ponownie i ostatecznie wszystkie tabele partycji nowy czy stary.

I możesz użyć Qemu do emulacji Raspberry Pi na standardowym komputerze z procesorem AMD / Intel. Poleciłbym to. Wiem, że to więcej informacji niż dotyczy oryginalnego postu, ale myślę, że prawdopodobnie jest to sposób, w jaki ten błąd jest uzyskiwany. Jest to wiek kontenera.

Dla każdego, kto zmaga się z tym, kto próbuje użyć Live USB lub innego narzędzia chroot do ponownej instalacji lub instalacji gruba - poradziłem sobie z tym kilka razy i zapomniałem go wcześniej udokumentować, chociaż zamierzałem.

Problem, z którym musisz się zmierzyć, to brak dostępu do ścieżki, którą określasz jako źródło (/ boot) lub miejsce docelowe (czy Twój system i chroot mogą zobaczyć /dev/sdana przykład?) Lub jedno i drugie. Kiedy przygotowujesz się do chroot, tworzysz montowania opraw, które są dostępne w środowisku chroot, lub robisz to w chroot, używając mount -t. Jest tak wiele przewodników online, które robią to w obie strony.

Musisz upewnić się, że powiążesz / dev lub tylko określone partycje zawierające pliki rozruchowe w / boot (np. / Dev / sda1). / boot jest oddzielną partycją lub katalogiem w / Chroot potrzebuje dostępu do dysku, na którym będziesz (ponownie) instalował grub, więc zrób fdisk -l w chroot, aby upewnić się, że urządzenie jest wymienione na wyjściu. Pamiętaj również, że jeśli nie masz osobnej partycji rozruchowej, ale masz katalog rozruchowy w katalogu / root z plikami rozruchowymi (nie tylko punktem montowania), musisz tylko zamontować partycję zawierającą katalog główny. Nie musisz wtedy montować niczego w katalogu / root / boot.

Musisz także upewnić się, że powiążesz system plików proc i system plików sys, ale każdy przewodnik, który widziałem, ma te dwa. Właśnie widziałem / dev czasami tęskniłem. Może być kilka przypadków, kiedy nie jest to potrzebne, ale nie znam ich.

tl; dr: upewnij się, że powiążesz mount / dev