[SOLVED] efi stub kernel loading problem

Help with issues regarding installation of Debian

Re: efi stub kernel loading problem

Postby Head_on_a_Stick » 2018-06-21 16:10

p.H wrote:- The drive containing the EFI files must be specified with -d (--disk) if different from /dev/sda.
/dev/nvme0n1p2 seems to be a partition. The drive is /dev/nvme0n1.

Ah yes, of course, thanks!

@Bolo, my posted command was slightly wrong, here is a corrected version:
Code: Select all
# efibootmgr -c -d /dev/nvme0n1 -p 1 -L 'Debian (EFI_STUB)' -l '/EFI/debian/vmlinuz' -u 'root=UUID=$uuid ro quiet rootfstype=ext4 add_efi_memmap initrd=/EFI/debian/initrd.img'
Charlie don't hack
User avatar
Head_on_a_Stick
 
Posts: 7651
Joined: 2014-06-01 17:46
Location: /dev/chair

Re: efi stub kernel loading problem

Postby Bolo » 2018-06-21 16:37

Nope it does not work but this time the listing is like this:
Code: Select all


******************************************************
Warning! This MBR disk does not have a unique signature.
If this is not the first disk found by EFI, you may not be able
to boot from it without a unique signature.
Run efibootmgr with the -w flag to write a unique signature
to the disk.
******************************************************



******************************************************
Warning! This MBR disk does not have a unique signature.
If this is not the first disk found by EFI, you may not be able
to boot from it without a unique signature.
Run efibootmgr with the -w flag to write a unique signature
to the disk.
******************************************************



******************************************************
Warning! This MBR disk does not have a unique signature.
If this is not the first disk found by EFI, you may not be able
to boot from it without a unique signature.
Run efibootmgr with the -w flag to write a unique signature
to the disk.
******************************************************

BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0001,0006,0000,0005,0007
Boot0000* debian
Boot0005* UEFI OS
Boot0006* Windows Boot Manager
Boot0007* UEFI: Generic Flash Disk PMAP
Boot0001* Debian(EFI_STUB)

Bolo
 
Posts: 21
Joined: 2018-06-20 19:02

Re: efi stub kernel loading problem

Postby Bolo » 2018-06-21 16:53

Maybe there is another way to boot kernel without grub? bootctl? If there is no way to load kernel directly from nvme disk.
Bolo
 
Posts: 21
Joined: 2018-06-20 19:02

Re: efi stub kernel loading problem

Postby Head_on_a_Stick » 2018-06-21 17:08

Bolo wrote:
Code: Select all
Run efibootmgr with the -w flag to write a unique signature

^ Try this ;)

Bolo wrote:bootctl?

I've used gummiboot with jessie and it worked well, stretch seems to have bootctl included with systemd so you could give it a try.

What do you have against GRUB anyway?
Charlie don't hack
User avatar
Head_on_a_Stick
 
Posts: 7651
Joined: 2014-06-01 17:46
Location: /dev/chair

Re: efi stub kernel loading problem

Postby Bolo » 2018-06-21 17:40

Thanks Head_on_a_Stick,
Where I should placed this -w flag? I was trying to use bootctl following instruction from arch wiki but unssuccefuly I mean the entry was made properly but when I lauch it while booting the system this did not worked - the system did not started. It looked like it did not pick up the right kernel launcher.
Grub sometimes causes troubles and from time to time it needs to be maintained. I would like to install as minimal system as it could be and use refind to manage of switching between Debian and Windows. I would like to focus on learning the Linux itself and do not bother on grub.
Bolo
 
Posts: 21
Joined: 2018-06-20 19:02

Re: efi stub kernel loading problem

Postby Bolo » 2018-06-21 19:49

I run:
Code: Select all
# efibootmgr -c -w /dev/nvme0n1 -p 1 -L 'Debian (EFI_STUB)' -l '/EFI/debian/vmlinuz' -u 'root=UUID=$uuid ro quiet rootfstype=ext4 add_efi_memmap initrd=/EFI/debian/initrd.img'

This made an entry but system did not start :(
Bolo
 
Posts: 21
Joined: 2018-06-20 19:02

Re: efi stub kernel loading problem

Postby Head_on_a_Stick » 2018-06-21 20:26

Bolo wrote:
Code: Select all
# efibootmgr -c -w /dev/nvme0n1 -p 1 -L 'Debian (EFI_STUB)' -l '/EFI/debian/vmlinuz' -u 'root=UUID=$uuid ro quiet rootfstype=ext4 add_efi_memmap initrd=/EFI/debian/initrd.img'

No, *do not* add the -w flag, I think you have to try that by itself.

Also you have missed the -d flag that identifies the drive — please read
Code: Select all
man efibootmgr

and familiarise yourself with the options rather than just blindly guessing.

Finally, using root=UUID=$uuid will *not* work, you need to use a real UUID in place of $uuid.

EDIT: also, I think the initrd path should be called from the root partition rather than the ESP, so:
Code: Select all
initrd=/boot/efi/EFI/debian/initrd.img

Are we having fun yet? :mrgreen:
Charlie don't hack
User avatar
Head_on_a_Stick
 
Posts: 7651
Joined: 2014-06-01 17:46
Location: /dev/chair

Re: efi stub kernel loading problem

Postby Bolo » 2018-06-22 14:26

Yes we have :) to the very end -- mine or linux.
First the answers:
I did -w flag running; efibootmgr -w /dev/nvme0n1.
I did not miss the parameter "-d" however it did not work so I was traying to guess - you are right, maybe I should not - and I was doing abortive tries - again:)
I did UUID - just for our conversation I copied/pasted the code from your previous post which was uuid. Sorry that I messed you up.
These all above - failed.
What I decided? Tomorrow (because t.g.i.f. and I am just relaxing with small glass of burbon :) ) I will do a fresh install but this time I will do this on standard SATA SSD while disconnecting all other drives and I will follow the wiki.debian instruction on efi stub. Why is that ?! because I have a theory (it is just a theory) that kernel 4.9 do not support nvme drives properly.
I have been doing researches over the internet on other distros forums and I have found that in arch previously there were the same problems and it was to do with kernel.
But most important is, that when you advise me to run
Code: Select all
# efibootmgr -c -d /dev/nvme0n1 -p 1 -L 'Debian (EFI_STUB)' -l '/EFI/debian/vmlinuz' -u 'root=UUID=$UUID ro quiet rootfstype=ext4 add_efi_memmap initrd=/EFI/debian/initrd.img'

I posted a listing where it has been stated :
"............******************************************************
Warning! This MBR disk does not have a unique signature.
If this is not the first disk found by EFI, you may not be able
to boot from it without a unique signature.
Run efibootmgr with the -w flag to write a unique signature
to the disk......"

but as you may remember after command: parted --list, there where not any of the MBR partition table. It must not be there because since 2 years up to now I stopped formating any of my drives as MBR - but only GPT. To me it seems to that kernel did nor recognized the nvme0n1p1 partition as a esp partition and that is the main issue. That is why I will try to do fresh install on SATA SSD and check it out.

To summarise: if it goes right then I will come back and I will ask you to direct me to the good source where I could find how to upgrade a kernel after installing stretch.
If it goes wrong I will be back and inform you about the outcome and sum up the whole ideas posted on this topic here and gather them into a procedure which I will execute hopefully this time with success.
regards.
Bolo
 
Posts: 21
Joined: 2018-06-20 19:02

Re: efi stub kernel loading problem

Postby p.H » 2018-06-22 21:06

I just tested it on a UEFI box and got it to work. The suggested efibootmgr command needs corrections.

- The kernel and initramfs files must be in an EFI partition. The UEFI firmware cannot read an ext4 filesystem.

- Pathnames must be EFI style (i.e. Microsoft style), starting from the root of the EFI partition, e.g. '\EFI\debian\vmlinuz` or "\\EFI\\debian\\initrd" ('\' must be within single quotes or escaped with a double \\ in order to be considered a normal character by the shell).

- The kernel and initramfs path and file names must reflect the ones you used to copy the original files from /boot into the EFI partition. Sometimes you used "vmlinuz", sometimes "vmlinuz.efi"... Make up your mind !

- The kernel parameter rootfstype=ext4 is useless. add_efi_memmap was not needed on my system.

- I don't think -w helps with a GPT table. Maybe try -g instead to get read of the warning.

So a correct command would be something like :

Code: Select all
efibootmgr -v --create -disk /dev/nvme0n1 --part 1 --label 'Debian (EFI_STUB)' --loader '\EFI\debian\vmlinuz' -u "root=UUID=$uuid ro quiet initrd=\\EFI\\debian\\initrd.img"


assuming that
- /dev/nvme0n1p1 is mounted on /boot/efi
- the kernel image is /boot/efi/EFI/debian/vmlinuz
- the initramfs is /boot/efi/EFI/debian/initrd.img
- $uuid contains the UUID of the root filesystem

Note : the kernel parameter string must not be within single quotes, othewise $uuid would not be substituted with its value. So \ characters must be escaped.

Note : if the EFI partition on the NVME drive does not work (which I doubt because you wrote that the normal Debian entry with GRUB works and it is on that same partition), you can try to install the files on the other EFI partition on the Windows drive /dev/sda.
p.H
 
Posts: 403
Joined: 2017-09-17 07:12

Re: efi stub kernel loading problem

Postby Bolo » 2018-06-23 09:16

Hello,
Finally everything works perfect without grub.
The main cause of my problem was that according to the https://wiki.debian.org/EFIStub
Code: Select all
export UUID=$(blkid -s UUID -o value /dev/sda3)

the $UUID - has been wiping out (I do not know why) whenever I rebooted the machine and that is why booting did not work.
instead of exporting UUID I used dynamically allocation of the variable. For standard SSD SATA drive the efiboot entry looks like this.
Code: Select all
efibootmgr -c -g -L "DEBIAN" -l '\EFI\debian\vmlinuz' -u "root=PARTUUID=$(blkid -s PARTUUID -o value /dev/sda2) ro nomodeset initrd=\\EFI\\debian\\initrd.img"

Now a few words of explanation. Obviously before i run above command i did:
Code: Select all
cp /vmlinuz /boot/efi/EFI/debian/
cp /initrd.img /boot/efi/EFI/debian/

in the entry /dev/sda2 - is a root partition.
PARTUUID can be switched with UUID - I think it does no matter. (I am not sure please correct me if I am wrong)
Because I have got nvidia (no matter) if I boot using EFI stub or with Grub I need delete 'quiet' option and put 'nomodeset' instead. Otherwise the booting will freeze. After the NVIDIA driver is installed 'nomodeset' is no needed anymore.

This solution is for SDA partition/drive.
For NVME partition/drive (or any other then SDA) the entry looks like this:
Code: Select all
efibootmgr -c -d /dev/nvme0n1 -p 1 -L "DEBIAN" -l '\EFI\debian\vmlinuz' -u "root=PARTUUID=$(blkid -s PARTUUID -o value /dev/nvme0n1p2) ro nomodeset initrd=\\EFI\\debian\\initrd.img"


/dev/nvme0n1 - is a drive
/dev/nvme0n1p1 - is efi boot partition - fat32
/dev/nvme0n1p2 - is a root partition - ext4
/dev/nvme0n1p3 - is swap partition
/dev/nvme0n1p4 - is home partition - ext4

So i think I maight to mark this topic as SOLVED?

MANY THANKS FOR ALL OF YOU!!! FOR YOUR TIME AND EFFORTS AND HELP!!!!!!!!!!!!!!!!!!!
Bolo
 
Posts: 21
Joined: 2018-06-20 19:02

Re: efi stub kernel loading problem

Postby Head_on_a_Stick » 2018-06-23 10:38

Bolo wrote:So i think I maight to mark this topic as SOLVED?

First check that you have a script in /etc/{initramfs,kernel}/postinstall/ to copy new kernel & initrd versions to the ESP after updates, make sure it is executable and run it manually to ensure that the kernel is copied correctly — I add a message to my own zz-update-esp script that I can see during kernel upgrades.

Also, is there any chance you could check a version of the command with Linux-style path separators in the boot options, to whit:
Code: Select all
efibootmgr -c -d /dev/nvme0n1 -p 1 -L "DEBIAN" -l '/EFI/debian/vmlinuz' -u "root=PARTUUID=$(blkid -s PARTUUID -o value /dev/sda2) ro nomodeset initrd=/EFI/debian/initrd.img"

I've used EFI_STUB booting on two UEFI laptops and the Linux-style path separators were accepted on both so I am curious to know if p.H's motherboard is defective in this respect.

At any rate the -u option is passed directly to the .efi loader, which is the kernel in this case and to suggest that the Linux kernel does not understand Linux-style path separators seems nonsensical :?
Charlie don't hack
User avatar
Head_on_a_Stick
 
Posts: 7651
Joined: 2014-06-01 17:46
Location: /dev/chair

Re: [SOLVED] efi stub kernel loading problem

Postby Bolo » 2018-06-23 14:19

Hey Head_on_a_Stick
Sure, no problemo.
Please give me a couple hours and I check it out.
Bolo
 
Posts: 21
Joined: 2018-06-20 19:02

Re: [SOLVED] efi stub kernel loading problem

Postby Bolo » 2018-06-23 15:33

Yeap it works as it should.
However I needed to change your code, because you did not replace sda2 as root partition on nvme0n1p2, so its correct form should look like this:
Code: Select all
efibootmgr -c -d /dev/nvme0n1 -p 1 -L "HEAD_ON_A_STICK" -l '/EFI/debian/vmlinuz' -u "root=PARTUUID=$(blkid -s PARTUUID -o value /dev/nvme0n1p2) ro nomodeset initrd=/EFI/debian/initrd.img"


:D
Bolo
 
Posts: 21
Joined: 2018-06-20 19:02

Re: [SOLVED] efi stub kernel loading problem

Postby p.H » 2018-06-24 06:44

Head_on_a_Stick wrote:I've used EFI_STUB booting on two UEFI laptops and the Linux-style path separators were accepted on both so I am curious to know if p.H's motherboard is defective in this respect.

My motherboard's UEFI fimware is defective in many ways, but not on this one. Actually I had not even tried with Unix-style forward slashes and directly tried with DOS-style backslashes. I just tried now, and indeed it works.

Head_on_a_Stick wrote:At any rate the -u option is passed directly to the .efi loader, which is the kernel in this case and to suggest that the Linux kernel does not understand Linux-style path separators seems nonsensical

There are slashes in the --loader (-l) parameter too, which is to be interpreted by the UEFI firmware, not the Linux kernel. Fortunately, after reading back the created entries it appears that efibootmgr converts forward slashes into backslashes.

Regarding the init= kernel command line parameter, it is used by the EFI stub kernel code, not the regular filesystem susbsystem. At this stage the kernel cannot read any file by itself yet because drivers for storage devices and filesystems are not yet available and must be loaded from the inintramfs, so no on-disk filesystem can be mounted. So the kernel must use EFI services to load the initramfs, and I suspected that it just passed the pathname as is and the EFI services required DOS/EFI-style pathnames. But it appears that either the kernel converts the slashes before passing the pathname, or the EFI services accept either Unix and DOS-style pathnames. I suspect the former.
p.H
 
Posts: 403
Joined: 2017-09-17 07:12

Previous

Return to Installation

Who is online

Users browsing this forum: No registered users and 4 guests

fashionable