Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230

 

 

 

[SOLVED] efi stub kernel loading problem

Ask for help with issues regarding the Installations of the Debian O/S.
Message
Author
Bolo
Posts: 22
Joined: 2018-06-20 19:02

Re: efi stub kernel loading problem

#21 Post by Bolo »

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 :(

User avatar
Head_on_a_Stick
Posts: 14114
Joined: 2014-06-01 17:46
Location: London, England
Has thanked: 81 times
Been thanked: 132 times

Re: efi stub kernel loading problem

#22 Post by Head_on_a_Stick »

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:
deadbang

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

Re: efi stub kernel loading problem

#23 Post by Bolo »

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.

p.H
Global Moderator
Global Moderator
Posts: 3049
Joined: 2017-09-17 07:12
Has thanked: 5 times
Been thanked: 132 times

Re: efi stub kernel loading problem

#24 Post by p.H »

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.

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

Re: efi stub kernel loading problem

#25 Post by Bolo »

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!!!!!!!!!!!!!!!!!!!

User avatar
Head_on_a_Stick
Posts: 14114
Joined: 2014-06-01 17:46
Location: London, England
Has thanked: 81 times
Been thanked: 132 times

Re: efi stub kernel loading problem

#26 Post by Head_on_a_Stick »

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 :?
deadbang

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

Re: [SOLVED] efi stub kernel loading problem

#27 Post by Bolo »

Hey Head_on_a_Stick
Sure, no problemo.
Please give me a couple hours and I check it out.

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

Re: [SOLVED] efi stub kernel loading problem

#28 Post by Bolo »

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

p.H
Global Moderator
Global Moderator
Posts: 3049
Joined: 2017-09-17 07:12
Has thanked: 5 times
Been thanked: 132 times

Re: [SOLVED] efi stub kernel loading problem

#29 Post by p.H »

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.

Post Reply