Arch Linux

deians

Member

Registered: 2026-08-21

Posts: 1

Setting up Secure Boot with Arch on a seperate NVME drive

Hi,

The question come further down, and it's all because of my specific setup, I've read the Arch Wiki on the Secure Boot and the process, but I'm still confused a bit, so before I mess up, I just want to confirm what I've read so far and check if what I've understood is right...

I have a HP Envy x360 AMD Radeon that had Windows 10 (then 11) so has the whole Secure Boot thing as expected these days.
My laptop only has one NVME slot. I bought an identical NVME to put Arch on it to keep it simple.
So I had to disable Secure Boot in the BIOS to install it. Cool, no problem. Job done. Arch installed. Happy.
But swapping the NVME's to boot back to Windows (for whatever reason) means I have to switch Secure Boot back on or I have to enter my BitLocker key to unlock it, fine whatever, I have the BitLocker key so I can boot Windows with Secure Boot On or Off.
So Arch in installed on this new physically separate NVME. I'm happy and comfortable with Arch, everything works, Plymouth works, my Logitech Master MX3 works, etc.
I was under the impression I was supposed to reenable Secure Boot after installing Arch. It doesn't seem to work. So Secure Boot is still disabled for now.
Next on my list is to harden Arch up a bit. It means getting Secure Boot working. I now know I need encrypted partitions, but I will do that later (I believe it's a pre-requisite of Secure Boot on Linux).

Anyway the questions:

1. Where are the 'actual' Security Keys kept? Are they stored on the TPM or BIOS chip or something? I'm asking because when I put 'Secure Boot' back on, it doesn't let me boot up even though I'm booting from a different NVME. So I'm not understanding something here.

2. Am I right in understanding that my Linux entry in 'Grub.cfg' needs to pick up some existing stored Security Keys? Or is it needed in the initram file that mkinitcpio generates? Please correct me if I'm still wrong... I assume the 'Security Key' that's saved somewhere in TPM/BIOD is the one BitLocker decrypts against if I boot the other Widnows NMVE with Secure Boot off (and with 'Secure Boot' back on, it does this all automatically without the BitLocker key, does that even make sense?). So is this they the case even if I'm using a separate NMVE drive?

3. Am I supposed to pick up the existing Security Key (presumably the one that HP/Microsoft setup from factory) from where ever it is stored, or tell Linux about it, so I can then put Secure Boot back on?

4. If I follow the Arch Wiki guide on setting up Secure Boot for my Arch setup (on a physically separate NVME drive to the windows one) can I still have both keys in wherever they are stored and point each OS to the relevant security key? If I do this will the Windows NVME be able to find it's old one if I make a new key for Arch to use?

5. Can I even read any existing security keys that might have been setup by Microsoft/HP when they did the initial factory image? If so, should I back it up and could I then restore it if I need to use Windows again next time.

6. If I wipe any existing security keys from the old Windows setup because I can only use one security key at a time (which I believe is the case), and then setup a new key to use for Arch only. Would I then just need to disable secure boot again to boot Windows back up using the BitLocker key? Or would the that not even work again?

Am I understanding enough so far? Or am I completely on the wrong path? I'm so confused to be honest. If answering all of the above is too much work, could someone send me to an useful link that puts it all together for me (for my setup)?

Thanks so much in advance. Looking forward to the replies.

Deian

V1del

Forum Moderator

Registered: 2012-10-16

Posts: 25,388

Re: Setting up Secure Boot with Arch on a seperate NVME drive

Disk encryption and secure boot have no relation to each other and one doesn't mandate the other and vice versa. (but it would make "sense" to combine the two, as someone taking out your harddrive could read the data on it without disk encryption)

Secure boot is to verify your boot chain, i.e. once enabled your UEFI will only boot binaries whose keys it knows about, which by default will be Microsofts keys for booting Windows. A "normal" Arch install will have nothing signed so secure boot will reject starting grub and in turn the linux kernel.

You probably want to read https://wiki.archlinux.org/title/Unifie … ecure_Boot and some of the links linked in that very top section, they will explain this in more detail. And definitely read the rest of it for ultimately setting this up, maybe a general refresher on UEFI via https://wiki.archlinux.org/title/Unifie … _Interface is also helpful.

That said while you should use those resources to inform you in more detail I'll give some pointers to your list

1. In NVRAM, which is a storage all modern UEFIs have for boot relevant information including secure boot keys

2. Yes and no, there are setups where you can use MS keys but it's also possible to generate your own and have them coexist, the majority of UEFIs will support that, if very unlucky you have a bad UEFI that can only store MS own keys. HP "should" be unproblematic from what I've seen. The bitlocker key has no direct relation to secure boot but yes that one will come from the TPM, but secure boot and the bitlocker key are two different things that are not directly related

3. You could, there are methods of using bootloaders or rather shims that have been signed by Microsoft, but it's not strictly required you can also generate your own

4. Yes, the keys have no relation to your disk drives, but to the EFI binaries that will be ran, the UEFI will compare them against it's internal database

5. Yes and it's reccommended to back them up, the secure boot article on the wiki will go over this

6. As mentioned you can and should have multiple keys and if not, you'd definitely not want to wipe the ones from Microsoft if you intend to secureboot windows

The arch wiki will go into more detail, but I'd reccommend you look at the sbctl tool that will also be mentioned there, it makes most of these tasks including ensuring Windows compat and signing your other pieces of the install comparatively trivial.

Last edited by V1del (2026-08-22 14:46:34)