A few bugs in 4.0.rc3

61 views
Skip to first unread message

Jo

unread,
Jan 27, 2018, 9:17:05 PM1/27/18
to qubes-users
hello guys,

i played a bit with rc3 and came across the following bugs:


qvm-backup/restore results in a complete system-shutdown, which is very
annoying.Using the gui/ qubes-manager instead of the terminal makes no
difference.

I will have a look into it/ try to fix it in my spare time these days.

So far, it looks like its related to fedora-26 templates(both minimal
and regular ), but appears only with certain templates i have.

Could be coincidence, tough.


qvm-sync appmenus removes the menu-entrys systemtools, logut, launch
terminal emulator etc.

Logging out/back in does not solve the problem temporally, like in the past.

Couldnt find a solution/workaround so far, nore was i able to pin down
exactly what triggers this bug.


For any hints id be grateful, since im already setting up my new system
for 4.0 stable.


btw, have the disp-vm commands changed? qvm-create is not recognized
anymore.

cheers.




Yuraeitha

unread,
Jan 27, 2018, 9:56:59 PM1/27/18
to qubes-users


- 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.

Jo

unread,
Jan 27, 2018, 10:17:10 PM1/27/18
to qubes-users
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.

Yuraeitha

unread,
Jan 27, 2018, 10:44:50 PM1/27/18
to qubes-users

Np's :) I hope you succeed!

I've sometimes had longer issues with the UEFI/BIOS settings. I remember once when I started using Qubes, I used a couple of days to figure out why I could't install Qubes on a z170 Asus motherboard, i5 6500 CPU. Then it turned out it was a UEFI/BIOS setting to allow two graphic cards (one intel onboard, the other extenal nvidia card). Quite frankly, I was stunned by the cause, sometimes it's settings we least expect to cause any problems. The mix of VT-d, hypervisors and other exotic things in Qubes, seems to make it more sensitive to some UEFI/BIOS settings.

Reply all
Reply to author
Forward
0 new messages