UEFI Dual Booting Debian encrypted LVM + Qubes encrypted BTRFS on GPT

I got a new laptop with nothing on it. Debian has been my go to OS so far, but want to transition to Qubes(4.1 w/KDE) and while i test/learn/setup Qubes so i can continue working on my Debian and can have it as backup if i have issues with Qubes.

I have been doing a lot of research on this, but nothing i find is concrete or is conflicting or requires Legacy/UEFI mix setup.

My understanding of the setup process so far as per Community/contents/docs/configuration/multiboot and Dual-booting Qubes and Ubuntu with Encrypted Disks :

  1. Install Debian first with /boot & encrypted LVM. But, /boot here has to be EFI since i’m installing on a brand new SSD on a UEFI system.
  2. Then install Qubes on the remaining free space. But then where does the /boot for Qubes go other thant the same /boot that was created for Debian? And it is advised against to have them both on the same /boot partition.

Laptop specs:

  • Intel Iris Xe Graphics G7
  • Intel Core i7-1165G7
  • 32 GB DDR4-3200 Samsung
  • 2TB 510 Seagate Firecuda

I am confused and would greatly appreciate if anyone can help lay out a clear path to achieve this.

Thank you

there 2 things named /boot, i think you mean /boot partition (aka ufi partition)
it shared with debian and almost any other os you if install on same disk

Keep in mind that Micah Lee link from 2014 is for a BIOS/MBR install; UEFI/GPT is a different story.

Background -

On an UEFI-booted system, there is the EFI System Partition (ESP). This is a FAT32 partition that stores the EFI bootloaders (*.efi) for the installed operating system(s). When your computer boots, the UEFI BIOS will look for the ESP and execute the .efi file that is configured according to the boot order. The ESP is typically small and only contains .efi files. There is(or should be) only one ESP on a given disk.

The files actually needed to load the operating system are stored on a “boot” partition. In the case of Debian or typical linux distributions, the boot partition contains the linux kernel and initial ramdisk files at minimum. In the case of Qubes OS, the boot partition also contains the Xen hypervisor.

With Qubes R4.1, Qubes will install the GRUB2 bootloader as grubx64.efi to the ESP. The GRUB2 EFI loader references the grub.cfg file to figure out what to do next. grub.cfg tells the loader where to find Qubes’ “boot” partition, and to load Xen, the linux kernel, and the initial ramdisk and execute them. Once the linux kernel executes, it relies on the initial ramdisk to unlock the big partition with all your encrypted data and subsequently mount the “root” filesystem to access all the rest of your programs and data.

Therefore a typical Qubes R4.1 install on an UEFI booted system with GRUB2 consists of:

  • EFI System Partition (ESP): grubx64.efi, grub.cfg, other OS .efi files
  • “boot” partition: Xen, kernel, initramfs/initrd
  • “root” partition: most of your data, generally LUKS-encrypted

Assuming your system has booted up fully, the mountpoints look like this:

/          (root partition)
/boot      (boot partition)
/boot/efi  (ESP)

If you simply wanted to add another (GNU/Linux) operating system, you’d have another root partition, another boot partition, and an additional .efi bootloader file installed to the ESP. This would mean your disk would have 5 partitions, for example:

/dev/sda1   (ESP, Qubes' \EFI\qubes\grubx64.efi, Debian's \EFI\debian\grubx64.efi)
/dev/sda2   (Qubes OS boot partition)
/dev/sda3   (Qubes OS LUKS-encrypted root partition)
/dev/sda4   (Debian boot partition)
/dev/sda5   (Debian LUKS-encrypted root partition)

In theory, you could consolidate both boot partitions into one, but this is not recommended since you’d want to keep the different OS’s isolated as possible considering you’ve accepted the risk of dual booting. To reinforce, dual booting is not recommended because let’s say you run malware while Debian is up. It could overwrite anything in the ESP or Qubes’ boot partition, essentially performing an “evil maid” attack, capturing your disk passphrase. The same can be said for Qubes overwriting Debian, though the barrier is higher if the threat we’re talking about is “malware from the internet”, or “I ran a command under Debian but accidentally specified the wrong partition and now Qubes doesn’t boot”.

Once you have all the partitions and OS’s installed, you have to worry about how you boot each OS. UEFI makes this a lot easier as you can use efibootmgr to install the correct entries into your UEFI BIOS nvram. As long as you have one entry pointing to Qubes’ grubx64.efi and another entry pointing to Debian’s grubx64.efi, make Qubes the default, and use your BIOS’ boot menu hotkey to run Debian.

You can get fancy and chainload the Debian GRUB2 .efi from Qubes’ GRUB menu, but I’ll leave that as an exercise for the reader since it gets into having one OS know about the other.


Thank you @icequbes1 for the detailed reply. This cleared a lot of confusion i had, though i still have quite a bit to figure out.

Yes, i was stuck because i couldn’t figure out the steps for UEFI.

From what i understand after your wonderful explaination, following would be my procedure on a fresh SSD:

Step 1: Install Debian

  • Partitions:
/dev/sda1  ESP
/dev/sda2  /boot     (unencrypted)
/dev/sda3  LUKS LVM:
                    /      root
                    /home  home
                    /swap  swap
  • Install GRUB normally

Debian should be installed.

Step 2: Install Qubes

/dev/sda4 /boot (unecrypted)
/dev/sda5 LUKS BTRFS
          - swap
          - btrfs subvolume group:
             - @
             - @home
             - @snapshots
  • Install grub normally for Qubes

This should be a straight forward install and should work, right?


  1. Is it recommended to install Qubes first then Debian (or other linux) or the other way round? Theoretically that shouldn’t matter, right?
  2. Would having Qubes on BTRFS create issues? My current understanding is that having an encrypted BTRFS is quite tricky. I would highly appreciate a good installation guide on that because every guide i’ve tried so far (mainly paritybit.ca guide, PopOs by Willi Mutschler and many other guides for references) i have failed and i have spent days trying to get it to work and given up, but i really want to be on BTRFS.
  3. Theoretically, having Debian on LVM+ext4 shouldn’t be a problem. Correct?
  4. Havind Debian on BTRFS as well should be straight forward as well?

Following Micah Lee’s instructions chainloading is required since we are installing on Legacy BIOS and after Qubes install, it cannot see the previously installed OS. Hence, we need to add the boot entry for the previously installed OS to /etc/grub.d/40_custom. But, isn’t this the workaround because of Legacy BIOS and that UEFI should eliminate this because we’d still want to keep both OS /boot separate and EFI should solve this as it has both bootloaders installed and knows the path to boot the OSes from their respective /boot partitions?

Again, thank you very much

for more advanced technique check this out Qubes OS Installation - BTRFS w/ Detached encrypted boot and header

I haven’t try to dual boot with same disk, but from my perspective, you don’t need to worry about grub configuration, because you use uefi and when pc boot up, you are loading uefi boot entries, then proceed to grub.

1 Like

It shouldn’t matter, though the latest OS that is installed might set itself as the default startup EFI entry. Use efibootmgr to modify this if there’s no easy way to do so within the BIOS setup.

I can’t provide a step-by-step guide, as I am not a master of the guided GUI installation, but it is possible strictly through the GUI.

If you reference @51lieal’s how-to, you’ll see that if you perform the partitioning and filesystem configuration yourself, then direct the GUI towards the right mount points, that will also work.

For both Qubes and Debian, you’ll have to tell it the ESP, which will be the same partition. After that, each OS should operate with its own partitions / LUKS-encrypted LVM / btrfs volumes.

I don’t see why it would be, but it’s up to you to define what “a problem” is.

Same answer as previous, as “straightforward” could mean various things to various people.

Chainloading was needed with an MBR-labeled disk as there was only one Master Boot Record per disk. The BIOS doesn’t know anything about partitions so it cannot create a boot menu that says “boot /dev/sda1” vs “boot /dev/sda2”. If a computer already had Windows and was made to dual-boot linux by installing GRUB to the MBR, it was not uncommon to get the MBR (with GRUB) wiped out by Windows after a Windows update. With UEFI, the shared ESP eliminates this, as the UEFI firmware simply needs to be told which .efi loader to execute.

My goal with providing background is to demonstrate how your partitions might look at the end, but you might have to “hack” at it to get it exactly how you want. There has never been a time where I’ve installed an OS perfectly how I wanted on the first try. If the system is already empty with no data, you only have everything to gain by making attempts and learning in the process.

Considering dual-boot is not recommended for a secure Qubes installation, it’s in your best interest to fully understand which partitions are which, and where the weak points are.

1 Like

That is exactly how it happened. The problem though is that Qubes installation didn’t recognize the already existing ESP and insisted on creating one. This resulted in my SSD effectively being interpreted as 2 different disks and one OS doesn’t recognize the other.

$ lsblk
nvme0n1             259:0    0   1.8T  0 disk  
├─nvme0n1p1         259:1    0   953M  0 part  /boot/efi  # created on Debian install
├─nvme0n1p2         259:2    0   954M  0 part  /boot      # Debian
├─nvme0n1p3         259:3    0 119.2G  0 part             # Debian LVM
│ └─nvme0n1p3_crypt 254:0    0 119.2G  0 crypt 
│   ├─db-swap       254:1    0   7.4G  0 lvm   [SWAP]
│   ├─db-root       254:2    0  18.6G  0 lvm   /
│   └─db-home       254:3    0  93.1G  0 lvm   /home
├─nvme0n1p4         259:4    0     1G  0 part         # Qubbes /boot
├─nvme0n1p5         259:5    0   3.9G  0 part         # Qubes swap
└─nvme0n1p6         259:6    0   1.7T  0 part         # Qubes /

BUT, there’s only 1 ESP partition which probably is created by Qubes as the default boot priority is Qubes.It does recognize Debian won’t give me a Grub boot entry. This probably means i should edit grub in Qubes dom0:

# ran from Debian
$ efibootmgr -v
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0003,0001,0000,2001,2002,2003
Boot0000* Linpus lite   HD(1,GPT,070151d1-cdc3-414b-b3ee-25e84bb2c862,0x800,0x1dc800)/File(\EFI\Boot\grubx64.efi)RC
Boot0001* debian        HD(1,GPT,070151d1-cdc3-414b-b3ee-25e84bb2c862,0x800,0x1dc800)/File(\EFI\debian\shimx64.efi)
Boot0003* Qubes OS      HD(1,GPT,070151d1-cdc3-414b-b3ee-25e84bb2c862,0x800,0x1dc800)/File(\EFI\qubes\grubx64.efi)
Boot2001* EFI USB Device        RC
Boot2003* EFI Network   RC

Grub in Debian doesn’t give Qubes entry:

# /etc/defaut/grub
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`

This seems like the problem described in UEFI troubleshooting | Qubes OS #Installation finished but “Qubes” boot option is missing and xen.cfg is empty / Installation fails with “failed to set new efi boot target” where in step 3 i’m not sure what the filesystem locations for following line will be since i’m on BTRFS not LVM.

kernel=vmlinuz-4.4.14-11.pvops.qubes.x86_64 root=/dev/mapper/qubes_dom0-root rd.lvm.lv=qubes_dom0/root rd.lvm.lv=qubes_dom0/swap i915.preliminary_hw_support=1 rhgb quiet

Steps taken in Debian to fix grub to see Qubes:

  • ran update-grub
  • ran efibootmgr -o to make Debian the first entry
  • ran os-prober - didn’t find Qubes

Couldn’t figure out how to fix grub in Qubes since update-grub: command not found and creating menuentry in /etc/grub.d/40_custom is for MBR not EFI.

For anyone has trouble creating boot option, this is my successful command in NVME disk
efibootmgr -v -c -u -L Qubes -l '\EFI\qubes\grubx64.efi' -d /dev/nvme0n1 -p 1 "placeholder /mapbs /noexitboot"