Issue with grub and secure boot

abdulrahim-ss · 2025-01-01 00:50:03

Hi!
I have a very specific problem that I am having a hard time resolving. First of all, I have newly installed arch on my laptop and am dual booting with windows 11. For multiple reasons, I require secure boot! After following the wiki, I have successfully gotten secure boot to work using sbctl with my own keys, and I am running grub. It worked well for a couple of days. One thing that confused me though, was that there were two boot options when booting up the system for some reason. I tried removing the redundant one with

 sudo efibootmgr -b 0 -B

but the entry shows up again after rebooting. The weird thing is that the entry in efibootmgr does not display the path like the other two for grub and windows.

BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0003,0001,0000
Boot0000* EFI Hard Drive (SAMSUNG MZAL81T0HDLB-00BL2)   PciRoot(0x0)/Pci(0x6,0x0)/Pci(0x0,0x0)/NVMe(0x1,00-25-38-A3-41-C2-C7-B8)/HD(5,GPT,19b7c621-6525-4797-9ed3-35703795f4f5,0x76be0000,0x3f5000)RC
Boot0001* GRUB  HD(5,GPT,19b7c621-6525-4797-9ed3-35703795f4f5,0x76be0000,0x3f5000)/\EFI\GRUB\grubx64.efi
Boot0003* Windows Boot Manager  HD(1,GPT,ab96db49-1172-4bad-895a-076dc618d9c0,0x800,0x82000)/\EFI\Microsoft\Boot\bootmgfw.efi57494e444f5753000100000088000000780000004200430044004f0042004a004500430054003d007b00390064006500610038003600320063002d0035006300640064002d0034006500370030002d0061006300630031002d006600330032006200330034003400640034003700390035007d00000065000100000010000000040000007fff0400
Boot2001* EFI USB Device        RC
Boot2002* EFI DVD/CDROM RC
Boot2003* EFI Network   RC

Now the main problem that I have right now is that I did not know or understand what swap was before installing Arch. So while I was reading the installation instructions, I decided for some reason to create a swap partition while creating my gpt partition setup. I created a 10GB swap partition, and for an even dumber reason, I created it right before my root partition that is followed by the efi partition. (I wanted a separate efi partition for Arch from windows!). The setup before looked something like this:

NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
zram0       254:0    0     4G  0 disk [SWAP]
nvme0n1     259:0    0 953.9G  0 disk
├─nvme0n1p1 259:1    0   260M  0 part
├─nvme0n1p2 259:2    0    16M  0 part
├─nvme0n1p3 259:3    0 756.3G  0 part
├─nvme0n1p4 259:4    0    10G  0 part
├─nvme0n1p5 259:5    0 183.3G  0 part /
├─nvme0n1p6 259:6    0     2G  0 part /boot
└─nvme0n1p7 259:7    0     2G  0 part

Notice how I didn't know at all how swap works and `archinstall` created its own swap partition. after I successfully setup secure boot, I decided to create a swap file instead and switch to that, which I was successfully able to do! Here comes the part where I ruined everything:
I boot into windows to do school work, and after a few days, I decided to delete the 10GB "swap" partition I had created from windows' disk management tool. I then rebooted to arch and landed in grub rescue. After long research, I figured out how to get everything working from grub rescue and grub shell and I can manually boot into arch. keyword: manually. I was able to update the grub config, but it does NOT work with secure boot. If I have secure boot enabled, I can't run `insmod normal` from grub rescue, because I then get the error: prohibited by secure boot policy.
When I disable secure boot, I can boot into arch directly from grub's boot menu with no need for manual commands in grub rescue or grub shell (however, not all menu options work, some lead to kernel panic!).
sbctl is acting very strange as well. Running `sudo sbctl verify` returns the following:

Verifying file database and EFI images in /boot...
✓ /boot/vmlinuz-linux.signed is signed
✓ /boot/EFI/BOOT/BOOTX64.EFI.signed is signed
✓ /boot/EFI/GRUB/grubx64.efi.signed is signed
✓ /boot/grub/x86_64-efi/core.efi.signed is signed
✓ /boot/grub/x86_64-efi/grub.efi.signed is signed
✓ /boot/EFI/BOOT/BOOTX64.EFI is signed
✗ /boot/EFI/GRUB/grubx64.efi is not signed
✗ /boot/grub/x86_64-efi/core.efi is not signed
✗ /boot/grub/x86_64-efi/grub.efi is not signed
✗ /boot/vmlinuz-linux is not signed

If I try to sign the unsigned efi files, I get

$ sudo sbctl sign -s /boot/vmlinuz-linux
✓ Signed /boot/vmlinuz-linux.signed

but still the same verify output. (Before I messed up with the partitions, verify would output a checkmark beside every entry, even with the .signed files existing!)

The structure inside my `/boot` folder is:

$ tree -L 2
.
├── EFI
│   ├── BOOT
│   └── GRUB
├── grub
│   ├── fonts
│   ├── grub.cfg
│   ├── grubenv
│   ├── locale
│   ├── themes
│   └── x86_64-efi
├── initramfs-linux-fallback.img
├── initramfs-linux.img
├── System Volume Information
├── vmlinuz-linux
└── vmlinuz-linux.signed

10 directories, 6 files

with the `/EFI` subdirectory having the structure:

.
├── BOOT
│   ├── BOOTX64.EFI
│   └── BOOTX64.EFI.signed
└── GRUB
    ├── grubx64.efi
    └── grubx64.efi.signed

3 directories, 4 files

As you can see, I very much don't really know what I am doing! what I want to solve is these following problems:

I feel like there are more efi files than there needs to be in the /boot directory. How do I clean up the boot menu and only have one grub boot option?
How do I get secure boot to work again?
How do I also clean up grub's boot menu and not get kernel panic again? (there is one option at the top called something like Arch Linux, with Linux linux.signed which results in kernel panic. Then there is an advanced menu with .signed, one without, and a recovery option. Only the option in the middle works, and I got it to work after updating the UUID and some other fixes.)

PS. updating the grub config does not help with

 grub-mkconfig -o /boot/grub/grub.cfg

If the grub config is required, or you want the output of any other commands listed here, or you want to see the boot and grub menus I mentioned, I'd be happy to post them here as well.

Thank you!

Last edited by abdulrahim-ss (2025-01-01 12:30:24)

Head_on_a_Stick · 2025-01-01 11:32:12

Boot0000 is created by the firmware because /EFI/Boot/boox64.efi is present on the EFI system partition.

I suspect your problems are caused by an incorrectly mounted /boot/ partition. It would probably be simplest to move /boot/ back to the root partition and mount the ESP under /efi/ instead.

If you want to keep a separate /boot/ partition and enjoy random filesystem corruption then make sure it is mounted correctly then re-install the kernel and re-run the grub-install command. I have no idea how sbctl works with GRUB though so you will have to wait for somebody else to comment on that.

abdulrahim-ss · 2025-01-01 12:42:55

Could you elaborate more?
/EFI/BOOT/BOOTx64.efi is not correct, as it is inside of /boot. I don't really understand what you mean by moving boot back to the root partition, do you mean that I should delete my efi partition (/dev/nvme0n1p5, which was 6 previously)? and what is the difference between /efi/ and /boot/?

Head_on_a_Stick · 2025-01-01 12:57:58

abdulrahim-ss wrote:

/EFI/BOOT/BOOTx64.efi is not correct, as it is inside of /boot

I gave the path relative to the EFI system partition so that would be correct if the ESP is mounted under /boot/.

abdulrahim-ss wrote:

do you mean that I should delete my efi partition

I meant that you should use the main root partition to hold /boot/ because the ESP needs a FAT filesystem, which is rather fragile and prone to corruption.

Mounting the ESP under /efi/ helps mitigate that because it's only written to if you need to update GRUB's core.img and it can be mounted on demand using autofs to further reduce exposure.

We should probably try to confirm the root cause of your problem first though. Is there another /boot/ directory already on the root partition containing kernel images etc?

abdulrahim-ss · 2025-01-01 14:07:36

No, I'm pretty sure there isn't. I have only one kernel image. And yes, the ESP is mounted under /boot. Quick note: the root partition is EXT4 and the efi partition is FAT32. See below:

NAME        FSTYPE    FSVER LABEL      UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
zram0       swap      1     zram0      2d7942ee-1eae-4fa1-857e-ca1c53724746                [SWAP]
nvme0n1
├─nvme0n1p1 vfat      FAT32 SYSTEM_DRV 9C67-585B
├─nvme0n1p2
├─nvme0n1p3 BitLocker 2
├─nvme0n1p4 ext4      1.0              ed6eaafc-af76-4552-afce-ee05fcd5e6b5   83.8G    48% /
├─nvme0n1p5 vfat      FAT32            AF43-7731                               1.8G     9% /boot
└─nvme0n1p6 ntfs            WINRE_DRV  668E68528E681D35

I still am not very sure I understand why you want me to move /boot/ to the root partition, since all the examples on the arch wiki have a separate efi partition for /boot/, and even windows has its own separate efi partition! would this help in fixing the issue with having multiple GRUB boot options in the boot menu?

I personally think that entire problem started from 'archinstall' installing GRUB during the initial arch installation, and then when I was setting up secure boot, `grub-install` using the command recommended in the wiki:

grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=GRUB --modules="tpm" --disable-shim-lock

installed a new GRUB bootloader separate from the one initially installed. Does that make sense?

Head_on_a_Stick · 2025-01-01 14:42:24

abdulrahim-ss wrote:

I still am not very sure I understand why you want me to move /boot/ to the root partition

That's more of a side issue at the moment. We should probably just focus on the problem itself and get your system working as it is. Sorry for the diversion.

abdulrahim-ss wrote:

would this help in fixing the issue with having multiple GRUB boot options in the boot menu?

Boot0000 is created by bootx64.efi on the ESP, as I have already said. Remove that file to remove Boot0000.

abdulrahim-ss wrote:

I personally think that entire problem started from 'archinstall' installing GRUB during the initial arch installation, and then when I was setting up secure boot, `grub-install` using the command recommended in the wiki:
grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=GRUB --modules="tpm" --disable-shim-lock
installed a new GRUB bootloader separate from the one initially installed. Does that make sense?

The grub-install command would replace /boot/EFI/grub/grubx64.efi with a new version, which is still correct for Boot0001.

I think you need more modules though. Read the wiki again.

abdulrahim-ss · 2025-01-01 14:56:41

Ok I removed /boot/EFI/BOOT/ entirely. What kind of modules do you mean? And what part of the wiki do you recommend I should read?

My only issues currently (which I think are related to each other) are:

GRUB menu has multiple alternatives that lead to kernel panic (one that has .signed in the name, and the fallback one), and a single one that actually boots, which is inside of the advanced menu.
Secure boot is not working anymore, and sbctl is not signing my efi files because .signed versions exist. removing them and resigning does not help either.

I just want to also add that I am not very familiar with EFI and boot partitions. I have dual booted multiple operating systems on previous computers I have owned, but this is my first time installing Arch linux.

Head_on_a_Stick · 2025-01-01 15:10:50

abdulrahim-ss wrote:

What kind of modules do you mean? And what part of the wiki do you recommend I should read?

https://wiki.archlinux.org/title/GRUB#Shim-lock

abdulrahim-ss wrote:

GRUB menu has multiple alternatives that lead to kernel panic (one that has .signed in the name, and the fallback one), and a single one that actually boots, which is inside of the advanced menu

You should probably share grub.cfg or the output of grub-mkconfig.

abdulrahim-ss wrote:

Secure boot is not working anymore

Please also share the output of

sbctl status

Thanks.

cryptearth · 2025-01-01 15:57:32

abdulrahim-ss wrote:

For multiple reasons, I require secure boot!
...
As you can see, I very much don't really know what I am doing!

well - aside from my personal opinion about secureboot - I doubt that you even understand why you might would need it in the first place
otherwise: enlighten us what those reasons are - as otherwise it sounds like an XY-problem

abdulrahim-ss · 2025-01-01 16:14:36

cryptearth wrote:

well - aside from my personal opinion about secureboot - I doubt that you even understand why you might would need it in the first place
otherwise: enlighten us what those reasons are - as otherwise it sounds like an XY-problem

I have seen a thousand guys like you on this forum saying the same about secure boot, and I don't really appreciate your tone. There are multiple reasons why I need secure boot: my laptop came with bitlocker and I don't want to remove it because it'll mess with my warranty. I can't run games with easyCheat and other antiCheat software, even if you think secure boot does not make my computer more secure, I like my current setup and I can't be bothered to keep turning secure boot on and off when switching between windows and arch...

I know this is posted in newbie corner, since I am indeed a newbie when it comes to arch, but assuming I don't know anything and that I haven't been reading up on the forums for days now when I clearly start by saying "i require secure boot" is very unnecessary and not helpful at all. Thank you for stopping by.

abdulrahim-ss · 2025-01-01 16:21:03

Head_on_a_Stick wrote:

You should probably share grub.cfg or the output of grub-mkconfig.

Here you go:

$ cat grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
insmod part_gpt
insmod part_msdos
if [ -s $prefix/grubenv ]; then
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="0"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
    saved_entry="${chosen}"
    save_env saved_entry
  fi
}

function load_video {
  if [ x$feature_all_video_module = xy ]; then
    insmod all_video
  else
    insmod efi_gop
    insmod efi_uga
    insmod ieee1275_fb
    insmod vbe
    insmod vga
    insmod video_bochs
    insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_gpt
insmod ext2
search --no-floppy --fs-uuid --set=root ed6eaafc-af76-4552-afce-ee05fcd5e6b5
    font="/usr/share/grub/unicode.pf2"
fi

if loadfont $font ; then
  set gfxmode=auto
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set lang=en_US
  insmod gettext
fi
terminal_input console
terminal_output gfxterm
if [ x$feature_timeout_style = xy ] ; then
  set timeout_style=menu
  set timeout=5
# Fallback normal timeout code in case the timeout_style feature is
# unavailable.
else
  set timeout=5
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/10_linux ###
menuentry 'Arch Linux' --class arch --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-ed6eaafc-af76-4552-afce-ee05fcd5e6b5' {
        load_video
        set gfxpayload=keep
        insmod gzio
        insmod part_gpt
        insmod fat
        search --no-floppy --fs-uuid --set=root AF43-7731
        echo    'Loading Linux linux.signed ...'
        linux   /vmlinuz-linux.signed root=/dev/nvme0n1p4 rw zswap.enabled=0 rootfstype=ext4 loglevel=3 quiet
}
submenu 'Advanced options for Arch Linux' $menuentry_id_option 'gnulinux-advanced-ed6eaafc-af76-4552-afce-ee05fcd5e6b5' {
        menuentry 'Arch Linux, with Linux linux.signed' --class arch --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-linux.signed-advanced-ed6eaafc-af76-4552-afce-ee05fcd5e6b5' {
                load_video
                set gfxpayload=keep
                insmod gzio
                insmod part_gpt
                insmod fat
                search --no-floppy --fs-uuid --set=root AF43-7731
                echo    'Loading Linux linux.signed ...'
                linux   /vmlinuz-linux.signed root=/dev/nvme0n1p4 rw zswap.enabled=0 rootfstype=ext4 loglevel=3 quiet
        }
        menuentry 'Arch Linux, with Linux linux' --class arch --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-linux-advanced-ed6eaafc-af76-4552-afce-ee05fcd5e6b5' {
                load_video
                set gfxpayload=keep
                insmod gzio
                insmod part_gpt
                insmod fat
                search --no-floppy --fs-uuid --set=root AF43-7731
                echo    'Loading Linux linux ...'
                linux   /vmlinuz-linux root=UUID=ed6eaafc-af76-4552-afce-ee05fcd5e6b5 rw zswap.enabled=0 rootfstype=ext4 loglevel=3 quiet
                echo    'Loading initial ramdisk ...'
                initrd  /initramfs-linux.img
        }
        menuentry 'Arch Linux, with Linux linux (fallback initramfs)' --class arch --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-linux-fallback-ed6eaafc-af76-4552-afce-ee05fcd5e6b5' {
                load_video
                set gfxpayload=keep
                insmod gzio
                insmod part_gpt
                insmod fat
                search --no-floppy --fs-uuid --set=root AF43-7731
                echo    'Loading Linux linux ...'
                linux   /vmlinuz-linux root=UUID=ed6eaafc-af76-4552-afce-ee05fcd5e6b5 rw zswap.enabled=0 rootfstype=ext4 loglevel=3 quiet
                echo    'Loading initial ramdisk ...'
                initrd  /initramfs-linux-fallback.img
        }
}

### END /etc/grub.d/10_linux ###

### BEGIN /etc/grub.d/20_linux_xen ###
### END /etc/grub.d/20_linux_xen ###

### BEGIN /etc/grub.d/25_bli ###
if [ "$grub_platform" = "efi" ]; then
  insmod bli
fi
### END /etc/grub.d/25_bli ###

### BEGIN /etc/grub.d/30_os-prober ###
### END /etc/grub.d/30_os-prober ###

### BEGIN /etc/grub.d/30_uefi-firmware ###
if [ "$grub_platform" = "efi" ]; then
        fwsetup --is-supported
        if [ "$?" = 0 ]; then
                menuentry 'UEFI Firmware Settings' $menuentry_id_option 'uefi-firmware' {
                        fwsetup
                }
        fi
fi
### END /etc/grub.d/30_uefi-firmware ###

### BEGIN /etc/grub.d/40_custom ###
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
### END /etc/grub.d/40_custom ###

### BEGIN /etc/grub.d/41_custom ###
if [ -f  ${config_directory}/custom.cfg ]; then
  source ${config_directory}/custom.cfg
elif [ -z "${config_directory}" -a -f  $prefix/custom.cfg ]; then
  source $prefix/custom.cfg
fi
### END /etc/grub.d/41_custom ###

Head_on_a_Stick wrote:

Please also share the output of
sbctl status

$ sbctl status
Installed:      ✓ sbctl is installed
Owner GUID:     503572f5-9bc1-422b-b6b2-4dc82e670de8
Setup Mode:     ✓ Disabled
Secure Boot:    ✗ Disabled
Vendor Keys:    microsoft

Thank you for your help so far!

Head_on_a_Stick · 2025-01-01 18:14:40

Looks like grub-mkconfig thinks the vmlinuz-linux.signed files are unified kernel images, which is why their menuentries don't boot.

Where do those vmlinuz-linux.signed files come from? Is that sbctl? I don't use it myself so I'm not sure how it works.

Last edited by Head_on_a_Stick (2025-01-01 18:15:23)

abdulrahim-ss · 2025-01-01 18:27:04

sbctl generated them using the command

sudo sbctl sign -s -o <efi file>.signed <same efi file>

After reading up after the fact, I realized that GRUB does not generally make use of .signed files. Systemd-boot is usually the bootloader that benefits from them, but I'm not quite sure what to do now!

Head_on_a_Stick · 2025-01-01 19:11:46

Get rid of the .signed files then regenerate grub.cfg.

abdulrahim-ss · 2025-01-01 19:50:09

Unfortunately, after deleting the .signed files, if I try to re-sign the efi files, sbctl generates the .signed files again, even when I run the normal

sudo sbctl sign -s <efi file>

with no output specified. I am having trouble getting sbctl to update its configuration and sign the files directly. Even weirder, after deleting the signed files, and /boot/EFI/BOOT earlier, I am getting this very weird error with both `sudo sbctl verify` and `sudo sbctl list-files`:

$ sudo sbctl list-files
populating ruleset for "/boot/EFI/BOOT" with access {execute,write_file,read_file,read_dir,remove_dir,remove_file,make_char,make_dir,make_reg,make_sock,make_fifo,make_block,make_sym,truncate}: open: no such file or directory

cryptearth · 2025-01-01 21:14:02

abdulrahim-ss wrote:

I have seen a thousand guys like you on this forum saying the same about secure boot, and I don't really appreciate your tone.

*popcorn emoji
ok there buddy ... yes, secure boot is just snakeoil to me - and your reply shows me that it found yet another victim

abdulrahim-ss wrote:

There are multiple reasons why I need secure boot: my laptop came with bitlocker and I don't want to remove it because it'll mess with my warranty.

I HIGHLY doubt THAT - as I can tell you for sure that such a clause would be illegal in europe and north america - and I guess that's true in quite a lot of other regions, too
even if - just using simple logic: the second you touch your bios and mess with that setting - and in fact you already modified your system permanently by playing around with SHIM and MO-keys - would already invalidate your warranty and hence some protection had to be in place like a uefi password set by the store or the oem to lock you out of that setting
the fact that you are even able to change it and that you already have modified the system from how you bought it makes your statement invalid within that one sentence itself

abdulrahim-ss wrote:

I can't run games with easyCheat and other antiCheat software,

sorry - but THAT is just complete bullshit!
EasyAntiCheat does require neither secureboot nor a tpm - same goes for BattlEye, GameGuard nProtect and several other common ones
whereever you got THAT information from - it'S just plain and simple WRONG
in fact: many anti cheat runs fine on linux as long as its dev has enabled support for it

abdulrahim-ss wrote:

even if you think secure boot does not make my computer more secure, I like my current setup and I can't be bothered to keep turning secure boot on and off when switching between windows and arch...

again - this makes your above statement about it would have something to do with your warranty complete invalid as you wouldn't even be allowed/able to mess with that setting let along install another OS along windows
btw - it's not like as I just "think" that SB doesn't make a system any more secure - it's again just simple logic: even with windows SB only secures the boot process - the moment you run any arbitrary software which is not signed by a key part of the whole trust chain you break it
secure boot would only work if one would seal the entire system all the way from the oem key up to what applications can be run in the OS - downloading and executing any random binary from the internet already breaks the chain
same goes for linux: the second you tinker with your system to even boot another OS - no matter which - already modifies it - in the case of arch you installed your own keys - in case of a signed distribution like opensuse which comes with shim you would get asked to add the opensuse key

TLDR: not even is your reply nonesense and thereby this topic just a XY-problem - you either just fell for marketing BS or completely missunderstand cryptography and how secureboot and a chain of trust had to be implemented to actual work

Head_on_a_Stick · 2025-01-01 22:36:39

abdulrahim-ss wrote:

after deleting the signed files, and /boot/EFI/BOOT earlier

Oh bugger, I forgot you did that. I meant for you to just (re)move bootx64.efi, no need to go nuclear. Sorry if that wasn't clear.

I think you might have to run `sbctl setup` but check the man page and other documentation for details. That command option has several flags and I really don't know how to use that utility. Perhaps just creating /boot/EFI/BOOT/ again will persuade it to work.

FWIW the documentation seems to claim .signed files are only created if the -o option is passed to sbctl. I cannot test this myself.

EDIT: check

sudo type sbctl

Do you have an alias somewhere?

Last edited by Head_on_a_Stick (2025-01-01 22:37:45)

ewaller · 2025-01-01 22:51:27

Cryptearth, I think you should stand down on this one. Regardless of your feelings about it, it is a valid use case and is supported by Arch Linux.

abdulrahim-ss · 2025-01-02 01:17:01

I have finally fixed my problem!

Head_on_a_Stick wrote:

I think you might have to run `sbctl setup` but check the man page and other documentation for details.

I didn't need to run setup, but it did point me in the right direction! I ran `sbctl setup --print-config` and finally found sbctl's json config files, where it had saved from the previous -s -o options that the output for each file is .signed. I first deleted the entry for the efi file that was under /boot/EFI/BOOT, and then modified the rest so that they don't end with .signed anymore. The config looked something like this for any future references:

$sudo nvim /var/lib/sbctl/files.json
{
    "/boot/EFI/GRUB/grubx64.efi": {
        "file": "/boot/EFI/GRUB/grubx64.efi",
        "output_file": "/boot/EFI/GRUB/grubx64.efi"
    },
    "/boot/grub/x86_64-efi/core.efi": {
        "file": "/boot/grub/x86_64-efi/core.efi",
        "output_file": "/boot/grub/x86_64-efi/core.efi"
    },
    "/boot/grub/x86_64-efi/grub.efi": {
        "file": "/boot/grub/x86_64-efi/grub.efi",
        "output_file": "/boot/grub/x86_64-efi/grub.efi"
    },
    "/boot/vmlinuz-linux": {
        "file": "/boot/vmlinuz-linux",
        "output_file": "/boot/vmlinuz-linux"
    }
}

I then just simply re-signed all the files - no need to regenerate the keys or do anything from scratch really!

Head_on_a_Stick wrote:

FWIW the documentation seems to claim .signed files are only created if the -o option is passed to sbctl. I cannot test this myself.

This was unfortunately not true, as it seems like as soon as you specify with the -o option, it saves to the json config which persists for all future signatures.

I would like to know where the `/EFI/BOOT/bootx64.efi` file came from? From your latest reply, it seemed to me that it is a common file to have? I thought from earlier that it came from my faulty installation of GRUB, but I am not sure now if it is needed or if it is fine that I deleted this directory.

Finally, thank you so much for your help! I might consider moving my /boot as you suggested earlier to the root partition, any recommendations on where I can read on why exactly I should be doing that and how to do it? Also, would that mean that I basically have a single partition for my entire Arch installation?
I would also like to know, to your knowledge, why do you think for eg. Windows has a separate efi partition? and another example is that even the Arch wiki suggests a separate partition for the `/home/` directory in some of its examples! I got the impression that having multiple partitions is better, since if one sector of the drive gets corrupted, some files on the other partitions might be saved, but from what you wrote it seems that it would be better if I had a single partition? Although, I would understand if the problem lies in the simple fact that efi require the older FAT32 scheme which might lead to problems as opposed to having /boot on a partition with a newer file system like ext4.

Last edited by abdulrahim-ss (2025-01-02 01:22:10)

Head_on_a_Stick · 2025-01-02 12:08:22

abdulrahim-ss wrote:

I would like to know where the `/EFI/BOOT/bootx64.efi` file came from?

The grub-install command will copy core.img to that location on the ESP if the --removable flag is passed; systemd-boot will hijack that location automatically, if you've ever tried that.

Lots of other operating systems use bootx64.efi to start UEFI installations because they lack utilities to modify the NVRAM boot entries, including the BSDs and Haiku.

abdulrahim-ss wrote:

I might consider moving my /boot as you suggested earlier to the root partition, any recommendations on where I can read on why exactly I should be doing that and how to do it?

There is some "official" advice in respect of the ESP mopuntpoint:

https://uapi-group.org/specifications/s … unt-points

They do recommend using /boot/ for the ESP but only if there is no XBOOTLDR partition. The recommendation is to take advantage of autofs mounts for the ESP and/or XBOOTLDR partition but this only happens automatically if systemd-boot (or the stub) is used -- GRUB would require manual modification of /etc/fstab. It is also worth noting that autofs mounts only work automatically if there is no fstab line for the partition in question, which would not be the case for anybody following the official Arch installation process or using archinstall.

For GRUB I think the best solution is to mount the ESP under /efi/ and add x-systemd.automount & x-systemd.mount-timeout=120 as fstab options, which will only mount the ESP if you run grub-install after the grub package is updated.

abdulrahim-ss wrote:

would that mean that I basically have a single partition for my entire Arch installation?

The ESP is still required but only for GRUB's core.img & modules.

abdulrahim-ss wrote:

why do you think for eg. Windows has a separate efi partition?

I think the wiki actually advises to have a single ESP and share the Windows generated partition with Arch. Some UEFI implementations have trouble with multiple ESPs and it certainly seems to complicate things unnecessarily (IMO).

abdulrahim-ss wrote:

even the Arch wiki suggests a separate partition for the `/home/` directory in some of its examples! I got the impression that having multiple partitions is better, since if one sector of the drive gets corrupted, some files on the other partitions might be saved, but from what you wrote it seems that it would be better if I had a single partition?

Backups are the answer to corruption :-)

I would always use a single root partition whenever possible (ESP excepted) because I don't see the need for anything else. I've even used a single partition to hold several distributions using btrfs subvolumes to share the space so I don't have to worry about individual partitions running out of space. Keep it simple.

Arch Linux

#1 2025-01-01 00:50:03

Issue with grub and secure boot

#2 2025-01-01 11:32:12

Re: Issue with grub and secure boot

#3 2025-01-01 12:42:55

Re: Issue with grub and secure boot

#4 2025-01-01 12:57:58

Re: Issue with grub and secure boot

#5 2025-01-01 14:07:36

Re: Issue with grub and secure boot

#6 2025-01-01 14:42:24

Re: Issue with grub and secure boot

#7 2025-01-01 14:56:41

Re: Issue with grub and secure boot

#8 2025-01-01 15:10:50

Re: Issue with grub and secure boot

#9 2025-01-01 15:57:32

Re: Issue with grub and secure boot

#10 2025-01-01 16:14:36

Re: Issue with grub and secure boot

#11 2025-01-01 16:21:03

Re: Issue with grub and secure boot

#12 2025-01-01 18:14:40

Re: Issue with grub and secure boot

#13 2025-01-01 18:27:04

Re: Issue with grub and secure boot

#14 2025-01-01 19:11:46

Re: Issue with grub and secure boot

#15 2025-01-01 19:50:09

Re: Issue with grub and secure boot

#16 2025-01-01 21:14:02

Re: Issue with grub and secure boot

#17 2025-01-01 22:36:39

Re: Issue with grub and secure boot

#18 2025-01-01 22:51:27

Re: Issue with grub and secure boot

#19 2025-01-02 01:17:01

Re: Issue with grub and secure boot

#20 2025-01-02 12:08:22

Re: Issue with grub and secure boot

Board footer