On Tuesday, November 7, 2017 at 7:27:48 PM UTC, Marek Marczykowski-Górecki wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On Tue, Nov 07, 2017 at 04:33:27AM -0800, Frédéric Pierret (fepitre) > wrote: > > Hi, > > I'm experiencing something strange in Qubes 4.0rc2: when I try to > > qvm-open-in-vm several images in the same vm it seems to does not work. > For > > e.g. from work appvm: > > > > qvm-open-in-vm '$default' appel.jpg (then I choose e.g. personal), It > opens > > great and I keep the image open in personal, and then I do the same with > > appel2.jpg but the image does not appear and does not exist in > /tmp/work-* > > > > Doing this with two differents targets VM or with e.g. PDF or TXT works > > great. Can someone test it please (just before trying to eventually > deeply > > debug...)? > > I can confirm this behavior. (I guess) it is because the opening the > second file in fact open it in the same viewer/editor instance. And that > command exit immediately after sending a message to main (first) > instance. So qvm-open-in-vm (in fact, /usr/lib/qubes/vm-file-editor) > thinks you already closed the file and remove it from the target VM. > This is very similar to more general issue we have with gnome-terminal > in DispVM - the command you use to open app/file do not wait until you > close app/file. > > - -- > Best Regards, > Marek Marczykowski-Górecki > Invisible Things Lab > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQEcBAEBCAAGBQJaAgksAAoJENuP0xzK19csi/AH+gOZ1aUZVuLv6cKAjNBSckdK > o7hwZBhdwwyeeBJ3NYdl0R1VDXWOSK+RMdh5jPXnXVdJHjJb2CXJ2nwrofWwP8C0 > Kv4O3scER6Iq7iFOns/0C9pvXAVs9FI0T9rZ98kGy9isIugDDIJJR2ie7hvKBhg1 > BeSXLFIBNPv3TERRxOqiZpOkWh7+YmDZWsIpTX1nldsEZDzWxvkbKbOK+fg7RhY1 > AkBJFjNTbNPIhwIqXVBIBBB7Ygu4J0TNP6k7f9eWYqCJrGgc4ykAglK/UhUf4Cwx > 4lyhRWveNt4td5bGBOCslnIQNQYdztViIN/ubxAcQMcIk4kaXHaqR19zc1MxNEE= > =M00S > -----END PGP SIGNATURE----- >
Update: The new released dom0 updates seems to have done the trick, debian-8 now works flawlessly. Much appreciated! No discovered delay or issues either for qvm-run or qvm-open-in-vm in debian.8. Debian-9 works too, but it needs to sit idle for a minute or two when started up, before qvm-run works. Also pressing the qvm-run impatiently or too early, seems like it can bug out and then nothing starts at all. Which means the VM has to be shutdown and re-started before trying again. So in regard of debian-9, start it up, be patient for a minute or two, before starting anything. The exact same applies to any App-VM running on the debian.9 template. Debian-8 works normal and is quick. If others are in the same situation, II'd stick with debian-8 for now. Also for anyone trying to get debian-9 running with this delay, then don't trust the circular status thingy in the Qubes widget in regard to whether debian-9 is ready or not. The extra minute or two, is after it's done starting according to the widget, and not from the point you first started it. The amount of time may also vary from machine to machine? What was done on my side: - I rebooted all of Qubes after the new dom0 update, (just to be sure everything was in proper place). - Unlink any debian-8 templates. - sudo dnf remove qubes-template-debian-8 - sudo qubes-dom0-update qubes-template-debian-8 - Profit. Further details: I'm not 100% sure it was the updates, but given it did not work before the updates, and worked afterwards, with no other chances, I strongly assume its the updates that fixed it. Also, here are some more complicated details, that may or may not matter. At the time of the update, I did not have debian-8 installed, which I had removed the day before during my own attempts to fix it. I only had debian-9 installed when the updates came out. After running the dom0 updates, and rebooting, debian-9 still did not work. So I went ahead and installed the debian-8, which to my pleasant surprise, unlike the many previous attempts, now worked right out of the box after the install, and seemingly for now flawlessly at that. However, debian-9 did still not work, so I re-installed debian-9. When I started debian-9, it did still not work, but I stayed with it for a bit, trying to see if I could get it working. I found out that debian-9 has a time-lag, or delay, before it works after starting up. And if spamming the qvm-run, it'll stop working entirely. debian-9 must run idle after it has booted up, for a minute or two. But once there, it works flawlessly too (it seems, did not try debian-9 much). Now I do not know if these templates really required a re-install to fix them, after all, I had debian-9 at the time of the updates. As you must see by now, I did not test whether debian-9 had a time delay before trying to re-install it, and debian-8 was not installed. I tried to update the debian-9 template too, at this current time, it did not fix the delay. I presume it's the Qubes tools in debian-9 that needs updating, but debian-8 is fine for now. So for anyone else out there, if the update did not fix it, try re-install the template, and try stick for debian-8 until debian.9 is working. Presumably, debian-9 may also work for some, and not for others? Is worth considering. Again, thanks a lot for the update. With debian-8 now working, and all user mistake caused old fedora templates removed, and all old AppVM's that was broken replaced with new Qubes 4 AppVM's, and all files transfered, everything seems to be working correctly. Including the Xfce4 shortcuts, albeit I haven't tested whether the shortcuts work extensively yet on different AppVM's. -- You received this message because you are subscribed to the Google Groups "qubes-devel" 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-devel/db6e5c41-be34-4cc4-895b-a1854c3aac52%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
