1) try to boot from a life system. Mount /boot and, in case of UEFI,
have a look in efi/qubes/xen.cfg or efi/BOOT/xen.cfg you should be
able to select a older kernel. Maybe that allows to reboot.
2) emergency backup is a good idea in any case. Open the encrypted
volume (using luks) then run vgchange -ay to activate all
logical volumes. With lvscan you should be able to see the names
(something like qubes-...-work-private
qubes-...-work-root
etc
It is the "private" one that you want. Mount them (they are all in
/dev/mapper/ ) and "rsync -auv" your data to a harddrive in
respective subdirs. That is less safe than the paranoid version
of qubes-backup since its grasps all ".config" files, but at least
you have a full take.
I wonder if I could make a Qube-style backup of the qubes in my hardrive instead of a rsync to restore/add them directly in the new installed Qube system, kind of lazy way
You can, with some extra work: The complete qubes-backup procdure is
explained online. It is, roughly speaking, a tar archive with special
checksum files to ensure pwds are correct.
I always to these backups by hand, to keep myself trained.
My method "sous-entend" that you "safe backup": in your life system
generate a container file (truncate -s 200G
/externalstorage/backup.luks), then losetup: (first losetup -f to get a
free slot, then bind it with losetup /dev/loopX
/externalstorage/backup.luks ), and cryptsetup luksFormat /dev/loopX
;cryptsetup luksOpen /dev/loopX BACKUP; mkfs.ext2 /dev/mapper/BACKUP ;
mount /dev/mapper/BACKUP /somemountpoint
For rsync'ing back inside qubes from subfolders you
- attach usb to dispVM1 (widget)
- lopsetup the container
- attach container mapper to dispVM2 (widget)
- there start same procedure as above at "luksOpen" step and then attach
the full decrypted backup to each VM with the widget, and rsync back the
correct subfolder in your home. You can use --exclude to avoid
"dot"-files ... best, Bernhard