Have you tried rescue mode using installation media? You can try it and I believe it should help. I had used rescue mode to edit my xen.cfg file which had helped to me boot the system one again in case I had passed some wrong parameters to xen.cfg. You can access rescue mode by pressing ctl+alt+f5. May be it will help you.
--You received this message because you are subscribed to the Google Groups "qubes-users" group.To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users...@googlegroups.com.To post to this group, send email to qubes...@googlegroups.com.To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/6079c7b0-acaa-4d1f...@googlegroups.com.For more options, visit https://groups.google.com/d/optout.
cub...@tutamail.com wrote on 4/3/19 6:26 PM:
Thank you for your suggestion. I have given it a try but unfortunately the systems hasn't yet been restored. (I'm guessing you referred to the following commands to enter rescue mode: pkill -9 anaconda; anaconda --rescue; )
I also tried mounting my Qubes disk in LinuxMint, using commands:cryptsetup luksOpen /dev/sda2 qubes-disk;then pvscan, pvdisplay, vgscan, vgdisplay, lvscan, lvdisplay.These allowed me to see logical structure of my qubes_dom0 volumes, volumes representing AppVM, but I was unsuccessful mounting these volumes to get access to the data.Comman 'lvscan' shows LV status next to each volumes, and only 'swap' was marked as active. Everything else was 'NOT active', including 'root', 'pool00', and AppVM volumes.Do you, or anybody else, have any idea how to proceed? I must recover the data. I hope they didn't get corrupted, only the access point has gone missing.
You're in the right area, but I don't see a "vgchange -ay" in your list of commands?
--You received this message because you are subscribed to the Google Groups "qubes-users" group.To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users...@googlegroups.com.To post to this group, send email to qubes...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/70a61521-d7dc-9e17...@danwin1210.me.
Every time now that I do a backup or restore I have to live in white knuckle fear that something might go wrong and I will lose again my system and have to restore again, a process that can be laborious and error prone not to mention simply time consuming.
Some simple instructions on how to do whatever needs to be done to keep this from happening -- defensively re-size dom0 or other Qubes? clear temp files out of certain dir used by the backup process? twiddle some settings? -- would be incredibly calming. I have a 1TB drive here so it seems unnecessary that my machine dies because of some shuffling of VM resizing issues. Can't I just allocate a ton of space to whatever this lvm process is?
I didn't see your original thread, but I think I had a somewhat similar problem. A workaround was to boot with nomodeset, and ultimately I had to disable sys-usb in order to boot without nomodeset.
Boot into installation media and choose "rescue a qubes system", follow the prompts to mount and chroot, then edit /boot/efi/EFI/qubes/xen.cfg (UEFI systems) and add "nomodeset" at the end of the "kernel=" line for the version that is set as default. On grub systems, just press 'e' when you see the grub menu at boot up, and add nomodeset on kernel line. You might have to hold down shift or esc while booting to make it show the menu.
Or, when it gets stuck, if you are able to switch to tty2 (ctrl alt f2), you can just do the same thing from there.