Get canonical path linux

Arch Linux

You are not logged in.

#1 2018-09-28 17:57:29

[Solved] grub-install: error: failed to get canonical path of ‘udev’

I am trying to install arch on my laptop that has a UEFI system.

I followed the wiki word by word till the boot loader installation where I tried to install GRUB.

The wiki says esp is the EFI system partition mount point, which for me was /dev/nvme0n1p1

But running the following command:

But got the following message:

What am I missing?

Last edited by bazalia (2018-09-29 08:27:32)

#2 2018-09-29 08:16:29

Re: [Solved] grub-install: error: failed to get canonical path of ‘udev’

#3 2018-09-29 08:26:38

Re: [Solved] grub-install: error: failed to get canonical path of ‘udev’

Thank you for the reply.

It seems that when I mounted my boot partition using

I thought that /dev/nvme0n1p1 was the mount point when it should’ve been /mnt/boot.

grub-install ran fine when I used «—efi-directory=/boot» instead.

#4 2021-06-27 17:45:15

Re: [Solved] grub-install: error: failed to get canonical path of ‘udev’

Thank you for the reply.

It seems that when I mounted my boot partition using

I thought that /dev/nvme0n1p1 was the mount point when it should’ve been /mnt/boot.

grub-install ran fine when I used «—efi-directory=/boot» instead.

I had the same error. In my case was because EFI system partition was formatted as ext4 and it seems GRUB does not support it. I formatted EFI system partition to FAT32 and then it worked.
I have no idea why this is not working if EFI system partition is formatted to ext4 since in this link it is being said GRUB supports ext4.
Could anyone tell me why grub-install is failing when EFI system partition is formatted as ext4?

As it is stated here in the answer by Tom Yan, EFI system partition must be formatted as FAT32 using:

Where X corresponds to your EFI system partition.

Источник

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

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

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

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

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

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

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

Загрузитесь в сеанс Live Linux.

Смонтируйте / раздел установленной ОС в /mnt

Настройте chroot среду:

Теперь вы находитесь в «поддельной» установке Linux, которая выглядит /mnt как / . Это означает, что все файлы, необходимые для GRUB, находятся /boot там, где система ожидает их, и вы можете установить GRUB так же, как если бы вы фактически запускали установленную систему:

Теперь перезагрузитесь, и вы увидите, что меню GRUB появилось нормально.

Если grub говорит, что не может разрешить канонический путь чего-либо, это означает, что он не существует или realpath() потерпел неудачу.

В этом случае попробуйте:

Если обе команды говорят «не удается найти файл или каталог», то вам нужно создать их.

Если вторая команда работает, а первая — нет, проверьте, почему 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, это не значит, что вы можете настроить разрешения для этих дисков одинаково.

Например, я создал этот файл:

И он содержит эти настройки:

Это по-прежнему не работает при использовании grub-install /dev/sda или update-grub для USB на Пи, debootstrapped Debian Stretch. Даже при использовании grub-uboot и grub-efi-arm существует ошибка, которая grub-probe не позволяет найти канонический путь.

Не только это, но и update-grub увидит и узнает, что операционные системы, но интересно, grub-install что не распознает операционную систему Debian на USB.

пример

Интересно, что когда я создаю chroot и могу работать update-grub , несмотря на то, что я нахожусь в операционной системе, которую я перезагрузил на сам USB, он не видит свою собственную операционную систему!

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

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

grub-uboot Обратите внимание на то, что из-за пределов контейнера я запускаю эту команду с установленным на Raspbian и без Grub на USB-диске, содержащем Debian с начальной загрузкой.

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

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

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

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

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

И вы можете использовать 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

Источник

What’s a «canonical path»?

So, an absolute path is a way to get to a certain file or location describing the full route to it, the full path, and it’s OS dependent (the absolute paths for Windows and Linux, for example, are different). A relative path, on the other hand, is a route to a file or location which is described from the current location .. (two dots) indicating a superior level in the directories tree. That has been clear to me for several years now.

When searching I’ve even seen that there are canonicalized files too! All I know is that CANONICAL means something like «according to the rules» or something.

Can somebody enlighten me in therms of theory about canonical stuff?

4 Answers 4

The whole point of making anything «canonical» is so that you can compare two things. For example, both ../../here/bar/x and ./test/../../bar/x may refer to the same location, but you can’t do a textual comparison on the two paths. However, if you turn them into their canonical representation, they both become ../bar/x , and we see that they actually refer to the same thing.

In short, it is often the case that you have many ways of referring to one thing, and in that case you may be able to define a canonical representation which is unique and which allows you to get a handle on col­lections of such things.

(If you’re looking for more examples, all of mathematics is full of «canonical» constructions for all sorts of objects, and very much with the same purpose in mind. Maybe this Wikipedia article can provide some ad­ditional directions.)

Источник

Failed to get canonical path of /cow

I am trying to install Ubuntu 12.10 for quite some time, and passing hurdles one by one. Now I am in a situation as follows.

I have got a PC and 10 GB HDD which will be totally dedicated to Ubuntu so no option of Wubi and dual boot.

I was trying to install from DVD, but it is getting stuck at «Out of frequency» error. So I had to adapt for USB boot option. But my PC is USB non bootable, so workaround is «Plop Boot Manager». So I am doing the installation procedure as follows:

1. starting from a CD drive which is having plop installed.
2. opting for for USB boot in plop options.
3. booting begins from USB.
4. monitor eventually gives «out of frequency» error
5. press Shift + Alt + F1 to get the terminal.
6. open the grub with sudo nano /etc/default/grub .
7. do necessary changes.
8. sudo update-grub .

Now here I am getting error as follows:

P4 3.06 GHz, 1 GB ram , 10 GB HDD without an OS, monitor CRT lg StudioWorks (7 years old). Mobo Mercury P4 266a NDMx (865 equivalent). The whole system is perfectly in working condition under XP, but it is USB non bootable, and all other devices working perfectly.

What should I do next?

6 Answers 6

After booting from the Ubuntu live CD (tried 14.04 and 16.04) I was able to work around this problem by running update-grub chroot’ed to the grub partition. (Substitute /dev/sda1 below with whatever partition you installed grub on. All commands as root.)

Find your drive that’s supposed to boot with

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

Is this your drive? Cool!

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

(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 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 drive.

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

or maybe this will work:

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.

Revised solution based on code above

The solution from above will not work totally without problems because it mounts the boot partition into the / (root) of the file system. That makes grub complain that /boot does not exist, of course. This will fix that problem:

As you see i also removed the line breaks so that it is easier to execute for everyone.

Another (simpler) solution

If you keep having problems getting it to work you should look to copy the /boot partition onto the / (root) partition. For that start your system with the Ubuntu live boot dvd and open the terminal. Inside it type:

To find out which partitions you have. In my case sda1 is my /boot partition which is about 250MB large and an sda5 which is about 500GB. I use these values in the commands below:

Set the bootable flag for the data partition and remove it for the boot partition:

Your computer will now look inside the sda5 for the boot files. Time to do the chrooting again, this time with some required folders needed for grub and which are generated by your Ubuntu live disc already:

Installation finished. No error reported.

If you do not see a message that the grub.cnf file is generated then also run the update command:

Now you can safely reboot and see the well known boot menu appear again.

This solution was the only one which was working for me after migrating from a physical server to a virtual machine. I hope someone finds this useful!

Источник

Arch Linux

You are not logged in.

#1 2019-01-07 21:20:37

[SOLVED] grub-install: error: failed to get canonical path of `/efi´.

I’m installing from archlinux-2019.01.01-x86_64.iso on an UEFI system and following the Installation guide down to the «Partition the disks» section and expected to pick up these instructions again at the start of the «Installation» section after following dm-crypt/Encrypting an entire system section Encrypted boot partition (GRUB) to set up encryption which goes fine until I get to the «Configuring GRUB» section where I get an error.

I think I have followed the instructions correctly.

Here are all the commands I’ve run so far and some notes on the filesystems.

This is the error the last command spits out:

I was thinking that maybe it was supposed to be /mnt/efi instead but that just gives:

Any idea where I went wrong or is it the wiki that’s wrong?

Last edited by BearerOfHonesty (2019-01-08 07:01:33)

#2 2019-01-07 21:39:39

Re: [SOLVED] grub-install: error: failed to get canonical path of `/efi´.

Apparently, grub-install tries to do something with the root filesystem (airootfs).

Try running the command from within the chroot after having installed base and grub (the package).

Last edited by respiranto (2019-01-07 21:40:44)

#3 2019-01-07 21:43:47

Re: [SOLVED] grub-install: error: failed to get canonical path of `/efi´.

When should I be doing that and is the system even ready for that yet? Comparing the two sets of instructions it doesn’t look like I’ve gotten far enough in the instructions for setting up encryption to where the normal installation instructions expect me to chroot which is why I haven’t tried yet.

#4 2019-01-07 22:38:08

Re: [SOLVED] grub-install: error: failed to get canonical path of `/efi´.

You should be ready to run pacstrap and then arch-chroot.

Don’t forget to change the mkinitcpio.conf inside the chroot.

#5 2019-01-08 02:47:15

Re: [SOLVED] grub-install: error: failed to get canonical path of `/efi´.

That seems to work.

With all the juggling around of the order of things to do in the two guides, have I made any obvious errors in the following commands? This includes redoing the last two sections in the original post in a different order but otherwise continues from there and seems to work other than that I still have to enter the passphrase twice, and it uses a US keymap rather than a Danish one for the first of those prompts, but these are at least obvious problems that are easy enough to work on, I’m more worried about having done something wrong that’s non-obvious.

Last edited by BearerOfHonesty (2019-01-08 03:09:00)

#6 2019-01-08 06:52:39

Re: [SOLVED] grub-install: error: failed to get canonical path of `/efi´.

Great that it works now. Please prepend ‘[SOLVED]’ to your thread’s title by editing the first post, unless you believe there are (serious) issues remaining.

Your list of commands looks generally fine. Some points:

You run grub-mkconfig twice. The second time suffices (though it does not at all harm to run it twice).

You install grub in both UEFI and BIOS mode. I’m not sure if that is what you want. There are good possible reasons though and in fact I had such a setup myself in the past.

You might consider not relying on grub-mkconfig, see [0] and the possibly generated the grub.cfg.

In order to prevent entering the password twice, see [1].

I didn’t know about umount’s -R option. Thanks for that. Unmounting explicitly before rebooting (or shutting down) is not necessary though.

Источник