How Did You Install Qubes?

From the subject.
Did anyone install Qubes from.the other medium than USB? How?

It’s an ISO file, you shouldn’t have any trouble burning it to a suitably sized bit of optical media and booting/installing from that.

I usualy do the install from “another” processor device. It can be anything like a Music Player with DSP or some Old DVD player etc. I do verify a size at least. You can use Clonezila to get an image from such a device if you want to be more convoluted.

I guess you have internal DVD rom devices…

@enmus already knows about this, but I’m putting it here for anyone else interested:

It creates a Qube called sys-pxe on your existing Qubes OS machine, and turns your ethernet NIC into a DHCP, TFTP, and NFS server, hosting the Qubes OS installer ISO.

You can then essentially plug any other machine that supports network boot into the network that your Qubes machine is on (make sure that you haven’t got another DHCP server on the same LAN, of course), and all machines will essentially boot the Qubes ISO over PXE.

To the end user, the experience is identical to booting as if the Qubes ISO was on a USB flash drive.

You can also specify a Kickstart file, allowing a Qubes OS unattended install.

For more info, check out the thread above (and please contribute if you can :slight_smile: )

@Syonyk, fully agree with what you’re saying, and definitely true.

I’m fairly certain that @enmus wasn’t having difficulty flashing an ISO. I think this thread is more of a brainstorm for creative ways to get Qubes OS on a machine.

Please correct me if I’m wrong, though :slight_smile:

But having said that, there’s definitely a place in this thread for “issues with flashing the ISO onto external media”.

I have always been perplexed by the fact that the Windows tool rufus has an option to alter the partition table of an ISO before flashing it.

I still am not sure why you’d want to change this…

If the creator of an ISO has already gone out of their way to ensure support for both MBR and UEFI, why would you want to mess with it? Why would you not want to copy the ISO exactly as it has been created…? :thinking:

Also, would a “Qubes OS ISO generator” (similar to the Raspberry Pi Imager in the video below) be of any benefit?

Explanation of what the Raspberry Pi Imager is:

Its main use case would be for Windows and MacOS users who have never “popped the hood” on their machines, and otherwise wouldn’t know how to flash an ISO (and verify checksums, check for tampering, etc.), I guess…

Comments, anyone?

@i2p, so you turn your external device into a block device, and attach it to the machine via cable (I’m assuming USB), correct?

That’s an interesting way of doing it. Hiding in plain sight. I like it :wink:

But is there any added benefit of doing it this way, over flashing NAND?

I’ve tried that. You have to use a dual-layered disc (the ISO is about 2-3GB larger than a single-layered disc), and it’s a lot slower than NAND…

Additional Method I have used successfully - Installing Qubes OS, configuring it, and then using dd

When I have multiple units of identical hardware that require additional configuration that a fresh Qubes OS install directly from the ISO doesn’t have (custom firmware, Xorg config files, additional GRUB parameters, etc.), I have gotten a single install configured with everything working “just the way I like it”, and then used dd to completely clone entire hard drives (this takes a while, though, because dd will still copy everything on the drive, including the empty space…).

I mean, are there actually any other ways to install Qubes OS…?

I mean, in order to perform an install, all you really need is:

  • An installation target

    • Can be local, remote, or a mix of the two
    • Can be a physical device, virtual device, image file, or something else (post your suggestions for “something else”)
  • An installation source

    • Can be local, remote, or a mix of the two
    • Can be packages, individual files, or something else (post your suggestions for “something else”)
  • An OS with enough functionality to perform/facilitate the install

    • Loads enough firmware and programs to perform the required functions (copy, erase, compile, etc.)
    • Does not use the drive you want to install Qubes OS on

Any creative suggestions on how else to perform an install, anyone? :slight_smile:

1 Like

i tried external DVD rom device, with ISO file burned on DVD,
but after Heads flashing, apparently Heads cannot boot from external DVD rom device

hi @Insurgo this is to continue the discussion in firmware backdoor ,
about recommended installation for Qubes + Heads laptop.

i remember, i can install Qubes, into Heads laptop, from USB thumbdrive,
without being accompanied by detached pgp signature,
& the installation was success.

so, how to do the recommended installation above ?

does it mean, we need to import QMSK & release signing key, into Heads ?

thanks & best regards,

@newbie something missing from Step 4 - Installing Qubes and other OSes - Heads - Wiki? Or Step 4 - Installing Qubes and other OSes - Heads - Wiki ?

Hey guys. Thanks for being interested in, just to remind you that this topic is How did you, and not How to.

That would be installing qubes 4.1 entry under Step 4 - Installing Qubes and other OSes - Heads - Wiki as referred previously.

This is standard thin LVM pool over LUKSv2 encrypted container, with fedora template used for qubes, Whonix used for updates (dom0, templates) and disposable sys-firewall, sys-usb and sys-net.

@enmus thanks for the friendly reminder.

1 Like

Could you possibly share how did you install Qubes? From the USB stick? I am genuinely interested in this, how to do it most securely today, with modern computers…

Both previous references says that it is directly from iso and detached signature file sitting side by side on an ext3/ext4 partition… I feel people don’t read.

The qubes section also shows, with screenshots, the booting and iso verification process.

@enmus: what is missing there?

1 Like

I guess you could already guess what
Thanks again for repeating in order to be more clear to me. Very nice idea though, while I still have concerns about using USB sticks!

1 Like

Release signing key (public key counterpart) is included in the firmware, as documented under the general section of the same page.

This is how Tails, Arch Linux, Qubes OS can boot directly from and ext3/ext4 formatted drive, if iso and iso.asc/iso.sig detached signature are sitting side by side on the USB thumb drive root directory.

If distros were detach signing their iso (Fedora stopped) those distros could also be booted the same way, at the condition of having their distro signing public key added under Heads and present in booted firmware to be able to verify corresponding detached signatures alongside of downloaded isos.

No magic there, the iso.asc/iso.sig detached signature is validated against the distribution public key that is provided under Heads. This is why Heads can validate both integrity and authenticity of those ISOs, just as their webpages describe to do so manually, but automatically under Heads. And since Heads validates those distribution signing public key as part of Heads firmware measured boot, the user can simply drop newer isos and detached signatures files and boot from them confidently.

Bonus, Qubes daily produced QA builds can also be booted the same way, since that corresponding public key is also under Heads since Maximized builds were merged under Heads.

Well, if you dd an image over USB thumb drive, you loose integrity validation. This is a worry-less alternative approach for Heads users.

Also, you could detach sign an ISO yourself from Heads if the distribution do not provide those

  • verify integrity manually from Heads recovery shell (mount-usb rw, cd /media, sha256sum distrib.iso, verify hashes manually.)
  • detach sign with your own private key (gpg --card-status, gpg --detach-sign distro.iso)
  • Sync changes (cd /, umount /media)
  • boot your own detached signed iso.

That way, you can trust that the iso is as expected prior of booting into it. Those “public” files can sit side by side alongside of other “public” (untrusted) files, where heads will verify them prior of mounting them and boot into them.

1 Like

hi @Insurgo

i compare Qubes distro key in heads github repo,
with Qubes 4.1.1 release signing key ,
it looks similar, but actually are different,

Qubes 4.1.1 release signing key, in Qubes download website,
are longer than Qubes distro key, in heads Github repo.
is it expected, or anything wrong ?

Will try to answer factually, which requires me to redo the process.
As you can see on heads/initrd/etc/distro/keys at master · osresearch/heads · GitHub , the latest time heads/qubes-4.key at master · osresearch/heads · GitHub was touched is linked to commit Separate trusted ISO signers from trusted config signers · osresearch/heads@c1be56c · GitHub which doesn’t give much information on what was applied to the public key to reduce its size 5 years ago.

So let’s attempt to replicate the work done there with tails.key which I had to update 10 months ago heads/tails.key at master · osresearch/heads · GitHub linked to commit tails.key : merging of new long-term signing key with old one so old … · osresearch/heads@7a324bb · GitHub which I left traces for reproducibility under the commit message, pointing to Update Tails public signing distro key (expires on 2022-01-19) by tlaurion · Pull Request #1023 · osresearch/heads · GitHub

So let’s replicate Update Tails public signing distro key (expires on 2022-01-19) by tlaurion · Pull Request #1023 · osresearch/heads · GitHub with qubes distribution public key (release key) and compare things on a dvm:

[user@disp2326 ~]$ cd /tmp
[user@disp2326 tmp]$ mkdir qubes-key
[user@disp2326 tmp]$ cd qubes-key/
[user@disp2326 qubes-key]$ wget
--2022-11-16 12:26:43--
Resolving (, 2604:1380:4601:1c00::1
Connecting to (||:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2379 (2.3K) [application/octet-stream]
Saving to: ‘qubes-release-4-signing-key.asc’

qubes-release-4-sig 100%[===================>]   2.32K  --.-KB/s    in 0s      

2022-11-16 12:26:44 (49.2 MB/s) - ‘qubes-release-4-signing-key.asc’ saved [2379/2379]

[user@disp2326 qubes-key]$ gpg --home /tmp/qubes-key/ --import qubes-release-4-signing-key.asc 
gpg: WARNING: unsafe permissions on homedir '/tmp/qubes-key'
gpg: keybox '/tmp/qubes-key/pubring.kbx' created
gpg: key 1848792F9E2795E9: 1 signature not checked due to a missing key
gpg: /tmp/qubes-key/trustdb.gpg: trustdb created
gpg: key 1848792F9E2795E9: public key "Qubes OS Release 4 Signing Key" imported
gpg: Total number processed: 1
gpg:               imported: 1
gpg: no ultimately trusted keys found
[user@disp2326 qubes-key]$ gpg --home /tmp/qubes-key/ --edit-key 1848792F9E2795E9 
gpg: WARNING: unsafe permissions on homedir '/tmp/qubes-key'
gpg (GnuPG) 2.3.7; Copyright (C) 2021 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

pub  rsa4096/1848792F9E2795E9
     created: 2017-03-06  expires: never       usage: SC  
     trust: unknown       validity: unknown
[ unknown] (1). Qubes OS Release 4 Signing Key

gpg> minimize
User ID "Qubes OS Release 4 Signing Key": 1 signature removed

pub  rsa4096/1848792F9E2795E9
     created: 2017-03-06  expires: never       usage: SC  
     trust: unknown       validity: unknown
[ unknown] (1). Qubes OS Release 4 Signing Key

gpg> quit
Save changes? (y/N) y
[user@disp2326 qubes-key]$ gpg --home /tmp/qubes-key/ --export --armor 1848792F9E2795E9 > qubes-release-4-signing-key_mod.asc
gpg: WARNING: unsafe permissions on homedir '/tmp/qubes-key'
[user@disp2326 qubes-key]$ wget
--2022-11-16 12:31:22--
Resolving (,,, ...
Connecting to (||:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1629 (1.6K) [text/plain]
Saving to: ‘qubes-4.key’

qubes-4.key         100%[===================>]   1.59K  --.-KB/s    in 0.001s  

2022-11-16 12:31:22 (1.58 MB/s) - ‘qubes-4.key’ saved [1629/1629]

[user@disp2326 qubes-key]$ ls -al 
total 72
drwxr-xr-x  3 user user   200 Nov 16 12:31 .
drwxrwxrwt 13 root root   320 Nov 16 12:29 ..
drwx------  2 user user    40 Nov 16 12:27 private-keys-v1.d
-rw-r--r--  1 user user  1312 Nov 16 12:29 pubring.kbx
-rw-r--r--  1 user user  1890 Nov 16 12:27 pubring.kbx~
-rw-r--r--  1 user user  1629 Nov 16 12:31 qubes-4.key
-rw-r--r--  1 user user  2379 Feb  8  2022 qubes-release-4-signing-key.asc
-rw-r--r--  1 user user  1611 Nov 16 12:30 qubes-release-4-signing-key_mod.asc
-rw-r--r--  1 user user 49152 Nov 16 12:29 tofu.db
-rw-------  1 user user  1200 Nov 16 12:27 trustdb.gpg

So we see that the 3 keys are different.

Let’s see how/why, comparing heads downloaded key with the one we just generated:

[user@disp2326 qubes-key]$ diff qubes-4.key qubes-release-4-signing-key_mod.asc
< Version: GnuPG v1

Basically, the generated one is the same as the old one, without the GPG v1 header and is considered equal.

Then lest’s compare heads downloaded one with the one coming from Qubes OS website:

[user@disp2326 qubes-key]$ diff qubes-4.key qubes-release-4-signing-key.asc 
< Version: GnuPG v1
< mqH0I+V+LuMtlE521YHKg0tsB9GVlfWBS10=
< =QN1j
> 8Bzd+ho+NoeUlAUCYaQmlwAKCRDd+ho+NoeUlB40D/0YwLGqX5O6tl/q0Vehud2N
> mm5OIpxSZKrpm8vNtf2/rzumBldFSczCtVAkHo4N23hC+IGKHSG7lFZlFue/cng0
> ngopJsfhbj8eAbtdo9lqiqQaiFtUrB8hTd1HgvHjCptBKrSKn4FlJJ91ypLkoyiX
> 27TcfToyEq6qFAWKXXQosYtCzh492WlD7GXXz32/1LnZKMS3TR4x+QfVRc9kn8X5
> HaempDgWw79d7ZAcSDuO4Kb2j/se4aLESTefKtJJ9LuPqhHZ+qGekUCyweiZ+mkR
> ok6XcaOHJEJgsvG1DIGwrGXyKkvqi12W8Q95XAF7y7C98vq4cVyhiLrBCbdgMY4X
> l9vHXIVEL3C032qu4AaeJ2tHZJvl1+nYqam8urQ/APk6pPVs75+IkH7zDfEHh+SF
> m6xAg/0fMKhYDlXB7l3UbiioV8vhBlHEf4XFR/VnnqM1B1TwdjywAbenc9Ev45L0
> 5oqfrerACvYMxUxQVR0WQyrsLjJzinKZjjZW5KYiRn9lO+27rp1kMQHQFhNX1pnj
> oVnJIi0AtwAXumKI78SQpVRMjj6+fqusI/1Zx63XcI9Y8BBZvssYscgt2c9oMtBT
> B/Ng9EaplpSSVCsdcN85VAR7CZT5YPsvsMzSmmUUIRoEb/dHMuMmh0YbBJbBUikP
> dcBETivefvOIZRjSyZYUTg==
> =6A62
[user@disp2326 qubes-key]$

Or more visually through meld:

Basically, gpg “minimize” operation of the key removed an additional signature (the release key being signed externally) which can be seen:

[user@disp2326 qubes-key]$ gpg --home /tmp/qubes-key/ --import qubes-release-4-signing-key_mod.asc
gpg: WARNING: unsafe permissions on homedir '/tmp/qubes-key'
gpg: key 1848792F9E2795E9: "Qubes OS Release 4 Signing Key" not changed
gpg: Total number processed: 1
gpg:              unchanged: 1
[user@disp2326 qubes-key]$ gpg --home /tmp/qubes-key/ --import qubes-release-4-signing-key.asc 
gpg: WARNING: unsafe permissions on homedir '/tmp/qubes-key'
gpg: key 1848792F9E2795E9: 1 signature not checked due to a missing key
gpg: key 1848792F9E2795E9: "Qubes OS Release 4 Signing Key" 1 new signature
gpg: Total number processed: 1
gpg:         new signatures: 1
gpg: no ultimately trusted keys found

Under Heads, we keep only the public key used to verify the detached signature. Any other signee which signed the key is not important, since the validity is already considered “trusted” per Heads committer (which signed his commit) and we try to reduce the size of the public key that are injected in the firmware, removing bloating stuff.

This is not really important in the gained size for Qubes release public key, but as can be seen for tails.key, not having applied gpg’s minimize on their ditrribution signing key (release public key) would have bloated us of 2191 additional signee, basically saying that recognisez the validity of the public key by apposing their signatures to it… We do not need that.

In short: Heads simply applied the same minimizing policy to all public key included in the firmware to limit bloating. Public keys are basically high entropy blobs, and are not compressed as part of Heads initrd packing otherwise. And since space is precious, anything that can be removed is removed :slight_smile:

And if we wanted to replicate the process without the warnings of keys, we would have to follow Verifying signatures | Qubes OS to get rid of the warnings above and add trust to Qubes master key, which is actually the signee we removed from qubes-4.key by above process, and explains the difference in size of the file uploaded under Heads github and used to verify detached signed iso!

1 Like

i see, okay, thanks for information @Insurgo

by the way, since you know a lot about heads, are you part of Heads development ?
i also see, apparently you add verifying installation into Heads documentation.

also, i tried to USB boot from external DVD,
but apparently Heads can only recognize USB thumb drive,
is it possible, for Heads, to USB boot from external DVD ?

if i understand correctly,
the release signing key, under Heads, will be used to verify detached PGP signature,
then the detached PGP signature, will be used to verify Qubes ISO. is it correct ?
but what i don’t understand is, whether it is done automatically by Heads ?
or we have to do it manually in the Heads recovery shell ?

in case the verification fails, will Heads give us kind of warning ?
i.e. release signing key under Heads, fail to verify detached PGP signature, in the media,
or detached PGP signature, fail to verify the ISO.

and then, in case the USB thumb drive we use is infected / compromised,
will it infect heads ?

thanks and regards,

@deeplow: please split the topic from here

It’s about Heads