Install fails on EFI from USB - 'Device not in tree' error during disk set up

[mattwillsher]

Qubes OS version (e.g., R3.2):

R4.0-RC1

Affected TemplateVMs (e.g., fedora-23, if applicable): N/A

---

Expected behavior:

Disk partition completes on UEFI system booting from USB

Actual behavior:

Error show in https://bugzilla.redhat.com/show_bug.cgi?id=1383873 appears, installation cannot continue

Steps to reproduce the behavior:

Happens each boot. Underlaying issue is unclear.

General notes:

---

Related issues:

[mex20]

Can you tell us a little bit more about your set up? What hardware do you have this issue on (if laptop then make/model and if desktop which mother board, CPU, type of storage medium). What boot options are you using to boot the USB stick? Is the bugzilla link you provided the actual logs from your installation attempt(s)? Also have you tried to use any of the UEFI troubleshooting work arounds to solve this issue?

The more information that you give, the easier it will be to pinpoint the issue.

[mex20]

Can you tell us a little bit more about your set up? What hardware do you have this issue on (if laptop then make/model and if desktop which mother board, CPU, type of storage medium). What boot options are you using to boot the USB stick? Is the bugzilla link you provided the actual logs from your installation attempt(s)? Also have you tried to use any of the UEFI troubleshooting work arounds to solve this issue?

The more information that you give, the easier it will be to pinpoint the issue.

[aidancully]

I ran into the same issue, Librem 15 rev 2, 32GB RAM 1TB SSD storage, trying to install QubesOS 4.0RC3 from flash. I am more than willing to help debug the issue.

[aidancully]

I ran into the same issue, Librem 15 rev 2, 32GB RAM 1TB SSD storage, trying to install QubesOS 4.0RC3 from flash. I am more than willing to help debug the issue.

[tikums]

I can confirm the same on QubesOS 4.0RC4 fresh install. There seems to be no way to bypass this bug, therefore the installation fails.

[tikums]

I can confirm the same on QubesOS 4.0RC4 fresh install. There seems to be no way to bypass this bug, therefore the installation fails.

[airedalesoftware]

Experiencing the same issue here on a late-model premium laptop with xeon processor, 64GB RAM, Samsung 500GB nvme, installing Qubes 4.0 RC4, from Easy 2 Boot flash drive, 16GB. It is actually a micro SD card in a usb 3.0 adapter, if that helps.
Just for confirmation, tried the same install with same media on completely different system: a 2012 era Fujitsu T902 with 16GB RAM and a core i5 processor, with a Samsung 250gb SSD.
Also tried using a USB 2 port on the t902 rather than a USB 3 port, as this sometimes causes interference.

Am able to get to the install stage where a target drive is selected. Once a drive is selected, and the "Done" button is pressed, after a few seconds an error window pops up: An unknown error has occurred. The only remedy is to debug or quit, and of course Quit means starting the installation over.

The callstack pop trace begins with:

File "/usr/lib/python3.5/site-packages/blivet/devicetree.py", line 184, in _remove_device raise ValueError("Device '%s' not in tree" % dev.name)

It appears that this error has nothing to do with the target drive, but is instead referencing the flash drive from which it is running. The storage log drive ref for this 16GB matches the drive that is causing the failure in the anaconda log, or perhaps more precisely the drive into which the ISO is uncompressed.

Also tried "I will configure partitioning" radio button selection instead of the automatic partitioning default, with same result. Not that it should have mattered, just an FYI. And last, it doesn't matter whether the target drive selected is full or clean. Tried on both. Again, not that it matters.

I saved off the following logs from the tty if you are interested. I would be happy to provide them via upload or email rather than pasting them here in their entirety:
anaconda.log
boot.log
program.log
storage.log

[airedalesoftware]

Experiencing the same issue here on a late-model premium laptop with xeon processor, 64GB RAM, Samsung 500GB nvme, installing Qubes 4.0 RC4, from Easy 2 Boot flash drive, 16GB. It is actually a micro SD card in a usb 3.0 adapter, if that helps.
Just for confirmation, tried the same install with same media on completely different system: a 2012 era Fujitsu T902 with 16GB RAM and a core i5 processor, with a Samsung 250gb SSD.
Also tried using a USB 2 port on the t902 rather than a USB 3 port, as this sometimes causes interference.

Am able to get to the install stage where a target drive is selected. Once a drive is selected, and the "Done" button is pressed, after a few seconds an error window pops up: An unknown error has occurred. The only remedy is to debug or quit, and of course Quit means starting the installation over.

The callstack pop trace begins with:

File "/usr/lib/python3.5/site-packages/blivet/devicetree.py", line 184, in _remove_device raise ValueError("Device '%s' not in tree" % dev.name)

It appears that this error has nothing to do with the target drive, but is instead referencing the flash drive from which it is running. The storage log drive ref for this 16GB matches the drive that is causing the failure in the anaconda log, or perhaps more precisely the drive into which the ISO is uncompressed.

Also tried "I will configure partitioning" radio button selection instead of the automatic partitioning default, with same result. Not that it should have mattered, just an FYI. And last, it doesn't matter whether the target drive selected is full or clean. Tried on both. Again, not that it matters.

I saved off the following logs from the tty if you are interested. I would be happy to provide them via upload or email rather than pasting them here in their entirety:
anaconda.log
boot.log
program.log
storage.log

[airedalesoftware]

I found a workaround. Maybe it will work for others.

My solution was to get the ISO as close to the hardware as I could, from a windows base machine. So, I downloaded rawrite32 and loaded up the same micro SD card with the bootable version 4.0 RC4 ISO, reformatting and thus overwriting E2B. The qubes installation guide recommends Rufus for creating the flash drive from windows. After my success with rawrite, I reburned the drive with rufus, but didn't test it. I can say that the two methods produce a bootable USB that look close enough to be indistinguishable. I prefer rawrite because it checks hashes when it loads the ISO for burning.

This allowed me to get past the "installation destination" spoke in the Qubes anaconda hub that was erroring out, and caused the very next step of the installation (choose a drive encryption password) to appear as it should. There were other issues, but none that seemed related to this particular bug report.

One issue I ran into that you may run into was on bootup - before the anaconda hub even loaded - the installer repeatedly recursed over this error:
reset superspeed USB device...using xhci_hcd

I just let it keep going and after about 15 minutes of this behavior it went past it and gave a successful installation. It seems the installer didn't like the fact it was loading over USB 3.0.

The reason I abandoned E2B is because it was formatting the flash drive with the NTFS file system. Based on the log data I studied, it appeared this may have contributed to the problem. Even so, this is a known bug in python/blivet/fedora.
Fedora incorporated a fix for this issue, in Fedora 26 and up.

Perhaps Qubes RC4 is using an earlier Fedora version or v26 build?

[airedalesoftware]

I found a workaround. Maybe it will work for others.

My solution was to get the ISO as close to the hardware as I could, from a windows base machine. So, I downloaded rawrite32 and loaded up the same micro SD card with the bootable version 4.0 RC4 ISO, reformatting and thus overwriting E2B. The qubes installation guide recommends Rufus for creating the flash drive from windows. After my success with rawrite, I reburned the drive with rufus, but didn't test it. I can say that the two methods produce a bootable USB that look close enough to be indistinguishable. I prefer rawrite because it checks hashes when it loads the ISO for burning.

This allowed me to get past the "installation destination" spoke in the Qubes anaconda hub that was erroring out, and caused the very next step of the installation (choose a drive encryption password) to appear as it should. There were other issues, but none that seemed related to this particular bug report.

One issue I ran into that you may run into was on bootup - before the anaconda hub even loaded - the installer repeatedly recursed over this error:
reset superspeed USB device...using xhci_hcd

I just let it keep going and after about 15 minutes of this behavior it went past it and gave a successful installation. It seems the installer didn't like the fact it was loading over USB 3.0.

The reason I abandoned E2B is because it was formatting the flash drive with the NTFS file system. Based on the log data I studied, it appeared this may have contributed to the problem. Even so, this is a known bug in python/blivet/fedora.
Fedora incorporated a fix for this issue, in Fedora 26 and up.

Perhaps Qubes RC4 is using an earlier Fedora version or v26 build?

[andrewdavidwong]

Perhaps Qubes RC4 is using an earlier Fedora version or v26 build?

Yes, 4.0 uses Fedora 25 in dom0:
https://www.qubes-os.org/doc/supported-versions/#dom0

[andrewdavidwong]

Perhaps Qubes RC4 is using an earlier Fedora version or v26 build?

Yes, 4.0 uses Fedora 25 in dom0:
https://www.qubes-os.org/doc/supported-versions/#dom0

[tikums]

@airedalesoftware I tried the suggested work-around of using rawrite32 to create bootable installation media for 4.0RC4. However, it did not work for me. The installation cannot complete after running into the same condition that triggers this error.

[tikums]

@airedalesoftware I tried the suggested work-around of using rawrite32 to create bootable installation media for 4.0RC4. However, it did not work for me. The installation cannot complete after running into the same condition that triggers this error.

[sortofdev]

Having a similar issue, tried burning the ISO both with Rufus (both in ISO and DD format) and Rawrite32. https://bugzilla.redhat.com/show_bug.cgi?id=1383873 seems to be issue related to Fedora 25. Any way to bypass this or should i simply try with older version of Qubes to get this running and try to update from older version to version 4.0RC4?

[sortofdev]

Having a similar issue, tried burning the ISO both with Rufus (both in ISO and DD format) and Rawrite32. https://bugzilla.redhat.com/show_bug.cgi?id=1383873 seems to be issue related to Fedora 25. Any way to bypass this or should i simply try with older version of Qubes to get this running and try to update from older version to version 4.0RC4?