Grub install ошибка не удалось получить канонический путь cow

Find your drive that’s supposed to boot with

mount

Or

parted -l

Or

fdisk /dev/sda

And type p to list the partitions, look for type 83.

(If you’ve got Fedora you might have to use the commands vgs and lvs and if you’ve got mdraid you might have to cat /proc/mdstat or mdadm -A --scan or insmod raid1 or insmod raid5 and then mdadm -A --scan) and you will use /dev/md0 or /dev/mapper/my-vg instead of /dev/sda

then try mount it

mkdir /mnt
mount /dev/sda1 /mnt
cd /mnt
ls -l

Is this your drive? Cool!

grub-install --recheck --root-directory=/mnt /dev/sda 

(Or whichever /dev drive your root is, with it’s mounted path)

grub-install --recheck --root-directory=/mnt /dev/sda --force

(Force it if it doesn’t like your partitions.)

Now it should boot into grub, and you can use the grub commands to boot up, after rebooting and selecting the right boot drive from the BIOS Setup, or by pressing ESC, F8 or F12 depending on your BIOS and whether you are quick enough, then at the Grub prompt — you can use tab completion to find it if it’s not (hd0,1) but (hd1,3) or something else instead, but beware, tab completion sometimes hangs for a few seconds if grub can’t read the filesystem. Once booted into Grub you can try to boot with:

insmod linux
ls
root=(hd0,1)
linux /boot/vmlinuz root=/dev/sda1
initrd /boot/initrd
boot

Or, hopefully you’ve still got an intact grub.cfg file…

ls
ls (hd0,1)/
ls (hd0,1)/boot
configfile (hd0,1)/boot/grub.cfg

Grub 1 allows you to do the installation from Grub:

install (hd0,1)

Once booted from the correct drive, you can retry update-grub and grub-install. If it still fails, you can try:

grub-mkconfig -o /mnt/boot/grub/grub.cfg

Your paths may differ of course, so just play with these commands until you can see what’s where and what’s going on.

It might be a sign of imminent hard drive failure at worst, or at best maybe just a partition flag or boot file that got overwritten accidentally, or a deliberately- or accidentally broken installer from another OS.

I get this error too, and I don’t think it happens in a chroot.

Background

I think this is when systemd cannot find the path because it is mounted in a directory. So, the difference is when you setup a chroot you already configure access to hardware, including drives.

Though you can configure this access inside Systemd that does not mean you can configure permissions for those drives the same way.

For instance, I created this file:

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

And it contains these settings:

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

This still does not work when using grub-install /dev/sda or update-grub for a USB on Pi debootstrapped with Debian Stretch. Even using grub-uboot and grub-efi-arm there is still that error the grub-probe cannot find the canonical path.

Not only that but though update-grub will see and know what the operating systems are, but interestingly grub-install does not recognize the Debian operating system is on USB.

Example

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#

Interesting, when I create a chroot and can run update-grub, even though I am on the operating system that I debootstrapped to the USB itself it does not see its own operating system!

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

It only sees Raspbian. This happens only when trying to install and update GRUB inside the container, but when I exit the chroot.

Watch how it now works because I did not unmount the chroot directories:

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

From outside the container mind you, I am running this command with grub-uboot installed on Raspbian and no Grub on the USB containing 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#

This does not happen using one of the unofficially available images for Debian ARM, but obviously this is still a customization not yet available for debootstrapping.

Troubleshooting

Really there are times when it is better just to create a path. The only next possibility (and a probable one) is to simply write GRUB. And for that I am just going to read on this page.

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

Another thing I want to share about this issue is a solution that might work, but realize microSD cards are very sensitive. I have been building my own Linux images and learned this fast. The best thing to do is use Qemu whenever you can, but to attempt to clear an old partition table you might try running sgdisk --zap-all on the drive.

sgdisk --zap-all /dev/sdd

In fact, sometimes if it gives an error the first time and it is not a read-only error, you can run it again and it will finally all the partition tables new or old.

And you can use Qemu to emulate Raspberry Pi on a standard AMD/Intel-based PC. I would recommend it. I know this is more information than pertains to the original post, but I think that is likely how this error is derived. It is the container age.

Найдите диск, который должен загрузиться с

mount

Или же

parted -l

Или же

fdisk /dev/sda

И введите p, чтобы получить список разделов, ищите тип 83.

(Если у вас есть Fedora, вам, возможно, придется использовать команды «vgs» и «lvs», а если у вас есть mdraid, вам может понадобиться «cat /proc/mdstat» или mdadm -A —scan или insmod raid1 или insmod raid5, а затем mdadm -A —scan), и вы будете использовать /dev/md0 или /dev/mapper/my-vg вместо / dev / sda

тогда попробуй смонтировать

mkdir /mnt
mount /dev/sda1 /mnt
cd /mnt
ls -l

Это твой диск? Здорово!

grub-install --recheck --root-directory=/mnt /dev/sda 

(В зависимости от того, какой диск / dev использует ваш корень, с установленным путем)

grub-install --recheck --root-directory=/mnt /dev/sda --force

(Принудительно, если вам не нравятся ваши разделы.)

Теперь он должен загрузиться в grub, и вы можете использовать команды grub для загрузки, после перезагрузки и выбора правильного загрузочного диска в BIOS Setup, или нажав ESC или F12 в зависимости от вашего BIOS и того, достаточно ли вы быстры, затем в приглашение Grub — вы можете использовать завершение табуляции, чтобы найти его, если оно не (hd0,1), но (hd1,3) или что-то еще, но будьте осторожны, завершение табуляции иногда зависает на несколько секунд, если grub не может прочитать диск,

insmod linux
ls
root=(hd0,1)
linux /boot/vmlinuz root=/dev/sda1
initrd /boot/initrd
boot

Или, надеюсь, у вас все еще есть неповрежденный файл grub.cfg… или, возможно, это сработает:

grub-mkconfig -o /mnt/boot/grub/grub.cfg
  • Печать

Страницы: [1]   Вниз

Тема: Не удалось получить канонический путь «/cow».  (Прочитано 5760 раз)

0 Пользователей и 1 Гость просматривают эту тему.

Оффлайн
Slasher40

Чёткое и внятное описание проблемы:
Здравствуйте, в Linux-е я новичок так что извиняюсь, предыстория:
Все началось с того что решил глубже окунуться в систему, на жесткий диск решил не ставить так как знаю откуда у меня растут руки. Поставил все на флешку с помощью Kali Linux (Так же на флешке с разделом: Persistence) ставил с помощью mkusb.

Нужно было установить драйвера Nvidia но он не применялся, в итоге оказалось что было мало места. Выделил место установилось но драйвер все так же не определяется. Устанавливал 396 драйвер, но все без успешно. Дальше раскрывая проблему понял что возможно нужно установить новое ядро Установил: 4.18.8 но как я понял дальше нужно было выбрать запуск с этого ядра. Решил воспользоваться: Grub Cosomizer но он выдает окно с: «grub-mkconfig не может быть успешно выполнен. Сообщение об ошибке: /usr/sbin/grub-probe: ошибка: не удалось получить канонический путь «/cow.» » Кнопка с выходом и изменением переменных сред, есть ошибка на: /boot/grub/device.map и /boot/grub/grub.cfg

Пробовал восстановить загрузчик,но безрезультатно вот лог: paste.ubuntu.com/p/tkMy3fYkwY/

Ошибка в загрузчике? И как исправить?

Заранее спасибо.

Правила форума
1.4. Листинги и содержимое текстовых файлов следует добавлять в сообщение с помощью тегов

Показать скрытое содержание
или [code]…[/code], либо прикреплять к сообщению в виде отдельного файла. Длинные гиперссылки следует оформлять при помощи тега [url=]…[/url]

  —Aleksandru

« Последнее редактирование: 21 Сентября 2018, 20:26:05 от Aleksandru »


Оффлайн
ecc83

решил глубже окунуться в систему, на жесткий диск решил не ставить

Это просто анекдот какой то…
Если нужно «окунуться», тогда выделяйте 20Гб дискового пространства и ставьте систему на диск.
Новые ядра не трогайте, разберитесь сначала со старыми…


Оффлайн
Slasher40

А по другому это ни как решить нельзя? Лишнего жесткого нет, да и приходится стартовать с разных компьютеров, а флешка с постоянным хранилищем это для меня единственное стоящее решение.


Оффлайн
ecc83

флешка с постоянным хранилищем это для меня единственное стоящее решение.

Тогда нужно использовать для этого специально собранные дистрибутивы. Например мне нравится Slax.

https://www.slax.org/el/

http://mirror.ppa.trinitydesktop.org/trinity-sb/cdimages/slax/

По ссылкам выше один и тот же дистрибутив с разным графическим окружением.

Устанавливать очень просто, из под Windows форматируется флешка FAT32, затем при помощи архиватора 7z распаковывается содержимое на флешку в каталог /slax. Потом заходишь на созданную флешку в папку /slax/boot и там нужно запустить файл bootinst.bat

После этого с этой флешки можно грузиться.

« Последнее редактирование: 21 Сентября 2018, 22:58:37 от ecc83 »


Оффлайн
Vitsliputsli

А с каких пор linux перестал работать с флешек? Работа с устройствами ввода/ввывода — это задача ядра, а оно одно (с определенными оговорками, конечно, но точно не в этом вопросе), так что по-большому счету без разницы что за дистрибутив.

Сообщение об ошибке: /usr/sbin/grub-probe: ошибка: не удалось получить канонический путь «/cow.»

Я так понимаю загружаетесь в систему восстановления, тогда попробуйте переключиться через chroot в созданную систему и там уже сгенерировать конфигурацию grub.


Оффлайн
Slasher40

попробуйте переключиться через chroot в созданную систему и там уже сгенерировать конфигурацию grub.

Можно по подробнее с этого момента, куда нажать и что сделать?


Оффлайн
Vitsliputsli


Оффлайн
AnrDaemon

А по другому это ни как решить нельзя? Лишнего жесткого нет, да и приходится стартовать с разных компьютеров, а флешка с постоянным хранилищем это для меня единственное стоящее решение.

Поставьте в виртуалку.

Хотите получить помощь? Потрудитесь представить запрошенную информацию в полном объёме.

Прежде чем [Отправить], нажми [Просмотр] и прочти собственное сообщение. Сам-то понял, что написал?…


Оффлайн
ecc83

куда нажать и что сделать?

Нажать никогда не поздно, главное, что бы это помогло

Пожалейте себя. Сделайте себе флешку за 15 минут по моей ссылке и останетесь здоровым и счастливым человеком.
Если же начнёте с перестановки ядра, то это у вас надолго.


  • Печать

Страницы: [1]   Вверх

Solution 1

Follow these steps:

  1. Boot into a Live Linux session.

  2. Mount the / partition of your installed OS to /mnt

    sudo mount /dev/sda6 /mnt
    
  3. Set up a chroot environment:

    sudo chroot /mnt
    
  4. You are now in a «fake» Linux install that treats /mnt as /. This means that all the files necessary for GRUB are in /boot where the system expects them to be and you can install GRUB just as if you were actually running your installed system:

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

Now reboot and you should see the GRUB menu appear normally.

Solution 2

If grub says that it could not resolve canonical path of something, it means that it does not exist or realpath() failed.

In this case, try:

$ realpath /cow
$ ls -la /cow

If both commands say «cannot find file or directory», then you have to create one.

If the second command works, but the first does not, check why realpath() does not work. One of the reasons can be that /proc is not mounted. In some implementations of libc, /proc/self/fd is used to get canonical path of a file.

Solution 3

For me

sudo touch /cow

solved the problem.

Solution 4

I get this error too, and I don’t think it happens in a chroot.

Background

I think this is when systemd cannot find the path because it is mounted in a directory. So, the difference is when you setup a chroot you already configure access to hardware, including drives.

Though you can configure this access inside Systemd that does not mean you can configure permissions for those drives the same way.

For instance, I created this file:

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

And it contains these settings:

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

This still does not work when using grub-install /dev/sda or update-grub for a USB on Pi debootstrapped with Debian Stretch. Even using grub-uboot and grub-efi-arm there is still that error the grub-probe cannot find the canonical path.

Not only that but though update-grub will see and know what the operating systems are, but interestingly grub-install does not recognize the Debian operating system is on USB.

Example

[email protected]:/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.
[email protected]:/home/pi#

Interesting, when I create a chroot and can run update-grub, even though I am on the operating system that I debootstrapped to the USB itself it does not see its own operating system!

[email protected]:/home/pi# mount /dev/sda1 /mnt
[email protected]:/home/pi# cd /mnt
[email protected]:/mnt# mount --bind /dev dev/
[email protected]:/mnt# mount --bind /sys sys/
[email protected]:/mnt# mount --bind /proc proc/
[email protected]:/mnt# mount --bind /dev/pts dev/pts
[email protected]:/mnt# chroot . bin/bash
[email protected]:/# update-grub
Generating grub configuration file ...
Found Raspbian GNU/Linux 9 (stretch) on /dev/mmcblk0p2
done
[email protected]:/#

It only sees Raspbian. This happens only when trying to install and update GRUB inside the container, but when I exit the chroot.

Watch how it now works because I did not unmount the chroot directories:

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

From outside the container mind you, I am running this command with grub-uboot installed on Raspbian and no Grub on the USB containing debootstrapped Debian.

[email protected]:/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
[email protected]:/mnt#

This does not happen using one of the unofficially available images for Debian ARM, but obviously this is still a customization not yet available for debootstrapping.

Troubleshooting

Really there are times when it is better just to create a path. The only next possibility (and a probable one) is to simply write GRUB. And for that I am just going to read on this page.

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

Another thing I want to share about this issue is a solution that might work, but realize microSD cards are very sensitive. I have been building my own Linux images and learned this fast. The best thing to do is use Qemu whenever you can, but to attempt to clear an old partition table you might try running sgdisk --zap-all on the drive.

sgdisk --zap-all /dev/sdd

In fact, sometimes if it gives an error the first time and it is not a read-only error, you can run it again and it will finally all the partition tables new or old.

And you can use Qemu to emulate Raspberry Pi on a standard AMD/Intel-based PC. I would recommend it. I know this is more information than pertains to the original post, but I think that is likely how this error is derived. It is the container age.

Related videos on Youtube

GRUB Error: grub-install: error: failed to get canonical path of `/cow'

01 : 22

GRUB Error: grub-install: error: failed to get canonical path of `/cow’

"/usr/sbin/grub-probe: error: failed to get canonical path of `'."" when using grub customizer

02 : 00

«/usr/sbin/grub-probe: error: failed to get canonical path of `’.»» when using grub customizer

Ubuntu: Failed to get canonical path of /cow

03 : 59

Ubuntu: Failed to get canonical path of /cow

Unix & Linux: grub-probe: error: failed to get canonical path of /cow (5 Solutions!!)

04 : 11

Unix & Linux: grub-probe: error: failed to get canonical path of /cow (5 Solutions!!)

arch linux- error:failed to get canonical path of 'airootfs' (grub to USB installation)

02 : 35

arch linux- error:failed to get canonical path of ‘airootfs’ (grub to USB installation)

Comments

  • I’m trying to re-install grub from a USB drive. I run the following:

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

    I get the following error:

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

    can someone explain the error, and how to solve it?

    Edit

    I’m trying to repair a broken dual-boot system, running from a USB containing linux mint.

    • OK, that edit is a step in the right direction. Are we to assume that you already have a Linux system installed? Does it boot from sda6? Does my answer here help?

    • FWIW, /cow seems to refer to the Copy-on-write filesystem which is mounted at / when booting from a CD or USB

    • Oddly enough, grub code has no matches for cow word at all.

  • I’m trying to install from the usb device. any way, I tried also without mounting — same error. can you explain the error?

  • @elyashiv please edit your question and explain what it is you are attempting. Are you attempting to rescue a broken system? Are you booting a live system from the USB? If so, tell us. What OS are you using? What makes you think GRUB has a root-device option and what do you expect that option to do? Have you set up a chroot environment? Whenever you ask a question, you need to explain exactly what t is you are trying to do, we can’t guess.

  • oops, I meant -root-directory

  • @elyashiv there’s not --root-directory either. Go read my answer here that explains how to reinstall grub.

  • look at the first answer here

  • @elyashiv OK, that is --boot-directory on my GRUB, this is the kind of thing that makes it essential to always mention your OS and versions of the software you are using. In any case, you don’t need that option, see updated answer.

  • Why are you talking about chroot when the question isn’t about« chroot«?

  • The OP says «running from a USB containing linux mint». That will be a chroot.

  • @PeterEhrlich I can’t imagine why a hosts entry would be relevant and none of the other file systems should be either. Are you sure you linked to the right post?

  • I have the first command working, but not the 2nd one.

  • ME: [email protected]:/# realpath /cow TERMINAL: /cow ME:# ls -la /cow TERMINAL: ls: impossible to access ‘/cow’: No file or folder of this kind (roughly translated).

  • I already typed the grub-install command (on dev.sda1), but I had an error talking about blocks. And I got the «cow» error with the «grub-install —recheck —root-directory=/mnt /dev/sda1» command.

  • So did for me, smart guy! :-) I transfer Acer One 10 from Windows to Linux. Very difficult problems with EFI, but it seems to be possible…

  • grub-install: error: unknown filesystem. However this worked: ln /dev/sdb1 /cow -fis did the trick. Well I planned to install grub on a USB-Stick. VBoxManage internalcommands createrawvmdk to get the stick ‘into’ Virtualbox. Add the vmdk and the Linux mint ISO and boot the box. USB-Stick uses GPT and is on /dev/sdb. (sdb1 is some FAT ) sdb2 is some 1MB BIOS-Boot (2168…4649) GPT and sdb3 the FAT for grub.cfg and other files. grub-install /dev/sdb3 -v —force —boot-directory=/media/mint/boot

Recents

Related

Понравилась статья? Поделить с друзьями:
  • Grub install dummy неисправимая ошибка
  • Grub install dev sda ошибка
  • Grounded ошибка при создании лобби
  • Grounded ошибка подключения к совместной игре
  • Grounded ошибка microsoft visual c runtime