Re: [qubes-users] [solved] Re: Failed to synchronize cache for repo 'qubes-dom0-cached', disabling.
On 11/12/18 12:11 PM, unman wrote: > On Sat, Nov 10, 2018 at 12:54:46PM +0100, Alex wrote: >>[...] >> Changed that with nano to read "4.0" instead of "$releasever" and voilà, >> updates went through. >> > > Please bear in mind that if you do this you are breaking the logic of > dnf, and will have to *manually* update that entry if you upgrade the > system. You are almost bound to forget this. > $releasever is part of yum/dnf, not Qubes. I am well aware of this, both the fact that I'm gonna forget about it and that $releasever is part of the yum workflow. Actually, since I hate "fedup", it's the way I update my other computers to a newer fedora version: dnf upgrade --releasever=29. > You can pass in --releasever=4.0 as an option, which would be a better > solution. That's true; but as the time of writing my original response, I could not figure out how $releasever was being catenated with both "25" and "4", so I imagined something "fixed" was automatically appended and decided not to brute-force the --releasever param. I use Qubes as my main workstation, so I don't have much time to extensively try and fix things... Still, I love it so much I thought I'd jump into the thread and post my workaround. > I havent encountered this bug myself,so cant account for it. It might be > helpful if those who have could say if they have enabled testing repos, > or are using plain 4.0 Qubes repositories. Any other detail would be > helpful. A very plain installation of R4.0, some couple of months after the official release (I had to upgrade the CPU to install R4.0 from R3.2, so I had to wait for it to arrive from an ebay seller in the UK). Looking at the bug linked by Andrew (github issue 4477), seems like Marek already found the cause. I'll monitor the issue and, as soon as this is resolved (which may involve a temporal link from yum.qubes-os.org/r25-4/ to yum.qubes-os.org/r4.0?), will revert the repo files in /etc/yum.repos.d to the original ones. Thank you everybody, -- Alex -- 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+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/d34197bb-8285-9faf-47a5-938574b46e51%40gmx.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] [solved] Re: Failed to synchronize cache for repo 'qubes-dom0-cached', disabling.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 11/12/18 5:11 AM, unman wrote: > On Sat, Nov 10, 2018 at 12:54:46PM +0100, Alex wrote: >> On 11/10/18 11:23 AM, hm...@tuta.io wrote: >>> hello >>> >>> I have exactly the same problem on two of my x230 Lenovo notebooks with >>> Qubes version R4.0.1rc1. >> Have had this very issue on R4.0. >> >> I checked by running, in dom0: >> # qubes-dom0-update -v >> >> That runs the dnf updater with the "-v" verbose flag. With that, the URL >> for the repositories will be printed on screen, in red (because it's >> happening in the UpdateVM). >> >> I found that the URL being printed was >> https://yum.qubes-os.org/r25-4/current/dom0/fc25/repodata/repomd.xml.metalink >> >> instead of the correct >> https://yum.qubes-os.org/r4.0/current/dom0/fc25/repodata/repomd.xml.metalink >> >> (the yum.qubes-os.org domain can be navigated with a browser). >> >> I found that inside [dom0]/etc/yum.repos.d/qubes-dom0.repo the url is >> saved as >> https://yum.qubes-os.org/r$releasever/current/dom0/fc25/repodata/repomd.xml.metalink >> >> Changed that with nano to read "4.0" instead of "$releasever" and voilà, >> updates went through. >> >> Check, try and let the list know ;) >> >> -- >> Alex > > Please bear in mind that if you do this you are breaking the logic of > dnf, and will have to *manually* update that entry if you upgrade the > system. You are almost bound to forget this. > $releasever is part of yum/dnf, not Qubes. > > You can pass in --releasever=4.0 as an option, which would be a better > solution. > > I havent encountered this bug myself,so cant account for it. It might be > helpful if those who have could say if they have enabled testing repos, > or are using plain 4.0 Qubes repositories. Any other detail would be > helpful. > > unman > This sounds like: https://github.com/QubesOS/qubes-issues/issues/4477 - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlvqaW4ACgkQ203TvDlQ MDAAIQ/6A57l5meIGtBmpYGZgIwOzqE6LaOkfghfYot+pXVAdzAr+TXfkkAmy4fp RmjagpufU2oVma2kwWAUjzVEZxgJI8KIQoBNN1vLiO3dH88KkDN4FJV5EJ1/QnBn AsdVvhUSNz8l2x1qhDGlthpnNHXaho2laBXV6WLIhGl8WAgnvXCiLyT0PMm/+lPx opnry33xATKxLBmvIuTVo0YtrHxIoaBicYdaZ3tCyefT3/MADfKjTG2kCMX6IExl Ov9T2oyEnzkqeC4qOhDvhnLrwcfewt4hRCmsPV/Xv7Q8FBr3MyO/7CVbI38m9bkS w7lq6uL5bS2HS4kseYOZQzqKEARjO83SEavwfyH+84uijDrfgoNqyFQcFVjpFyCo bXc/Ncdo2HOflQxtVpuSJmsnSE9+BBzuXD+VXABxst6HGaHlP5Cy8566nJI9GEsk 8jb57cdg8lRHNHzy/uBw/tXyckhOfyjREdD7UG9tju/JYaECNoV+KsXNg2rCisCc OH3OwS8aNDitvU8sH/J1JMgWh83HMyLH+8bJQoMbLVR6yALPdRyOUQcw15z0XIsG NUJTr8tZVDVN+KECvVXgXs9LXrnEObyndPe4Mh9sXSZP6jsfDtBpDgTQfnEmXpJ0 yfQTU3hcgSvatqCRJy2DxroGpY8qk/r5vegUuytcuNhO6xo6yZo= =TTVl -END PGP SIGNATURE- -- 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+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/36ea7dd7-65a7-7935-68b2-2a295a12424f%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] downloading to vault when there is not netvm is n/a?
Hello Stumpy, Am Di., 13. Nov. 2018, 03:55 hat Stumpy geschrieben: > I was copying some things from my vaultvm to some othr appvms and got > this message: > > [user@vault Documents]$ qvm-copy file.txt > rm: cannot remove '/etc/hosts': No such file or directory > sudo: unable to resolve host personal: No such file or directory > [...] > I have no idea what it is talking about, how it downloaded anything when > the vault vm shows up in my qubes manager as having no network access > (which it shouldnt), or why qvm-copy file.txt would evoke some response > about the /etc/host file and/or start downloadings things. > Can you please add the info which Qubes Version you are running and which template the vault-vm is using. Is the image a default Qubes image or has it been changed? I suggest to set a default template and make sure that no netvm is set, then run the steps again and look if you get the same results. Or maybe create a new AppVM based on the same template like your vault-vm and run the same steps to check if this a reproducible effect. I'll try to run the same steps on my Qubes 4 and my fedora-28-minimal based Vault VM - O > -- 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+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/CAJ3yz2s39fxmkbEHnOv_NcESPv%2BXHmo9n-ebc1kLqAQgnpgNaA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Qubes OS 3.2.1 has been released!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear Qubes Community, We're pleased to announce the stable release of Qubes 3.2.1! As we previously announced [1], this is the first and only planned point release for version 3.2. Since no major problems were discovered with 3.2.1-rc1, this stable release is not significantly different from the release candidate. Features: - Fedora 28 TemplateVM - Debian 9 TemplateVM - Whonix 14 Gateway and Workstation TemplateVMs - Linux kernel 4.14 Release 3.2.1 has replaced Release 3.2 on the Downloads page. [2] What is a point release? - A point release does not designate a separate, new version of Qubes OS. Rather, it designates its respective major or minor release (in this case, 3.2) inclusive of all updates up to a certain point. Installing Qubes 3.2 and fully updating it results in the same system as installing Qubes 3.2.1. What should I do? - - If you're currently using an up-to-date Qubes 3.2 installation, then your system is already equivalent to a Qubes 3.2.1 installation. No action is needed. Regardless of your current OS, if you wish to install (or reinstall) Qubes 3.2 for any reason, then the 3.2.1 ISO will make this more convenient and secure, since it bundles all Qubes 3.2 updates to date. It will be especially helpful for users whose hardware is too new to be compatible with the original Qubes 3.2 installer. As a reminder, Qubes 3.2 (and, therefore, Qubes 3.2.1) is scheduled to reach EOL (end-of-life) on 2019-03-28. [3] What about Qubes 4.0.1? - --- We recently announced the release of 4.0.1-rc1. [4] You can help us test [5] this release candidate and report any bugs you encounter [6] so that they can be fixed before the stable release. [1] https://www.qubes-os.org/news/2018/10/05/qubes-321-rc1/ [2] https://www.qubes-os.org/downloads/ [3] https://www.qubes-os.org/doc/supported-versions/#qubes-os [4] https://www.qubes-os.org/news/2018/11/05/qubes-401-rc1/ [5] https://www.qubes-os.org/doc/testing/ [6] https://www.qubes-os.org/doc/reporting-bugs/ This announcement is also available on the Qubes website: https://www.qubes-os.org/news/2018/11/12/qubes-321/ - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlvqXxwACgkQ203TvDlQ MDCD/Q/+L3x9DdqsQTExGpdOUU4zFrtf8eCveokv0P/2OoQWQDyBblc7TwcFdzev yB7dK3yFiCxxSnPNNlDBFqKl/aQX736q8YOskHopx7+jFhhiNpOkIF+pyQi+6pty vsjaMGKJUIeJRVVMANVb8z9xtKuntmXiosN7LuMyjVPn4datg/N4se7bBoJD EzSH51+NADWOsld2cGIqHqf9VIc6aKKcV2mmd+wivYF4L8yFS7v9zj1L5fuSRlZF InAKaAM0bNY7pAslGzM8KynwXcHLqRPBbbXmb75VdIQx+Cd5dlNmwHBxSN+fBvKE 1etziXTp9kPzlo3I6Cm6DA9OTH3hwBr+GJ0ElYxRqFYHsoA288pToLLw9a7ErhE9 wAFRoPvlwP3Fyr4SxvRg+FTtxOcXmEIjhBJXXDQVTvh43h8JPjCqn4dAps6hMPl3 8ixI+lGtu0NVY4dIxFjNwHQzumZPGzNcqAeqly2G8a5Z6em0GL98WwQ7slx/sLBv QHvXwXx8pe/+KXfhmHDrlkyuCw4SYhOFejKQ5H/DmTGrRpUpuNc6utOOCMYqWvYM DJR/ZI9kz/e7XQIBeccZxACECfp/+Wn1CHFd615kIFLgyuYXu64lJSAJiTr7gfgv ek1O8VaEIN8uqPlCvnKIY2zHwALwL4/tlZTHx7K3go4oq6lGIKc= =Fc8r -END PGP SIGNATURE- -- 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+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/995f5711-da7d-6a42-a012-2aa9fde010e3%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 4: Windows 7 HVM loses internet connection after installing Qubes Windows Tools
On 11/12/18 9:47 PM, Otto Kratik wrote: On Monday, November 12, 2018 at 1:52:44 PM UTC-5, Ivan Mitev wrote: Hi, Since you mention that the network is functional without QWT installed there's probably an issue with your ip settings in the windows HVM. Make sure that the IP you've manually configured in windows matches the one assigned to the VM (in dom0, run `qvm-prefs vmname visible_ip`). Also check that the ip/gateways/dns ips you've configured are properly applied in the vm (`ipconfig /all` in a command prompt), it could be that the "Qubes Network Setup" service is still active for some reason. Then, if everything looks OK, try to ping the VM's IP from the VM (this should work), then the gateway, then the DNS IPs. I'll give this a try, thanks. So far in the Windows HVM I have not put any value under "gateway" because that is not mentioned in the instructions from Issue3585 above. Only IP address, Subnet mask, and DNS server fields are filled out. Default gateway is left empty. Oh, I see. I've updated the issue to add a mention about the gateway. Actually the issue was originally meant to document the problems with QWT on R4 but it slowly evolved into a step-by-step guide. I've also added a note about QWT 4 breaking *new* HVMs (I thought the breakage was only when updating from QWT3 to QWT4). It seems it's a hit-or-miss process, IIRC some users managed to have QWT4 running. What value, if anything, should go under Gateway in the VM? The ip address shown by Qubes as belonging to the network-providing VM itself, ie Sys-Net or Sys-Firewall, namely 10.137.0.6 ? Or something else? The ip output by `qvm-prefs vmname visible_gateway` ; if you don't have a fancy vpn/firewall setup, it's likely 10.137.0.6. Also, I am presuming the values listed for DNS servers are universal constants at the moment in Qubes 4, meaning 10.139.1.1 and 10.139.1.2 are absolute values for all installations and not dynamically dependent on specific configuration? Yes, IIRC the DNS servers were hardcoded somewhere in one of the qubes python scripts in dom0. -- 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+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/c0e05adc-cf1e-ebd6-9e0c-31bb632a5f96%40maa.bz. For more options, visit https://groups.google.com/d/optout.
[qubes-users] downloading to vault when there is not netvm is n/a?
I was copying some things from my vaultvm to some othr appvms and got this message: [user@vault Documents]$ qvm-copy file.txt rm: cannot remove '/etc/hosts': No such file or directory sudo: unable to resolve host personal: No such file or directory --2018-11-12 21:49:40-- https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 151.101.124.133 Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|151.101.124.133|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 1617334 (1.5M) [text/plain] Saving to: ‘hosts.1’ 0K .. .. .. .. .. 3% 118K 13s 50K .. .. .. .. .. 6% 237K 9s 100K .. .. .. .. .. 9% 66.0M 6s 150K .. .. .. .. .. 12% 243K 6s 200K .. .. .. .. .. 15% 11.0M 4s 250K .. .. .. .. .. 18% 60.8M 4s 300K .. .. .. .. .. 22% 31.9M 3s 350K .. .. .. .. .. 25% 247K 3s 400K .. .. .. .. .. 28% 7.83M 3s 450K .. .. .. .. .. 31% 17.8M 2s 500K .. .. .. .. .. 34% 32.0M 2s 550K .. .. .. .. .. 37% 30.8M 2s 600K .. .. .. .. .. 41% 234K 2s 650K .. .. .. .. .. 44% 36.4M 2s 700K .. .. .. .. .. 47% 221M 1s 750K .. .. .. .. .. 50% 192M 1s 800K .. .. .. .. .. 53% 165M 1s 850K .. .. .. .. .. 56% 301M 1s 900K .. .. .. .. .. 60% 211M 1s 950K .. .. .. .. .. 63% 206M 1s 1000K .. .. .. .. .. 66% 234K 1s 1050K .. .. .. .. .. 69% 56.4M 1s 1100K .. .. .. .. .. 72% 71.6M 1s 1150K .. .. .. .. .. 75% 57.9M 0s 1200K .. .. .. .. .. 79% 158M 0s 1250K .. .. .. .. .. 82% 314M 0s 1300K .. .. .. .. .. 85% 268M 0s 1350K .. .. .. .. .. 88% 82.6M 0s 1400K .. .. .. .. .. 91% 91.2M 0s 1450K .. .. .. .. .. 94% 80.3M 0s 1500K .. .. .. .. .. 98% 13.1M 0s 1550K .. .. . 100% 167K=1.7s 2018-11-12 21:49:42 (942 KB/s) - ‘hosts.1’ saved [1617334/1617334] /etc/hosts: Scheme missing. FINISHED --2018-11-12 21:49:42-- Total wall clock time: 2.8s Downloaded: 1 files, 1.5M in 1.7s (942 KB/s) sent 4/5 KB I have no idea what it is talking about, how it downloaded anything when the vault vm shows up in my qubes manager as having no network access (which it shouldnt), or why qvm-copy file.txt would evoke some response about the /etc/host file and/or start downloadings things. Can someon help me make sense of this? -- 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+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/21a07e23-8f10-1311-c3e5-4ff2287d73d2%40posteo.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] qvm-trim-template hung now stuck with remnants of the process
On Mon, Nov 12, 2018 at 08:47:43PM +0100, cubit wrote: > I was running qvm-trim-template on my 6 templates - Qubes 3.2 - but the > process looked to hang on 2 of them. After 30 minutes of waiting (usually > 2-3 minutes max) I ctrl+c them > This resulted in files being left behind blocking me from running > qvm-trim-template again on the problem ones. > If I do qvm-trim-template whonix-gw-14 I get the error > Disk usage before: > 2644484 /var/lib/qubes/vm-templates/whonix-gw-14/root.img > Creating temporary VM... > Traceback (most recent call last): > File "/usr/bin/qvm-trim-template", line 172, in > main() > File "/usr/bin/qvm-trim-template", line 115, in main > fstrim_vm.create_on_disk() > File "/usr/lib64/python2.7/site-packages/qubes/modules/000QubesVm.py", line > 1298, in create_on_disk > self.storage.create_on_disk(verbose, source_template) > File "/usr/lib64/python2.7/site-packages/qubes/storage/__init__.py", line > 175, in create_on_disk > os.mkdir (self.vmdir) > OSError: [Errno 17] File exists: '/var/lib/qubes/appvms/trim-whonix-gw-14' > I though maybe I could delete the trim-whonix-gw-14 app VM but get this error > then > > $ sudo rm -rf /var/lib/qubes/appvms/trim-whonix-gw-14 > $ qvm-trim-template whonix-gw-14 > Disk usage before: > 2644484 /var/lib/qubes/vm-templates/whonix-gw-14/root.img > Creating temporary VM... > Traceback (most recent call last): > File "/usr/bin/qvm-trim-template", line 172, in > main() > File "/usr/bin/qvm-trim-template", line 115, in main > fstrim_vm.create_on_disk() > File "/usr/lib64/python2.7/site-packages/qubes/modules/000QubesVm.py", line > 1320, in create_on_disk > self._update_libvirt_domain() > File "/usr/lib64/python2.7/site-packages/qubes/modules/000QubesVm.py", line > 767, in _update_libvirt_domain > raise e > libvirt.libvirtError: operation failed: domain 'trim-whonix-gw-14' already > exists with uuid 1dcd7cd5-aaa9-4b62-8254-73b8db63190b > > > Can anyone suggest how to rectify this so I can trim once again? > > CuBit > Read https://www.qubes-os.org/doc/remove-vm-manually/ The libvirt error shows you need to manually remove that qube. qvm-remove just-db trim-whonix-gw-14 unman -- 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+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20181113004603.62ebyi73foobhvmb%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] qvm-trim-template hung now stuck with remnants of the process
I was running qvm-trim-template on my 6 templates - Qubes 3.2 - but the process looked to hang on 2 of them. After 30 minutes of waiting (usually 2-3 minutes max) I ctrl+c them This resulted in files being left behind blocking me from running qvm-trim-template again on the problem ones. If I do qvm-trim-template whonix-gw-14 I get the error Disk usage before: 2644484 /var/lib/qubes/vm-templates/whonix-gw-14/root.img Creating temporary VM... Traceback (most recent call last): File "/usr/bin/qvm-trim-template", line 172, in main() File "/usr/bin/qvm-trim-template", line 115, in main fstrim_vm.create_on_disk() File "/usr/lib64/python2.7/site-packages/qubes/modules/000QubesVm.py", line 1298, in create_on_disk self.storage.create_on_disk(verbose, source_template) File "/usr/lib64/python2.7/site-packages/qubes/storage/__init__.py", line 175, in create_on_disk os.mkdir (self.vmdir) OSError: [Errno 17] File exists: '/var/lib/qubes/appvms/trim-whonix-gw-14' I though maybe I could delete the trim-whonix-gw-14 app VM but get this error then $ sudo rm -rf /var/lib/qubes/appvms/trim-whonix-gw-14 $ qvm-trim-template whonix-gw-14 Disk usage before: 2644484 /var/lib/qubes/vm-templates/whonix-gw-14/root.img Creating temporary VM... Traceback (most recent call last): File "/usr/bin/qvm-trim-template", line 172, in main() File "/usr/bin/qvm-trim-template", line 115, in main fstrim_vm.create_on_disk() File "/usr/lib64/python2.7/site-packages/qubes/modules/000QubesVm.py", line 1320, in create_on_disk self._update_libvirt_domain() File "/usr/lib64/python2.7/site-packages/qubes/modules/000QubesVm.py", line 767, in _update_libvirt_domain raise e libvirt.libvirtError: operation failed: domain 'trim-whonix-gw-14' already exists with uuid 1dcd7cd5-aaa9-4b62-8254-73b8db63190b Can anyone suggest how to rectify this so I can trim once again? CuBit -- 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+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/LR8SmJY--3-1%40tutanota.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 4: Windows 7 HVM loses internet connection after installing Qubes Windows Tools
On Monday, November 12, 2018 at 1:52:44 PM UTC-5, Ivan Mitev wrote: > Hi, > Since you mention that the network is functional without QWT installed > there's probably an issue with your ip settings in the windows HVM. Make > sure that the IP you've manually configured in windows matches the one > assigned to the VM (in dom0, run `qvm-prefs vmname visible_ip`). > Also check that the ip/gateways/dns ips you've configured are properly > applied in the vm (`ipconfig /all` in a command prompt), it could be > that the "Qubes Network Setup" service is still active for some reason. > > Then, if everything looks OK, try to ping the VM's IP from the VM (this > should work), then the gateway, then the DNS IPs. I'll give this a try, thanks. So far in the Windows HVM I have not put any value under "gateway" because that is not mentioned in the instructions from Issue3585 above. Only IP address, Subnet mask, and DNS server fields are filled out. Default gateway is left empty. What value, if anything, should go under Gateway in the VM? The ip address shown by Qubes as belonging to the network-providing VM itself, ie Sys-Net or Sys-Firewall, namely 10.137.0.6 ? Or something else? Also, I am presuming the values listed for DNS servers are universal constants at the moment in Qubes 4, meaning 10.139.1.1 and 10.139.1.2 are absolute values for all installations and not dynamically dependent on specific configuration? -- 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+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/b43e8281-bad6-49a6-9007-2ed6a9c758e7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 4: Windows 7 HVM loses internet connection after installing Qubes Windows Tools
Hi,
On 11/12/18 8:02 PM, Otto Kratik wrote:
Here's what I've done so far:
Created a new Windows 7 SP1 HVM by using an .iso as I've done many times
successfully in the past on Qubes 3.2. Everything works fine, HVM is created
and runs correctly, internet connection is intact and functioning as expected.
Downloaded Qubes Windows Tools 4.0 and installed them into the HVM as per
documentation. Installation of QWT 4.0 completely *breaks* HVM and places it
into a totally irrecoverable state, as detailed here near the top:
https://github.com/QubesOS/qubes-issues/issues/3585
"at the following reboot, windows fails to boot and tries to repair files, which as
usual doesn't fix anything (the VM might boot at some point, without the tools
installed)"
Deleted the HVM, and started over from scratch by creating a new one. This
time, I installed Qubes Windows Tools version 3.2.2.3 instead of 4.0. That
worked perfectly fine, and the usual QWT-enhanced Windows HVM appeared with
full screen resolution, mouse pointer integration etc. Except, the internet
connection suddenly completely went offline and stopped functioning.
As per Issue 1 again from the same source, I tried the following instructions:
https://github.com/QubesOS/qubes-issues/issues/3585
Issue 1 - Networking isn't set up properly
The PV adapter's status is stuck at "Identifying"; pinging an ip works but pinging a host
fails, indicating a problem with DNS resolution. A tcpdump on sys-firewall indeed shows that DNS
requests are sent to the gateway's ip and are rejected. The reason is that in R4 VMs are now using
the exposed "/qubes-{primary,secondary}-dns" values, while R3.2's Windows Tools still use
/qubes-gateway (whose IP in R4 is different from /qubes-primary-dns).
Workaround: disable the "Qubes Network Setup" service (with gui/msconfig, or sc config
"QubesNetworkSetup" start= disabled in a command prompt) and configure the network
manually.
Settings:
DNS{1,2}: 10.139.1.1, 10.139.1.2
Subnet: 255.255.255.0
IP: in dom0, qvm-prefs vmname ip will output the VM's ip. Caveat: a
cloned/restored/... VM will likely have its IP changed so you'll have to
remember to update your network settings.
Implementing this attempted fix did *NOT* solve the problem, and the lack of
internet connectivity persists despite doing everything suggested. All other
VMs on the system have their internet connections working perfectly fine.
What are the next suggested steps to try? Should that fix have worked
regardless of using QWT 3.2.2.3 rather than 4.0, as long as the base system is
Qubes 4 instead of 3.2? If not, what options should I be using for my specific
situation? What do I do from here to get internet connectivity back?
Since you mention that the network is functional without QWT installed
there's probably an issue with your ip settings in the windows HVM. Make
sure that the IP you've manually configured in windows matches the one
assigned to the VM (in dom0, run `qvm-prefs vmname visible_ip`).
Also check that the ip/gateways/dns ips you've configured are properly
applied in the vm (`ipconfig /all` in a command prompt), it could be
that the "Qubes Network Setup" service is still active for some reason.
Then, if everything looks OK, try to ping the VM's IP from the VM (this
should work), then the gateway, then the DNS IPs.
--
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+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/fccd0b96-b05e-c964-9cb9-fa8611034e1f%40maa.bz.
For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Fedora-29-minimal :: Feedback / Using it as sys-Template
Hello, did someone succeeded installing and using sys-vms (sys-usb|net|firewall) based on the new fedora-29-minimal template from the testing repositories (sudo qubes-dom0-update --enablerepo=qubes-templates-itl-testing fedora-29-minimal) with working network connectivity? - O -- 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+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/CAJ3yz2uE2LSg0%2BFDtr8%3DPXwXNUJWzpJRaJcrZC7r2tZXitxECQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Qubes 4: Windows 7 HVM loses internet connection after installing Qubes Windows Tools
Here's what I've done so far:
Created a new Windows 7 SP1 HVM by using an .iso as I've done many times
successfully in the past on Qubes 3.2. Everything works fine, HVM is created
and runs correctly, internet connection is intact and functioning as expected.
Downloaded Qubes Windows Tools 4.0 and installed them into the HVM as per
documentation. Installation of QWT 4.0 completely *breaks* HVM and places it
into a totally irrecoverable state, as detailed here near the top:
https://github.com/QubesOS/qubes-issues/issues/3585
"at the following reboot, windows fails to boot and tries to repair files,
which as usual doesn't fix anything (the VM might boot at some point, without
the tools installed)"
Deleted the HVM, and started over from scratch by creating a new one. This
time, I installed Qubes Windows Tools version 3.2.2.3 instead of 4.0. That
worked perfectly fine, and the usual QWT-enhanced Windows HVM appeared with
full screen resolution, mouse pointer integration etc. Except, the internet
connection suddenly completely went offline and stopped functioning.
As per Issue 1 again from the same source, I tried the following instructions:
https://github.com/QubesOS/qubes-issues/issues/3585
Issue 1 - Networking isn't set up properly
The PV adapter's status is stuck at "Identifying"; pinging an ip works but
pinging a host fails, indicating a problem with DNS resolution. A tcpdump on
sys-firewall indeed shows that DNS requests are sent to the gateway's ip and
are rejected. The reason is that in R4 VMs are now using the exposed
"/qubes-{primary,secondary}-dns" values, while R3.2's Windows Tools still use
/qubes-gateway (whose IP in R4 is different from /qubes-primary-dns).
Workaround: disable the "Qubes Network Setup" service (with gui/msconfig, or sc
config "QubesNetworkSetup" start= disabled in a command prompt) and configure
the network manually.
Settings:
DNS{1,2}: 10.139.1.1, 10.139.1.2
Subnet: 255.255.255.0
IP: in dom0, qvm-prefs vmname ip will output the VM's ip. Caveat: a
cloned/restored/... VM will likely have its IP changed so you'll have to
remember to update your network settings.
Implementing this attempted fix did *NOT* solve the problem, and the lack of
internet connectivity persists despite doing everything suggested. All other
VMs on the system have their internet connections working perfectly fine.
What are the next suggested steps to try? Should that fix have worked
regardless of using QWT 3.2.2.3 rather than 4.0, as long as the base system is
Qubes 4 instead of 3.2? If not, what options should I be using for my specific
situation? What do I do from here to get internet connectivity back?
--
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+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/a0504ed0-b571-40ce-ad9c-e4d8bd868c89%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[qubes-users] HCL - Dell Latitude E6520
Issues with Wifi adapter -- 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+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/82e712bf-de9a-4c08-8167-6cfeb58b687e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout. Qubes-HCL-Dell_Inc_-Latitude_E6520-20181112-121135.cpio.gz Description: Binary data Qubes-HCL-Dell_Inc_-Latitude_E6520-20181112-121135.yml Description: Binary data
Re: 'invisible' blobs are blobs too (Re: [qubes-users] HCL - Purism Librem 13 v2)
I have to say, while im happy to see people are actually trying to get a constructive discussion here, im missing facts, sources and numbers. The only blob in an X230 which could be security relevant imo is the embedded controller. The EC will most likely be liberated in the near future, and even if it isnt, that is just no comparison to the amount of attack-surface and security-relevance of the blobs a Librem contains. But thats a personal opinion, there are some who consider stock-bios not a problem at all, because their threat-model does not contain such highly-skilled attacks or they trust the vendor. However, UEFI-exploits from non-state-actors have already been found in the wild, and will become a lot more common imo. Example: https://www.welivesecurity.com/2018/09/27/lojax-first-uefi-rootkit-found-wild-courtesy-sednit-group/ About the Intel-ME: The other blob in an x230 is be the "ROMP/BUB"-module (which is the only part left from the Intel ME), roughly around ~90 kB after me-cleaner (~ 1.5 MB without), and, very important, the me is shut down before the kernel initializes. The Me-version Generation 3 like they are used in a Librem, however, are after applying ME-cleaner "rbe", "kernel" , "syslib" AND "bup" , and the minimum firmware-size is at best ~ 300 kb, and is not shut down at all. BTW, i feel like people overestimate the relevance of the Intel Managment Engine. THere is so much fake-news about the ME, its ridiculous. That being said, i personally would never use a device for sensitive stuff with ME-generation 3 ore higher, and certainly not one with a prop BIOS ore a significant amount of dangerous blobs.Again, these are personal choices, bashing without even providing any sources to fact-check for the reader wont help anybody. While i would love to have the option of buying a completely free Laptop directly from a vendor, i have serious doubts about how this would be possible with x86 architecture, and i wanst able to find any specific information on how pursim is planning to achieve that. Freeing a Librem isnt simply a matter of more work and development, without having Intels signing keys, it is flat-out technically impossible. And i would love to believe that Intel will provide Purism those keys, but given the fact that they didnt do it even for Google, i doubt it even more. Some more information on this matter would be really great, maybe im missing something? If any of these information are incorrect please tell me so, and most important, please provide sources. On 11/12/18 12:15 PM, unman wrote: > On Mon, Nov 12, 2018 at 09:58:25AM +, Holger Levsen wrote: >> On Sun, Nov 11, 2018 at 03:45:21PM +, unman wrote: >>> lenovo x230s are still widely available, and great for Qubes. >> while I agree with that, I want to point out that they contain several >> non free blobs which cannot be changed. >> >> just because there was so much purism bashing in this thread. :-D >> >> >> -- >> cheers, >> Holger, who is happy that his keyboard, memory and battery works > Try, but 22rip didnt have that as a criteria in his choices. Also, the > x230 keyboard,memory and battery all work. ;-) > -- Kind Regards Jonathan Seefelder CryptoGS IT-Security Solutions Hofmark 43b D-84564 Oberbergkirchen Phone: +49 8637-7505 Fax: +49 8637-7506 Mail: i...@cryptogs.de www.cryptogs.de -- 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+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/a94c36f7-ecee-caa4-ba93-381acde1a6c0%40cryptogs.de. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] Re: Removing KDE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 11/12/18 1:03 AM, unman wrote:> Though why you would want to remove Plasma? So easy to configure and > customize, and really enhances Qubes experience. > > unman Yeah! I hope someday KDE will be default desktop again. Unfortunately there are some bugs with tasks tray and domains/devices widget. -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEznLCgPSfWTT+LPrmFBMQ2OPtCKUFAlvphP0ACgkQFBMQ2OPt CKVhGA/+N+FSE6u496K2tTgU2Mgver1KCVTFQxSE8WuKL2HXx2TygKEptHW8HfFl /7XnFzzAxZrWNEBDc26bc8FJm30B+PmG/w9JiRjSCiz/5d4gk2vjP1IaawgAEKs6 2/UR6FcwPV3L2Ja9CyTYKz5T0ZTj5Oax6rGCVHyogBkeNwOWV1Nywl8xtBLZhYFO rHWYlcBaZKnMejVGF4qxr/Ku7L2IA0I/uhIcw2IQMWXUqvQD7CafPxKrrrgJFpC9 sOhG+U8JbpoiPCHB13vDdgXQqNYamAmIMozYAtqRikEDutdJ8THDVx+RaWWMk0jT NnvCmraOHvkQwISunq4FZobURYI5UjbvSwRcfYJ7CMz5LcYQVjRu7vYGWN9JF9XN PZEs0LIdyLIM2s1LdiTlhfnxUJcWMnoJzmCpqnkpV3vMlf/qpMmQDgxJ7Wa76v5o ccNVwzYWsUga0KkYwNdJdLlneG1h+X6YzMIwm+BT3SWPsbxRgWVcIQsK8AT7uCyO +FbM8Ki5U1P5seHRLC7hwR4m9LPvRwdJut5KTqQItRUkQJjrCS0HcV96BIfMldCv aB2kit/KlVq76s+ed8q4SkfrEmGQBM6Mnp7MEWXdgNIwUm5UbzDoC/K34bTkcidj ApRvATfBPEdHh6HHs0FSVHFRV3p16Nt+xyjym4YHJWMwvEg93QY= =gQxu -END PGP SIGNATURE- -- 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+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/6d699ca7-a369-5577-44fc-dfab24310ac0%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: 'invisible' blobs are blobs too (Re: [qubes-users] HCL - Purism Librem 13 v2)
On Mon, Nov 12, 2018 at 09:58:25AM +, Holger Levsen wrote: > On Sun, Nov 11, 2018 at 03:45:21PM +, unman wrote: > > lenovo x230s are still widely available, and great for Qubes. > > while I agree with that, I want to point out that they contain several > non free blobs which cannot be changed. > > just because there was so much purism bashing in this thread. :-D > > > -- > cheers, > Holger, who is happy that his keyboard, memory and battery works Try, but 22rip didnt have that as a criteria in his choices. Also, the x230 keyboard,memory and battery all work. ;-) -- 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+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20181112111521.or4rlgnl5gtp5xjf%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] [solved] Re: Failed to synchronize cache for repo 'qubes-dom0-cached', disabling.
On Sat, Nov 10, 2018 at 12:54:46PM +0100, Alex wrote: > On 11/10/18 11:23 AM, hm...@tuta.io wrote: > > hello > > > > I have exactly the same problem on two of my x230 Lenovo notebooks with > > Qubes version R4.0.1rc1. > Have had this very issue on R4.0. > > I checked by running, in dom0: > # qubes-dom0-update -v > > That runs the dnf updater with the "-v" verbose flag. With that, the URL > for the repositories will be printed on screen, in red (because it's > happening in the UpdateVM). > > I found that the URL being printed was > https://yum.qubes-os.org/r25-4/current/dom0/fc25/repodata/repomd.xml.metalink > > instead of the correct > https://yum.qubes-os.org/r4.0/current/dom0/fc25/repodata/repomd.xml.metalink > > (the yum.qubes-os.org domain can be navigated with a browser). > > I found that inside [dom0]/etc/yum.repos.d/qubes-dom0.repo the url is > saved as > https://yum.qubes-os.org/r$releasever/current/dom0/fc25/repodata/repomd.xml.metalink > > Changed that with nano to read "4.0" instead of "$releasever" and voilà, > updates went through. > > Check, try and let the list know ;) > > -- > Alex Please bear in mind that if you do this you are breaking the logic of dnf, and will have to *manually* update that entry if you upgrade the system. You are almost bound to forget this. $releasever is part of yum/dnf, not Qubes. You can pass in --releasever=4.0 as an option, which would be a better solution. I havent encountered this bug myself,so cant account for it. It might be helpful if those who have could say if they have enabled testing repos, or are using plain 4.0 Qubes repositories. Any other detail would be helpful. unman -- 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+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/2018111209.nj6lj7dotaeegxvq%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
'invisible' blobs are blobs too (Re: [qubes-users] HCL - Purism Librem 13 v2)
On Sun, Nov 11, 2018 at 03:45:21PM +, unman wrote: > lenovo x230s are still widely available, and great for Qubes. while I agree with that, I want to point out that they contain several non free blobs which cannot be changed. just because there was so much purism bashing in this thread. :-D -- cheers, Holger, who is happy that his keyboard, memory and battery works --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C -- 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+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20181112095825.65tlq4mjdqgo2lh4%40layer-acht.org. For more options, visit https://groups.google.com/d/optout. signature.asc Description: PGP signature
Re: [qubes-users] Re: Updated Debian template-Recieved "Configuring grub-pc" message??
mandag den 12. november 2018 kl. 03.10.59 UTC+1 skrev 22...@tutamail.com: > Thank you both for the comments... > > In the message I remember a statement: "..This menu allows you to > select...automatic run for, if any...running grub-install automatically is > recommended". I believe it also said something to the effect: "...will use > the previous selection..." > > Considering I already completed the update and everything is working should I > be concerned? Would anything bad already have happened? Next time I'll pick > try the "/dev/xvda" file and see what happens but does it default to the same > selection as prior to the upgrade when nothing is selected? > > Thanks again... If your TemplateVM/AppVM/StandaloneVM is able to start up, after you have done the upgrade then I don't think you should be concerned. Just keep in mind in the future, that you should use /dev/xvda as your device for grub :) -- 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+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/cdb493ad-0ad1-4cb4-bd09-44a51d10ef7d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Removing KDE
mandag den 12. november 2018 kl. 01.03.18 UTC+1 skrev unman: > On Sun, Nov 11, 2018 at 09:54:08AM -0800, aaq via qubes-users wrote: > > søndag den 11. november 2018 kl. 17.17.27 UTC+1 skrev a...@it-minds.dk: > > > Hello everybody! > > > > > > I wanted to try out KDE with Qubes 4, but found that it was simply too > > > much compared to my needs. > > > > > > Unfortunately, removing KDE again isn't as simple as installing it. My > > > biggest issues is that it hijacked some core components across the > > > system, even though I am not using KDE (such as the notification frontend > > > among other things). > > > > > > I found an old thread where Marmarek suggested using `dnf mark install` > > > on the packages that dnf wrongly tries to remove, but dnf remains way too > > > aggressive in what it wants to remove. > > > > > > Basically dnf wants to remove everything X related, not only the KDE > > > stuff installed. > > > > > > If anybody knows any way of reverting and purging KDE completely, I would > > > be eternally grateful! > > > > > > Otherwise I might just have to backup all my stuff and go for a reinstall > > > :( > > > > > > Thanks in advance! > > > > > > PS: Lesson has been learned.. don't mindlessly install unncessary things. > > > Thanks. > > > > So.. > > > > I ended up deleting most of the packages (if not all) by hand. > > Unfortunately, my system is in a limbo mode right now. The notification > > front end still looks weird (in dom0), and my lightdm is presented with a > > black background. Other than that, my system works fine. > > Kind of annoying in this state, but works. My OCD is just getting the best > > of me :) > > > > It would be nice with some comments in the documentation on the website > > about KDE being hard to revert from, or at least some specific instructions > > on how to revert. I would be more than happy to contribute with that, but I > > am going to need some help with the steps needed. > > > > Hope someone will chime in! > > The simplest way to remove (most of) KDE is, I think: > dnf remove kdelibs,plasma-workspace > > Removing those packages pulls out those that depend on them while > leaving Xfce (and X) untouched. > > Though why you would want to remove Plasma? So easy to configure and > customize, and really enhances Qubes experience. > > unman Honestly I completely agree. If I was to use a DE I would definitely prefer KDE or GNOME over XFCE (I sincerely hate XFCE, loose opinion held strongly). I am however an avid user of i3, and since most of my stuff is opened and configured through templatevm/standalonevm, I don't really have a particular need for a heavy dom0 DE. My machine only has 8 gb of RAM, and so far that is more enough for my usage, but I fear if I bloat dom0 too much, that I might end up having some issues.. My biggest issue right now is, that after I installed KDE and logged in to Plasma, it didn't correctly override all the XFCE/gtk stuff. So my machine was in a state where it started up some things from kde and some stuff from xfce. That was obviously completely unwanted behavior.. If you have some guidelines though, as to how I can switch off xfce stuff and turn completely to the dark side, I mean KDE, then I would appreciate your time. Thank you! Regards! -- 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+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/9f551631-973e-4816-8907-eaf574b377be%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] System won't start after adding video card to qube
Dear Community, I wanted to change the resolution of a HVM. I couldn't, then I come up with the idea of adding the video card as a device to the VM. Then everything became dark and the system halted, which is I guess normal, because in retrospect this was a bad idea. But, the VM is not set to start on boot, so I don't understand why the system won't start. Failed to start default.target: Transaction is destructive. See system logs and 'systemctl status default.target' for details. initrd.target - Initrd Default Target Loaded: loaded (/use/lib/systemd/system/initrd.target; static; vendor preset: enabled) Active: inactive (dead) Docs: man:systemd.special(7) The qube that is causing the problem can be deleted, it was just for testing purposes only, but I don't know how to delete a qube from emergency shell and I don't know if that would solve my problem. Thank you in advance! Imestin -- 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+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/LR6179p--3-1%40tuta.io. For more options, visit https://groups.google.com/d/optout.
