Unable to install GRUB in /dev/nvme

previously, installation on to nvme drivers has been fixed and used to operate correctly.

using $ ubuntu-bug ubiquity, or $ ubuntu-bug debian-installer -> would be better as it would include a lot of logs and details of package versions throughout.

i386-pc is a bit weird, as I would expect nvme drives to only install in the UEFI mode.

Dimitri,

 Thanks a lot! I will do it now, :)

Dimitri,

 I used the 'Legacy mode' in BIOS, and after I switch to 'UEFI mode', it works fine, I thought this issue might be related to BIOS. Thanks a lot!

Looks like a simple problem with grub's device iteration code not understanding /dev/nvme can also be hd0, since it's a new device type instead of a conventional scsi disk.

Status changed to 'Confirmed' because the bug affects multiple users.

No, this is an issue in grub-installer directly, which fails to figure out that /dev/nvme0n1 is the disk without partition numbers. It may still be that grub doesn't like nvme devices as hd0, but we're failing at grub-installer splitting the device name correctly.

Wait, the partitions on nvme devices are named /dev/nvme0n1? That's a bug in the kernel then; it should be named /dev/nvmd0p1. The 'p' is the partition separator character linux has used since the dawn of time for devices whose base name ends in a digit.

No, it's not that simple.

The kernel and anything is free to use the naming policy it wants, but that's not the problem here. p* is still used in nvme, but there is a numbering before that for the device ID -- nvme0n1 points to a "drive", nvme0n1p1 points to a partition. This issue is in grub-installer, it's just that I don't have NVMe drives to play with to figure it out.

Could someone seeing this issue please run the installer but just before that, modify grub-installer to add "set -x" near the top so we can see which part of grub-installer does the parsing wrong?

Reassigning to grub-installer since we don't need to bug the kernel team for this...

i have nvme drive, I did the enablement using qemu vm (so can be tested there). currenty i have nvme drive and it works fine. However, I have installed it in the uefi mode. I do not believe nvme drives work in "legacy" mode at all, because there is no bios support for them.

however i will not switch my laptop to legacy boot mode.

Changing the title back to reflect the situation.

Note that NVMe devices are named by /dev/nvme[device number]n[namespace number]p[partition number].
This means if you format your NVMe device with at least one partition, you'll end up with at least three devices: /dev/nvme0, /dev/nvme0n1 and /dev/nvme0n1p1

If you create an `EFI boot section` before partitioning the rest of the device, you can install `grub` on `/dev/nvme0n1`.

Example:
- `/dev/nvme0n1`
-- `/dev/nvme0n1p1`, EFI boot section, 500MB
-- `/dev/nvme0n1p2`, ext4, [all the free space]

grub-install on `/dev/nvme0n1` now works.

@Dimitri, Comment #11 is actually not true. nvme drives *do* work in legacy mode. But the bootloader has to be installed to /dev/nvme0n1.

@Mathieu, can we make sure this is high priority and on track for fixing in Yakkety and SRU to Xenial?

I just got an Intel NUC Skull Canyon with a NVMe drive and hit this bug trying to install 16.04 LTS. The install fails completely. I get a choice to select drive to install grub to and change to /dev/nvme0n1 but when I press the "Ok" button nothing happens. Selecting any of the other options has the same effect, Ok button doesn't do anything. I have to restart my computer with ctrl+alt+del.

When I restart the installer and try to fix the partition table manually the "new partition table" is greyed out and I can't remove the lvm volumes created beforehand.

If any help is needed to debug this I can probably help out next week, just tell me what to do.

I am experiencing the same behaviour while installing Xubuntu 16.04 onto a desktop computer containing only a NVMe drive. I cant use the OK Button, abort or close the dialog.

Workaround: when installer starts, select manual partitioning and select /dev/nvme0n1 as the place where to install the bootloader (bottom of the partitioning window).

(I didn't manage to boot this particular system with UEFI enabled, this workaround only works in legacy mode for me)

Encountering the same problem. I am using DELL XPS 13 9360 (with Windows 10 Home 64-bit pre-installed) and want to install Ubuntu 16.04.2 LTS as dual-boot.

I had the same issue as this, managed to get it to work after a lot of trial and error:
http://askubuntu.com/questions/884991/ubuntu-16-10-dual-boot-error-grub-efi-amd64-signed-package-failed-to-install

I suspect it is a problem related to NVMe disks?

> Could someone seeing this issue please run the installer but just before that, modify grub-installer to add "set -x"

~ # grub-installer

+ [ ]
+ ROOT=
+ chroot=
+ . /usr/share/grub-installer/functions.sh
+ . /usr/share/grub-installer/otheros.sh
+ newline=

+ db_capb backup
+ _db_cmd CAPB backup
+ IFS= printf %s\n CAPB backup
+ IFS=
 read -r _db_internal_line
+ RET=multiselect backup progresscancel align escape plugin-terminal
+ return 0
+ archdetect
+ ARCH=amd64/generic
+ info architecture: amd64/generic
+ log info: architecture: amd64/generic
+ logger -t grub-installer info: architecture: amd64/generic
+ ls /proc
+ initial_proc_contents=1
10
100
10066
10067
10129
10130
11
12
123
12438
12439
12444
125
13
15
16
17
18
183
184
185
193
194
195
196
2
20
20501
206
207
208
209
21
210
217
22
23
25
26
27
28
29
29966
29968
3
30
30523
30600
30919
30920
30974
30975
30976
30979
31
32
33
34
35
36
360
362
37
38
39
40
46
47
48
49
5
50
60
631
636
677
679
7
7165
7182
7183
7184
7185
7186
7187
7196
7197
7198
7219
7263
75
76
77
79
8
81
84
85
86
87
88
89
9
90
91
92
93
94
95
96
99
acpi
buddyinfo
bus
cgroups
cmdline
consoles
cpuinfo
crypto
devices
diskstats
dma
driver
execdomains
fb
filesystems
fs
interrupts
iomem
ioports
irq
kallsyms
kcore
key-users
keys
kmsg
kpagecount
kpageflags
loadavg
locks
mdstat
meminfo
misc
modules
mounts
mtrr
net
pagetypeinfo
partitions
sched_debug
self
slabinfo
softirqs
stat
swaps
sys
sysrq-trigger
sysvipc
timer_list
timer_stats
tty
uptime
version
vmallocinfo
vmstat
zoneinfo
+ [ -z 1
10
100
10066
10067
10129
10130
11
12
123
12438
12439
12444
125
13
15
16
17
18
183
184
185
193
194
195
196
2
20
20501
206
207
208
209
21
210
217
22
23
25
26
27
28
29
29966
29968
3
30
30523
30600
30919
30920
30974
30975
30976
30979
31
32
33
34
35
36
360
362
37
38
39
40
46
47
48
49
5
50
60
631
636
677
679
7
7165
7182
7183
7184
7185
7186
7187
7196
7197
7198
7219
7263
75
76
77
79
8
81
84
85
86
87
88
89
9
90
91
92
93
94
95
96
99
acpi
buddyinfo
bus
cgroups
cmdline
consoles
cpuinfo
crypto
devices
diskstats
dma
driver
execdomains
fb
filesystems
fs
interrupts
iomem
ioports
irq
kallsyms
kcore
key-users
keys
kmsg
kpagecount
kpageflags
loadavg
locks
mdstat
meminfo
misc
modules
mounts
mtrr
net
pagetypeinfo
partitions
sched_debug
self
slabinfo
softirqs
stat
swaps
sys
sysrq-trigger
sysvipc
timer_list
timer_stats
tty
uptime
version
vmallocinfo
vmstat
zoneinfo ]
+ get_serial_console
+ sed -e s/.*\(console=[^ ]*\).*/\1/ /proc/cmdline
+ local defconsole=BOOT_IMAGE=linux --- debconf/priority=high DEBCONF_DEBUG=5 auto=true url=192.168.1.194:80 hw-detect/load_firmware=false hostname=gator netcfg/get_domain=lan partman-auto/disk="/dev/nvme0n1" initrd=initrd.gz
+ echo BOOT_IMAGE=linux --- debconf/priority=high DEBCONF_DEBUG=5 auto=true url=192.168.1.194:80 hw-detect/load_firmware=false hostname=gator netcfg/get_domain=lan partman-auto/disk="/dev/nvme0n1" initrd=initrd.gz
+ grep -qe console=\(ttyS\|com\)
+ serial=
+ cached_available_ids=
+ findfs /
+ grub_probe -t device /
+ [ != true ]
+ apt-install grub-common
+ is_grub_common_installed=true
+ grub-probe -t device /
grub-probe: error: failed to get canonical path of `rootfs'.
+ mount
+ grep on
+ tail -n1
+ cut -d -f1
+ roo...

Similar to the other bug reports, I receive the following error when following the installation wizard on Ubuntu 16.04: "Unable to install GRUB in /dev/nvme"

I was able to get an encrypted install of Ubuntu with v16.04 with the bootloader on /dev/nvme0n1 working with UEFI boot, with some small tweaks following comments #14 (https://bugs.launchpad.net/ubuntu/+source/grub-installer/+bug/1507505/comments/14) and #19 (https://bugs.launchpad.net/ubuntu/+source/grub-installer/+bug/1507505/comments/19),

The steps I followed in the installer were:

1) Select manual partition setup
2) make sure drive /dev/nvme0n1 is blank
3) create a partition at front of drive, 1000MB (whatever size you need), mapped to /boot
4) create "physical encrypted partition" following the boot partition with the remaining space
5) assign new encrypted partition with the / mount point
6) select /dev/nvme0n1 as the partition to install the boot loader

grub-pc update failed on Ubuntu 16.04

cat /var/log/apt/term.log
...
Setting up grub-pc (2.02~beta2-36ubuntu3.17) ...^M
device node not found^M
device node not found^M
device node not found^M
device node not found^M
Installing for i386-pc platform.^M
Installation finished. No error reported.^M
Installing for i386-pc platform.^M
grub-install: error: cannot find a GRUB drive for /dev/disk/by-id/nvme-eui.0025385a71b1a709,. Check your device.map.^M
...

Was able to manually install grub using the following command.
$ sudo grub-install /dev/nvme1n1
$ sudo grub-install /dev/nvme0n1

Is there a command I can run to determine why it picked the above device path?

 $ ll /dev/disk/by-id/nvme-eui.0025385a71b1a709
lrwxrwxrwx 1 root root 13 Mar 14 14:58 /dev/disk/by-id/nvme-eui.0025385a71b1a709 -> ../../nvme1n1

It looks like that path should have worked anyways...

I have the same problem with the latest version installed on an nvme drive (4.15.0-29). It seems that when there's a single nvme drive and no other disks it may work, but when other drives are present, grub-install doesn't seem to install the bootloader on the nvme device. The workaround I found was to put the EFI partition on an attached s/ata disk (/dev/sda1) and put root and everything that needed to be fast in an LVM on the nvme drive. I did need to boot to the installer, mount the nvme root on /mnt and the other efi directory on /mnt/boot/efi, create the required devices in /mnt, chroot to /mnt and then run install-grub /dev/sda followed by grub-update, after which, the newly installed system came up as it should by booting to the EFI device, /dev/sda1 which booted to the root on the nvme device.

Afterwards, I dd'd the first 2K sectors of /dev/sda and /dev/nvme0n1 and while the partition table was present on the nvme drive, where the boot loader should have been contained zeros. Oddly enough, using the -d option on install-grub seemed to indicate that something was written somewhere.

Experiencing a similar problem here using 18.10 64b on a laptop featuring 2 nvme-drives.
Installation was started through legacy bios (UEFI off) and proceeded simlilar to #23:
1) Select manual partition setup
2) install to blank /dev/nvme0n1 is blank
3) create a partition at front of drive, 500MB , mapped to /boot
4) create "physical encrypted partition" following the boot partition of 80 GB
5) assign new encrypted partition with the / mount point
6) select /dev/nvme1n1 (yes, this is THE OTHER DRIVE, because win10 resides on this one and this is the drive set as primary boot-device in th BIOS setting) as the partition to install the boot loader.

Grub-installation then fails and a dialogue asking how to proceed is shown with the options:
A) choose a different device to install the bootloader on (with a drop-down list showing all disks and partitions present on the system but neiter re-tying to install on nvme0n1 nor nvme1n1 succeeds)
B) continue without a bootloader
C) cancel the installation

I suspect my issues are related to not using UEFI in conjunction with installing on a nvme-drive rather than cross-installing the bootloader to a differing nvme-drive from where the ubuntu-system resides on. I'll try to install via UEFI next and check out #14...