QubesOS stuck at boot

Hi, im new here. I have limited experience with ssh, bash etc. Ive been using qubes os for about 2 months now and it was working pretty good except a few wierd errors. My backups had issues. They got stuck at 100%. When i tried to verify the backups i also got errors. Im still testing this out so nothing too important was on it so i didnt think twice about the backup errors.

However the real problems started happening when just now while i was installing snap store to my debian-11 template while running a backup simutaneously… the terminal said the installation was successful but i was unable to create an appvm based off template. It gave my errors saying dom0 couldnt create vm. I thought a restart would do the trick… boy was i wrong…

Everytime i boot now i get stuck at this page

Im able to enter my password to unlock LUKS but it throws me this error shortly after everytime.

Thankfully not much important information is lost. But ive spent the last 2 months playing with different configurations to see what works best. Ive left notes on which configs i like best but a lot of it hasnt been backed up :frowning:

Id appreciate some help

Other information: i have dual boot on with windows (veracrypt). Secure boot is off. My windows os is running fine

I tried using the rescue method with the qubes iso on my usb but it says no linux partition.

Ive checked the disks and qubes os partitions are there for sure. Tbh im not sure if im using rescue properly. Just followed another thread with someone with a similar problem

Can you copy the rdsosreport.txt and check it for specific errors/failures? Or upload it here so someone can take a look.

I don’t know if it’s related or useful but following the same rescue process, I get this message about “any Linux partitions” but I see the partitions when running this command:

fdisk -l

I think the rescue is currently broken:

You can fix it with a hack if you really need it:

A quick & dirty workaround for anyone stumbled on this
A really quick & dirty ad-hoc workaround would be to rename all find_existing_installations to _find_existing_installations in the /usr/lib*/python*/site-packages/pyanaconda/rescue.py file and then re-run anaconda rescue: anaconda --rescue --lang us

I would like to do this but all I can find is /usr/lib64/python3.8/site-package/pyanaconda/rescue.py without _find_existing_installations. There is such a file under /usr/lib64/python3.8/site-package/pyanaconda/modules/storage/devicetree/rescue.py but even when appending an underscore before the function and resetting anaconda, there is nothing under /mnt/sysimage.

Hey, first off… apologies for untimely response. The law firm has been busy.

I wasnt able to copy the rdosreport because qubes wasnt able to detect my usb. I followed some instructions on another thread that said to type in ‘blkid’. I have tried re formatting the disk to NFTS, exfat, fat etc. No luck

So i tried something from another thread with someone with a similar problem. See below.

I clicked ‘e’ and removed ‘quiet’ and edited the rd.luks… as per instructed above. Then clicked ctl +x to reboot in verbose. Please see screenshot for result

The following showed up. I tried blkid again but the result was the same. Then i plugged my usb in and it seemed it was found but not authorized for use. Trying blkid again, yielded the same result unfortunately.

Im not sure where to go from here.

P.s please expect delayed responses as im a busy lawyer and not a techie! :slight_smile:

Appreciate all the responses :wink:

1 Like

You can copy this log file to one of your nvme0n1 disk partitions, for example you can copy it on your EFI partition /dev/nvme0n1p1:

mkdir -p /mnt/tmp
mount /dev/nvme0n1p1 /mnt/tmp
cp /run/initramfs/rdsosreport.txt /mnt/tmp/
umount /mnt/tmp

You should’ve used UUID 0e585dad-... of your crypto_LUKS partition /dev/nvme0n1p8 in rd.luks instead of d7c9210f-61e8-4dd0-9d64-24f4d88a658b

I have a similiar problem.

This fellow said he solved his issue:

Someone suggested this issue came up with having two different drives in the laptop.

I know in previous versions of Qubes I had problems with having an OS on both drives, so I blanked the second one, and it allowed it to function. I have thought of opening my laptop and unplugging the drive I am not using now. Anyone have thoughts if that might work?

I have an Alienware 15 R2 which has Qubes on one drive and another OS on the second drive.

Someone suggested that the problem is actually in Python? What is on Line 19.

I am not much help in this, but I thought if I added symptoms someone might find a common factor. ??


It’s just related to an other error message at the start of rescue system, not the real Qubes OS so I don’t think it’s relevant here ?

Thanks for replying

You would not happen to know what was changed between Qubes 4.2 RC2 and Qubes 4.2 RC3 in the initial detect for install?

I have thought this to be likely a timing issue, which might not show up so well in looking at software.

Would anyone like to hypothesize if install would work if I removed the second hard drive from the Librem V2. Why not just try it. I will have to spend money to have someone do that.

I would think I might replace the faster SSD with the thought it has developed a hitch in its git along.

I could hypothesize that my firmware has acquired some kind of malware, but I am not that important.

I suspect that I should be able to boot, if I learned the commands in the recovery console. I now try to limit my computer stuff to two hours a day. So this may not happen this week.

Happy Halloween

Ive copied it to nvme but idk how to read the file or copy to external usb

You can boot from some LiveUSB or some other OS and copy the file from there.