grub-probe: error: kan het canonieke pad van / cow

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

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

Volg deze stappen:

1. Start een Live Linux-sessie op.

2. Koppel de / partitie van je geïnstalleerde besturingssysteem aan /mnt

   sudo mount /dev/sda6 /mnt 

3. Zet een chroot omgeving op:

   sudo chroot /mnt 

4. Je bevindt je nu in een “nep” Linux-installatie die /mnt behandelt als / . Dit betekent dat alle bestanden die nodig zijn voor GRUB zich in /boot bevinden waar het systeem ze verwacht en je kunt GRUB installeren alsof je daadwerkelijk je geïnstalleerde systeem draait:

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

Start nu opnieuw op en je zou het GRUB-menu normaal moeten zien verschijnen.

Opmerkingen

• Ik ‘ m probeer vanaf het usb-apparaat te installeren. hoe dan ook, ik heb het ook geprobeerd zonder te monteren – dezelfde fout. kun je de fout uitleggen?
• @elyashiv bewerk je vraag en leg uit wat je probeert. Probeert u een kapot systeem te redden? Start je een live systeem op vanaf de USB? Zo ja, vertel het ons . Welk besturingssysteem gebruik je? Waarom denk je dat GRUB een root-device optie heeft en wat verwacht je dat die optie doet? Heeft u een chroot -omgeving opgezet? Telkens wanneer je een vraag stelt, moet je precies uitleggen wat je probeert te doen, we kunnen ‘ niet raden.
• oeps, ik bedoelde -root -directory
• @elyashiv daar ‘ is ook niet --root-directory. Lees mijn antwoord hier waarin wordt uitgelegd hoe je grub opnieuw installeert.
• bekijk het eerste antwoord hier

Als grub zegt dat het het canonieke pad van iets niet kan oplossen , betekent dit dat het niet bestaat of realpath() mislukt.

Probeer in dit geval:

$ realpath /cow $ ls -la /cow 

Als beide commandos zeggen “kan bestand of map niet vinden”, dan moet je er een aanmaken.

Als het tweede commando werkt, maar het eerste niet, kijk dan waarom realpath() werkt niet. Een van de redenen kan zijn dat /proc niet is aangekoppeld. In sommige implementaties van libc wordt /proc/self/fd gebruikt om het canonieke pad van een bestand op te halen.

Opmerkingen

• Ik heb het eerste commando werkend, maar niet het tweede.
• ME: root @ ubuntu: / # realpath / cow TERMINAL: / cow ME: # ls -la / cow TERMINAL: ls: onmogelijk om access ‘ / cow ‘: geen bestand of map van dit type (ruwweg vertaald).

Ik krijg deze fout ook, en ik denk niet dat het gebeurt in een chroot.

Achtergrond

Ik denk dat dit is wanneer systemd het pad niet kan vinden omdat het in een directory is aangekoppeld. Het verschil is dus dat wanneer je een chroot instelt, je al toegang tot hardware configureert, inclusief schijven.

Hoewel je kunt deze toegang binnen Systemd configureren, wat niet betekent dat je de rechten voor die schijven op dezelfde manier kunt configureren.

Ik heb bijvoorbeeld dit bestand gemaakt:

/etc/systemd/system/[email protected]/override.conf 

En het bevat s deze instellingen:

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

Dit werkt nog steeds niet bij gebruik van grub-install /dev/sda of update-grub voor een USB op Pi debootstrapped met Debian Stretch. Zelfs als je grub-uboot en grub-efi-arm gebruikt, is er nog steeds die fout dat de grub-probe het canonieke pad niet kan vinden.

Niet alleen dat, maar hoewel update-grub zal zien en weten wat de besturingssystemen zijn, is het interessant dat grub-install niet erken dat het Debian-besturingssysteem op USB staat.

Voorbeeld

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# 

Interessant, wanneer ik een chroot maak en update-grub kan uitvoeren, ook al ben ik op het besturingssysteem dat ik debootstrapped naar de USB zelf, het ziet zijn eigen besturingssysteem niet!

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

Het ziet alleen Raspbian. Dit gebeurt alleen wanneer ik GRUB in de container probeer te installeren en bij te werken, maar wanneer ik de chroot afsluit.

Kijk hoe het nu werkt, want ik heb de chroot-mappen niet ontkoppeld:

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

Van buiten de container, let wel, ik ben aan het rennen dit commando met grub-uboot geïnstalleerd op Raspbian en geen Grub op de USB met 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# 

Dit niet gebeurt met een van de onofficieel beschikbare afbeeldingen voor Debian ARM , maar dit is duidelijk nog een aanpassing die nog niet beschikbaar is voor debootstrapping.

Probleemoplossing

Er zijn echt momenten waarop het beter is om gewoon een pad te creëren. De enige volgende mogelijkheid (en een waarschijnlijke) is om simpelweg GRUB te schrijven. En daarvoor ga ik gewoon op deze pagina lezen.

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

Een ander ding dat ik over dit probleem wil delen, is een oplossing die zou kunnen werken, maar besef dat microSD-kaarten erg gevoelig zijn. Ik heb mijn eigen Linux-images gebouwd en heb dit snel geleerd. Het beste wat u kunt doen is Qemu gebruiken wanneer u maar kunt, maar om te proberen een oude partitietabel te wissen, kunt u proberen sgdisk --zap-all op de schijf uit te voeren.

sgdisk --zap-all /dev/sdd 

In feite, soms als het de eerste keer een foutmelding geeft en het niet is een alleen-lezen fout, je kunt het opnieuw uitvoeren en het zal uiteindelijk alle partitietabellen nieuw of oud bevatten.

En je kunt Qemu gebruiken om Raspberry te emuleren Pi op een standaard AMD / Intel-pc. Ik zou het aanraden. Ik weet dat dit meer informatie is dan betrekking heeft op het oorspronkelijke bericht, maar ik denk dat dit waarschijnlijk is hoe deze fout is afgeleid. Het is het containertijdperk.

Op basis van wat er is geschreven, lijkt het erop dat je GRUB probeert te installeren op / dev / sda. Je wilt de schijf niet mounten.

Waarschijnlijk ben je op zoek naar: grub-install /dev/sda

GRUB man-pagina ter referentie, of u kunt man grub-install vanaf uw systeem: http://linux.die.net/man/8/grub-install

Reacties

• Ik heb het grub-install commando al getypt (op dev.sda1), maar ik had een fout bij het praten over blokken. En ik kreeg de ” koe ” fout met de ” grub-install –check –root-directory = / mnt / dev / sda1 ” commando.

Voor iedereen die hiermee worstelt en probeert een live USB of andere chroot te gebruiken om grub opnieuw te installeren of te installeren – ik heb dit een paar keer behandeld en ben vergeten het eerder te documenteren, hoewel ik van plan was .

Het probleem waarmee u wordt geconfronteerd, is dat grub geen toegang heeft tot het pad waarnaar u verwijst, hetzij als de bron (/ boot) of de bestemming (kunnen uw systeem en chroot zien /dev/sda bijvoorbeeld?) of beide. Wanneer je je voorbereidt om te chroot, maak je bindmounts aan die toegankelijk zijn in de chroot-omgeving, of je doet dit binnen de chroot met mount -t. Er zijn zoveel gidsen online die het op beide manieren doen.

Je moet ervoor zorgen dat je / dev bindt of alleen de specifieke partitie (s) die de bootbestanden bevat in / boot (bijv. / Dev / sda1) . / boot is ofwel een aparte partitie of een directory in /. De chroot heeft toegang nodig tot de drive waarop je grub gaat (her) installeren, dus doe fdisk -l in de chroot om er zeker van te zijn dat je het apparaat in de uitvoer kunt zien. Merk ook op dat als je geen aparte opstartpartitie hebt, maar je hebt wel een opstartmap in / root met de opstartbestanden (niet alleen een koppelpunt), dan hoef je alleen de partitie met root te koppelen. je hoeft niets te mounten in / root / boot.

Je moet er ook voor zorgen dat je het proc-bestandssysteem en het sys-bestandssysteem bindt, maar elke guide die ik heb gezien, heeft die twee. Ik heb net gezien / dev heeft het soms gemist. Er kunnen enkele gevallen zijn waarin je het niet nodig hebt, maar ik weet het niet.

tl; dr: zorg ervoor dat je mount / dev bindt

Reacties

• Waarom heb je het over chroot als de vraag niet ‘ t over is chroot ?
• Het OP zegt ” draaiend vanaf een USB met linux mint “. Dat zal een chroot zijn.