View previous topic :: View next topic |
Author |
Message |
alecStewart1 Tux's lil' helper
Joined: 03 Jul 2022 Posts: 148
|
Posted: Wed Apr 10, 2024 2:35 am Post subject: Move from GRUB to plain EFI Stubs? |
|
|
Hey gang,
So I'm kind of getting a little tired of GRUB, and not just because of the current issues people seem to be having with it. I've used GRUB on my machines in the past, and have ran into random issues with it before that are frustrating.
I think it's about high time I just move to using EFI stubs instead, considering that I currently don't dual boot on this machine, nor do I really plan on doing so at the moment and my motherboard supports UEFI.
Current, this is how my SSD is partitioned:
Code: |
nvme0n1 259:0 0 931.5G 0 disk
nvme0n1p1 259:1 0 256M 0 part /boot
nvme0n1p2 259:2 0 8G 0 part [SWAP]
nvme0n1p3 259:3 0 923.3G 0 part /
|
Code: |
/dev/nvme0n1p1 vfat 253M 171M 82M 68% /boot
/dev/nvme0n1p3 btrfs 924G 435G 485G 48% /
|
I guess the question would be is where do I start with making /dev/nvme0n1p1 into a valid partition for booting with EFI stubs? I know installkernel has the experimental efistub USE flag, but other than that I guess should I create a new partition for /efi, then remove the one at /boot? Haven't done this in a minute, so apologizes for asking dumb questions.
EDIT: grammar
Last edited by alecStewart1 on Wed Apr 10, 2024 2:39 pm; edited 1 time in total |
|
Back to top |
|
|
pietinger Moderator
Joined: 17 Oct 2006 Posts: 5117 Location: Bavaria
|
|
Back to top |
|
|
alecStewart1 Tux's lil' helper
Joined: 03 Jul 2022 Posts: 148
|
Posted: Wed Apr 10, 2024 3:00 pm Post subject: Re: Move from GRUB to plain EFI Stubs? |
|
|
Hmm okay, that is a lot easier. I use sys-kernel/gentoo-kernel, because I'm kind of lazy. I'll have to double check, but I think I just need to do steps 3 - 6. I will ask if there's anything you need to do for kernel commandline params, because I used ZSwap and have stuff for AppArmor and page poisoning (I'm paranoid), and I have some of those things specified in the grub.cfg. |
|
Back to top |
|
|
grknight Retired Dev
Joined: 20 Feb 2015 Posts: 1921
|
Posted: Wed Apr 10, 2024 3:04 pm Post subject: |
|
|
I recently replaced GRUB with rEFInd on one machine. It was super easy and will never need configuration again. The automatic detection is great.
Basically install with emerge, then run refind-install.
rEFInd only runs kernel stubs or other EFI executables. |
|
Back to top |
|
|
pietinger Moderator
Joined: 17 Oct 2006 Posts: 5117 Location: Bavaria
|
|
Back to top |
|
|
alecStewart1 Tux's lil' helper
Joined: 03 Jul 2022 Posts: 148
|
Posted: Wed Apr 10, 2024 4:01 pm Post subject: Re: Move from GRUB to plain EFI Stubs? |
|
|
Oh I have savedconfig for sys-kernel/gentoo-kernle, so usually I open the kernel config file in Emacs and edit stuff there, and then rebuild the kernel just by called emerge --ask --verbose sys-kernel/gentoo-kernel.
pietinger wrote: |
Yes. You might check your current kernel command line parameters with "cat /proc/cmdline"
|
So what do to add parameters with EFI stubs? Use efibootmgr's -u option? So like
Code: |
efibootmgr -c -d /dev/nvme0n1 -p 1 -L "Gentoo" -l '\efi\gentoo\bzImage.efi' -u 'root=/dev/nvme0n1p3 page_poison=1 apparmor=1 security=apparmor,{other security stuff} zswap.enabled=1 zswap.compressor=zstd'
|
I think I remember coming across your article when I was installing Gentoo at first. I'll have to go through again and see what else I can enable. I do use this PC for gaming, so I'll have to go an determine what I should and shouldn't enable.
For anyone coming here and seeing this message, I find that [url=https://www.kernelconfig.io/index.html ]kernelconfig.io[/url] is really useful when doing kernel configuration. For instance, in pietinger's article there's a mention of an option that in make menuconfig reads
Quote: |
Check for invalid mappings in user page tables
|
If I'm just editing the kernel config file myself, I can go to kernelconfig.io and search exactly "Check for invalid mappings in user page tables" to find item in the kernel config file to change, and low and behold it's CONFIG_PAGE_TABLE_CHECK, and the option below that in the menuconfig is CONFIG_PAGE_TABLE_CHECK_ENFORCED. Really makes editing the kernel config with menuconfig or manually a lot easier. Plus, you can look up what the option does whenever someone asks you if "CONFIG_[X]" is enabled. |
|
Back to top |
|
|
pietinger Moderator
Joined: 17 Oct 2006 Posts: 5117 Location: Bavaria
|
Posted: Wed Apr 10, 2024 5:26 pm Post subject: Re: Move from GRUB to plain EFI Stubs? |
|
|
alecStewart1 wrote: | [...] So what do to add parameters with EFI stubs? Use efibootmgr's -u option? So like
Code: | efibootmgr -c -d /dev/nvme0n1 -p 1 -L "Gentoo" -l '\efi\gentoo\bzImage.efi' -u 'root=/dev/nvme0n1p3 page_poison=1 apparmor=1 security=apparmor,{other security stuff} zswap.enabled=1 zswap.compressor=zstd' |
|
Almost right ... but the most important thing is still missing: initrd=
Code: | efibootmgr -c -d /dev/nvme0n1 -L "Gentoo" -l '\efi\gentoo\bzImage.efi' -u 'root=/dev/nvme0n1p3 page_poison=1 apparmor=1 security=apparmor,{other security stuff} zswap.enabled=1 zswap.compressor=zstd initrd=\efi\gentoo\INTRAMFS-FILE_FROM_DIST-KERNEL' |
Please read: https://forums.gentoo.org/viewtopic-p-8805827.html#8805827 (and the next 5 posts) _________________ https://wiki.gentoo.org/wiki/User:Pietinger |
|
Back to top |
|
|
alecStewart1 Tux's lil' helper
Joined: 03 Jul 2022 Posts: 148
|
Posted: Thu Apr 11, 2024 12:18 am Post subject: Re: Move from GRUB to plain EFI Stubs? |
|
|
pietinger wrote: | alecStewart1 wrote: | [...] So what do to add parameters with EFI stubs? Use efibootmgr's -u option? So like
Code: | efibootmgr -c -d /dev/nvme0n1 -p 1 -L "Gentoo" -l '\efi\gentoo\bzImage.efi' -u 'root=/dev/nvme0n1p3 page_poison=1 apparmor=1 security=apparmor,{other security stuff} zswap.enabled=1 zswap.compressor=zstd' |
|
Almost right ... but the most important thing is still missing: initrd=
Code: | efibootmgr -c -d /dev/nvme0n1 -L "Gentoo" -l '\efi\gentoo\bzImage.efi' -u 'root=/dev/nvme0n1p3 page_poison=1 apparmor=1 security=apparmor,{other security stuff} zswap.enabled=1 zswap.compressor=zstd initrd=\efi\gentoo\INTRAMFS-FILE_FROM_DIST-KERNEL' |
Please read: https://forums.gentoo.org/viewtopic-p-8805827.html#8805827 (and the next 5 posts) |
Do I still need to do all of this if I use gentoo-kernel and installkernel with the efistub USE flag?
EDIT: Ah, silly me, I forgot a few things:
I believe this command is close to what I'll have to use, since I use the dist-kernel (sys-kernel/gentoo-kernel)
Code: |
# 6.6.21 can be replaced with whatever kernel version, I imagine
efibootmgr -c -d /dev/nvme0n1 -L "gentoo" -l /efi/EFI/gentoo/vmlinuz-6.6.21-gentoo-dist-hardened.efi -u 'root=/dev/nvme0n1p3 quiet init_on_alloc=1 init_on_free=1 randomize_kstack_offset=on random.trust_cpu=off slab_nomerge pti=on page_poison=1 iommu.passthrough=0 iommu.strict=1 vsyscall=none apparmor=1 security=apparmor lsm=landlock,yama,integrity,apparmor,bpf driver=free amdgpu.modeset=1 snd-usb-audio.quirk_alias=0db0419c:0b051917 video=DP-1:2560x1440@165 zswap.enabled=1 zswap.compressor=zstd zswap.zpool=zsmalloc zswap.max_pool_percent=15 initrd=/efi/EFI/gentoo/initramfs-6.6.21-gentoo-dist-hardened.img'
|
But there's one more thing: Intel Microcode:
I have the following in my make.conf now:
Code: |
MICROCODE_SIGNATURES="-s 0x00090672"
|
And I believe I have to do the kernel stuff as well here?
https://wiki.gentoo.org/wiki/Intel_microcode#New_method_without_initram-fs.2Fdisk_.28efistub_compatible.29
Last edited by alecStewart1 on Thu Apr 11, 2024 12:52 am; edited 1 time in total |
|
Back to top |
|
|
pietinger Moderator
Joined: 17 Oct 2006 Posts: 5117 Location: Bavaria
|
Posted: Thu Apr 11, 2024 12:50 am Post subject: Re: Move from GRUB to plain EFI Stubs? |
|
|
alecStewart1 wrote: | Do I still need to do all of this if I use gentoo-kernel and installkernel with the efistub USE flag? |
I dont think so ... but I really dont know what all this automagic stuff is doing ...
I am old and do it as I always do -> I learned in my youth: if you want it to work, do it yourself
Have you read the wiki page about installkernel: https://wiki.gentoo.org/wiki/Installkernel ? (For me, this is more complicated to understand than doing it manually) _________________ https://wiki.gentoo.org/wiki/User:Pietinger |
|
Back to top |
|
|
alecStewart1 Tux's lil' helper
Joined: 03 Jul 2022 Posts: 148
|
Posted: Thu Apr 11, 2024 12:56 am Post subject: Re: Move from GRUB to plain EFI Stubs? |
|
|
pietinger wrote: | alecStewart1 wrote: | Do I still need to do all of this if I use gentoo-kernel and installkernel with the efistub USE flag? |
I dont think so ... but I really dont know what all this automagic stuff is doing ...
I am old and do it as I always do -> I learned in my youth: if you want it to work, do it yourself
Have you read the wiki page about installkernel: https://wiki.gentoo.org/wiki/Installkernel ? (For me, this is more complicated to understand than doing it manually) |
If you read my edit, I have a gut feeling I still need to add the commandline options in with efibootmgr. That or I can put them in the CONFIG_CMDLINE option in my kernel config.
Also I'm still a little curious about the intel microcode. |
|
Back to top |
|
|
pietinger Moderator
Joined: 17 Oct 2006 Posts: 5117 Location: Bavaria
|
Posted: Thu Apr 11, 2024 1:08 am Post subject: Re: Move from GRUB to plain EFI Stubs? |
|
|
+
alecStewart1 wrote: | Also I'm still a little curious about the intel microcode. |
Please forget that. When using our dist-kernel THEN the initramfs will do the microcode-update (the only requirement is that you have emerged "intel-microcode).
This: https://wiki.gentoo.org/wiki/Intel_microcode#New_method_without_initram-fs.2Fdisk_.28efistub_compatible.29 is only necessary when you do a manually kernel configuration (without an initramfs).
alecStewart1 wrote: | [ Code: | # 6.6.21 can be replaced with whatever kernel version, I imagine
efibootmgr -c -d /dev/nvme0n1 -L "gentoo" -l /efi/EFI/gentoo/vmlinuz-6.6.21-gentoo-dist-hardened.efi -u 'root=/dev/nvme0n1p3 quiet init_on_alloc=1 init_on_free=1 randomize_kstack_offset=on random.trust_cpu=off slab_nomerge pti=on page_poison=1 iommu.passthrough=0 iommu.strict=1 vsyscall=none apparmor=1 security=apparmor lsm=landlock,yama,integrity,apparmor,bpf driver=free amdgpu.modeset=1 snd-usb-audio.quirk_alias=0db0419c:0b051917 video=DP-1:2560x1440@165 zswap.enabled=1 zswap.compressor=zstd zswap.zpool=zsmalloc zswap.max_pool_percent=15 initrd=/efi/EFI/gentoo/initramfs-6.6.21-gentoo-dist-hardened.img' |
|
+
alecStewart1 wrote: | If you read my edit, I have a gut feeling I still need to add the commandline options in with efibootmgr. That or I can put them in the CONFIG_CMDLINE option in my kernel config. |
You can put everything into your CONFIG_CMDLINE ... EXCEPT initrd=
BTW: I have given you the correct syntax with \ and NOT with /
initrd=/efi/EFI/gentoo/initramfs-6.6.21-gentoo-dist-hardened.img
=> MUST BE:
initrd=\EFI\gentoo\initramfs-6.6.21-gentoo-dist-hardened.img
Maybe ... only mabe READ the articles I have given you
Especially: Please read: https://forums.gentoo.org/viewtopic-p-8805827.html#8805827 (and the next 5 posts) _________________ https://wiki.gentoo.org/wiki/User:Pietinger |
|
Back to top |
|
|
pietinger Moderator
Joined: 17 Oct 2006 Posts: 5117 Location: Bavaria
|
Posted: Thu Apr 11, 2024 1:18 am Post subject: |
|
|
P.S.: If you work with versions in your filenames (kernel-6.6.6.efi // initramfs-6.6.6) THEN you must create always a new UEFI entry ... therefore MY recommendation ist to rename both to:
bzImage.efi and initramfs.CPIO and make an UEFI entry ONLY for these names. THEN you can use the same UEFI entry for every new kernel ... and if you read:
1. the efistub wiki article (*), OR
2. my article
you will see we make two UEFI entries to have a backup kernel we can boot
*) https://wiki.gentoo.org/wiki/EFI_stub#Backup_kernel _________________ https://wiki.gentoo.org/wiki/User:Pietinger |
|
Back to top |
|
|
alecStewart1 Tux's lil' helper
Joined: 03 Jul 2022 Posts: 148
|
Posted: Thu Apr 11, 2024 2:46 am Post subject: |
|
|
pietinger wrote: | P.S.: If you work with versions in your filenames (kernel-6.6.6.efi // initramfs-6.6.6) THEN you must create always a new UEFI entry ... therefore MY recommendation ist to rename both to:
bzImage.efi and initramfs.CPIO and make an UEFI entry ONLY for these names. THEN you can use the same UEFI entry for every new kernel ... and if you read:
1. the efistub wiki article (*), OR
2. my article
you will see we make two UEFI entries to have a backup kernel we can boot
*) https://wiki.gentoo.org/wiki/EFI_stub#Backup_kernel |
Hmm, okay. So I guess if I were to do your recommendation, but still use the dist-kernel, I could do;
- move vmlinuz-x.x.x-gentoo-dist-hardened.efi initramfs-x.x.x-gentoo-dist-hardened.img in /efi/EFI/gentoo to /efi/EFI/gentoo/bmzImage.efi and /efi/EFI/gentoo/initramfs.CPIO (respectively)
- run
Code: |
efibootmgr -c -d /dev/nvme0n1 -L "gentoo" -l '\EFI\gentoo\bzImage.efi' -u 'root=PARTUUID="my-long-uuid" ro quiet init_on_alloc=1 init_on_free=1 randomize_kstack_offset=on random.trust_cpu=off slab_nomerge pti=on page_poison=1 iommu.passthrough=0 iommu.strict=1 vsyscall=none apparmor=1 security=apparmor lsm=landlock,yama,integrity,apparmor,bpf driver=free amdgpu.modeset=1 snd-usb-audio.quirk_alias=0db0419c:0b051917 video=DP-1:2560x1440@165 zswap.enabled=1 zswap.compressor=zstd zswap.zpool=zsmalloc zswap.max_pool_percent=15 initrd=\EFI\gentoo\initramfs.CPIO |
- and whatever other efibootmgr commands I need for the items in /efi/EFI/gentoo/backup and /efi/EFI/gentoo/secure? |
|
Back to top |
|
|
pietinger Moderator
Joined: 17 Oct 2006 Posts: 5117 Location: Bavaria
|
Posted: Thu Apr 11, 2024 2:10 pm Post subject: |
|
|
alecStewart1 wrote: | Hmm, okay. So I guess if I were to do your recommendation, but still use the dist-kernel, I could do;
- move vmlinuz-x.x.x-gentoo-dist-hardened.efi initramfs-x.x.x-gentoo-dist-hardened.img in /efi/EFI/gentoo to /efi/EFI/gentoo/bmzImage.efi and /efi/EFI/gentoo/initramfs.CPIO (respectively)
- run
Code: | efibootmgr -c -d /dev/nvme0n1 -L "gentoo" -l '\EFI\gentoo\bzImage.efi' -u 'root=PARTUUID="my-long-uuid" ro quiet init_on_alloc=1 init_on_free=1 randomize_kstack_offset=on random.trust_cpu=off slab_nomerge pti=on page_poison=1 iommu.passthrough=0 iommu.strict=1 vsyscall=none apparmor=1 security=apparmor lsm=landlock,yama,integrity,apparmor,bpf driver=free amdgpu.modeset=1 snd-usb-audio.quirk_alias=0db0419c:0b051917 video=DP-1:2560x1440@165 zswap.enabled=1 zswap.compressor=zstd zswap.zpool=zsmalloc zswap.max_pool_percent=15 initrd=\EFI\gentoo\initramfs.CPIO |
|
Yes.
alecStewart1 wrote: | - and whatever other efibootmgr commands I need for the items in /efi/EFI/gentoo/backup and /efi/EFI/gentoo/secure? |
The names "backup" and "secure" are only suggestions and do not have to be used. You use e.g. "gentoo" for your main boot entry. If you want a backup, you can also copy both files to \EFI\backup\* and then create a boot entry:
Code: | efibootmgr -c -d /dev/nvme0n1 -L "backup" -l '\EFI\backup\bzImage.efi' -u 'root=PARTUUID="my-long-uuid" ro quiet init_on_alloc=1 init_on_free=1 randomize_kstack_offset=on random.trust_cpu=off slab_nomerge pti=on page_poison=1 iommu.passthrough=0 iommu.strict=1 vsyscall=none apparmor=1 security=apparmor lsm=landlock,yama,integrity,apparmor,bpf driver=free amdgpu.modeset=1 snd-usb-audio.quirk_alias=0db0419c:0b051917 video=DP-1:2560x1440@165 zswap.enabled=1 zswap.compressor=zstd zswap.zpool=zsmalloc zswap.max_pool_percent=15 initrd=\EFI\backup\initramfs.CPIO |
Please do not be surprised that this entry is now booted first (because the efibootmgr places it first in the boot order when creating an entry). This is of course not a problem because you can change the boot order again (either directly in the BIOS or with efiboomgr). The easiest way is of course to create the backup entry first and then the main entry. I then proceed like this with a new kernel (here the copying of the intramfs is still missing - because I don't have an initramfs):
https://wiki.gentoo.org/wiki/User:Pietinger/Tutorials/Boot_kernel_via_UEFI#Cheat_Sheets_for_a_standard_stub_kernel
But I would like to emphasize once again that none of this is a must, everyone can decide for themselves what they want to do. AFAIK, for example, the automatic installkernel works in such a way that it makes entries WITH version (and therefore creates a new entry every time; I just don't like that). _________________ https://wiki.gentoo.org/wiki/User:Pietinger |
|
Back to top |
|
|
alecStewart1 Tux's lil' helper
Joined: 03 Jul 2022 Posts: 148
|
Posted: Fri Apr 12, 2024 2:46 pm Post subject: |
|
|
Okay...it seems like something else is missing.
Without modifying the boot entries created by installkernel with the efistub USE flag, my motherboard cannot detect the those generate EFI files. It can detect the EFI file for the Live USB I use.
However the Live USB I have can detect other "boot loaders" and when I select the one that is at "\EFI\gentoo\vmlinuz-6.6.21-gentoo-hardened.efi" to be loaded I get a brief glimpse of the kernel loading or dmesg and then the I guess it fails and the computer reboots.
When I boot into the Live USB and do everything I need to chroot into the Gentoo installation
Code: |
mkdir -p /mnt/gentoo/efi
mount /dev/nvme0n1p3 /mnt/gentoo
mount --types proc /proc /mnt/gentoo/proc
mount --rbind /sys /mnt/gentoo/sys
mount --rbind /dev /mnt/gentoo/dev
mount --bind /run /mnt/gentoo/run
mount --make-rslave /mnt/gentoo/sys
mount --make-rslave /mnt/gentoo/dev
mount --make-slave /mnt/gentoo/run
chroot /mnt/gentoo /bin/sh
source /etc/profile
mount -a
|
And then run efibootmgr I do not see any other EFI boot entries besides the one for the Live USB.
I don't know why this is.
One thing I found from the uefi-mkconfig (which is what installkernel uses to create EFI boot entries) is that to have it automatically add stuff to the kernel command line you can add them in a file at
Code: |
/etc/default/uefi-mkconfig
/etc/kernel/uefi-mkconfig
/usr/lib/kernel/uefi-mkconfig
|
https://github.com/Biosias/uefi-mkconfig?tab=readme-ov-file#kernel-commands
Although I genuinely have no idea what the format of this file is supposed to be, nor how I'm supposed to specify things for the kernel command line only.
Looking at the actual script, I guess I just add those items I want in the kernel command line in the file. So I assume something like this
Code: |
cat /etc/default/uefi-mkconfig
# I believe UUID has to be used if you're using initramfs
# we dont' include initrd because uefi-mkconfig will automatically detect that
root=UUID="some_long_uuid" ro quiet init_on_alloc=1 init_on_free=1 randomize_kstack_offset=on random.trust_cpu=off slab_nomerge pti=on page_poison=1 iommu.passthrough=0 iommu.strict=1 vsyscall=none apparmor=1 security=apparmor lsm=landlock,yama,integrity,apparmor,bpf driver=free amdgpu.modeset=1 snd-usb-audio.quirk_alias=0db0419c:0b051917 video=DP-1:2560x1440@165 zswap.enabled=1 zswap.compressor=zstd zswap.zpool=zsmalloc zswap.max_pool_percent=15
|
At least, that's my guess.
At this point, I'm a little frustrated and I only have a few ideas as to what's going wrong:
- installkernel and uefi-mkconfig are not adding anything to the kernel command line, except, supposedly, the initramfs: https://github.com/Biosias/uefi-mkconfig?tab=readme-ov-file#initramfs-auto-discovery
- uefi-mkconfig isn't creating valid EFI files, somehow?
- There's something erroneous in my kernel config
- There's something wrong with my motherboard
- The SSD I have has somehow gone kaput
I'm kind of at a loss so if anyone has any ideas, let me know. After work I'm going to just try creating a EFI boot entry myself and not rely on installkernel and uefi-mkconfig. If that doens't work, my best guess it's a hardware issue. |
|
Back to top |
|
|
pietinger Moderator
Joined: 17 Oct 2006 Posts: 5117 Location: Bavaria
|
Posted: Fri Apr 12, 2024 5:17 pm Post subject: |
|
|
Yes, there are some cases where mainboard manufacturers do not adhere to the UEFI specifications. We have already had cases in our forum where it was not possible to create a separate UEFI entry. We then had to fall back on the emergency solution \EFI\BOOT\BOOTX64.EFI.
What surprises me: If you already have grub in use, you should at least see the entry for the grub (\EFI\GENTOO\GRUBX64.EFI) when querying with "efibootmgr" ... except ... You have installed the grub using the parameter "removable". In this case, the BOOTX64.EFI currently in use IS the GRUB.
You could check all this by trying to manually create a boot entry ...
( Unfortunately I can't help you with the installation with automagic. ) _________________ https://wiki.gentoo.org/wiki/User:Pietinger |
|
Back to top |
|
|
alecStewart1 Tux's lil' helper
Joined: 03 Jul 2022 Posts: 148
|
Posted: Fri Apr 12, 2024 6:31 pm Post subject: |
|
|
pietinger wrote: | Yes, there are some cases where mainboard manufacturers do not adhere to the UEFI specifications. We have already had cases in our forum where it was not possible to create a separate UEFI entry. We then had to fall back on the emergency solution \EFI\BOOT\BOOTX64.EFI.
What surprises me: If you already have grub in use, you should at least see the entry for the grub (\EFI\GENTOO\GRUBX64.EFI) when querying with "efibootmgr" ... except ... You have installed the grub using the parameter "removable". In this case, the BOOTX64.EFI currently in use IS the GRUB.
You could check all this by trying to manually create a boot entry ...
( Unfortunately I can't help you with the installation with automagic. ) |
Well there is something at \EFI\gentoo\grubx64.efi....except my motherboard doesn't recognize it as a valid UEFI entry. If I use the LiveUSB to select \EFI\gentoo\grubx64.efi I get put into a GRUB rescue shell that I can't fully see because it gets shoved partially off screen. So maybe that says something.
I guess I could always try manually making a boot entry at \efi\boot\bootx64.efi, as in the EFI stub Gentoo Wiki page says in the troubleshooting section:
Quote: |
Some rare (U)EFI implementations do not accept individual EFI entries. In this case it often works to use the removable media boot path, see Efibootmgr #removable media for details. E.g. this command will copy the kernel for a 64 bit UEFI:
Code: |
root #cp /usr/src/linux/arch/x86/boot/bzImage /efi/EFI/boot/bootx64.efi
|
Be advised that this is against the (U)EFI specification, as it will circumvent the (U)EFI boot selection on internal drives (which are configured using EFI boot entries).
|
So if the only EFI boot entry that gets detected on my machine is the one on the LiveUSB, which is at \EFI\BOOT\BOOTX64.EFI on the LiveUSB, I guess I have to do something similar on my machine? That kind of stupid, and makes me not want to by another MSI motherboard in the future.
I could also for the heck of it try rEFInd, but I have a feeling that won't work any better if it doesn't do the non-standard \efi\boot\bootx64.efi thing, which may be the only way I can use (U)EFI on the motherboard I have. |
|
Back to top |
|
|
alecStewart1 Tux's lil' helper
Joined: 03 Jul 2022 Posts: 148
|
Posted: Fri Apr 12, 2024 6:34 pm Post subject: |
|
|
Ah, I found on the rEFInd Gentoo wiki page:
https://wiki.gentoo.org/wiki/REFInd#Installation_to_the_EFI_Default.2FFallback_path
Quote: |
rEFInd can be installed to a disk using the default/fallback filename of EFI/BOOT/bootx64.efi. The computer's NVRAM entries will not be modified when installing in this way. Most EFI and UEFI firmware support a fallback EFI image to boot from if the configured EFI file cannot be found, and some will also override the configured boot selection if the fallback boot image is found. This can be used to boot into EFI mode when doing so otherwise is difficult.
Code: | root # refind-install --usedefault /dev/sda |
Where /dev/sda is the ESP. This installation method can be used as either a permanent setup to create a bootable USB flash drive or install rEFInd on a computer that tends to "forget" its NVRAM settings or as a temporary bootstrap to get the system to boot in EFI mode.
|
So maybe rEFInd isn't a bad option. |
|
Back to top |
|
|
pietinger Moderator
Joined: 17 Oct 2006 Posts: 5117 Location: Bavaria
|
Posted: Fri Apr 12, 2024 7:18 pm Post subject: |
|
|
alecStewart1,
you will see on every (UEFI-)bootable USB-stick a \EFI\BOOT\BOOTX64.EFI ... because the reason why this default name exists IS: You dont want make an UEFI entry for a REMOVABLE medium (every time) ... so this name must be recognized by every UEFI system ... to be able to boot from a stick without creating an UEFI entry ... now guess why the name of the grub parameter which renames grubx64.efi into bootx64.efi is "--removable" ? ... yes, the main intention is to install grub to a stick ... but it can be used also to boot from a harddisk (as fallback if a normal entry cannot be created).
NOW ... at the moment you dont know whether your mainboard accepts a selfmade UEFI entry ... and you dont want to try it ... so, yes, refind is just another bootloader (be aware: refind can load ONLY efistubs ...)
At the end you choose what you want ... you know now all options.
Have fun with Gentoo ! _________________ https://wiki.gentoo.org/wiki/User:Pietinger |
|
Back to top |
|
|
alecStewart1 Tux's lil' helper
Joined: 03 Jul 2022 Posts: 148
|
Posted: Fri Apr 12, 2024 7:34 pm Post subject: |
|
|
pietinger wrote: | alecStewart1,
NOW ... at the moment you dont know whether your mainboard accepts a selfmade UEFI entry ... and you dont want to try it ... so, yes, refind is just another bootloader (be aware: refind can load ONLY efistubs ...)
|
Well I'll have to double check by messing with some of the uefi-mkconfig stuff and also manually creating a UEFI entry, but I have gut feeling that it doesn't. If the EFI boot entries at \EFI\gentoo\vmlinuz-x.x.x-gentoo-hardened.efi are not even recognizable to my motherboard, noted by the fact that they aren't in the motherboards boot menu at all and they are only viewable through the LiveUSB boot menu, and the only viewable EFI boot entry on the motherboard boot menu is the one on the LiveUSB which the default of EFI/BOOT/BOOTX64.EFI, I have a feeling the motherboard doesn't accept individual EFI entries.
Again I'll have to test those two things and see, but I have a good feeling. |
|
Back to top |
|
|
alecStewart1 Tux's lil' helper
Joined: 03 Jul 2022 Posts: 148
|
Posted: Mon Apr 15, 2024 12:44 am Post subject: |
|
|
Okay...refind seems to work until I get to "Starting systemd-udevd" or whatever and it errors out with
Code: |
sh: line 1: gzip command not found
setfont:[some error number]: Bad font height 0 (max height 128)
|
Or something along those lines. Kind of hard to copy-paste. I've ran into these errors before...but I don't remember how I fixed them.
EDIT: Found a few possible related issues:
https://forums.gentoo.org/viewtopic-t-1167862-highlight-gzip.html
https://forums.gentoo.org/viewtopic-t-1168380-highlight-gzip.html
I bet I forgot to set CONFIG_FRAMEBUFFER_CONSOLE. Wouldn't surprise me. It'd be bad if it was a dracut issue. |
|
Back to top |
|
|
alecStewart1 Tux's lil' helper
Joined: 03 Jul 2022 Posts: 148
|
Posted: Mon Apr 15, 2024 2:40 pm Post subject: |
|
|
Alright...CONFIG_FRAMEBUFFER_CONSOLE is enabled.
At this point, my best guess it there's some issue with dracut. It seems like quite a few people are having issues with it post the profile upgrades from 17.0 -> 23.0.
I'll give genkernel a shot, as in at least both of those posts in my previous reply people are saying genkernel gives them working initramfs. At least I have a kernel config to work with already. |
|
Back to top |
|
|
keet Guru
Joined: 09 Sep 2008 Posts: 571
|
Posted: Tue Apr 16, 2024 3:02 pm Post subject: |
|
|
I'm booting successfully, having built my kernel and initramfs using genkernel. I used this command to add the entry:
efibootmgr -d (device node of E.F.I. partition, in my case /dev/nvme0n1p1) -p 1 -c -L "Gentoo EFI stub" -l /vmlinuz-6.8.2-gentoo-x86_64 -u "crypt_root=UUID=(blkid of encrypted physical partition) real_root=UUID=(blkid of decrypted root in /dev/mapper) root_trim=yes rw initrd=initramfs-6.8.2-gentoo-x86_64.img" |
|
Back to top |
|
|
Nowa Developer
Joined: 25 Jun 2014 Posts: 429 Location: Nijmegen
|
Posted: Tue Apr 16, 2024 7:47 pm Post subject: |
|
|
Your /etc/default/uefi-mkconfig should be correct, if what you add there is not showing when you 'efibootmgr -u' then this is a bug (please report it at the uefi-mkconfig github page). This is the first release of uefi-mkconfig so it may very well be that something is not working properly yet. If you want to try something that is a bit more tested, enable the systemd flag on installkernel in which case it will use virt-firmware from fedora instead of uefi-mkconfig (note this requires some components from systemd-utils but nonetheless should work on openrc systems)
That being said, there are many ways the firmware may be "broken" and therefore unnable to efi stub boot, some examples of things I have seen:
- the command line is not passed to the efi binary (this you can workaround with using a built-in cmdline or a unified kernel image)
- the firmware does not allow adjusting the bootorder from the os (in which case life gets hard when you want to install multiple versions in parallel as installkernel does)
- the firmware does not respect boot entries at all, and only boots the windows boot loader path and the fallback path (in which case life is again difficult)
My advice, if the firmware is tricky, then just use systemd-boot or refind. I have personally spent way too much time debugging and working around broken firmware and it is never worth the effort, the performance impact of systemd-boot and refind is neglible. _________________ OS: Gentoo 6.10.12-gentoo-dist, ~amd64, 23.0/desktop/plasma/systemd
MB: MSI Z370-A PRO
CPU: Intel Core i9-9900KS
GPU: Intel Arc A770 16GB & Intel UHD Graphics 630
SSD: Samsung 970 EVO Plus 2 TB
RAM: Crucial Ballistix 32GB DDR4-2400 |
|
Back to top |
|
|
Biosias n00b
Joined: 18 Apr 2024 Posts: 1
|
Posted: Thu Apr 18, 2024 6:01 pm Post subject: |
|
|
Hello, developer of uefi-mkconfig here. Format of uefi-mkconfig config needs to be only space separated kernel commands. I've tested your list of commands and the entries are generated correctly so it seems this isn't due to uefi-mkconfig itself.
However thank you for pointing out the lack of information about format in which should kernel commands be added to the configuration. I will document it properly.
But as other have pointed out, UEFI implementations are sometimes very weird ... to say the least. Even on my own machie, I can add entries but the firmware seems to at random ignore the set bootorder. |
|
Back to top |
|
|
|