Yes, im running the backups trough sys-usb-> extern ssd.The sys-usb is the default one from the installation.Im doing a complete new setup, for the very same reasons you mentioned.
Updating (and enabling testingrepos) was the very first thing i did. Im using coreboot+seabios and coreboot+grub+encrypted /boot, i could try an installation with the original bios/firmware, however this would be only for testing-purposes, since it would completely break my my security-setup/threat-model. They device(x230/i7/16gbram) did run qubes 3:2 so far without any issues.(and the very same coreboot images) Thanks for the hint, i will play around a bit tomorrow with different coreboot images. cheers. On 01/28/2018 03:56 AM, Yuraeitha wrote: > > - Are you running the backup through an AppVM? Doing backup in dom0 may cause > bugs or be really slow. I believe this is involved in the python/admin code > in Qubes 4, and is therefore different than it was in Qubes 3.2. So in Qubes > 4, be sure to do it in an AppVM, freshly made in Qubes 4. The general idea I > believe is to allow to network the backup process, that's why it was made to > work in an AppVM. No attention was given to allow backup in dom0 here, > probably on purpose since nothing should be done in dom0 anyway. > > - Is the template/AppVM you're using specifically to run the backup based on > a Qubes 4 template/AppVM? While Qubes 3.2. AppVM's can work in Qubes 4, it's > generally my experience that they are more buggy/slow, and work better if > re-made in Qubes 4 and then transfer the files over. Personally I took no > chances and purged all my Qubes 3.2. templates/AppVM's in favour for fresh > Qubes 4 ones. Removing Qubes 3.2. templates is obvious due to likely code > differences in the qubes-core-agent-* packages, etc., but the AppVM is more > controversial without confirmation and based on anecdotal experience. > Generally I experienced improvements by purging Qubes 3.2. AppVM's in favour > for freshly Qubes 4 made ones. > > - Did you update dom0? I've also seen the qvm-create not working, but this > only happens on a buggy install of Qubes 4, typically with python errors on > the last step during first boot when creating default VM-configuarations and > networking VM's. Generally I solved it either by re-install with different > UEFI/BIOS settings, EFI/Grub settings, UEFI/BIOS update, try switch between > EFI/Grub boot methods, loading different drivers. > > Generally the most effective method to get Qubes 4 RC-1/2/3 to work on a > system that I had issues with, was to unplug the drive, put it in a machine > that works with Qubes. Then install Qubes, update it fully, and then put it > back into the first machine again. Usually always work for me on any machine > that on paper should support Qubes. Also Grub is easier to do this, as EFI > paths can be a pain to adjust, they change when moving from a machine to > another, while Grub does not change. Also be careful if you install on > another machine, might be a good idea to remove the other drives first, just > in case. Also EFI installs on a machine with existing EFI paths may cause > issues. > All in all in short, use Grub is recommended here, and also to unplug other > drives on the install machine you use. > > Assuming you did not update dom0 due to the above bug, then once you get it > updated, everything "should" work much, much better. > -- 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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/c472b4d1-52cd-cdba-eedc-5f27a0211d1b%40seefelder-web.de. For more options, visit https://groups.google.com/d/optout.
