Installation stuck at Attached SCSI removable disk, then goes into dracut timeout

Hello,

So I recently edited the ISO file for Qubes as the out of the box version had me stuck at Xen relinquishing VGA interface. I followed the UEFI troubleshooting, tried every step separately, still can’t get into the installer.

  • I commented out both noexitboot and mapbs

  • I changed the option=console to none

Now, all the logs come up, it then stops at “Attached SCSI removable disk”

After a few minutes, a few “Warning: dracut-initqueue timeout - starting timeout scripts” show.

The final thing that happens is I’m entered into the dracut emergency shell.

Here’s a screenshot:

Cheers to anyone who can offer some help, have tried everything! Thanks :slight_smile:

Unfortunately, I’m currently searching for the same answer. I’m using a Lenovo T460s that I selected off the HCL thinking I might be able to get a successful install this time around. (My Alienware laptop was also a no-go for Qubes…) I’ve tried 4.0.4 and the 4.1 alpha and flashed the bios to latest and back-rev’d jic. (UEFI boots, Legacy does not) Tried nomodeset as well through the rescue (I know that’s a video thing but it was suggested on another thread) and tried all the recommended fixes off the troubleshooting page. Other Linux distros come up / install w/no issues so it’s def a Qubes installer thing…

I’m kinda bummed as I bought this Lenovo used off Ebay bc the T460s all had excellent Qubes support based on the HCL. I’m parsing through the debugs and I’m hoping something will stick out. Please let me know if you find something!

Edit: As I just got done writing this, I might’ve stumbled on to something in the dmesg. I’m not seeing my NVME SSD come up in the debug and the only real error messages I’m seeing in there is

“systemd-gpt-auto-generator: EFI loader partition unknown, exiting.”

and

“systemd-gpt-auto-generator: (The boot loader did not set EFI variable LoaderDevicePartUUID.)”

Imma gonna head down the rabbit hole on these messages to see if this could be related to our problem.

This bug report seems to be in line with some of the mentioned issues:

So I would suggest you follow up there, if you confirm it matches your situation. Complemented with the positive reports on the HCL as @malsware mentioned if posted there, I believe it is possible to get some developer attention.

That is indeed the same messages I’m getting on my machine so I’m going to add to the thread with what I’ve attempted since last night and mention that my machine should be relatively well supported from the HCL recs. (Right now, it only has 8GB RAM but there’s 32GB in the post that will hopefully show up in the next few weeks.)

Thanks for sending the ticket over and making us aware of it! Dammit, I knew I should’ve checked the issue tracker before tearing apart the laptop… :slight_smile:

1 Like

I updated the above referenced Github issue so look for more potential info there if you’re experiencing this issue.

Hey, op, I found the issue on my machine. I documented it here but long/short, it was the USB creation process. Try using their recommended processes from the installation page and see if it also works for you. After spending all day on it, turns out it was an easy issue from the start… :slight_smile: