If it doesn’t ask for the password for the LUKS encrypted volume, then it make sense that /dev/mapper/qubes_dom0-root is missing – it shoul only be available, after the password has been entered.
Can you try to edit the GRUB command line and remove the quiet and see how the boot goes?
I clicked E for edit and under module 2 i see rhgb quiet. Should I remove that?
When I remove it and press F10 to boot, it loads large lines of commands and few minutes later it will not boot successfully. I think I should try doing the steps you suggested without using the password to sdb3? just directly go to shell and try the commands?
there has to be a solution for this. I cant possibly be the only person with this problem. It was working one day, then next day i started getting these boot errors.
@ChrisA can you look at this for me? anaconda rescue is broken · Issue #5609 · QubesOS/qubes-issues · GitHub
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 don’t understand how I would proceed with these steps? Do I type this in shell? or how do I get it done? what is the commands?
When did the error start appearing?
Unplanned shutdown, or out of diskspace errors?
Edit:
Is it possible you ran out of disk space?
I think I may have encountered this before.
What I did to solve it was delete some Qubes that could easily be restored.
Are you only able to boot into the shell from the USB stick?
ah yes, that could have happened. I am not sure how though because it has 180gb on the main sdb3 drive. How can I delete one or two of my custom created qubes?
Yes, i can load into shell with the original usb stick i use to boot into it or a second usb with the recovery option.
Hi,
You can check them out as reported “here”.
Of course, You have first of all boot from usb, luksOpen your sd<X>3 partition, then run lsblk to get which are your deletable VMs.
Cheers,
M.
can I get step by step instructions please?
I find it so rude to ignore people and poking others.
I’m out of ideas - so I can only suggest that you try to follow the suggestion from mila:
Since you don’t have a working dom0, you’ll have to boot some kind of LiveOS and work from that.
Thanks @ChrisA and @mila @kernel
I agree with this idea. Will this process allow me to view my files for any of the vm templates?
I really only care to unlock it with another live OS then access the files to back them up to another drive.
What steps should I take to unlock the old OS password and access the files in a new LIVE OS?
and How do I delete vm templates on the OLD OS
If that’s all you want to do, then I just did a really quick’n’dirty test:
After this, I could inspect them with:
xubuntu@xubuntu:~$ sudo -i
root@xubuntu:~# df -h
Filesystem Size Used Avail Use% Mounted on
tmpfs 1.5G 2.4M 1.5G 1% /run
/dev/loop0 2.4G 2.4G 0 100% /cdrom
/cow 7.3G 111M 7.1G 2% /
tmpfs 7.3G 0 7.3G 0% /dev/shm
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
tmpfs 7.3G 508K 7.3G 1% /tmp
tmpfs 1.5G 92K 1.5G 1% /run/user/999
/dev/mapper/qubes_dom0-root 20G 4.4G 15G 24% /media/xubuntu/ecba85df-43bd-432b-bb64-0e073bb1a485
/dev/mapper/qubes_dom0-vm--fedora--36--private 2.0G 212K 1.9G 1% /media/xubuntu/de437d44-8216-4258-95fe-ba191530088c
/dev/mapper/qubes_dom0-vm--debian--11--private 2.0G 8.3M 1.9G 1% /media/xubuntu/bcf7eacb-34da-40f8-9acb-9997728dd4ff
/dev/mapper/qubes_dom0-vm--whonix--ws--16--private 2.0G 356K 1.9G 1% /media/xubuntu/14696937-0373-4df6-909e-67017fe2fae0
/dev/mapper/qubes_dom0-vm--sys--net--private--1667740233--back 2.0G 364K 1.9G 1% /media/xubuntu/1a03192c-3004-42d1-94f9-c4f010fef3dd
/dev/mapper/qubes_dom0-vm--sys--net--private 2.0G 1.3M 1.9G 1% /media/xubuntu/1a03192c-3004-42d1-94f9-c4f010fef3dd1
/dev/mapper/qubes_dom0-vm--personal--private 2.0G 90M 1.8G 5% /media/xubuntu/be5c7d46-02d3-4ae8-93dc-c721e8e89ffb
/dev/mapper/qubes_dom0-vm--whonix--gw--16--private 2.0G 456K 1.9G 1% /media/xubuntu/afc174a2-f203-41a3-bc16-132f077b0ca5
/dev/mapper/qubes_dom0-vm--sys--whonix--private--1667739990--back 2.0G 272K 1.9G 1% /media/xubuntu/5c735fbb-f5f2-4123-a29b-e4a31778542f
/dev/mapper/qubes_dom0-vm--sys--whonix--private 2.0G 272K 1.9G 1% /media/xubuntu/5c735fbb-f5f2-4123-a29b-e4a31778542f1
root@xubuntu:~#
root@xubuntu:~# cd /media/xubuntu/be5c7d46-02d3-4ae8-93dc-c721e8e89ffb/home/user/
root@xubuntu:/media/xubuntu/be5c7d46-02d3-4ae8-93dc-c721e8e89ffb/home/user# ls
Desktop Documents Downloads Music Pictures Public Templates Videos
root@xubuntu:/media/xubuntu/be5c7d46-02d3-4ae8-93dc-c721e8e89ffb/home/user#
If GUI doesn’t give you the volume you are looking for, take a look inside /dev/mapper/:
ls /dev/mapper/
This sounds like it will work. I’ll try it. Do you know if the vm–vault was able to open or display? I wonder if vault is only accessible on the Qubes OS?
Ok this worked! I was able to see all the volumes.
The only thing is, I am missing access to the files in the documents / downloads section of the volume. I only see the bin directories. I don’t see documents/downloads/desktop directories.
What commands can I run to access those/download those?
I tried showing hidden files/directories in the file manager without any luck
Well this is pretty messed up. It seems like I cannot access the vault’s files that I had saved in the documents folder.
My understanding is, those files/directories should be in the (config folder)
My other VM’s do show some data in the /config folder of the /dev/mapper/qubes-dom0-vm-work-private (etc etc etc)
This is not the case for the vault vm for some odd reason. No files in the config folder for “vault vm’s”. I tried all three of the vault volume’s (not sure why it has 3 of them).
Maybe I need to openLuks like @mila suggested? I dont know how to run luksOpen command. is this correct?
cryptsetup luksOpen /dev/sdb3
I found my luks-UUID using lsblk
also the directory /home/user is locked. How can I unlock it?
Do you still need help? I’ll contact you by pm.
How did you get on? If you’ve not managed already, my suggestion would be to delete a couple of templates you can easily restore, e.g. whonix ones (+ the backup file).
Then if the issue was with diskspace, the drives should be able to map, and you’ll be able to boot into Qubes