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.
Для восстановления GRUB потребуется загрузочный диск или флешка с дистрибутивом Linux. Итак, вы загрузились в Live-режиме. Теперь нужно открыть терминал.
1.Нужно определить раздел диска, на котором был установлен GRUB fdisk -l
.
2.Например установлен в /dev/sda
, примонтируем корневой раздел, выполняем команду (вместо /dev/sda вы должны указать свой раздел):sudo mount /dev/sda /mnt
. Если для загрузчика у вас выделен отдельный раздел, то нужно примонтировать еще и его (вместо /dev/sdX укажите ваш boot-раздел):sudo mount /dev/sdX /mnt/boot
3.Посмотреть содержимое директории /mnt, чтобы убедиться, что мы примонтировали верный раздел:ls /mnt
.
4.Нужно создать ссылки на несколько директорий, к которым GRUB должен иметь доступ для обнаружения всех операционных систем. Для этого выполните команды:sudo mount --bind /dev /mnt/dev sudo mount --bind /dev/pts /mnt/dev/pts sudo mount --bind /proc /mnt/proc sudo mount --bind /sys /mnt/sys
.Если у вас используется UEFI, то еще нужно примонтировать EFI-раздел в директорию /mnt/boot/efi :sudo mount /dev/nvme0n1p1 /mnt/boot/efi
например…
5.Для генерации файла конфигурации GRUB используется команда update-grub
. Данная команда автоматически определяет файловые системы на вашем компьютере и генерирует новый файл конфигурации. Выполняем команду:sudo update-grub
.
Если вдруг утилита update-grub не определила ваш Windows ,то можно будет запустить update-grub повторно уже из вашей Linux-системы, когда вы в нее загрузитесь (мне это помогло и Windows определился).
6.Осталось выполнить установку GRUB на диск. Мы определили раздел на котором у нас установлен GRUB на первом шаге данного руководства. Это раздел /dev/sda.
Для установки GRUB используется команда grub-install
, которой нужно передать в качестве параметра диск, на который будет выполняться установка (в моем случае это диск /dev/sda
):grub-install /dev/sda
.
7.Выходим из окружения chroot: exit
.
8.Отмонтируем все разделы, которые мы примонтировали:sudo umount /mnt/sys sudo umount /mnt/proc sudo umount /mnt/dev/pts sudo umount /mnt/dev
. Если вы монтировали boot-раздел, то его тоже нужно отмонтировать:sudo umount /mnt/boot
.Если вы монтировали EFI-раздел, отмонтируем:sudo umount /mnt/boot/efi
.Отмонтируем корневой раздел:sudo umount /mnt
.
9.Перезагружаем компьютер:reboot
.
Если во время перезагрузки компьютера меню GRUB не появилось, то это еще не значит, что он не восстановился. Возможно, просто установлена нулевая задержка и меню не показывается. Чтобы показать меню GRUB нужно во время загрузки, после того, как появился логотип материнской платы:
удерживать клавишу Shift, если у вас классический BIOS
; нажать Esc, если у вас UEFI
.
Если у вас, при выполнении grub-update, не определился Windows и не был добавлен в меню GRUB, то уже загрузившись в вашу систему Linux (не LiveCD), откройте терминал и выполните:sudo grub-update
.
Getting this error while downloading grub.
ubuntu@ubuntu:/boot/grub$ sudo grub-install /dev/sda
Installing for i386-pc platform.
grub-install: error: failed to get canonical path of `/cow'.
asked Apr 8, 2019 at 14:41
If you don’t want to risk unmounting /cow, I found a neat little trick which fools grub-probe into thinking there is an empty filesystem on /cow and then ignores it.
dd if=/dev/zero bs=1M count=1 of=cowfile
mkfs -t vfat cowfile
mv cowfile /cow
This worked for me running on a live usb wher grub-mkconfig wasn’t working.
answered May 13, 2019 at 23:30
SurpriseDogSurpriseDog
5723 silver badges18 bronze badges
1
You must log in to answer this question.
Not the answer you’re looking for? Browse other questions tagged
.
Not the answer you’re looking for? Browse other questions tagged
.
По сути нам нужно лишь указать дополнительным параметром, куда мы примонтировали корневой раздел.
Проверим все сначала. Мы загрузились в Live-версии Linux. Открыли терминал под root’ом. В моем примере диск – sda.
Примонтируем корневой раздел sda1
# mount /dev/sda1 /mnt
И если раздел boot отдельно, то и его тоже (для примера sda2)
# mount /dev/sda2 /mnt/boot
Теперь установим GRUB, используя параметр –root-directory
# grub-install --root-directory=/mnt /dev/sda
Заметьте, что указываем не раздел, а сам диск sda в последней команде. Ваш диск может отличаться, будьте внимательны.