[qubes-users] Re: Installing Win7 on a Dell
On Monday, February 19, 2018 at 6:08:44 AM UTC+1, Glen H wrote: > On Sunday, February 18, 2018 at 9:59:24 AM UTC-5, Daniel Moerner wrote: > > On Saturday, February 17, 2018 at 9:06:03 PM UTC-5, Glen H wrote: > > > Hi, > > > > > > I'm a new user and am trying to get Win7 Pro x64 installed in Qubes 4rc4. > > > I have a Dell e7440 and it doesn't come with a Windows .iso. Before I > > > installed Qubes I used the Dell recovery tool to create a recovery usb > > > disk for Win7 to re-install the OS but I'm not sure if this is usable to > > > install with Qubes. > > > > > > I tried following the instructions on the Qubes website by creating a new > > > Qube without a template but I could not change it from PVM to HVM. Then > > > when I tried booting from the USB recovery disk it would load up a > > > terminal and then exit after 10 seconds. > > > > > > When I try to boot the recovery USB disk from the main BIOS it boots up > > > fine. Does anyone have any tips for installing Win7 in Qubes 4? > > > > > > Thanks, > > > > > > Glen > > > > Hi, > > > > Check out these two issues: > > Installing Windows 7: https://github.com/QubesOS/qubes-issues/issues/3592 > > Installing Qubes Windows Tools: > > https://github.com/QubesOS/qubes-issues/issues/3585 > > > > The two problems you describe in the post seem to be the following: > > 1. Use qvm-prefs to set the virt_mode to hvm; the GUI doesn't work. > > 2. Make sure you set the video-model to cirrus for install. > > > > Best, > > Daniel > > Hi, > > Thanks for the tips Daniel. I'm stuck at not being able to boot from the usb > disk. I am doing: > > ``` > qvm-create --class StandaloneVM --label red win7new > qvm-prefs win7new virt_mode hvm > qvm-prefs win7new memory 4000 > qvm-prefs win7new maxmem 4000 > qvm-prefs win7new kernel '' > qvm-volume extend win7new:root 25g > qvm-prefs win7new debug True > qvm-features win7new video-model cirrus > > # Then attach usb drive to untrusted, but all of these fail to boot: > > qvm-start --hddisk untrusted:sda win7new > qvm-start --hddisk untrusted:sda1 win7new > qvm-start --hddisk untrusted:/dev/sda win7new > qvm-start --hddisk untrusted:/dev/sda1 win7new > ``` > > I'm not sure whether to use the whole drive (no name) or the first partition > (named DELLRESTORE)...but I tried both. > > I get the error message in the win7new terminal: > > ``` > SeaBIOS (version ...) > Machine UUID ... > Booting from Hard Disk... > Boot failed: not a bootable disk > > Booting from Floppy... > Boot failed: could not read the boot disk > > No bootable device. > ``` > > So it seems that it doesn't recognize the USB drive as bootable even though I > can boot it from the main BIOS (in legacy mode). > > Any help would be appreciated. > > Glen First, welcome to the Qubes community! :) A few things first, starting to use Qubes can be a bit overwhelming, but you'll get the hang of it over time if you keep using it. For starters, look here in the command you use "untrusted:sda" which is something Qubes exclusive and you therefore had no chance knowing this. Untrusted, is a word that needs replacing for whichever untrusted AppVM you're using to hold your USB or SATA controllers. It's called untrusted because dom0 is trusted, and you need to use an less untrusted domain that doesn't compromise your more trusted domain, dom0. This is a bit tricky for new users to catch on, on, as it's ambiguity for new users, at best. To solve this, then you first need to figure out where your controller is located. If you have no sys-usb or similar, then it's likely still in dom0. It's insecure to keep this in the secure dom0 domain, but mostly you should be fine for some time yet if you're not a high target profile, and never leave your computer unattended in public or near people you don't trust with your life. Still, having it in dom0 is still more secure than not using Qubes. Just keep in mind you eventually want to migrate away from using dom0 for anything, but it's not always easy just yet due to some fixes and hardwares require you still manually manage dom0 from time to time, so it's not yet entirely a users responsibility, as there are still times when you need to use dom0. So if your USB or SATA controllers are in dom0 (Your SATA controllers will be if you did not move them yourself, and USB controllers depend on your hardware, the installer might or might not have done it automatically). If you don't have a sys-usb VM, then it's probably still in dom0. I don't know your current knowledge on Linux, so I'll take the liberty to add more details just in case. In conclusion from the above, instead of untrusted, it should look like this dom0:sda for dom0, and sys-usb:sda for sys-usb, whereever that controller is located. further, sda may look like sdb, sdc, or if adding partitins, like sdb2 or sdf4. It's kind of like C:/ in windows, followed by d:/ for your DVD drive, on most machines. Instead it's "sd" follow
[qubes-users] Re: Installing Win7 on a Dell
On Sunday, February 18, 2018 at 9:59:24 AM UTC-5, Daniel Moerner wrote: > On Saturday, February 17, 2018 at 9:06:03 PM UTC-5, Glen H wrote: > > Hi, > > > > I'm a new user and am trying to get Win7 Pro x64 installed in Qubes 4rc4. > > I have a Dell e7440 and it doesn't come with a Windows .iso. Before I > > installed Qubes I used the Dell recovery tool to create a recovery usb disk > > for Win7 to re-install the OS but I'm not sure if this is usable to install > > with Qubes. > > > > I tried following the instructions on the Qubes website by creating a new > > Qube without a template but I could not change it from PVM to HVM. Then > > when I tried booting from the USB recovery disk it would load up a terminal > > and then exit after 10 seconds. > > > > When I try to boot the recovery USB disk from the main BIOS it boots up > > fine. Does anyone have any tips for installing Win7 in Qubes 4? > > > > Thanks, > > > > Glen > > Hi, > > Check out these two issues: > Installing Windows 7: https://github.com/QubesOS/qubes-issues/issues/3592 > Installing Qubes Windows Tools: > https://github.com/QubesOS/qubes-issues/issues/3585 > > The two problems you describe in the post seem to be the following: > 1. Use qvm-prefs to set the virt_mode to hvm; the GUI doesn't work. > 2. Make sure you set the video-model to cirrus for install. > > Best, > Daniel Hi, Thanks for the tips Daniel. I'm stuck at not being able to boot from the usb disk. I am doing: ``` qvm-create --class StandaloneVM --label red win7new qvm-prefs win7new virt_mode hvm qvm-prefs win7new memory 4000 qvm-prefs win7new maxmem 4000 qvm-prefs win7new kernel '' qvm-volume extend win7new:root 25g qvm-prefs win7new debug True qvm-features win7new video-model cirrus # Then attach usb drive to untrusted, but all of these fail to boot: qvm-start --hddisk untrusted:sda win7new qvm-start --hddisk untrusted:sda1 win7new qvm-start --hddisk untrusted:/dev/sda win7new qvm-start --hddisk untrusted:/dev/sda1 win7new ``` I'm not sure whether to use the whole drive (no name) or the first partition (named DELLRESTORE)...but I tried both. I get the error message in the win7new terminal: ``` SeaBIOS (version ...) Machine UUID ... Booting from Hard Disk... Boot failed: not a bootable disk Booting from Floppy... Boot failed: could not read the boot disk No bootable device. ``` So it seems that it doesn't recognize the USB drive as bootable even though I can boot it from the main BIOS (in legacy mode). Any help would be appreciated. Glen -- 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/582b151d-3198-4c85-93bf-4608075505d2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Q4rc4 :: qvm-prefs-screenshot-to-clipboard - 1st attempt
On Sunday, February 18, 2018 at 11:00:35 PM UTC+1, [799] wrote: > -- > Qubes 4rc3 > Lenovo X230 + Lenovo W540 > > Gesendet von ProtonMail mobile > > > > > Original-Nachricht > An 18. Feb. 2018, 22:25, Yuraeitha wrote: > > On Saturday, February 17, 2018 at 11:11:40 PM UTC+1, [799] wrote: > > Hello, > > > > having the idea of a qvm-screenshot-to-clipboard script I was eager to try > > writting a script. > > The solution I had in mind could work but I am struggling with a small > > issue and would like to get some help. > > The script takes a screenshot in dom0, store it to a file and qvm-copy the > > file to the target appvm (one and only command line argument for the > > script). > > Then within the AppVM it is using xclip to copy the graphic to clipboard > > and removes all temporary files in the AppVM and dom0 > > All pieces are working, except the xclip command when launced from dom0. > > > > When I launch the command within the AppVM it is working. > > But I need to start the xclip command from an external script and when I do > > so, the same command is not working. > > It seems that I am missing something when using xclip via script which is > > run in a new terminal session (from dom0 but also within the App) > > > > Any ideas how to fix this? > > It feels so frustrating that I nearly have a working solution but I am > > missing the last few meters. > > > > How to use the script: > > > > 1) in dom0: launch script > > > > 2) make the screenshot by selection the area > > > > as the xclip is not working in the AppVM as supposed: > > > > 3) switch to the AppVM where the screenshot should be used > > > > 4) launch the "helper script" in the AppVM which is running the following > > command > > > > xclip -selection clipboard -t image/png > > /home/user/QubesIncoming/dom0/qvm-screenshot-to-clipboard.png > > > > My qvm-screenshot-to-clipboard script which has to be placed and run from > > dom0: > > > > --- BEGIN of script --- > > > > > > #!/bin/bash > > # qvm-screenshot-to-clipboard > > # Creates a dom0 screenshot and copy it to the Clipboard of an AppVM > > > > MyAppVM=$1 > > MyScreenshot=qvm-screenshot-to-clipboard.png > > > > # Take screenshot in dom0 by selecting an area and adding border+shadow > > gnome-screenshot --area --include-border --border-effect=shadow > > --file=/tmp/$MyScreenshot > > > > # Copy screenhot to AppVM command line argument / delete existing file > > > > qvm-run $MyAppVM 'rm -f /home/user/QubesIncoming/dom0/$MyScreenshot' > > > > qvm-copy-to-vm $MyAppVM /tmp/$MyScreenshot > > > > ###FIXME begin > > > > # I would like to just invoke the following > > # command via qvm-run in the AppVM > > # but the clipboard is just empty when using > > # this approach. > > # running the same command > > # xclip -selection clipboard -t image/png > > /home/user/QubesIncoming/dom0/qvm-screenshot-to-clipboard.png > > # therof I have put the command into a helper > > # script in my AppVM: > > # qvm-run $MyAppVM /home/user/qvm-screenshot-to-clipboard-appvm.sh > > # the script is working when it is launched from > > # an already opened gnome-terminal window > > # but it will not work when the script is invoked > > # from dom0 via qvm-run or through an own > > # strangely it is also not working when I start > > # the script from within the appvm > > # 'xterm -e > > > If interested, I've recently made a similar > > script that works a little differently. > > [...] > > mv "$(xfce4-screenshooter -fo ls)" ~/Screenshots > > ( sleep 3 ) > > qvm-move-to-vm Base ~/Screenshots/screenshot_* > > [...] > > Your scripts can be used to save all screenshots to a folder in an AppVM > whereas my scripts is mainly for quick copy'n paste. > > I think I'll also change my script to use xfce4-screenshoiter instead of > gnome-screenshot. > Thanks for the hint. > > I have uploaded my script to GitHub, maybe you should do the same or we add > it to the repository so that users can pick the right script for their needs? > > As you mentioned: > Choice is always a good thing. > > [799] @ [799] Aight, I followed up on your suggestion and made a wiki for this script. Feel free to use it any way you like. https://github.com/Aekez/scripting-qubes/wiki/Streamlining-the-Screenshotting If our scripts in the end can't be merged without loosing strengths or avoiding new weaknesses in them, then perhaps an idea could be to use ideas from each others scripts which work. For example if you're okay with it I might add the clipboard functionality. Of course crediting you. But then there is the question if our scripts could essentially be merged into a single script by such a move? If so, then I don't mind you posting it, I'll simply add a reference to your script in the wiki so anyone reading it will be made aware of yours. Credits doesn't matter much to me, so I don't mind if you put a merged script together, if this
[qubes-users] Re: Undoing an errant qubes-dom0-upgate
On Monday, February 19, 2018 at 2:43:59 AM UTC+1, Demi Obenour wrote: > I ran qubes-dom0-upgate with the testing repo enabled, which broke my system. > How do I recover? How was it broken? Can you reach dom0? or can't you boot at all? Any error messages of interest appearing during failure? For example during grub, kernel, xen, graphic and x-server errors, virtualisation errors? Do you have access to the journalctl command? Can you reach the dom0 system with recovery mode, from your Qubes install media? Do you remember the nature of the updates you installed? Was there a kernel included? Xen perhaps? Something you remember? even a single word might be insightful and give a better clue. You can always manually extract your AppVM's data from a live medium boot, but this, is probably a last ditch resort if nothing else works. But for that, we need more information to go on, there are literally beyond thousands upon thousands of ways a system can break. But a clue, can for example narrow it down to 30% of all the ways something broke, and another clue perhaps further narrowing down the possible culprit. Therefore, information is vital here, more is needed. -- 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/08eaa4e0-af53-4663-bec3-49f789bd7799%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Undoing an errant qubes-dom0-upgate
I ran qubes-dom0-upgate with the testing repo enabled, which broke my system. How do I recover? -- 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/CAJEMUN_cVZXCkW4DoNA_dot0qXbNg_Njfeo7frmNmg0C%3DTVLBw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Did qubes-dom0-upgrade to R4.0, won't boot
On Monday, February 19, 2018 at 1:09:08 AM UTC+1, Demi Obenour wrote: > I upgraded my install to R4.0 and now my system won't boot. How can I fix it? > > > Some notes: > > > - Firmware recognizes Qubes, tries to load it > - Qubes won't boot > - The filesystems CAN mount when I do a rescue boot. > - Transient message is attached I did not watch the video you attached, can you perhaps instead describe what happens? For example, does your screen go black during boot after install? or during early install? Such details may provide vital clues. It sounds a lot to me like it's a graphic driver issue, which is probably due to the kernel, or associated modules. Everything written below, follows that "assumption". - For Grub, you can easily temporarily modify the grub settings during early boot, by pressing the E key on a grub menu. Put "nomodeset" somewhere in the latter part of the Module line. - For EFI, you'll have to either fetch a live-boot to gain access to Qubes root system, and then edit the efi.cfg file found somewhere in /boot, typically /boot/efi/EFI/qubes/xen.cfg or something like it, or if you're terminal savy, you can edit the file directly from the qubes dom0 terminal that you reported you gained access to (probably the most easy if you're that far already). This fix applies both to the EFI installer medium, as well as any finished installed system booting via EFI, whichever is having the black screen. - Grub is by far the most quick to troubleshoot, but they may also act differently, for example on which drivers they load. Try both approaches, see if one works. - You can also try disable IOMMU for GTX graphics. If you know your system fully meet the system requirements, then try change UEFI settings. Sometimes it's a rogue setting messing everything up, sometimes it may be a really unlikely setting. For example I've once seen Qubes unable to boot up, because external graphic card was sharing memory with the internal graphic card. Stuff like this, trial and error and see if you can find something. -- 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/0a702dad-5c90-4de9-9e10-4faf1f0b9a89%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Custom 16:9 dispay resolution to be applied at qubes-os startup (Q4.0rc4)
On Sunday, February 18, 2018 at 11:17:48 PM UTC+1, cub...@tutamail.com wrote: > Hi, > Could anyone help me with figuring out how to set one of the custom display > resolution as startup default? > > Qubes 4.0 rc 4 comes with many predefined resolutions but unfortunately only > one with the aspect ration of 16:9. > > I then created various custom resolution modes and added them to desplay > options. I used the following commands: > cvt - to get new mode parameters > xrandr --newmode - to define new resolution mode > xrandr --addmode - to add newly defined resolution mode to deplay drop-down > box > xrandr --output - to apply new, desired resolution to the current display. > > What I can't work out is how to make of my new, custom resolution to be used > by qubes-os as default. > What qubes-os configuration files should I modify and how in order to achieve > that? Do I need to interfere with xen.config? > > If you already have a solution please share. > > Thank you > Paul I must have brainfarts today, I keep remembering things I should have mentioned. In order to execute your scripts inside an AppVM, with keyboard controls located in dom0 or sys-usb, you'll need to use something like this, a command that executes a command inside your AppVM. If the command in the AppVM is small enough, then you can also bypass the script in the AppVM entirely, and just execute the command directly from the keybind in dom0, instead of executing a full script. You might have to modify it a bit, it can be a bit erm, how to put it, special at times. But once you have the right modified command down, you just need to back it up so you don't loose it again. qvm-run AppVM "gnome-terminal -e command-to-execute -options, etc." qvm-run AppVM "terminal" etc. qvm-run AppVM bash etc. Basically, it depends on the AppVM's terminal, bash and PID logic, and what not. Try experiment with it. -- 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/fb73fc97-e012-4f8e-8b74-c11fd07733ad%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: HP 1040 G3 laptop - wireless toggle button doesn't work
On Sunday, February 18, 2018 at 8:49:09 PM UTC+1, cub...@tutamail.com wrote: > Hi, > I've installed Qubes-OS 4.0 rc4 on HP 1040 G3 laptop. > It seems HP has changed the rules of the game and introduced dedicated driver > for the physical wireless toggle button (located above the keyboard, next to > the audio on/off button). > I actually test installed Windows 10 on the laptop to confirm the new > feature. And indeed, without installing "wireless button driver" pressing the > button would not cause any effect. > The same holds true with Qubes-OS installed on the laptop. > > Is there any way of forcing this button to work? It works fine on older HP > laptop models but they seems to be tightening their hardware architecture > even further. > > My alternative approach for now is to create scrips in sys-net VM to load / > unload kernel modules (sudo rmmod iwlmvm / sudo rmmod iwlwifi / sudo modprobe > iwlwifi). This does work fine but is not as elegant as pressing dedicated > button. > > Please share your thoughts and suggestions on forcing HP 1040 G3 to behave. > > Thank you > Paul As for your wireless button, you can do the same as above, write it in a script, and keybind it. While the specific keybind key may not be changeable, you can literally pick any other default keys to keybind instead. I'm not sure about the fan speed thingy, it sounds like you either need a better kernel module (kind of like an external, optional, secondary driver from the kernel's more primary drivers, if using windows language), or a poor setting in UEFI. It could also be a bad UEFI version that requires UEFI to be updated, but you may want to try other fixes before updating your UEFI, which can go wrong if not done properly, bricking your laptop's motherboard. But perhaps you have done it before, in which case, it's less dangerous if you know what you get yourself into here. But try see if you can find a kernel moduel first for your CPU/motherboard, try google any Linux systems using your hardware, this is not something unique to Qubes, but may likely appear on any number of Linux systems using this hardware. -- 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/fc96c952-68a9-4391-9a41-c7b1581ca71c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Custom 16:9 dispay resolution to be applied at qubes-os startup (Q4.0rc4)
On Sunday, February 18, 2018 at 11:17:48 PM UTC+1, cub...@tutamail.com wrote: > Hi, > Could anyone help me with figuring out how to set one of the custom display > resolution as startup default? > > Qubes 4.0 rc 4 comes with many predefined resolutions but unfortunately only > one with the aspect ration of 16:9. > > I then created various custom resolution modes and added them to desplay > options. I used the following commands: > cvt - to get new mode parameters > xrandr --newmode - to define new resolution mode > xrandr --addmode - to add newly defined resolution mode to deplay drop-down > box > xrandr --output - to apply new, desired resolution to the current display. > > What I can't work out is how to make of my new, custom resolution to be used > by qubes-os as default. > What qubes-os configuration files should I modify and how in order to achieve > that? Do I need to interfere with xen.config? > > If you already have a solution please share. > > Thank you > Paul You don't have to go and change anything major, you can basically just write it into a script, and then make that script execute whenever Qubes boots. This is very powerful, as it puts you into the habits to do other cool things with this, the limitation is the sky, or your imagination. Essentially, just open up a dom0 terminal, write "nano screen-settings.sh" Copy paste, or write, your script in the window. When done, close it with shift+x, which gives you a yes, no, or cancel choice to save, pick Y for yes. Then it'll ask you the name, you already wrote that, so just press enter to confirm the name. Now make the script executeable, do that with sudo chmod +x /path/to/your/script.sh Then you can open Sessions and Startup in System-Tools, or instead just write "xfce4-session-settings" in dom0 to open the GUI window. Go to the "Application Autostart" tab. Click "Add", write a name, whatever you like, and add the location of your script in the command-line. This should essentially execute your script every time you boot up. You can also keybind it, similarly by going to System-Tools, Keyboard, and then the Shortcut tab. For example, it may be nice to have a keyboard to handle screen resolution, etc. for when you plugin a HDMI external monitor, projector, or similar, which annoyingly never memorizes last settings. So having a keybind here is very nice if you run into those situations. This approach doesn't limit you to screen settings, you can do a whole lot of things with this method. -- 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/5b73426f-bf3f-423c-bfed-94a558d1a06c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Re: [qubes-users] Q4rc4 :: qvm-prefs-screenshot-to-clipboard - 1st attempt
On Sunday, February 18, 2018 at 11:32:16 PM UTC+1, awokd wrote: > On Sun, February 18, 2018 10:24 pm, Yuraeitha wrote: > > > hmm, thinking about it, did you try awokd's approach? > > He had but it wasn't working so I was just suggesting trying out a > different command line option for xclip. Could be because it was in a > different session or something, like you're saying. @awokd Most likely yes, I haven't seen a command that can't be run from dom0 yet, it just need a little spanki'... Ahem, love. I haven't yet fully grasped why some commands behave different as they do when from dom0, compared to when same command is executed inside the AppVM. For example the bash example above. But I imagine, grasping this difference, one can probably execute anything from 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/d5e105c6-8007-48c7-9a60-303bdf4c5453%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Q4rc4 :: qvm-prefs-screenshot-to-clipboard - 1st attempt
On Sunday, February 18, 2018 at 11:00:35 PM UTC+1, [799] wrote: > -- > Qubes 4rc3 > Lenovo X230 + Lenovo W540 > > Gesendet von ProtonMail mobile > > > > > Original-Nachricht > An 18. Feb. 2018, 22:25, Yuraeitha wrote: > > On Saturday, February 17, 2018 at 11:11:40 PM UTC+1, [799] wrote: > > Hello, > > > > having the idea of a qvm-screenshot-to-clipboard script I was eager to try > > writting a script. > > The solution I had in mind could work but I am struggling with a small > > issue and would like to get some help. > > The script takes a screenshot in dom0, store it to a file and qvm-copy the > > file to the target appvm (one and only command line argument for the > > script). > > Then within the AppVM it is using xclip to copy the graphic to clipboard > > and removes all temporary files in the AppVM and dom0 > > All pieces are working, except the xclip command when launced from dom0. > > > > When I launch the command within the AppVM it is working. > > But I need to start the xclip command from an external script and when I do > > so, the same command is not working. > > It seems that I am missing something when using xclip via script which is > > run in a new terminal session (from dom0 but also within the App) > > > > Any ideas how to fix this? > > It feels so frustrating that I nearly have a working solution but I am > > missing the last few meters. > > > > How to use the script: > > > > 1) in dom0: launch script > > > > 2) make the screenshot by selection the area > > > > as the xclip is not working in the AppVM as supposed: > > > > 3) switch to the AppVM where the screenshot should be used > > > > 4) launch the "helper script" in the AppVM which is running the following > > command > > > > xclip -selection clipboard -t image/png > > /home/user/QubesIncoming/dom0/qvm-screenshot-to-clipboard.png > > > > My qvm-screenshot-to-clipboard script which has to be placed and run from > > dom0: > > > > --- BEGIN of script --- > > > > > > #!/bin/bash > > # qvm-screenshot-to-clipboard > > # Creates a dom0 screenshot and copy it to the Clipboard of an AppVM > > > > MyAppVM=$1 > > MyScreenshot=qvm-screenshot-to-clipboard.png > > > > # Take screenshot in dom0 by selecting an area and adding border+shadow > > gnome-screenshot --area --include-border --border-effect=shadow > > --file=/tmp/$MyScreenshot > > > > # Copy screenhot to AppVM command line argument / delete existing file > > > > qvm-run $MyAppVM 'rm -f /home/user/QubesIncoming/dom0/$MyScreenshot' > > > > qvm-copy-to-vm $MyAppVM /tmp/$MyScreenshot > > > > ###FIXME begin > > > > # I would like to just invoke the following > > # command via qvm-run in the AppVM > > # but the clipboard is just empty when using > > # this approach. > > # running the same command > > # xclip -selection clipboard -t image/png > > /home/user/QubesIncoming/dom0/qvm-screenshot-to-clipboard.png > > # therof I have put the command into a helper > > # script in my AppVM: > > # qvm-run $MyAppVM /home/user/qvm-screenshot-to-clipboard-appvm.sh > > # the script is working when it is launched from > > # an already opened gnome-terminal window > > # but it will not work when the script is invoked > > # from dom0 via qvm-run or through an own > > # strangely it is also not working when I start > > # the script from within the appvm > > # 'xterm -e > > > If interested, I've recently made a similar > > script that works a little differently. > > [...] > > mv "$(xfce4-screenshooter -fo ls)" ~/Screenshots > > ( sleep 3 ) > > qvm-move-to-vm Base ~/Screenshots/screenshot_* > > [...] > > Your scripts can be used to save all screenshots to a folder in an AppVM > whereas my scripts is mainly for quick copy'n paste. > > I think I'll also change my script to use xfce4-screenshoiter instead of > gnome-screenshot. > Thanks for the hint. > > I have uploaded my script to GitHub, maybe you should do the same or we add > it to the repository so that users can pick the right script for their needs? > > As you mentioned: > Choice is always a good thing. > > [799] btw, I don't mind if you merge some of the code, what I feel is important here is that people have something that just works. Besides a crucial part of this code is something I got elsewhere anyway, I just don't remember where anymore. In short, the mv "$()" part of the script to bypass the "save as" is not my invention, but something I learned elsewhere, where-ever that was in time and space. -- 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/b3a09260-755f-4c3d-b56f-61062ce10a57%40googlegroups.com. For m
Re: Re: [qubes-users] Q4rc4 :: qvm-prefs-screenshot-to-clipboard - 1st attempt
On Sun, February 18, 2018 10:24 pm, Yuraeitha wrote: > hmm, thinking about it, did you try awokd's approach? He had but it wasn't working so I was just suggesting trying out a different command line option for xclip. Could be because it was in a different session or something, like you're saying. -- 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/61986be918df1dab4a84817f42f123ab.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Q4rc4 :: qvm-prefs-screenshot-to-clipboard - 1st attempt
On Sunday, February 18, 2018 at 11:00:35 PM UTC+1, [799] wrote: > -- > Qubes 4rc3 > Lenovo X230 + Lenovo W540 > > Gesendet von ProtonMail mobile > > > > > Original-Nachricht > An 18. Feb. 2018, 22:25, Yuraeitha wrote: > > On Saturday, February 17, 2018 at 11:11:40 PM UTC+1, [799] wrote: > > Hello, > > > > having the idea of a qvm-screenshot-to-clipboard script I was eager to try > > writting a script. > > The solution I had in mind could work but I am struggling with a small > > issue and would like to get some help. > > The script takes a screenshot in dom0, store it to a file and qvm-copy the > > file to the target appvm (one and only command line argument for the > > script). > > Then within the AppVM it is using xclip to copy the graphic to clipboard > > and removes all temporary files in the AppVM and dom0 > > All pieces are working, except the xclip command when launced from dom0. > > > > When I launch the command within the AppVM it is working. > > But I need to start the xclip command from an external script and when I do > > so, the same command is not working. > > It seems that I am missing something when using xclip via script which is > > run in a new terminal session (from dom0 but also within the App) > > > > Any ideas how to fix this? > > It feels so frustrating that I nearly have a working solution but I am > > missing the last few meters. > > > > How to use the script: > > > > 1) in dom0: launch script > > > > 2) make the screenshot by selection the area > > > > as the xclip is not working in the AppVM as supposed: > > > > 3) switch to the AppVM where the screenshot should be used > > > > 4) launch the "helper script" in the AppVM which is running the following > > command > > > > xclip -selection clipboard -t image/png > > /home/user/QubesIncoming/dom0/qvm-screenshot-to-clipboard.png > > > > My qvm-screenshot-to-clipboard script which has to be placed and run from > > dom0: > > > > --- BEGIN of script --- > > > > > > #!/bin/bash > > # qvm-screenshot-to-clipboard > > # Creates a dom0 screenshot and copy it to the Clipboard of an AppVM > > > > MyAppVM=$1 > > MyScreenshot=qvm-screenshot-to-clipboard.png > > > > # Take screenshot in dom0 by selecting an area and adding border+shadow > > gnome-screenshot --area --include-border --border-effect=shadow > > --file=/tmp/$MyScreenshot > > > > # Copy screenhot to AppVM command line argument / delete existing file > > > > qvm-run $MyAppVM 'rm -f /home/user/QubesIncoming/dom0/$MyScreenshot' > > > > qvm-copy-to-vm $MyAppVM /tmp/$MyScreenshot > > > > ###FIXME begin > > > > # I would like to just invoke the following > > # command via qvm-run in the AppVM > > # but the clipboard is just empty when using > > # this approach. > > # running the same command > > # xclip -selection clipboard -t image/png > > /home/user/QubesIncoming/dom0/qvm-screenshot-to-clipboard.png > > # therof I have put the command into a helper > > # script in my AppVM: > > # qvm-run $MyAppVM /home/user/qvm-screenshot-to-clipboard-appvm.sh > > # the script is working when it is launched from > > # an already opened gnome-terminal window > > # but it will not work when the script is invoked > > # from dom0 via qvm-run or through an own > > # strangely it is also not working when I start > > # the script from within the appvm > > # 'xterm -e > > > If interested, I've recently made a similar > > script that works a little differently. > > [...] > > mv "$(xfce4-screenshooter -fo ls)" ~/Screenshots > > ( sleep 3 ) > > qvm-move-to-vm Base ~/Screenshots/screenshot_* > > [...] > > Your scripts can be used to save all screenshots to a folder in an AppVM > whereas my scripts is mainly for quick copy'n paste. > > I think I'll also change my script to use xfce4-screenshoiter instead of > gnome-screenshot. > Thanks for the hint. > > I have uploaded my script to GitHub, maybe you should do the same or we add > it to the repository so that users can pick the right script for their needs? > > As you mentioned: > Choice is always a good thing. > > [799] oh I went away from my pc for a short while while writing a new post, didn't see you had answered meanwhile. But I definitely agree. I'll see if I can get it on github tomorrow. -- 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/c855d4f3-db5d-4223-b605-fc9369b0c5ec%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Re: [qubes-users] Q4rc4 :: qvm-prefs-screenshot-to-clipboard - 1st attempt
On Sunday, February 18, 2018 at 1:11:58 AM UTC+1, [799] wrote: > Hello awokd, > > Original-Nachricht > An 17. Feb. 2018, 23:41, 'awokd' via qubes-users schrieb: > > > Can't really find a man page for xclip. What > > happens when you run this in dom0? > > xclip doesn't have to be present in dom0 as the command is only used in the > AppVM. > As such you might need to install it in your template VM. > > In dom0 you are only using gnome-screenshot to make the screenshot. > If it is not available in dom0 you can install it via qubes-dom0-update > gnome-screenshot or use any other existing sxreenshot-app which is available > in your dom0 and offers the option to safe screenshots directly to file. > > Question regarding security: > As far as I can tell I don't think that the suggested solution to transfer > screenshots to an AppVM offers a great security risk as the data is only > flowing from (!) dom0 to your AppVM and the graphic file is creating in dom0. > But as I am far away from being a security expert, I'd like to hear a more > qualified feedback if working with this script might be a bad idea. > > Regards > > [799] hmm, thinking about it, did you try awokd's approach? I do something very similar for my QubesTV setup that I'm working on polishing, which works on scripts too, like we're doing here. The command may have to be adjusted a bit, but in general, it should work, even without xclip in dom0. Actually, I'd go as far as to say it should most definitely work for xclip, while my scripts here are different, I've done it enough to tell it can work if modified correctly. Either way, try awokd's command out, it will definitely work in one variant or different. The question is if require a bit of modification. For example, maybe use "qvm-run AppVM bash 'command to execute inside AppVM -o etc. lalala'" instead of say, "qvm-run AppVM gnome-terminal -e 'command to execute inside AppVM -o etc. lalala'". For example I've seen a case where one when executed inside the AppVM, will open the executed QubesTV streaming link in the same browser, same tab, while the very same command inserted into the AppVM from dom0, would open up a whole new instance of Firefox, and thereby open a new window. Which, needless to say, doesn't work. The solution was to use bash for already running firefox, so that it won't start a new firefox instance. Hopefully you can use any of this to make qvm-run appvm "command" work. In terms of security, I'm in the same boat, I can't say for sure. But I agree with the notion, that it "probably"? is secure due to the one direction flow of data. -- 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/8bc85072-ac09-4ccc-8915-331ea300a33f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Custom 16:9 dispay resolution to be applied at qubes-os startup (Q4.0rc4)
Hi, Could anyone help me with figuring out how to set one of the custom display resolution as startup default? Qubes 4.0 rc 4 comes with many predefined resolutions but unfortunately only one with the aspect ration of 16:9. I then created various custom resolution modes and added them to desplay options. I used the following commands: cvt - to get new mode parameters xrandr --newmode - to define new resolution mode xrandr --addmode - to add newly defined resolution mode to deplay drop-down box xrandr --output - to apply new, desired resolution to the current display. What I can't work out is how to make of my new, custom resolution to be used by qubes-os as default. What qubes-os configuration files should I modify and how in order to achieve that? Do I need to interfere with xen.config? If you already have a solution please share. Thank you Paul -- 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/L5ezclA--3-0%40tutamail.com. For more options, visit https://groups.google.com/d/optout.
AW: [qubes-users] Re: Q4rc4 :: qvm-prefs-screenshot-to-clipboard - 1st attempt
-- Qubes 4rc3 > Lenovo X230 + Lenovo W540 Gesendet von ProtonMail mobile Original-Nachricht An 18. Feb. 2018, 22:25, Yuraeitha wrote: On Saturday, February 17, 2018 at 11:11:40 PM UTC+1, [799] wrote: > Hello, > > having the idea of a qvm-screenshot-to-clipboard script I was eager to try > writting a script. > The solution I had in mind could work but I am struggling with a small issue > and would like to get some help. > The script takes a screenshot in dom0, store it to a file and qvm-copy the > file to the target appvm (one and only command line argument for the script). > Then within the AppVM it is using xclip to copy the graphic to clipboard and > removes all temporary files in the AppVM and dom0 > All pieces are working, except the xclip command when launced from dom0. > > When I launch the command within the AppVM it is working. > But I need to start the xclip command from an external script and when I do > so, the same command is not working. > It seems that I am missing something when using xclip via script which is run > in a new terminal session (from dom0 but also within the App) > > Any ideas how to fix this? > It feels so frustrating that I nearly have a working solution but I am > missing the last few meters. > > How to use the script: > > 1) in dom0: launch script > > 2) make the screenshot by selection the area > > as the xclip is not working in the AppVM as supposed: > > 3) switch to the AppVM where the screenshot should be used > > 4) launch the "helper script" in the AppVM which is running the following > command > > xclip -selection clipboard -t image/png > /home/user/QubesIncoming/dom0/qvm-screenshot-to-clipboard.png > > My qvm-screenshot-to-clipboard script which has to be placed and run from > dom0: > > --- BEGIN of script --- > > > #!/bin/bash > # qvm-screenshot-to-clipboard > # Creates a dom0 screenshot and copy it to the Clipboard of an AppVM > > MyAppVM=$1 > MyScreenshot=qvm-screenshot-to-clipboard.png > > # Take screenshot in dom0 by selecting an area and adding border+shadow > gnome-screenshot --area --include-border --border-effect=shadow > --file=/tmp/$MyScreenshot > > # Copy screenhot to AppVM command line argument / delete existing file > > qvm-run $MyAppVM 'rm -f /home/user/QubesIncoming/dom0/$MyScreenshot' > > qvm-copy-to-vm $MyAppVM /tmp/$MyScreenshot > > ###FIXME begin > > # I would like to just invoke the following > # command via qvm-run in the AppVM > # but the clipboard is just empty when using > # this approach. > # running the same command > # xclip -selection clipboard -t image/png > /home/user/QubesIncoming/dom0/qvm-screenshot-to-clipboard.png > # therof I have put the command into a helper > # script in my AppVM: > # qvm-run $MyAppVM /home/user/qvm-screenshot-to-clipboard-appvm.sh > # the script is working when it is launched from > # an already opened gnome-terminal window > # but it will not work when the script is invoked > # from dom0 via qvm-run or through an own > # strangely it is also not working when I start > # the script from within the appvm > # 'xterm -e > If interested, I've recently made a similar > script that works a little differently. > [...] > mv "$(xfce4-screenshooter -fo ls)" ~/Screenshots > ( sleep 3 ) > qvm-move-to-vm Base ~/Screenshots/screenshot_* > [...] Your scripts can be used to save all screenshots to a folder in an AppVM whereas my scripts is mainly for quick copy'n paste. I think I'll also change my script to use xfce4-screenshoiter instead of gnome-screenshot. Thanks for the hint. I have uploaded my script to GitHub, maybe you should do the same or we add it to the repository so that users can pick the right script for their needs? As you mentioned: Choice is always a good thing. [799] -- 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/Yekef6OjKPpwPjI-xqxT_nSnXoHRm9BjlG8YaNa36L9YOdGyQwzsiesfsyxieEXbD0zj-R-_GTp2KWoWAHBtxjyukwYjOnGj6ZYOEEy06qc%3D%40protonmail.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Q4rc4 :: qvm-prefs-screenshot-to-clipboard - 1st attempt
On Sunday, February 18, 2018 at 10:25:19 PM UTC+1, Yuraeitha wrote: > On Saturday, February 17, 2018 at 11:11:40 PM UTC+1, [799] wrote: > > Hello, > > > > having the idea of a qvm-screenshot-to-clipboard script I was eager to try > > writting a script. > > The solution I had in mind could work but I am struggling with a small > > issue and would like to get some help. > > The script takes a screenshot in dom0, store it to a file and qvm-copy the > > file to the target appvm (one and only command line argument for the > > script). > > Then within the AppVM it is using xclip to copy the graphic to clipboard > > and removes all temporary files in the AppVM and dom0 > > All pieces are working, except the xclip command when launced from dom0. > > > > When I launch the command within the AppVM it is working. > > But I need to start the xclip command from an external script and when I do > > so, the same command is not working. > > It seems that I am missing something when using xclip via script which is > > run in a new terminal session (from dom0 but also within the App) > > > > Any ideas how to fix this? > > It feels so frustrating that I nearly have a working solution but I am > > missing the last few meters. > > > > How to use the script: > > > > 1) in dom0: launch script > > > > 2) make the screenshot by selection the area > > > > as the xclip is not working in the AppVM as supposed: > > > > 3) switch to the AppVM where the screenshot should be used > > > > 4) launch the "helper script" in the AppVM which is running the following > > command > > > > xclip -selection clipboard -t image/png > > /home/user/QubesIncoming/dom0/qvm-screenshot-to-clipboard.png > > > > My qvm-screenshot-to-clipboard script which has to be placed and run from > > dom0: > > > > --- BEGIN of script --- > > > > > > #!/bin/bash > > # qvm-screenshot-to-clipboard > > # Creates a dom0 screenshot and copy it to the Clipboard of an AppVM > > > > MyAppVM=$1 > > MyScreenshot=qvm-screenshot-to-clipboard.png > > > > # Take screenshot in dom0 by selecting an area and adding border+shadow > > gnome-screenshot --area --include-border --border-effect=shadow > > --file=/tmp/$MyScreenshot > > > > # Copy screenhot to AppVM command line argument / delete existing file > > > > qvm-run $MyAppVM 'rm -f /home/user/QubesIncoming/dom0/$MyScreenshot' > > > > qvm-copy-to-vm $MyAppVM /tmp/$MyScreenshot > > > > ###FIXME begin > > > > # I would like to just invoke the following > > # command via qvm-run in the AppVM > > # but the clipboard is just empty when using > > # this approach. > > # running the same command > > # xclip -selection clipboard -t image/png > > /home/user/QubesIncoming/dom0/qvm-screenshot-to-clipboard.png > > # therof I have put the command into a helper > > # script in my AppVM: > > # qvm-run $MyAppVM /home/user/qvm-screenshot-to-clipboard-appvm.sh > > # the script is working when it is launched from > > # an already opened gnome-terminal window > > # but it will not work when the script is invoked > > # from dom0 via qvm-run or through an own > > # strangely it is also not working when I start > > # the script from within the appvm > > # 'xterm -e > > If interested, I've recently made a similar script that works a little > differently. I'll put it here as having options and choice is a good thing. > > > mv "$(xfce4-screenshooter -fo ls)" ~/Screenshots > ( sleep 3 ) > qvm-move-to-vm Base ~/Screenshots/screenshot_* > > > > > > I know many here don't need an explanation since it's a rather straight > forward simple working script that "just works", but for those who may need > it, here are some considerations to take into account about the script: > > - The mv "$() part of the script serves as a function to remove "save as" and > instead auto-save with the name screenshot_+date+timestamp. > > - Never remove the -o attribute if you want the mv "$() part of the script > working. > > - The first line decides where to save the screenshot, and the third line > pulls the screenshot from this location. By narrowing down an empty folder > specifically this use-case, you avoid false positive transfers, although > those are unlikely in dom0 anyway. > > - By default this scripts sends screenshots to an offline AppVM that I > frequently have running in the background for offline applications and daily > used data. > > - AppVM name used: Base > > - Fullscreen, keep the f attribute. > > - Region, change -fo to -ro > > - Window, change -fo to -wo > > - The screenshot_* part, will move any files or folders beginning with > screenshot_*, at the given address location. If you got older screenshots > there, then they will also be moved. This should not be a big problem though, > if you only use these scripts and keep the folder empty. > > - You can also optionally keybind scripts to different AppVM's, so you don't > have to move them a second time from the standard AppVM. > > - Need longer time
[qubes-users] Re: Q4rc4 :: qvm-prefs-screenshot-to-clipboard - 1st attempt
On Saturday, February 17, 2018 at 11:11:40 PM UTC+1, [799] wrote: > Hello, > > having the idea of a qvm-screenshot-to-clipboard script I was eager to try > writting a script. > The solution I had in mind could work but I am struggling with a small issue > and would like to get some help. > The script takes a screenshot in dom0, store it to a file and qvm-copy the > file to the target appvm (one and only command line argument for the script). > Then within the AppVM it is using xclip to copy the graphic to clipboard and > removes all temporary files in the AppVM and dom0 > All pieces are working, except the xclip command when launced from dom0. > > When I launch the command within the AppVM it is working. > But I need to start the xclip command from an external script and when I do > so, the same command is not working. > It seems that I am missing something when using xclip via script which is run > in a new terminal session (from dom0 but also within the App) > > Any ideas how to fix this? > It feels so frustrating that I nearly have a working solution but I am > missing the last few meters. > > How to use the script: > > 1) in dom0: launch script > > 2) make the screenshot by selection the area > > as the xclip is not working in the AppVM as supposed: > > 3) switch to the AppVM where the screenshot should be used > > 4) launch the "helper script" in the AppVM which is running the following > command > > xclip -selection clipboard -t image/png > /home/user/QubesIncoming/dom0/qvm-screenshot-to-clipboard.png > > My qvm-screenshot-to-clipboard script which has to be placed and run from > dom0: > > --- BEGIN of script --- > > > #!/bin/bash > # qvm-screenshot-to-clipboard > # Creates a dom0 screenshot and copy it to the Clipboard of an AppVM > > MyAppVM=$1 > MyScreenshot=qvm-screenshot-to-clipboard.png > > # Take screenshot in dom0 by selecting an area and adding border+shadow > gnome-screenshot --area --include-border --border-effect=shadow > --file=/tmp/$MyScreenshot > > # Copy screenhot to AppVM command line argument / delete existing file > > qvm-run $MyAppVM 'rm -f /home/user/QubesIncoming/dom0/$MyScreenshot' > > qvm-copy-to-vm $MyAppVM /tmp/$MyScreenshot > > ###FIXME begin > > # I would like to just invoke the following > # command via qvm-run in the AppVM > # but the clipboard is just empty when using > # this approach. > # running the same command > # xclip -selection clipboard -t image/png > /home/user/QubesIncoming/dom0/qvm-screenshot-to-clipboard.png > # therof I have put the command into a helper > # script in my AppVM: > # qvm-run $MyAppVM /home/user/qvm-screenshot-to-clipboard-appvm.sh > # the script is working when it is launched from > # an already opened gnome-terminal window > # but it will not work when the script is invoked > # from dom0 via qvm-run or through an own > # strangely it is also not working when I start > # the script from within the appvm > # 'xterm -e If interested, I've recently made a similar script that works a little differently. I'll put it here as having options and choice is a good thing. mv "$(xfce4-screenshooter -fo ls)" ~/Screenshots ( sleep 3 ) qvm-move-to-vm Base ~/Screenshots/screenshot_* I know many here don't need an explanation since it's a rather straight forward simple working script that "just works", but for those who may need it, here are some considerations to take into account about the script: - The mv "$() part of the script serves as a function to remove "save as" and instead auto-save with the name screenshot_+date+timestamp. - Never remove the -o attribute if you want the mv "$() part of the script working. - The first line decides where to save the screenshot, and the third line pulls the screenshot from this location. By narrowing down an empty folder specifically this use-case, you avoid false positive transfers, although those are unlikely in dom0 anyway. - By default this scripts sends screenshots to an offline AppVM that I frequently have running in the background for offline applications and daily used data. - AppVM name used: Base - Fullscreen, keep the f attribute. - Region, change -fo to -ro - Window, change -fo to -wo - The screenshot_* part, will move any files or folders beginning with screenshot_*, at the given address location. If you got older screenshots there, then they will also be moved. This should not be a big problem though, if you only use these scripts and keep the folder empty. - You can also optionally keybind scripts to different AppVM's, so you don't have to move them a second time from the standard AppVM. - Need longer time, for example to carefully select text in region screenshots, then expand the sleep timer to, say, 20 seconds. - Make scripts executable and put them in dom0 $HOME/ folder. Then simply just keybind them in Qubes Menu --> System-Tools --> Keyboard ---> Shortcut tab. - If dom0 is ever compromised, or the AppVM you backup your sc
[qubes-users] Re: Installing Ubuntu template VM in Qubes 3.2
On Sunday, February 18, 2018 at 7:15:47 PM UTC+1, klausd...@mail2tor.com wrote: > Hey guys, > > I want to create a Ubuntu Template VM in Qubes OS, but i don´t know how to > do this. Can someone help me or someone who aleady did this, can describe > how to do this? > > best regards What are the reasons you want Ubuntu? By any chance is it due to codecs and such licenses? You can quite easily get all of that working in Fedora or Debian. I may have overlooked something, but one of the bigger reasons to want ubuntu, may be codecs and ability to play videos? I'll go ahead and take a guess that it might be partly codec related, though I may be guessing wrong. For example an easy fix to make Fedora play almost any modern video --> clone your fedora template --> Add RPMFusion to your new fedora clone template. Install ffmpeg and vlc from RPMFusion repositories (Qubes has a really easy and quick guide to enable them). Voila, you can now watch HTML5 content videos in firefox on AppVM's based on your fedora template clone. Verify if it works with www.youtube.com/html5 For protected content, such as copyright protection, which can mess up an otherwise working HTML5 video, you'll probably need the google browser either way, directly from googles website. Unfortunately it can be messy to get protected content to play in browsers like Firefox. But that should apply to Ubuntu as well. -- 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/7971f3c5-51af-468a-9f08-607ec29c76c2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Installing Ubuntu template VM in Qubes 3.2
On Sun, Feb 18, 2018 at 08:20:40PM -, 'awokd' via qubes-users wrote: > On Sun, February 18, 2018 7:10 pm, Unman wrote: > > On Sun, Feb 18, 2018 at 06:22:46PM -, 'awokd' via qubes-users wrote: > > >> https://github.com/QubesOS/qubes-issues/issues/3596 is resolved. Seems > >> to be impacting Ubuntu builds as well. > >> > >> > > > > That issue doesnt affect Ubuntu builds, BUT the recent update to 3.2.3 > > HAS broken the builds because of the changes in debian packaging there. > > The changes in Debian packaging also broke Debian builds. Is your point > one of semantics, or is it a different root cause? (Asking for my own > education, not to nitpick.) It's a different root cause. The stretch build completes all the modules but then breaks on the template build. The Ubuntu builds fail on the packaging within the modules. Its almost always the case that major (sometimes minor) changes in Debian builds will break the Ubuntu templates because they arent incorporated in to the testing structure. So we are always playing catch up in those circumstances. -- 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/20180218204311.omebxj2cjkipylmj%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Installing Ubuntu template VM in Qubes 3.2
On Sun, February 18, 2018 7:10 pm, Unman wrote: > On Sun, Feb 18, 2018 at 06:22:46PM -, 'awokd' via qubes-users wrote: >> https://github.com/QubesOS/qubes-issues/issues/3596 is resolved. Seems >> to be impacting Ubuntu builds as well. >> >> > > That issue doesnt affect Ubuntu builds, BUT the recent update to 3.2.3 > HAS broken the builds because of the changes in debian packaging there. The changes in Debian packaging also broke Debian builds. Is your point one of semantics, or is it a different root cause? (Asking for my own education, not to nitpick.) > Im going to fix this. Thank you! -- 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/1d8e5e489772f0bb082aba1f52bd6f0b.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Yubico FIDO U2F Security Key and Qubes
On Sunday, February 18, 2018 at 3:51:00 AM UTC+1, William Bormann wrote: > On a lark, I purchased a Yubico FIDO U2F Security key. It's an inexpensive > USB token that can be used for two-factor authentication for Gmail and > Facebook, among others. I'd like to use it on my Qubes RC4 system. > > I've read the USB documentation, but thought I'd see if somebody else running > Qubes has managed to get this working as advertised on their system. The > current path that seems most promising is to bring up SYS-USB, but I have > some concerns about doing this since my keyboard and mouse are both usb > devices. > > Can anyone reply with a "hand waving" set of steps I should follow? I would > greatly appreciate hearing your solution. I did not yet get around to testing it out for locking down Qubes my self just yet, but there should be quite a lot of people who managed to. Consider that there are at least a good amount of people wanting this, and generally you see people posting about whether to do it or not (like your post), over people who somehow messed it up and are locked out of their system. >From that, I'd deduce that it is probably safe. But you may want to do backup >first, at least of your most important AppVM's, just in case something should >go south. You never know, whatever can go wrong, will eventually go wrong, as >the saying goes. Also for what purposes? LUKS disk decryption? Qubes password login/logout when insert/retracting the Yubi-key? Third-party services in AppVM's? But having said that, I doubt it's a big issue, especially not if you backup first. Also from what I can read, your old password still works, in case the key isn't working anymore, or is lost/stolen. This isn't a measure against cracking, but a measure against people looking over a persons shoulder, or if sitting under a camera, stuff like that where the password can be stolen. Although of course, it can also servee as a means to memorize a crazy long strong password with high entropy, which makes cracking your drive even harder. Whatever the case, you should probably have a means to remember a long random password with strong entropy, in case you loose your hardware key, for example write it on a piece of paper and hide it inside a wall (or something crazy like that). You can alaos backup the hardware key's seed, which is recommended in case you loose the key and need a new key with same 2nd factoring credentials. Essentially, it likely more boils down to how you handle your key, and how you prevent loosing it, or exposing it to potential attackers in the physical world. Just search these google mails, you probably won't find many having issues, and instead find people asking questions before they start using it. -- 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/f73f119e-24ca-4e16-a78d-0128c87ceddb%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] HP 1040 G3 laptop - wireless toggle button doesn't work
Hi, I've installed Qubes-OS 4.0 rc4 on HP 1040 G3 laptop. It seems HP has changed the rules of the game and introduced dedicated driver for the physical wireless toggle button (located above the keyboard, next to the audio on/off button). I actually test installed Windows 10 on the laptop to confirm the new feature. And indeed, without installing "wireless button driver" pressing the button would not cause any effect. The same holds true with Qubes-OS installed on the laptop. Is there any way of forcing this button to work? It works fine on older HP laptop models but they seems to be tightening their hardware architecture even further. My alternative approach for now is to create scrips in sys-net VM to load / unload kernel modules (sudo rmmod iwlmvm / sudo rmmod iwlwifi / sudo modprobe iwlwifi). This does work fine but is not as elegant as pressing dedicated button. Please share your thoughts and suggestions on forcing HP 1040 G3 to behave. Thank you Paul -- 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/L5eSbDB--3-0%40tutamail.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] HP laptop - issue with "pulsating" fan, ramping up and down every 3s
Hi, I've recently bought an HP 1040 G3 laptop to use with Qubes-OS. The latest version has been installed (4.0 rc4) but I have few issues that I'm trying to sort out. One of them is the issue with fan speed. As the qubes OS starts the fan is constantly on, but the speeed seems to insrease ever so slightly every 3s. That creates an "pulsting" effect of the fan noise which, when using the laptop for a longer time, becomes really disturbing. I tried to find solutions online but as of now was unsuccessful. In Power Management settings of quebes there is no reference to fan speed or settings that could influence it. Could anyone advise how to setup and control fan speed with qubes-os? Many thanks -- 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/L5ePVnF--3-0%40tutamail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Installing Ubuntu template VM in Qubes 3.2
On Sun, Feb 18, 2018 at 06:22:46PM -, 'awokd' via qubes-users wrote: > On Sun, February 18, 2018 5:41 pm, klausdiet...@mail2tor.com wrote: > > Hey guys, > > > > > > I want to create a Ubuntu Template VM in Qubes OS, but i don´t know how > > to do this. Can someone help me or someone who aleady did this, can > > describe how to do this? > > https://www.qubes-os.org/doc/templates/ubuntu/ . Also, check > https://www.qubes-os.org/doc/building-archlinux-template/ for a bit more > detailed example, but I suggest waiting until > https://github.com/QubesOS/qubes-issues/issues/3596 is resolved. Seems to > be impacting Ubuntu builds as well. > > That issue doesnt affect Ubuntu builds, BUT the recent update to 3.2.3 HAS broken the builds because of the changes in debian packaging there. Im going to fix this. If you want a Ubuntu template pro tem until the build is fixed, I've put some here: qubes.3isec.org 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/20180218191026.xpuat223s4xfa34b%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Installing Ubuntu template VM in Qubes 3.2
On Sun, February 18, 2018 5:41 pm, klausdiet...@mail2tor.com wrote: > Hey guys, > > > I want to create a Ubuntu Template VM in Qubes OS, but i don´t know how > to do this. Can someone help me or someone who aleady did this, can > describe how to do this? https://www.qubes-os.org/doc/templates/ubuntu/ . Also, check https://www.qubes-os.org/doc/building-archlinux-template/ for a bit more detailed example, but I suggest waiting until https://github.com/QubesOS/qubes-issues/issues/3596 is resolved. Seems to be impacting Ubuntu builds as well. -- 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/d29636a56991446d406644533023b77c.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Installing Ubuntu template VM in Qubes 3.2
Hey guys, I want to create a Ubuntu Template VM in Qubes OS, but i don´t know how to do this. Can someone help me or someone who aleady did this, can describe how to do this? best 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/4bdc82a99d54424df96dbc322a188f75.squirrel%40_. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Install on Dell XPS 13 (9350)
On Sat, February 17, 2018 8:33 pm, ynwa44 via qubes-users wrote: > On Tuesday, February 13, 2018 at 4:31:33 PM UTC+4, awokd wrote: > >> On Tue, February 13, 2018 11:32 am, xxx.l...@gmail.com wrote: >> >>> Thank you for your help awokd, I now have sys-net running in HVM mode >>> on the XPS 9350 wifi card in permissive mode, this resolve the issue >>> on 4.0. >> >> Glad it worked out! But consider getting a different wifi card some day >> that doesn't need permissive mode, it's not the best from a security >> perspective. :) > > Can you please help with connecting to wifi for the first time? Sure, but more details would be helpful. If you have the same model laptop and wireless card and need to enable permissive mode, check up thread for documentation on how to do that. -- 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/2518d9cbd073721d42d1b85f502768eb.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Bitmessage Shortcut in Whonix APP VM
Hey, i want to know how to set a shortcut in the whonix App VM. I installed Bitmessage in Whonix WS Template and used this to create a shortcut: https://qubes-os.org/doc/managing-appvm-shortcuts/ But it didn´t work this way. Any Ideas? -- 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/476d42ba05c181007d0673d152558971.squirrel%40_. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: QUBES 4 r4 - dom0 UTC time is incorrect - manual change each reboot.
On Thursday, February 15, 2018 at 5:42:44 PM UTC-5, schnuren...@gmail.com wrote: > On Tuesday, February 13, 2018 at 10:51:12 PM UTC+1, QUBE-A-LICIOUS wrote: > > Hi there, > > > > I have a fresh install of Qubes 4r4. However, when I reboot and or login I > > have to manually change dom0 time to UTC. > > > > Impact: Whonix/Tor does not work because of the incorrect time. > > > > Manual workaround: > > 1. Get the correct UTC from a browser. > > 2. Open Dom0 Terminal and update to UTC such as the following: > > > > sudo date --set "2018-02-13 21:30" > > > > 3. Shutdown Service:sys-whonix > > 4. Restart a whonix domain such as Domain:anon-whonix(this restarts the > > sys-whonix service that was just shutdown. > > 5. Then run WhonixCheck to make sure it works. It usually does and > > Whonix/Tor is functional. > > > > = > > Qubes cannot be this bad, really. > > > > How can I have this Date and time correctly updated on boot up? Like it > > should. > > > > Thanks for all your help. > > NSJ > > Most times it is easy to point on another guilty one instead looking what may > happen with the own stuff. So far you are the only one with this misbehavior. > Qubes works as expected - at least in this point. > But most user already experienced this behavior; qubes-os or any other > distribution. > The keyword is hwclock. You always update the software-based time, but if you > restart, all temporary data is gone. (should) > So your OS fetches at boot the time from the bios. > If you update your time within the qubes-os, you should update your hardware > clock (hc) as well: sudo hwclock --systohc > If your time resets when you unplug your device from power supply, your > device's battery is flat. -- I did some analysis this morning. So at the same point in time the following settings on my Qubes laptop showed the following values. (Bottom line is that whonix/tor does not work) 1. The hardware BIOS clock is: 1030 (BIOS battery good, removed laptop battery for few hours and date/time stayed same) 2. Dom0 time is: 0530 ( via date command) 3. service:sys-whonix is: 1030 (via date command) 4. Clock on upper right of screen is: 0430 Tor Boostrap info is: Whonixcheck gave up waiting clock skew -21635 in directory from DIRSERV sudo date --set “2018 -02-18 17:30:00” - I think that on a normal bootup the clocks should be in sync and Whonix/Tor should 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/b675243c-a3b6-4d39-9742-b26040fd90b8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: R4.0 rc4 sys-whonix. Tor running as root and shouldn't be?
On Sun, Feb 18, 2018 at 07:25:55AM -0800, msgh...@gmail.com wrote: > On Sunday, February 18, 2018 at 9:29:26 PM UTC+7, sebuq wrote: > > The command sudo tor --verify-config produces an output You are running > > Tor as root. You don't need to, and you probably shouldn't (full output > > below). > > > > How is this rectified? > > > > > > user@host:~$ sudo tor --verify-config > > Feb 18 14:21:23.474 [notice] Tor 0.3.2.9 (git-64a719dd25a21acb) running > > on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1t, Zlib 1.2.8, > > Liblzma 5.1.0alpha, and Libzstd N/A. > > Feb 18 14:21:23.474 [notice] Tor can't help you if you use it wrong! > > Learn how to be safe at https://www.torproject.org/download/download#warning > > Feb 18 14:21:23.474 [notice] Read configuration file "/etc/tor/torrc". > > Feb 18 14:21:23.477 [warn] You are running Tor as root. You don't need > > to, and you probably shouldn't. > > Run it as user without sudo as warning suggests: > user@host:~$ tor --verify-config > sudo allows you to execute a command as superuser, or another user. In Qubes, it's use is unfettered, although you can change this if you wish. This is in the FAQ, and also here: https://www.qubes-os.org/doc/vm-sudo By calling "sudo tor" you invoke tor as root, which is not recommended. As msgheap says, dont use sudo here. If you check with ps, you'll see that tor isnt running as root in normal operation. -- 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/20180218165113.vxfl45e7qr6cdpwb%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] cannot build ubuntu template
On Sat, Feb 17, 2018 at 07:54:17AM -0800, snowboard...@gmail.com wrote: > running qubes 3.2 > > I am following default instructions from Archlinux.Tried to build template > for trusty. > > I cloned the default repo. > > there is a problem with python2 because in fedora 23 there is no such > package. I had to manually edit and put python-sh in Makefile, builder.conf > and setup script. After that everything seems to be working fine but it > crashes during make qubes-vm with this message: > > ln -s ../../bin/qrexec-client-vm > /home/user/qubes-src/core-agent-linux/debian/tmp/usr/lib/qubes/qrexec_client_vm > install qrexec-fork-server > /home/user/qubes-src/core-agent-linux/debian/tmp/usr/bin > install qubes-rpc-multiplexer > /home/user/qubes-src/core-agent-linux/debian/tmp/usr/lib/qubes > make[2]: Leaving directory `/home/user/qubes-src/core-agent-linux/qrexec' > make[1]: Leaving directory `/home/user/qubes-src/core-agent-linux' >dh_install > cp: cannot stat > 'debian/tmp/lib/systemd/system/netfilter-persistent.service.d/30_qubes.conf': > No such file or directory > dh_install: cp -a > debian/tmp/lib/systemd/system/netfilter-persistent.service.d/30_qubes.conf > debian/qubes-core-agent//lib/systemd/system/netfilter-persistent.service.d/ > returned exit code 1 > make: *** [binary] Error 2 > dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status > 2 > /home/user/qubes-builder/qubes-src/builder-debian/Makefile.qubuntu:200: > recipe for target 'dist-package' failed > make[2]: *** [dist-package] Error 2 > Makefile.generic:156: recipe for target 'packages' failed > make[1]: *** [packages] Error 1 > Makefile:212: recipe for target 'core-agent-linux-vm' failed > > > Why is it so difficult to build a default template? Should be working oob > right? > It should indeed work oob. Truth is that I only really support 1 LTS and the latest Ubuntu version. I havent built Trusty for some time, and it's difficult to keep it up to date with the changing code base.The right thing to do would be to take it out the build configs. If there's some specific reason that you need trusty, and you cant install as HVM, I'll take a quick look and see if the build issues can be fixed. It may be simple. Can you let me know? -- 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/20180218163858.zneywsadxvgi3fbf%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: qubes network
On Sun, Feb 18, 2018 at 02:58:34PM +, Mr SpOn wrote: > thanks Andrew for the quick response. > > when trying to create a new VM > im getting this error: could not find capabilities for arch=x86_64. > > those this means my laptop doesn't support this feature? > > thanks > J > Do you have VT-x enabled in BIOS? That would be the usual cause. -- 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/20180218163236.dj2bzjb7wiptpn6k%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: R4.0 rc4 sys-whonix. Tor running as root and shouldn't be?
On Sunday, February 18, 2018 at 9:29:26 PM UTC+7, sebuq wrote: > The command sudo tor --verify-config produces an output You are running > Tor as root. You don't need to, and you probably shouldn't (full output > below). > > How is this rectified? > > > user@host:~$ sudo tor --verify-config > Feb 18 14:21:23.474 [notice] Tor 0.3.2.9 (git-64a719dd25a21acb) running > on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1t, Zlib 1.2.8, > Liblzma 5.1.0alpha, and Libzstd N/A. > Feb 18 14:21:23.474 [notice] Tor can't help you if you use it wrong! > Learn how to be safe at https://www.torproject.org/download/download#warning > Feb 18 14:21:23.474 [notice] Read configuration file "/etc/tor/torrc". > Feb 18 14:21:23.477 [warn] You are running Tor as root. You don't need > to, and you probably shouldn't. Run it as user without sudo as warning suggests: user@host:~$ tor --verify-config -- 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/28471444-f7af-4359-9789-636433bd20d6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Installing Win7 on a Dell
On Saturday, February 17, 2018 at 9:06:03 PM UTC-5, Glen H wrote: > Hi, > > I'm a new user and am trying to get Win7 Pro x64 installed in Qubes 4rc4. I > have a Dell e7440 and it doesn't come with a Windows .iso. Before I > installed Qubes I used the Dell recovery tool to create a recovery usb disk > for Win7 to re-install the OS but I'm not sure if this is usable to install > with Qubes. > > I tried following the instructions on the Qubes website by creating a new > Qube without a template but I could not change it from PVM to HVM. Then when > I tried booting from the USB recovery disk it would load up a terminal and > then exit after 10 seconds. > > When I try to boot the recovery USB disk from the main BIOS it boots up fine. > Does anyone have any tips for installing Win7 in Qubes 4? > > Thanks, > > Glen Hi, Check out these two issues: Installing Windows 7: https://github.com/QubesOS/qubes-issues/issues/3592 Installing Qubes Windows Tools: https://github.com/QubesOS/qubes-issues/issues/3585 The two problems you describe in the post seem to be the following: 1. Use qvm-prefs to set the virt_mode to hvm; the GUI doesn't work. 2. Make sure you set the video-model to cirrus for install. Best, Daniel -- 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/d9826928-1733-4ac4-ac8a-fdb6ab5fe490%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: qubes network
thanks Andrew for the quick response. when trying to create a new VM im getting this error: could not find capabilities for arch=x86_64. those this means my laptop doesn't support this feature? thanks J Sent from my iPhone > On Feb 17, 2018, at 8:08 PM, Andrew David Wong wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > >> On 2018-02-17 04:44, Mr SpOn wrote: >> hi how are you i just install your OS and it was great, very easy. >> very happy :) >> > > I'm glad to hear that. :) > >> is there any documentation about the recomend setups needed the >> first time you install qubes os? for now ive only done an update. >> > > Take a look at the Getting Started page: > > https://www.qubes-os.org/getting-started/ > > And our documentation in general: > > https://www.qubes-os.org/doc/ > >> is my laptop supposed to be connected to the internet all the >> time? > > It can be, if you want, but it's not required. > >> and every time i want to use firefox i should assign to "personal >> vm" network access? (under settings) for the period of time i want >> to used it? (this is just an example). >> > > For general web browsing, most people just have a dedicated VM (e.g., > the "untrusted" VM) that always has the same NetVM setting. > >> thanks J >> >> Sent from my iPhone >> > > P.S. - Please keep the qube-users mailing list CCed and direct future > queries there. You can read more about our mailing lists here: > > https://www.qubes-os.org/mailing-lists/ > > - -- > Andrew David Wong (Axon) > Community Manager, Qubes OS > https://www.qubes-os.org > > -BEGIN PGP SIGNATURE- > > iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlqIxAMACgkQ203TvDlQ > MDC3MRAAzWF8DU1pPPDAc3bWDP2tP0FpxxGSYuLL0CTHZ5p2iQPgzRCmlncr7jX3 > koI+CORgnEUEtCIsX7hhfnSUPseZESPFWAm2oIwZgFu+pKB7LYxyNL2g8JdUKOQB > KgrOXFl/CSX8QRKQYh2jRvYkXVPAbUrnOK6gwNArBqR4vWU+E8riXodIrvDU2B/i > yoY9hHt48rzVE9iD7nf7E78yUimhfbIc+mkFBOgzLOTcLAHgmRHvH91PBqD9ziwq > p5PvNiG31KRigTe215aJiFkPy/ra/RCiJj9KA3qFZb1OEesSq8J9Io4f9nqXLu+L > IuL2w/3VinAODwIb95Ub1EwyzLmm4smXHpoHwCKM6Tu/utkJlvIMRR7QDCnTeILF > C8Vrr6vxjqnZ0tSeWJ2HP1p0HzDNrd2CbuT/vxqwsQytl9R7QdM6kVngGf8ANltK > 857oYkDG+SiUQCiluB44aLAAlA08O4tDzyLSLGiXXVxN0MP3887+7HLFR2tXVaby > DYv7+zFZoRHKInQZuzpf6j1vA0xN7HUyi/Z7z0tlXEwT1p/yv1PrAh6vwqbiz3rh > ZTxZYCEtQjW+sCyO3ppdXJXKDAH27c0I4nOcdCBpBgQTOsVwqYsFGk+oMeuF4w+F > 5vvSeGiRhiRvoHtCdB/VbcGkvi+Bpw0zwl8JkIb4bMwluds32Cc= > =MbVl > -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/DM5PR03MB263303F333C0C9E5B33C90FEA8C90%40DM5PR03MB2633.namprd03.prod.outlook.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] R4.0 rc4 sys-whonix. Tor running as root and shouldn't be?
The command sudo tor --verify-config produces an output You are running Tor as root. You don't need to, and you probably shouldn't (full output below). How is this rectified? user@host:~$ sudo tor --verify-config Feb 18 14:21:23.474 [notice] Tor 0.3.2.9 (git-64a719dd25a21acb) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1t, Zlib 1.2.8, Liblzma 5.1.0alpha, and Libzstd N/A. Feb 18 14:21:23.474 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning Feb 18 14:21:23.474 [notice] Read configuration file "/etc/tor/torrc". Feb 18 14:21:23.477 [warn] You are running Tor as root. You don't need to, and you probably shouldn't. -- 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/9abbf6d8-cb7b-b38e-f343-0564c335ccf9%40dasamy.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Qubes 4.0 - there will be rc5
Thought so. Wise decision IMO -- 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/863e74a1-4ef2-42b5-9835-e9227b9b98c1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] HCL - ASRock Z370 Pro4, i5-8600K
Hi, I have recently installed Qubes 4 rc4 on 8th gen intel CPU. HCL details attached to this e-mail. Note: There was an issue with graphic adapter. More details here: https://groups.google.com/forum/#!msg/qubes-users/YjNkEM1srSk/ljMSWgNTBAAJ Other than that everything works very nice. Kind regards, Krisjanis -- 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/CA%2BbLPogPufk7veLDtF73DBOSDu8n%2B3QPEB81-25TmHywO9HARQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout. Qubes-HCL-ASRock-Z370_Pro4-20180218-113044.yml Description: application/yaml Qubes-HCL-ASRock-Z370_Pro4-20180218-113044.cpio.gz Description: GNU Zip compressed data
[qubes-users] Start VMs on boot before user login (Qubes OS 4.0rc4)
Hello, Is it possible to start all VMs marked as "Start qube automatically on boot" on Qubes OS boot and not on user login in Qubes OS? Is it possible to do it without Qubes OS autologin? I want to have a working server application on VM on Qubes OS boot without the need to login in Qubes OS. -- 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/aac46c65-faa0-474e-9c8f-91dbfed35749%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.