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]   Вниз

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

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

Я тоже получаю эту ошибку, и я не думаю, что это происходит в 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. Я бы порекомендовал это. Я знаю, что это больше информации, чем относится к исходному сообщению, но я думаю, что, вероятно, как эта ошибка происходит. Это контейнерный век.