[gentoo-user] SOLVED: NVMe drive and grub

[gentoo-user] SOLVED: NVMe drive and grub

[Peter Humphrey]

On Thursday 7th April 2016 I wrote:

> I have a new box with an NVMe SSD drive attached to the PCI bus via an
> M.2 interface. The drive shows up as /dev/nvme0n1, with partitions
> /dev/nvme0n1p1, /dev/nvme0n1p2, ... 

> After following the instructions in the handbook for a UEFI system, I get
> as far as a kernel panic. Grub finds the kernel and starts it, but it seems
> to be passing a null root device name.

> Can anyone offer some advice to help me get past this?

The problem was sys-boot/grub-2.02_beta2-r9, which UEFI never ran.

The fix was to get rid of grub altogether and instead use sys-boot/gummiboot. 
Not only was it fully functional, it was a welcome relief not to have to 
grapple with grub's baroque complexity and to be able to return to the simple 
booting I remember from years ago.

I'd spent five long days wrestling with grub, going round in circles and 
getting nowhere, before I was pointed to gummiboot.

Let's hope this helps someone else get a new computer booting.

-- 
Rgds
Peter

Re: [gentoo-user] SOLVED: NVMe drive and grub

[Adam Carter]

[-- Attachment #1: Type: text/plain, Size: 693 bytes --]

> The problem was sys-boot/grub-2.02_beta2-r9, which UEFI never ran.
>
> The fix was to get rid of grub altogether and instead use
> sys-boot/gummiboot.
> Not only was it fully functional, it was a welcome relief not to have to
> grapple with grub's baroque complexity and to be able to return to the
> simple
> booting I remember from years ago.
>
> I'd spent five long days wrestling with grub, going round in circles and
> getting nowhere, before I was pointed to gummiboot.
>

I also failed to get grub2 + UEFI working. So either;
1. We're both dummies
2. The handbook instructions are incorrect and/or inadequate

Can anyone else that is familiar comment on the grub2 + UEFI doc quality?

[-- Attachment #2: Type: text/html, Size: 1094 bytes --]

Re: [gentoo-user] SOLVED: NVMe drive and grub

[Poison BL.]

On Mon, Apr 11, 2016 at 8:56 PM, Adam Carter <adamcarter3@gmail.com> wrote:
>
>> The problem was sys-boot/grub-2.02_beta2-r9, which UEFI never ran.
>>
>> The fix was to get rid of grub altogether and instead use
>> sys-boot/gummiboot.
>> Not only was it fully functional, it was a welcome relief not to have to
>> grapple with grub's baroque complexity and to be able to return to the
>> simple
>> booting I remember from years ago.
>>
>> I'd spent five long days wrestling with grub, going round in circles and
>> getting nowhere, before I was pointed to gummiboot.
>
>
> I also failed to get grub2 + UEFI working. So either;
> 1. We're both dummies
> 2. The handbook instructions are incorrect and/or inadequate
>
> Can anyone else that is familiar comment on the grub2 + UEFI doc quality?

Well, the uefi related commands in the kernel build section appears to
gloss over the potential issues that having a misconfigured kernel
(notably, one lacking either a builtin root= command line or an
initramfs that will handle that) directly uefi-stub booted will bring,
and installing the kernel as bootx64.efi might be contributing to grub
itself not being loaded.

The other potential source of an issue I see is that, while the kernel
build section of the handbook appears to point towards using
/boot/efi/ for the fat32 EFI partition (presumably based on earlier
usage/recommendations/commands), the grub2 part of the bootloaders
page in the handbook gives "--efi-directory=/boot". That would cause
grub to be on the wrong partition, completely out of reach of the uefi
firmware's boot process.

If it's in the right place despite that (such as, the user noticing
the discrepancy and adjusting for it, or me assuming the effect of
that flag all wrong), it's still potentially being overridden by the
bootx64.efi file put in place in the earlier chapter, unless grub
auto-adds itself to the efi boot list with a higher priority than the
generic quasi-bios-style 'disk' boot entry (with, say, efibootmgr).

The file 'bootx64.efi' is the default that uefi looks for when booting
a 'disk' in a quasi-bios-style fallback (if there's not a real 'boot
this particular thing' like the windows boot manager adds), which also
makes the efibootmgr example that sets up a boot entry for it a little
redundant (though using efibootmgr, one could add an entry for grub to
fix the whole mess).

Of course, using efibootmgr, you could also just add entries for your
kernels, having copied them to files named something sensible in the
efi filesystem, each built with an embedded command line and/or
initramfs that's sufficient to boot, and cut out the middleman. It's a
little more 'hands on' than running grub2-mkconfig when you're
changing things around for a new kernel, though.

-- 
Poison [BLX]
Joshua M. Murphy

Re: [gentoo-user] SOLVED: NVMe drive and grub

[Sam Jorna]

[-- Attachment #1: Type: text/plain, Size: 710 bytes --]

On Mon, Apr 11, 2016 at 10:31:42PM -0400, Poison BL. wrote:
> The file 'bootx64.efi' is the default that uefi looks for when booting
> a 'disk' in a quasi-bios-style fallback (if there's not a real 'boot
> this particular thing' like the windows boot manager adds), which also
> makes the efibootmgr example that sets up a boot entry for it a little
> redundant (though using efibootmgr, one could add an entry for grub to
> fix the whole mess).

It should be noted that this is very firmware-specific - some implementations
use this only as a fallback, some use it as an override to the "default" menu
selection, and some only use it if no other alternatives exist.

--
Sam Jorna (wraeth)
GnuPG Key: D6180C26

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 951 bytes --]

Re: [gentoo-user] SOLVED: NVMe drive and grub

[R0b0t1]

[-- Attachment #1: Type: text/plain, Size: 109 bytes --]

None of this is grub's fault, it's users are just petulant children.

It's bloated but pick a real argument.

[-- Attachment #2: Type: text/html, Size: 154 bytes --]

Re: [gentoo-user] SOLVED: NVMe drive and grub

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 664 bytes --]

On Tue, 12 Apr 2016 10:56:56 +1000, Adam Carter wrote:

> I also failed to get grub2 + UEFI working. So either;
> 1. We're both dummies
> 2. The handbook instructions are incorrect and/or inadequate
> 
> Can anyone else that is familiar comment on the grub2 + UEFI doc
> quality?

ISTR getting GRUB to work with UEFI was pretty straightforward, but I had
to use efibootmgr to let the firmware know that GRUB was available and
make it the default.

It was a while ago though, I've since ditched GRUB in favour of
gummiboot/bootctl on UEFI hardware.


-- 
Neil Bothwick

If you can smile when things go wrong, you have someone in mind to blame.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-user] SOLVED: NVMe drive and grub

[Marc Joliet]

[-- Attachment #1: Type: text/plain, Size: 1947 bytes --]

(I've got a bad habit of saving unfinished emails in the drafts folder and 
then forgetting about them.  I found this one while cleaning it up and thought 
it might still be informative.)

On Tuesday 12 April 2016 10:56:56 Adam Carter wrote:
>> The problem was sys-boot/grub-2.02_beta2-r9, which UEFI never ran.
>> 
>> The fix was to get rid of grub altogether and instead use
>> sys-boot/gummiboot.
>> Not only was it fully functional, it was a welcome relief not to have to
>> grapple with grub's baroque complexity and to be able to return to the
>> simple
>> booting I remember from years ago.
>> 
>> I'd spent five long days wrestling with grub, going round in circles and
>> getting nowhere, before I was pointed to gummiboot.
>
>I also failed to get grub2 + UEFI working. So either;
>1. We're both dummies
>2. The handbook instructions are incorrect and/or inadequate
>
>Can anyone else that is familiar comment on the grub2 + UEFI doc quality?

Poison already gave a more informative reply than I could have , but just to 
give a data point: I have successfully installed GRUB on an old Mac Mini from 
2007 (obtained from a friend).  The main hiccup was that I couldn't get any 
live CDs to boot in EFI mode, so I resorted to grub2-mkimage in order to 
"bootstrap" booting in EFI mode.  Once that was resolved, grub2-install worked 
just fine, as long as I passed --efi-directory=/boot/efi.  I have yet to test 
whether I can boot directly with GRUB or still need refind.

(I was being stubborn and wanted to run what I found out after the fact is 
referred to as mixed mode, which allows a 64 bit kernel to access a 32 bit 
EFI, in which case you *need* a boot loader like GRUB.  BTW, another thing I 
found out afterwards is that Debian apparently has mixed-mode live media 
starting with the Jessie release.)

HTH
-- 
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]