Installation crashes

[gnuppek]

Qubes OS version:

Release 4.0

Affected component(s):

Installation

---

Steps to reproduce the behavior:

Start installation from CD

Expected behavior:

The first screen of the installation GUI (welcome screen) appears, after selecting the language (right now only English available) you should be able to click on continue to get to the next page.

Actual behavior:

The first screen of the installation GUI (welcome screen) appears, after a few seconds a popup appears saying "unknown error", regardless of clicking on continue or not. If clicking on continue, that does not make any difference. The installation is stuck at that point, you never reach the next screen.

Resulting error is "ValueError: device is already in tree"

General notes:

System is Intel I5-4570, 16GB, on Asus H87 Plus, BIOS latest revision
Graphics is IGP
Memtest ok for several hours single core and multi core
Tried using UEFI and legacy

Please see log:
anaconda.log

---

Related issues:

None known.
The only similar issue I found is "device is not in tree" which does not seem to fit this issue.

[lunarthegrey]

Are you using a RAID controller or software/bios RAID? I've seen a lot of issues around fakeraid and anaconda. Or do both of your drives have the same UUID (assuming you have more than 1 drive attached)?

I found this https://bugzilla.redhat.com/show_bug.cgi?id=1472999#c17

[lunarthegrey]

Are you using a RAID controller or software/bios RAID? I've seen a lot of issues around fakeraid and anaconda. Or do both of your drives have the same UUID (assuming you have more than 1 drive attached)?

I found this https://bugzilla.redhat.com/show_bug.cgi?id=1472999#c17

[gnuppek]

@lunarthegrey
No hardware raid controller. I was hoping for softraid (mdadm) and already had prepared some partitions loosely based on the QubesOS docs about custom install:

• The simpler part is 2 partitions for mirrored /boot
• The more complex part as follows: I have been using a SSD for Qubes R3.2 which did quite well, but had nothing like a failsafe design so I hoped to enhance this for the new Qubes R4.0 installation by using 2 mirrored partitions on the backend side cached by LVM cache using the "old" SSD on the frontend side:
  LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
  root qubes_dom0 Cwi-a-C--- 255,00g [cache] [root_corig] 0,00 11,00 100,00
  swap qubes_dom0 -wi-a----- 10,00g

Swap completely located on the SSD.
No duplicate UUIDs I am aware of.

[gnuppek]

@lunarthegrey
No hardware raid controller. I was hoping for softraid (mdadm) and already had prepared some partitions loosely based on the QubesOS docs about custom install:

• The simpler part is 2 partitions for mirrored /boot
• The more complex part as follows: I have been using a SSD for Qubes R3.2 which did quite well, but had nothing like a failsafe design so I hoped to enhance this for the new Qubes R4.0 installation by using 2 mirrored partitions on the backend side cached by LVM cache using the "old" SSD on the frontend side:
  LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
  root qubes_dom0 Cwi-a-C--- 255,00g [cache] [root_corig] 0,00 11,00 100,00
  swap qubes_dom0 -wi-a----- 10,00g

Swap completely located on the SSD.
No duplicate UUIDs I am aware of.

[lunarthegrey]

@gnuppek Did you check to see what the UUIDs are?

[lunarthegrey]

@gnuppek Did you check to see what the UUIDs are?

[gnuppek]

@lunarthegrey I'm afraid I didn't check the UUIDs when I tried the installation. I just didn't expect UUIDs then because I only prepared the LVM vols but no filesystems (I thought I leave that to the installation process). Maybe I'm wrong but I think of UUIDs only when having filesystems. As the installation failed, I purged everything afterwards to start over on a pristine system, so I don't have a chance to look it up now, sorry.
I will try again and tell about the results.

[gnuppek]

@lunarthegrey I'm afraid I didn't check the UUIDs when I tried the installation. I just didn't expect UUIDs then because I only prepared the LVM vols but no filesystems (I thought I leave that to the installation process). Maybe I'm wrong but I think of UUIDs only when having filesystems. As the installation failed, I purged everything afterwards to start over on a pristine system, so I don't have a chance to look it up now, sorry.
I will try again and tell about the results.

[gnuppek]

Hmm, it's getting weird...
Prior to opening this issue I tried roughly ten times to install Qubes 4.0. Every single time I encountered a.m. crash. Then I gave up for a short while, opened this issue and installed Ubuntu 16.04 (BIOS/MBR) in the meantime. Afterwards I converted that to UEFI/GPT/SecureBoot, just for the sake of it. Runs flawlessly after I got the hang of it. Learned a lot.

Then I recreated the LVM stuff for qubes again from scratch. Afterwards I tried the Q4 installation quite a few times again. Crash after crash, but that specific bug did not appear again. Now at least I was able to get past the first screen and configure keyboard and stuff before it got stuck. In contrast to the original problem with no message at all.

Then I saw, the md devices are not always available after starting the installation. So I changed to the text console and tried mdadm --assemble --scan. Then back to the graphical installer. Most of the time that crashed anyways, but at different times. Attempt after attempt I modified the "back-and-forth-dance" using the text-console to check/activate the md devices and the graphical installer and finally managed to get through the installation.

Well, up to now I'm not able to boot this, but hey, who wants to complain. That's a problem for tomorrow.

Here are two pictures I took when one of the new installations was stuck. That time not a complete crash, so I was able to switch between text console and GUI.

Maybe that might help in finding the root cause. I think that is because of the LVM stuff, especially in combination with the LVM cache and the raids.

I'll take care of the boot problem myself according to https://www.qubes-os.org/doc/uefi-troubleshooting/

Feel free to close this issue anytime you like.
Thanks for your help.

[gnuppek]

Hmm, it's getting weird...
Prior to opening this issue I tried roughly ten times to install Qubes 4.0. Every single time I encountered a.m. crash. Then I gave up for a short while, opened this issue and installed Ubuntu 16.04 (BIOS/MBR) in the meantime. Afterwards I converted that to UEFI/GPT/SecureBoot, just for the sake of it. Runs flawlessly after I got the hang of it. Learned a lot.

Then I recreated the LVM stuff for qubes again from scratch. Afterwards I tried the Q4 installation quite a few times again. Crash after crash, but that specific bug did not appear again. Now at least I was able to get past the first screen and configure keyboard and stuff before it got stuck. In contrast to the original problem with no message at all.

Then I saw, the md devices are not always available after starting the installation. So I changed to the text console and tried mdadm --assemble --scan. Then back to the graphical installer. Most of the time that crashed anyways, but at different times. Attempt after attempt I modified the "back-and-forth-dance" using the text-console to check/activate the md devices and the graphical installer and finally managed to get through the installation.

Well, up to now I'm not able to boot this, but hey, who wants to complain. That's a problem for tomorrow.

Here are two pictures I took when one of the new installations was stuck. That time not a complete crash, so I was able to switch between text console and GUI.

Maybe that might help in finding the root cause. I think that is because of the LVM stuff, especially in combination with the LVM cache and the raids.

I'll take care of the boot problem myself according to https://www.qubes-os.org/doc/uefi-troubleshooting/

Feel free to close this issue anytime you like.
Thanks for your help.

[lunarthegrey]

What happens if you just use the default LVM thin-provisioning partition layout that you can have the installer automatically configure? Does it work then? If so, I would think it has something to do with your partitioning layout. Otherwise it may be some other strange bug.

[lunarthegrey]

What happens if you just use the default LVM thin-provisioning partition layout that you can have the installer automatically configure? Does it work then? If so, I would think it has something to do with your partitioning layout. Otherwise it may be some other strange bug.

[gnuppek]

I wasn't able to boot what I got as a result from yesterday's installation attempt. No real surprise as the installer did show a warning about something like "installing the boot loader failed". So I started from scratch today, this time using what I think should be the simplest possible configuration. No prepared LVM vols, no RAID, no SSD cache, no crypt. Not even multiple disks. Just that ole SSD /dev/sda. Only thing is I didn't use thin provisioning but LVM and did the partitioning myself (complete SSD using ext4 as /). That attempt got me the same warning about boot loader, so I wasn't able to boot this new installation either. I got a progress bar when trying to boot, but that ran into a timeout after a while. On the text console I could see Qubes wasn't able to find the qubes_dom0-root lvol. Weird.

I think I call it a day and try again tomorrow. Next time no configuration at all. Just click on everything that looks like "auto"....

[gnuppek]

I wasn't able to boot what I got as a result from yesterday's installation attempt. No real surprise as the installer did show a warning about something like "installing the boot loader failed". So I started from scratch today, this time using what I think should be the simplest possible configuration. No prepared LVM vols, no RAID, no SSD cache, no crypt. Not even multiple disks. Just that ole SSD /dev/sda. Only thing is I didn't use thin provisioning but LVM and did the partitioning myself (complete SSD using ext4 as /). That attempt got me the same warning about boot loader, so I wasn't able to boot this new installation either. I got a progress bar when trying to boot, but that ran into a timeout after a while. On the text console I could see Qubes wasn't able to find the qubes_dom0-root lvol. Weird.

I think I call it a day and try again tomorrow. Next time no configuration at all. Just click on everything that looks like "auto"....

[marmarek]

After you get "installing the boot loader failed", switch to console and look into logs in /tmp for details about that. Either anaconda.log or program.log.

[marmarek]

After you get "installing the boot loader failed", switch to console and look into logs in /tmp for details about that. Either anaconda.log or program.log.

[gnuppek]

Finally. It's up and running. I just had to choose the simplest possible configuration:

• select only one disk (/dev/sda) for the installation
• prior to the installation remove all partitions from that disk
• uncheck disk encryption
• leave the rest as it is (thin provisioning, automatic partitioning)

Well, it's by far not the configuration I had hoped for, but at least it's something.

[gnuppek]

Finally. It's up and running. I just had to choose the simplest possible configuration:

• select only one disk (/dev/sda) for the installation
• prior to the installation remove all partitions from that disk
• uncheck disk encryption
• leave the rest as it is (thin provisioning, automatic partitioning)

Well, it's by far not the configuration I had hoped for, but at least it's something.