Bug#934218: cdrom: grub-install fails with "failed to get canonical path of /dev/nvme0np1"

[Josep Guerrero Sole]

Package: cdrom
Severity: important
Tags: d-i



-- System Information:
Debian Release: 9.9
APT prefers oldstable
APT policy: (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-9-amd64 (SMP w/8 CPU cores)
Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8), LANGUAGE=ca:en_US:es:en_GB (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Since the problem prevents me from installing the system, I'm writing the bug report from another system, so the automatically gathered data above is not correct.

The correct values (those that I know) are:

Debian Release: 10.0
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-5-amd64

I'm trying to install Debian Buster on a system with 1 500GB NVMe disk (intended to be the system and boot disk) and 4 12TB disks intended to store data.

When partitioning the NVME disk, I create a 1GB EPS partition and a 1GB grubbios partition. The rest of the disk is configured as a RAID1 partition (it will only have one component, but I may be able to add a second disk later, so I prefer configuring it as a RAID from the beginning). The RAID partition is then configured as an LVM physical volume which ends as the only physical volume of a LVM volume group, which is further partitioned into several logical volumes to be mounted on some system directories (/, /tmp, /usr, /var, swap, ...).

The 4 12TB disks are partitioned with just one Linux raid partition, and the 4 of them are configured as a RAID6 device, that again is configured as an LVM physical volume which ends as the only component of another volume group, with just one logical volume.

The whole installation seems to work flawlessly, but when installing the grub boot loader, I get the error:

grub-install dummy failed

In the syslog, I can find the message

grub-install: error: failed to get canonical path of `/dev/nvme0n1p1`

Executing manually:

chroot /target grub-install --force "dummy"

results in exactly the same message. As a result, I am unable to install the system.

This bug seems to have appeared in some Ubuntu forums, and there is a sort of workaround in this comment:

https://bugs.launchpad.net/ubuntu/+source/grub-installer/+bug/1507505/comments/25

but I would prefer avoiding creating the eps partition on the 12TB disks (I would have to do that on all the disks to keep the raid partitions the same size).

Regards,

Josep Guerrero

[Steve McIntyre]

Hi Josep,

OK, that makes sense.

>The 4 12TB disks are partitioned with just one Linux raid partition,
>and the 4 of them are configured as a RAID6 device, that again is
>configured as an LVM physical volume which ends as the only component
>of another volume group, with just one logical volume.
>
>The whole installation seems to work flawlessly, but when installing
>the grub boot loader, I get the error:
>
>grub-install dummy failed
>
>In the syslog, I can find the message
>
>grub-install: error: failed to get canonical path of `/dev/nvme0n1p1`
>
>Executing manually:
>
>chroot /target grub-install --force "dummy"
>
>results in exactly the same message. As a result, I am unable to
>install the system.
>
>This bug seems to have appeared in some Ubuntu forums, and there is a
>sort of workaround in this comment:
>
>https://bugs.launchpad.net/ubuntu/+source/grub-installer/+bug/1507505/comments/25
>
>but I would prefer avoiding creating the eps partition on the 12TB
>disks (I would have to do that on all the disks to keep the raid
>partitions the same size).

You don't describe the system hardware that you're working with. What
do you have? This sounds like *potentially* a firmware issue, but it's
not 100% clear yet.

When you tried to run grub-install by hand, did you have /dev and
/sys mounted ok in the chroot? If you could try again and add a "-v"
to the grub-install command line that will give us more
information. It *will* be verbose, but only the last few lines are
likely to matter.

--
Steve McIntyre, Cambridge, UK. st...@einval.com
"Because heaters aren't purple!" -- Catherine Pitt

[Josep Guerrero]

Hi, Steve

Thanks a lot for your answer! I'll try to answer your questions and I'll add
some new information on the problem.

> When you tried to run grub-install by hand, did you have /dev and
> /sys mounted ok in the chroot?

I'm not sure, I admit I didn't check for that. Just after I received the grub
error in the installer (the text one, just in case it's important), I switched
to a second console with Alt-F2, executed:

tail /var/log/syslog,

and I saw a line about executing

chroot /target grub-install --force "dummy"

and after that, the error I mentioned in my previous message:

grub-install: error: failed to get canonical path of `/dev/nvme0n1p1`

I did not mount or umount anything by myself, so the chrooted /target was in
the state the debian installer had left it after failing with the grub
installation.

> If you could try again and add a "-v"
> to the grub-install command line that will give us more
> information. It *will* be verbose, but only the last few lines are
> likely to matter.

I'll do that (sorry, but I won't have physical access to that system till
Monday).

> You don't describe the system hardware that you're working with. What
> do you have? This sounds like *potentially* a firmware issue, but it's
> not 100% clear yet.

Sorry, you are completely right. I'm attaching the lshw output for this
machine

I've been trying more ideas with this system, and I contacted the seller for
advice (they suggested changing some BIOS setup options, some of them related
to firmware, most of them related to UEFI settings).

After changing those options (I'm not completely sure if they had any effect,
but maybe) I reinstalled again with a simpler configuration (just to be
faster), without RAID or LVM, and just used standard partitions on the NVMe
disk (all the system partitions were in that disk). This time it failed again
on the grub installation, but there wasn't an explicit error message on the
syslog (just that it failed with status 1) and when tried the the grub
installation manually on a second console using:

chroot /target grub-install "dummy"

the error message was that grub-install was unable to find the

/usr/lib/grub/i386-pc/modinfo.sh

file. At that point, I tried continuing the installation without the boot
loader (didn't try that before), and the installer asked if I wanted to
install grub in a (I think, citing from memory) "external removable media". I
chose "Yes" and when I rebooted, among the options there was a new UEFI one
but the installer USB UEFI options were missing. Choosing the new option
brought me to the grub prompt, which was an improvement, but didn't boot the
system.

After (again citing from memory) issuing some grub commands, I don't remember
the exact parameters, but they were:

root (hdX,Y)
linux /boot/vmlinux-XXXXX root=/dev/nvme0n1p2
initrd /boot/initrd-XXXXX
boot

the system booted, as far as I can tell, correctly. I executed

grub-install /dev/nkvm0n1

on the newly booted system, which ran without errors, removed the installer
USB and got again a new UEFI option, but still I only got the grub prompt when
rebooting (I could boot from there with the same set of instructions as
before). I was planning on trying to find if I could get grub to execute those
instructions by itself, so the system can boot normally, and write a followup
to the bug report, but I just saw your message.

Sorry about the length of the message. Hope some of this information is
useful.

Regards,

Josep Guerrero

[Josep Guerrero]

Hi again,

Finally I've managed to install a fully working grub on the system. The grub
installation process from the installer still fails, with the output attached
to the previous message, but I found a way to install a fully functional grub
in the system following these steps:

1) When the grub installation fails, I accepted installing grub in an external
removable media (this, I think, makes the USB work a grub bootable device, but
it's no longer functional as booting installer device. Since I can overwrite
it again, it's not a big problem).

2) When booting from this new grub USB device, I only get to the grub prompt.
I need to issue the following commands (with the right parameter values):

root=(lvm/dev/mapper/root-lvm-device)
linux /boot/vmlinuz-image-file root=/dev/mapper/root-lvm-device quiet
initrd /boot/initrd-file
boot

to boot the newly installed system.

3) First thing I did, after booting the system, was:

grub-install /dev/nvme0n1

which seemed to work and provided a new UEFI boot entry (which didn't require
an external USB device), but still took me only to the grub prompt when
booting the system.

4) After some googling and reading, I edited the file

/etc/default/grub

to include the line:

GRUB_DISABLE_OS_PROBER=false

and executed:

update-grub2

on the booted system. This finally provided a fully functional grub
installation (it may be that adding the line in /etc/default/grub is not
necessary, I didn't check if it worked without that).

Finally, I commented out the added line in /etc/default/grub.

I think that, in this particular case and for some reason, grub installation
doesn't work when done from the installer (maybe I did something wrong?), but
works if done from the newly installed system. Of course, you need to find a
way to boot that system first.

Hope this information helps with the problem!

Josep Guerrero