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

2019-08-10 Thread 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-X root=/dev/nvme0n1p2
initrd /boot/initrd-X
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 Guerrerokilimanjaro
description: Computer
product: AS -1013S-MTR (To be filled by O.E.M.)
vendor: Supermicro
version: 0123456789
serial: A324200X9405087
width: 64 bits
capabilities: smbios-3.1.1 dmi-3.1.1 smp vsyscall32
configuration: boot=normal family=To be filled by O.E.M. sku=To be filled 
by O.E.M. uuid=----AC1F6B7CCF82
  *-core
   description: Motherboard
   product: H11SSL-i
   vendor: Supermicro
   physical id: 0
   version: 1.01
   serial: ZM18CS600800
   slot: To be filled by O.E.M.
 *-firmware
  description: BIOS
  vendor: American Megatrends Inc.
  physical id: 0
  version: 1.1
  date: 02/15/2019
  size: 64KiB
  capacity: 16MiB
  capabilities: pci upgrade shadowing cdboot bootselect socketedrom edd 
int13floppy1200 int13floppy720 int13floppy2880 int5printscreen int14serial 
int17printer acpi usb biosbootspecification uefi
 *-memory
  description: System Memory
  physical id: 21
  slot: System board or motherboard
  size: 32GiB
  capacity: 2TiB
  capabilities: ecc
  configuration: errordetection=multi-bit-ecc
*-bank:0
 description: DIMM DDR4 Synchronous Registered (Buffered) 2667 MHz 
(0.4 ns)
 product: 9ASF1G72PZ-2G6D1
 vendor: Micron Technology
 physical id: 0
 serial: 20E655A

Bug#934218: Sort of fully working workaround

2019-08-14 Thread 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



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

2019-08-08 Thread 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