Qubes 3.2 UEFI install media

1,757 views
Skip to first unread message

Dave C

unread,
Jun 26, 2017, 2:29:36 AM6/26/17
to qubes-users
I recently had some success install Qubes 3.2 on a lenovo p51, booting UEFI. I went through a lot of a trial and error in the process. I'm hoping this post can save others some time. I've seen in other threads some struggling to get Qubes working with UEFI firmware.

I intended to save my command history to disk so that I could post step-by-step exactly what to do. But I must have been in a dispvm at the time, because now I can't find that history. So the following is from memory and not precise.

I tried every trick I could find related to Qubes UEFI installation, and thinkpad troubleshooting. What finally worked does not appear to be documented in any of the Qubes documentation. Qubes uses Fedora's installer, Anaconda, and the following approach is documented on Fedora's wiki.

1. Follow Qubes install guide up to the `dd` command. Don't write to usb with `dd`.
https://www.qubes-os.org/doc/installation-guide/

2. Instead, use Fedora's `livecd-iso-to-disk` tool. You'll need the `livecd-tools` package. See https://fedoraproject.org/wiki/How_to_create_and_use_Live_USB#Command_line_method:_Using_the_livecd-iso-to-disk_tool_.28Fedora_only.2C_non-graphical.2C_both_non-destructive_and_destructive_methods_available.29

I don't recall for certain exactly what I passed to `livecd-iso-to-disk`. Try this:

sudo livecd-iso-to-disk --efi --format Qubes-R3.2-x86_64.iso /dev/xvdi

The media as written will not quite boot, yet. Qubes EFI boot is configured to find a label "Qubes-R3.2-x86_64", but the media written by the livecd tool is labelled "BOOT" (and the filesystem does not support the longer label, so the --label option would not help).

3. Mount the usb media (/dev/xvdi in the example above)

4. Edit xen.cfg. If I recall correctly, `<mount>/EFI/BOOT/xen.cfg`.

In this file, replace every occurrence of `LABEL=Qubes-R3.2-x86_64` with `LABEL=BOOT`

You should now have install media that work on UEFI firmware!


After install, I recommend upgrading kernel version for recent hardware. I.e. with

sudo qubes-dom0-update --enablerepo=qubes-dom0-unstable kernel kernel-qubes-vm


Stephan Marwedel

unread,
Jul 10, 2017, 12:46:38 PM7/10/17
to Dave C, qubes-users
Thanks for this interesting hint. Following your detailed instructions I
was able to create a bootable media that correctly boots on my Thinkpad
in UEFI mode. However, when the kernel finished loading, an emergency
shell appears and the following messages are displayed:

Starting Dracut Emergency Shell...

Warning: /dev/root does not exist

Entering emergency mode

It seems that the kernels loads OK, but is unable to find a root
filesystem to mount. As I do not have Qubes currently installed on my
machine, I am unsure about how to specify a root filesystem. The only
valid root filesystem is the one on the installation media, but that
should be found automatically. Or is it necessary to specify it manually?

Regards,
Stephan

Stephan Marwedel

unread,
Jul 11, 2017, 4:49:20 AM7/11/17
to Dave C, qubes-users
I was able to determine the cause of the problem. After having changed
the label by editing xen.cfg as described the following needs to be done
in addition before the media can be used on an UEFI system to install Qubes:

5. Unmount the USB media, but leave it connected to the machine.
Assuming that the USB device is named /dev/xvdi, execute the following
command:

dosfslabel /dev/xvdi1 BOOT

This creates a label name that the UEFI bootloader uses to identify the
root image. Now the media can be used to install Qubes 3.2.

tani.la...@gmail.com

unread,
Jan 13, 2018, 7:38:37 AM1/13/18
to qubes-users

Thanks a lot Dave C and Stephan Marwendel. By following both of your instructions I got the installation working on my Lenovo ThinkPad Yoga 460!

stan00...@gmail.com

unread,
Mar 16, 2018, 9:38:14 AM3/16/18
to qubes-users

Hi, I have one question (I am pretty new).
By doing dosfslabel /dev/sdb1 BOOT Im getting the following message:

There are differences between boot section and its backup.
This is mostly harmless. Differences: (offset:original/backup)
--many numbers--
Not automatically fixing this.

Can I just ignore this message ? Or what can I do to fix it ?

Reply all
Reply to author
Forward
0 new messages