[qubes-users] Re: Updated HCL report - Dell Precision 5520
On Sunday, May 6, 2018 at 9:46:32 AM UTC-4, Yassine wrote: > Updating previous report as reinstalling from 4.0-rc3 to 4.0 > > Needed to edit xen EFI config to remove mapbs/noexitboot keys and disable > nouveau modesetting (nouveau.modeset=0) Jim, Were you able to successfully install Qubes UEFI from the dd produced usb on your Dell Precision 5520? -- 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/d0d873d3-ef2f-4cdd-b53f-4e759184f602%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Paste not working from one appvm to another appvm's bash (4.0)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12/4/18 6:06 PM, s.w.i.m.on.qu...@gmail.com wrote: > I also do not have a middle mouse key, again, somewhere online > said that could be used as well. Yep, that's how I do it > Is there some way I can do this? Sure. 1) pipe the output of the program that prints the cypher into a file... # my_cipher_program > cipher_output.sh 2) send that text file to the other qube via # qvm-copy cipher_output.sh 3) in the target qube, edit the ciper_output.sh file to contain only the cipher and before that whatever command line statement this cipher is a parameter to. 4) make the script executable # chmod +x ciper_output.sh 5) run it # ./ciper_output.sh /Sven -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEE18ry22WNibwI1qeq2m4We49UH7YFAlwHI6YACgkQ2m4We49U H7Yq1xAA1moKk1d4+I/bIYF/Z8dEoGCtwMWOfeBYnFmNsbtvNPB2S1BYotAOsiCl NR59J/6ycIC1B9sRR8/joTwejlqx1zP42OB210DagpeAGteg5tWUbtj+wuWFBRzF McoLKcDNPF9k9oCNP0M3d80cDJFmtcGnlFB2Fp67jrhvOKNexIxl97LKGnPWk3gw YWV/sQW1XGzJ+u1tplfUomzj3cBLMV6lb+4KpWMS2VJf+lWKC0IXl8ny2koY1k8j ZkahLhEKwz2oES/NsQIah6id1gugLjj2DAONC4OG3yrgffzS8gDCBhZaYINQPTZy sJlOnFjWuOt9bEzd3qLgtt3K+puQBBZ9PcKTvTf7kHRN1C3qXDN123mJ2X5X/K/Z ld6MA4PTFaqkTKmS0JshAGgxDWg4xJmrXNAS7yn9aujrZ5sc3+Lg08jNLdycpo+2 02KHgKm15ytGtd+O7gXTtODW3JauJ0FQZwlFw4aN8qzeQLKRs8YwzhB63zyjlYwV mDD8893lz4nBlgPmI+iriT6YXEgoU5T4RwHnIPDJv1hf0Z0lTYiefMNkQbE/bafH RI2RyA/s7CuLw4yOLTNwPOZz2ffXHX0YGyIe02wdXCNAeMSdHkgtKLZXVGH1EYbZ TYDSiitUWW3G4EfU4N4ys/ZgFRCXGxQfWQjFULZl25ThYYtXNKM= =JsNQ -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/730d8e55-d18d-0af8-f027-6aed09c6e9e0%40SvenSemmler.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Paste not working from one appvm to another appvm's bash (4.0)
I have a Fedora minimal install hat I need to copy a very long cipher key into it's terminal from a file on another appvm. In the source appvm I can hit Ctl+C then Ctl+Shift+C and it will say 1Kb copied from 'appvm'. Going into the destination appvm xterm window (using passwordless sudo, qvm-run -u root 'appvm' xterm) I cannot paste using Ctl+V or Ctl+Shift+V. It will say "Qubes clipboard has been copied to the VM and wiped" but nothing prints into Xterm. Right clicking in the window does nothing. My keyboard does not have an Insert key, I read somewhere that can be used. I also do not have a middle mouse key, again, somewhere online said that could be used as well. Is there some way I can do this? I have already tried transcribing the cipher but the length of the cipher makes error checking nearly impossible without going crazy. Destination vm is a Fedora 27 minimal install with only qubes-core-agent-networking installed and the particular program I wanted to install on it. There didnt seem to be a specific 'clipboard' qubes dependency to install. -- 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/79ca34ef-aa93-45b2-929e-f2ffeecd4614%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Installed KDE, removed KDE, now lightdm and startx are broken
On Tue, Dec 4, 2018 at 5:41 PM wrote: > Hey all! > > Using Qubes 4.0.1-rc1, been updating with qubes-dom0-update > --releasever=4.0 > > I installed @kde-desktop-qubes, and then later uninstalled it. > > This seems to have ripped out lightdm and some other parts of X/Xfce. > > Now I don't have lightdm to login, and startx fails to load any video > driver. > > I can't seem to reinstall @xfce-desktop-qubes or similar. > > Any way to find all RPMs included in that group and download on another > machine to pass to the Qubes partition after opening with cryptsetup? > > Or, any other solution to this seem apparent? > > Thanks! > > - Devin > `startxfce4` allows me to get a graphical display up, but then I completely lose all input. -- 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/CAHe59t73ZhojpHrU9bE%3DvvsUcOXvq6aE9wgLCHcWGgvYwVYbbA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Installed KDE, removed KDE, now lightdm and startx are broken
Hey all! Using Qubes 4.0.1-rc1, been updating with qubes-dom0-update --releasever=4.0 I installed @kde-desktop-qubes, and then later uninstalled it. This seems to have ripped out lightdm and some other parts of X/Xfce. Now I don't have lightdm to login, and startx fails to load any video driver. I can't seem to reinstall @xfce-desktop-qubes or similar. Any way to find all RPMs included in that group and download on another machine to pass to the Qubes partition after opening with cryptsetup? Or, any other solution to this seem apparent? Thanks! - Devin -- 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/a4fa4176-fbba-4253-8001-9671426cee4b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Q4 qube-manager broke after dom0 software update yesterday
I was away for a week and dutifully did all my software updates upon
returning. After updating Dom0 the qube-manager that was running started
having problems, so I restarted it, but it then refused to run.
RuntimeError: the PyQt4.QtCore and PyQt5.QtCore modules both wrap the
QtObject class
The problem appears to be qube-manager/python3 is first picking up
references to PyQt5 when first launching, and later it is picking up
some PyQt4 references via
/usr/lib64/python3.5/site-packages/qubesadmin/__pycache__/*.pyc files,
which then load files from
/usr/lib64/python3.5/site-packages/PyQt4/__pycache__/* , and thus
PyQt4/QtGui.so gets loaded.
It looks like the qubes-manager-4.0.22-1.noarch is the latest, though I
can't help but think this is a case of cache poisoning or some Qt4/Qt5
environment issue. If so, can the __pycache__/*.pyc files be removed and
regenerated, or is there another way to avoid the mixing of PyQt versions?
thanks,
Steve
--
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/a6de8368-4610-3aad-22f8-41654217fc73%40jhuapl.edu.
For more options, visit https://groups.google.com/d/optout.
dom0> qube-manager
Traceback (most recent call last):
File "/bin/qubes-qube-manager", line 9, in
load_entry_point('qubesmanager==4.0.22', 'console_scripts',
'qubes-qube-manager')()
File "/usr/lib/python3.5/site-packages/pkg_resources/__init__.py", line 542,
in load_entry_point return get_distribution(dist).load_entry_point(group, name)
File "/usr/lib/python3.5/site-packages/pkg_resources/__init__.py", line 2575,
in load_entry_point return ep.load()
File "/usr/lib/python3.5/site-packages/pkg_resources/__init__.py", line 2235,
in load return self.resolve()
File "/usr/lib/python3.5/site-packages/pkg_resources/__init__.py", line 2241,
in resolve module = __import__(self.module_name, fromlist=['__name__'], level=0)
File "/usr/lib/python3.5/site-packages/qubesmanager/qube_manager.py", line
41, in from PyQt4 import QtGui # pylint: disable=import-error
RuntimeError: the PyQt4.QtCore and PyQt5.QtCore modules both wrap the QObject
class
dom0> sudo strace qube-manager
...
open("/usr/lib64/python3.5/asyncio/__pycache__/sslproto.cpython-35.pyc",
O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib64/python3.5/site-packages/PyQt5/__pycache__/__init__.cpython-35.pyc",
O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib64/python3.5/site-packages/PyQt5",
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
open("/usr/lib64/python3.5/site-packages/PyQt5/QtCore.so", O_RDONLY|O_CLOEXEC)
= 3
...
open("/usr/lib64/python3.5/site-packages/sip.so", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib64/python3.5/site-packages/PyQt5/QtGui.so", O_RDONLY|O_CLOEXEC) =
3
...
open("/lib64/libXau.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib64/python3.5/site-packages/PyQt5/QtWidgets.so",
O_RDONLY|O_CLOEXEC) = 3
...
open("/usr/lib/python3.5/site-packages/qubesadmin/__pycache__/tags.cpython-35.pyc",
O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/python3.5/site-packages/qubesadmin/events/__pycache__/__init__.cpython-35.pyc",
O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib64/python3.5/site-packages/PyQt4/__pycache__/__init__.cpython-35.pyc",
O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib64/python3.5/site-packages/PyQt4",
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
open("/usr/lib64/python3.5/site-packages/PyQt4/QtGui.so", O_RDONLY|O_CLOEXEC) =
3
...
open("/lib64/libuuid.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib64/python3.5/site-packages/PyQt4/QtCore.so", O_RDONLY|O_CLOEXEC)
= 3
open("/bin/qubes-qube-manager", O_RDONLY|O_CLOEXEC) = 3
...
open("/usr/lib/python3.5/site-packages/pkg_resources/__init__.py",
O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/python3.5/site-packages/qubesmanager/qube_manager.py",
O_RDONLY|O_CLOEXEC) = 3
/usr/lib/python3.5/site-packages/qubesadmin/label.py:
:py:meth:`PyQt4.QtGui.QIcon.fromTheme`'''
dom0> find /usr/lib/python3.5/site-packages/qubesadmin -type f -exec grep -Hi
Qt4 {} \;
Binary file
/usr/lib/python3.5/site-packages/qubesadmin/__pycache__/label.cpython-35.pyc
matches
Binary file
/usr/lib/python3.5/site-packages/qubesadmin/__pycache__/label.cpython-35.opt-1.pyc
matches
Re: [qubes-users] Q4.0 qvm-prefs kernel property vs the installed/latest kernel
On 11/22/18 8:00 PM, unman wrote: On Tue, Nov 20, 2018 at 01:03:43PM -0500, Steve Coleman wrote: I have two up to date fedora-26 templates, that have long since been upgraded to fc28, that are both apparently 'stuck' at kernel version 4.14.74-1. I apparently can not set either template to a newer kernel. There are a lot of customizations involved so I am hoping not to have to go back to the fc28 rpm and start all over. Both methods of inspection show the old kernel: QubeManager /QubeSettings/advanced/kernel/ qvm-prefs --get kernel The current/latest installed fc28 kernel version appears to be 4.18.18-200, yet this latest kernel does not even show up under the QubeManager settings, nor qvm-prefs, and absolutely refuses to set/update this 'kernel' key to this latest kernel version number. The qvm-prefs utility simply claims that this newer kernel version is not installed, yet "rpm-qa | grep 4.18.18-200" clearly shows that it is. In fact rpm says that the older kernel 4.14.74-1 is *not* installed. If so, then how is this template even running? I'm using it daily! I know dnf can block a package from upgrading, but that is clearly not what is happening here. The packages do update but apparently Qubes is just not seeing them, as to be able to display any in Qube-Manager or set/use them using qvm-prefs. The "Qubes Global Settings" shows the default kernel as 4.14.74-1, and I can't even change that, because the newer kernels are not listed there either. A file system scan for the old version number yields /usr/lib/modules/* directory that shows up with 4.14.74-1 as an *fc26* module rather than a fc28 module, so this whole version disparity appears to be due to some kind of botched fc26 --> fc28 system/module check routine during a past upgrade? At least that I my best guess at the moment of what broke and when. In fact /usr/lib/modules/4.14.74-1.pvops.qubes.x86_64/build/ is the only *build directory* where as all the newer kernels this is merely a symlink into /usr/src/kernels/*/ Is there anywhere that I would find a Qubes "version setting" that switches from fc26 modules to fc28 modules? Or is it just somehow scanning for this "build" directory and then ignoring the newer symlinks? Any clues of what this should be doing might be very helpful about now. thanks, Steve Steve, The appVMs are booting using kernels set in dom0. You can find more recent kernels in the testing repositories. Install them in dom0 and they will become available to use in your qubes. They are kernel-qubes-vm.. and kernel-latest-qubes-vm sudo qubes-dom0-update --enablerepo=current-testing --action=search kernel-latest-qubes-vm I think the "latest" is now 4.19.2, but you can specify earlier versions if you wish Thank you for that wonderful explanation. It turns out that the issue was that the package "kernel-latest-qubes-vm" was not installed in Dom0. So, no wonder I could not set any newer kernel version number. Not sure how that happened unless it was some kind of dependency being removed via some kind of conflict resolution. The only thing is there is absolutely *no rpm history* for this package! This gets chalked in as being a mystery in my book. thanks, Steve 8*} -- 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/798cc4fa-c84e-dfb6-765c-be56f9978ceb%40jhuapl.edu. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] connecting AppVM via jack to remote jack for sound output
No specific requirements, i just knew about Jack and there is a plethora of options jack1, jack2, netjack, JackTrip etc. but i will now dive into pulseaudio and see where it leads me, thanks for the hint Ivan. -- 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/701438f3-bc8b-4d76-b8a1-ec976e4a9b3c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] connecting AppVM via jack to remote jack for sound output
On 12/4/18 5:16 PM, dimi wrote: Have been reading up on jack audio control kit and decided to try out to get sound from my surfing AppVM over to a rpi3 which is connected to my PA. I'd prefer not to lay 25m Audio cables which is bad for sound quality and it also would free up my Desk from this little ugly Boxessess. Does anyone have any experience and success storys or can point me to a painless solution? IMHO your best bet would be to use pulseaudio over the network. I used that setup years ago but lost my notes so can't help with specifics, but searching "pulseaudio over network" on the web give plenty of useful info. It boils down to setting up pulseaudio on the rpi3 with the module-native-protocol-tcp module and configuring your AppVM to use a sink that sends audio to the network server instead of dom0. By the way, do you have any specific requirement for using JACK ? It's mostly used for low-latency/low-jitter audio stuff - which is orthogonal with tcp/udp. -- 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/46920fca-01b8-de3c-1c02-4ff61c2ea02c%40maa.bz. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Decrypting and mounting a partition while qube starts
mike:
I would decrypt in dom0 and attach decrypted to qubes. You can script
this in dom0 as part of startup process - if you are content with dom0
encryption you can store the password, rather than enter it each time.
Cool -- I like the idea!
What approach would you recommend for these:
a) if the partition was to be decrypted during dom0 boot -- where to script it?
b) if the partition was to be decrypted right before a qube's start -- is there
a pre-domain-boot script kind of thing?
c) if the password was to be typed -- any idea how to pop up some password
input dialog box?
Many thanks unman!
Mike
I'm decrypting my drive with two partitions and connect them to the VMs on
startup like this in dom0:
Keyfile: /root/my-drive-decrypt/keyfile
Script: /root/my-drive-decrypt/my-drive-decrypt.sh
#! /bin/bash
case "$1" in
start)
cryptsetup --cipher=XXX --offset=XXX
--key-file=/root/my-drive-decrypt/keyfile --key-size=XXX open --type=plain
/dev/disk/by-id/XXX my-drive
kpartx -a /dev/mapper/my-drive
vgchange -ay my-drive
qvm-block d my-drive1-vm $(qvm-block l my-drive1-vm | cut -f1 -d ' ')
qvm-block d my-drive2-vm $(qvm-block l my-drive2-vm | cut -f1 -d ' ')
qvm-block a --persistent -o frontend-dev=xvdi my-drive1-vm $(qvm-block
l | grep my-drive1 | cut -f1 -d ' ')
qvm-block a --persistent -o frontend-dev=xvdi my-drive2-vm $(qvm-block
l | grep my-drive2 | cut -f1 -d ' ')
;;
stop)
qvm-block d my-drive1-vm $(qvm-block l my-drive1-vm | cut -f1 -d ' ')
qvm-block d my-drive2-vm $(qvm-block l my-drive2-vm | cut -f1 -d ' ')
vgchange -an my-drive
sleep 1
kpartx -d /dev/mapper/my-drive
cryptsetup close my-drive
;;
status)
;;
*)
echo $"Usage: $0 {start|stop|status}"
exit 2
esac
exit 0
Service: /etc/systemd/system/my-drive-decrypt.service
[Unit]
Description="Decrypt my-drive"
Requires=qubes_core.service
After=qubes_core.service
[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/root/my-drive-decrypt/my-drive-decrypt.sh start
ExecStop=/root/my-drive-decrypt/my-drive-decrypt.sh stop
[Install]
WantedBy=multi-user.target
Enable service:
systemctl enable my-drive-decrypt.service
-
ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the
NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!
15GB disk! No bandwidth quotas!
Commercial and Bulk Mail Options!
--
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/780a6837-db03-70dd-622b-1e9ed185eede%40vfemail.net.
For more options, visit https://groups.google.com/d/optout.
[qubes-users] connecting AppVM via jack to remote jack for sound output
Have been reading up on jack audio control kit and decided to try out to get sound from my surfing AppVM over to a rpi3 which is connected to my PA. I'd prefer not to lay 25m Audio cables which is bad for sound quality and it also would free up my Desk from this little ugly Boxessess. Does anyone have any experience and success storys or can point me to a painless solution? I have found this two links but they achieve something different. https://www.qubes-os.org/doc/external-audio/ https://github.com/zamaudio/qubes-jack -- 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/8dd9cd2a-3621-4a74-8fd3-18fc619b9b1f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Decrypting and mounting a partition while qube starts
> I would decrypt in dom0 and attach decrypted to qubes. You can script > this in dom0 as part of startup process - if you are content with dom0 > encryption you can store the password, rather than enter it each time. Cool -- I like the idea! What approach would you recommend for these: a) if the partition was to be decrypted during dom0 boot -- where to script it? b) if the partition was to be decrypted right before a qube's start -- is there a pre-domain-boot script kind of thing? c) if the password was to be typed -- any idea how to pop up some password input dialog box? Many thanks unman! Mike -- 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/6c9c0c8f-b5af-461f-b1a3-a9f96917fa94%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
